Rate limits

Ocamba’s APIs apply rate limits on the number of requests to ensure a stable and reliable service for all clients. Please consult our API reference section to learn rate limits for each endpoint. 

All API endpoints for rate limits are on a per-account basis and use a fixed-time-window rate limiting algorithm with two windows: a 1-second window and a 1-minute window.

All API traffic is subject to these rate limits and will receive an HTTP 429 status code (Too many requests) if a rate limit is reached.

All API endpoints use one of the following rate limits.

All responses that haven’t hit the limit will contain the HTTP response headers that indicate how much of your allowed request limit has been used and how much is left during that time window.

Make sure to use these headers to control your request rate, particularly if you’re operating a 3rd-party app that sends requests on behalf of Ocamba customers.

Response headers

• X-RateLimit-Limit: The total number of requests permitted within a current time window.

• X-RateLimit-Remaining: The estimated number of requests you can still make during the current time window.

• X-RateLimit-Reset: The number of seconds left until the rate limit window refreshes.

When you receive HTTP 429 status code, X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers are not returned. In most cases, the original headers are replaced by a Retry-After header, which provides an integer value representing how many seconds you must wait before sending new requests. However, if the Retry-After header has a value of -1, it indicates a parallel request limit has been exceeded.

What does Retry-After: -1 mean?

The value -1 signifies that your client has hit the parallel concurrency limit (i.e., the number of simultaneous requests allowed has been exceeded).

In this scenario, we cannot provide a reliable retry time because the retry window depends on when one of your in-flight requests completes.

Unlike rate limiting based on a fixed time window, parallel limits are dynamic and depend on current usage.

Query param rate limits

If you request any subresource (additional) fields on a parent resource through the fields query parameter, you will have a stricter (lower) rate limit.

In the following examples campaigns is a parent resource while creator and account are subresources.

Examples

If you're making an HTTP GET request to /v2/adex/campaigns?fields=id,company_id,creator_id,creatoryour requests will be at a lower rate limit than if you had not requested additional information. Similarly, a GET request to /v2/adex/campaigns?fields=id,company_id,account_id,account will result in a lower rate limit than a call to /v2/adex/campaigns?fields=id,company_id without specifying *account* as an additional field.

Note that each call may consume rate limits from multiple endpoints when subresources are requested. For example, let's assume we have 150 calls per minute on /v2/adex/campaigns, 50 calls per minute on /v2/ocamba/accounts, and 50 calls per minute on /v2/ocamba/members. When subresources like account or creator are included using the fields query parameter, rate limits are deducted from the parent endpoint (/campaigns).

This means that although you’re making a single request to /campaigns, the API internally performs additional lookups (e.g., for account or creator), each of which counts against that specific subresource’s rate limit.

GET /v2/adex/campaigns?fields=id,account_id,account and GET /v2/adex/campaigns?fields=id,account_id,account,creator_id,creator are still counted only against the /v2/adex/campaigns endpoint.

Even if subresources like account and creator are included via the fields parameter, the rate limit for those additional resources is not affected. Instead, each of those calls counts as multiple calls against the /campaigns endpoint itself.

For example, the last request would count as 3 calls on /campaigns, leaving you with 147 calls remaining out of 150 — while /accounts and /members limits stay untouched.

The rate limits on all of these calls reset at the same window. Similar rules apply for burst limits.