Rate Limiting

For authenticated requests, you can make up to 1,000 requests per hour and 10,000 per day by default. This limit is enforced by authorized application as well as by IP address. The algorithm is implemented as a leaky bucket, so there is no fixed reset time. If you exceed the maximum number of requests within the time period, you will receive a 429 Too Many Requests response from the API call.

warning

Do not perform concurrent requests by application or IP to the UltraCart system, or you will also receive a 429 Too Many Requests response.

Requesting a higher limit

Increases are granted case by case, after a review of your integration. Expect a recommendation to spread the workload across 24 hours, to update objects only when something changed, and to cache responses locally and refresh that cache from webhook notifications rather than polling. Most requests are resolved by one of those changes instead of a larger quota.

Email support@ultracart.com with these four answers.

Which application. Limits are enforced per authorized application and per IP address, so name the one being limited and the address its calls originate from. OAuth applications are registered under Developer Applications and carry a client ID, covered in the OAuth 2.0 Guide. Simple key applications are covered in Authentication. The X-UltraCart-Request-Id header returned by a throttled call identifies that call in the application logs, so include one if you have it.

Which endpoints, and how often. Name the endpoints that need the higher limit and describe the shape of the traffic: steady polling, a nightly batch, a one-time backfill, or bursts that track order volume. An hourly breach and a daily breach have different answers.

Whether the BigQuery Data Warehouse SDK fits. Bulk reads over history do not belong on the REST API. The warehouse answers them in a single query and the REST rate limits do not apply, which covers backfills, nightly exports, and reporting pipelines. It is read-only and lags live data by one to two minutes, so it does not replace reads that have to be current.

Whether webhooks replace the polling. If the traffic is a loop asking whether something changed, a webhook removes it. Subscribe to the event, cache what arrives, and stop asking.

Abuse rate limits

To protect the quality of service from UltraCart, additional rate limits may apply to some actions. For example, rapidly creating content, polling aggressively instead of using webhooks, making API calls with concurrency, or repeatedly requesting data that is computationally expensive may result in abuse rate limiting.

It is not intended for this rate limit to interfere with any legitimate use of the API. Your normal rate limits should be the only limit you target. Please contact UltraCart Support if your use is affected by this rate limit.