Errors and Limits

Your integration must handle API errors and rate limits without creating duplicate requests or unnecessary load.

Public APIs and Native NDIS APIs have different behaviours:

• Public APIs primarily retrieve data stored in quickclaim.
• Native APIs send requests directly to the live NDIS environment.
• Native API limits are based on the NDIS service being called.

Public API limits

Public API limits and endpoint-specific behaviour are maintained in the quickclaim Public API documentation.

Because many Public endpoints return stored quickclaim data, repeatedly calling an endpoint does not make the underlying NDIS data refresh faster.

Design your integration to:

• Request only the data you need
• Use available filters
• Avoid unnecessary polling
• Cache responses where appropriate
• Respect any rate-limit response returned by quickclaim

Native API limits

The following limits apply to the listed Native NDIS services.

Service	Version	Rate limit
Non-PACE Budget	4.0	200 calls per hour
Participant Plan Type	4.0	5,000 calls per hour
Interactions	3.0	5,000 calls per hour and 20 calls per second
Notifications	3.0	5,000 calls per hour and 20 calls per second
PACE Budget	5.0	5,000 calls per hour
Payments	4.0	5,000 calls per hour and 20 calls per second
PACE Historical	4.0	5,000 calls per hour
Plans	4.0	5,000 calls per hour and 20 calls per second
Quotations	3.0	100 calls per hour
Products	3.0	5,000 calls per hour and 20 calls per second
Reference Data	3.0	5,000 calls per hour and 20 calls per second
Service Bookings	4.0	5,000 calls per hour and 20 calls per second

Rate limits may be changed by the NDIA. Confirm the applicable limit with quickclaim before implementing a high-volume or scheduled process.

Contact quickclaim if you require the rate limit for an API that is not listed.

Common HTTP errors

Status	Meaning	Recommended action
400 Bad Request	The request is invalid or was rejected by the downstream service	Review the response message and correct the request before retrying
401 Unauthorized	Authentication is missing or invalid	Check the base URL and authentication format for quickclaim v1 or v2
403 Forbidden	The organisation, provider or participant authority is insufficient	Confirm NDIS connection, provider access and participant authority
404 Not Found	The URL, version, endpoint or requested resource was not found	Check the base URL, API version and endpoint path
422 Unprocessable Entity	The request failed a validation rule	Correct the invalid fields before resubmitting
429 Too Many Requests	A rate limit has been exceeded	Wait before retrying and reduce the request rate
500 Internal Server Error	The request failed unexpectedly	Record the response and retry only when safe
502–504	A dependent service is unavailable or timed out	Use a limited retry process with increasing delays

Always review the response body. It may contain more specific information than the HTTP status alone.

Authentication errors

Authentication differs between Native API versions.

quickclaim v1

Use:

org-id: YOUR_ORGANISATION_ID x-api-key: YOUR_API_KEY

quickclaim v2

Use:

org-id: YOUR_ORGANISATION_ID Authorization: x-api-key YOUR_SECRET

A 401 response commonly means that:

• Credentials are missing or incorrect
• The v1 authentication format was used with a v2 URL
• The v2 authentication format was used with a v1 URL
• Stage credentials were used in production
• The API secret is no longer valid

Handling rate limits

When you receive a 429 response:

1. Stop sending new requests to the affected service.
2. Follow the Retry-After header if it is provided.
3. Otherwise, retry using exponential backoff with random jitter.
4. Reduce concurrency and request frequency.
5. Avoid retrying every failed request at the same time.
6. Contact quickclaim if the limit continues to block the required workload.

Do not repeatedly retry a request without a delay.

Safe retry behaviour

Read-only requests

Read-only requests can usually be retried after temporary 429 or 5xx responses.

Use:

• A limited number of attempts
• Exponential backoff
• Random jitter
• A maximum retry delay
• Logging for every failed attempt

Claims and data-changing requests

Do not automatically retry a claim or another data-changing request unless you have confirmed that the original request was not processed.

A timeout or server error does not always mean the NDIS rejected the operation. Retrying without checking may create a duplicate request.

Before retrying:

1. Retain the original request reference.
2. Check whether the operation already exists.
3. Review the response and available transaction history.
4. Retry only after confirming the original request was not processed.

NDIS claim responses

A successful HTTP response does not necessarily mean that an NDIS claim has been accepted.

Your integration must also review:

• Claim status
• Payment Request Number
• Rejection code
• Rejection description
• Any warning or validation messages

See NDIS Rejection Codes for more information.

What should I log?

Record enough information to investigate a failure:

• Date and time
• Environment
• quickclaim version
• API service and version
• Endpoint and HTTP method
• HTTP status
• Response message
• Request or correlation identifier
• Claim or batch reference, where applicable
• Retry count

Do not log API keys, secrets or unnecessary participant information.

Contacting support

When contacting support@quickclaim.io, include:

• Your organisation ID
• quickclaim version
• API service and version
• Endpoint and HTTP method
• Date and time of the request
• HTTP status and response message
• Request or correlation identifier
• Whether the request was retried

Never include your API key or secret.