quickclaim provides two ways for organisations to integrate with the National Disability Insurance Scheme (NDIS) APIs. Both options ultimately interact with the same NDIS data and services but differ in how that interaction is managed.
In this blog, we’re going to explore the difference between the two, to support you in making the best decision for you and your business. Let’s take a look.
1. Native APIs
The Native APIs are a direct mirror of the official APIs provided by the National Disability Insurance Agency (NDIA). quickclaim exposes these APIs through a different base URL but otherwise preserves the same request structures, authentication model, and behaviour.
This means that developers interact with the APIs exactly as documented by the NDIA. For example, retrieving participant budgets requires the same parameters (participant number, surname, date of birth and plan ID) and authentication token used by the NDIA APIs.
Using the Native APIs gives organisations full control over their integration and ensures that the behaviour and structure of the API calls remain consistent with the NDIA documentation.
However, this approach requires developers to manage authentication tokens, handle rate limits, orchestrate multiple API calls to retrieve related information, and build their own data storage if they wish to retain historical information.
Native APIs are typically preferred by organisations that:
- Want full control of the integration
- Already have infrastructure built around the NDIA APIs
- Require behaviour identical to the official NDIA interface
- Prefer to manage data storage and processing themselves.
2. Public APIs
The Public APIs are proprietary APIs developed by quickclaim to simplify integration with the NDIS ecosystem.
Instead of exposing the NDIA APIs exactly as they are, quickclaim provides a simplified interface that combines multiple underlying Native API calls into a single request. These APIs also manage authentication internally and provide a simpler access model using an orgId and API key, eliminating the need for OAuth token generation and refresh logic.
Another key feature of the Public APIs is that quickclaim stores relevant NDIS data on its own infrastructure. This allows the APIs to return information quickly without repeatedly calling the NDIA endpoints, reducing rate-limit issues and improving performance.
Because quickclaim aggregates and stores data from multiple NDIS APIs, the Public APIs can also return richer datasets in a single call. For example, information that would normally require multiple requests (plans, budgets, bookings, etc.) can be retrieved through a single endpoint.
Public APIs are typically preferred by organisations that:
- Want a faster or simpler integration
- Prefer not to manage NDIA token authentication
- Want to avoid NDIA API rate-limit constraints
- Want consolidated datasets without orchestrating multiple API calls
- Prefer quickclaim to manage the complexity of the NDIA APIs.
| Category | Native APIs | Public APIs |
|---|---|---|
| Purpose | Direct mirror of NDIA APIs | Simplified APIs built by quickclaim |
| Compatibility | Identical to NDIA API documentation | Abstracted interface designed for ease of use |
| Authentication | NDIA OAuth token generation and refresh required | Simple API key authentication (orgId + X-API Key) |
| API Calls Required | Often multiple calls required to retrieve related data | Multiple NDIA calls combined into a single endpoint |
| Rate Limits | Subject to NDIA API rate limits | Reduced impact due to quickclaim caching and aggregation |
| Data Storage | No storage — data retrieved directly from NDIA | Data stored by quickclaim for faster retrieval |
| Performance | Dependent on NDIA API response times | Typically faster due to cached datasets |
| Complexity of Integration | Higher – developers must manage tokens, orchestration, and error handling | Lower – simplified endpoints and authentication |
| Control and Flexibility | Maximum control, identical to NDIA behaviour | Abstracted layer managed by quickclaim |
| Best For | Organisations already integrated with NDIA APIs or requiring full control | Organisations seeking a faster, simpler integration with minimal development overhead |
Strategic takeaway
The differences between the two are many, but in the end, you can decide which suits you best on the following, as indicated above:
- Native APIs are best for organisations already integrated with NDIA APIs or requiring full control
- Public APIs are best for organisations seeking a faster, simpler integration with minimal development overhead.
