General

Rate Limiting

The API enforces rate limits per API token, per endpoint, per time window. Each endpoint lists its own quota in its description in the Reference.

RateLimit header

Every response includes a single RateLimit header in IETF draft-8 format:

RateLimit: limit=5, remaining=4, reset=58
FieldMeaning
limitTotal requests allowed in the window
remainingRequests left in the current window
resetSeconds until the window resets

Exceeding the limit

When a request is rejected the API returns 429 Too Many Requests. The RateLimit header is still present and will show remaining=0:

HTTP/1.1 429 Too Many Requests
RateLimit: limit=5, remaining=0, reset=43

Wait reset seconds before retrying.

Recommendations

Check remaining before sending bursts. When you receive a 429, wait exactly reset seconds before retrying. Implement exponential backoff on top of this for additional robustness.

  • Read remaining proactively and slow down before it reaches zero
  • On 429: wait reset seconds, then retry
  • Layer exponential backoff on top for robustness against transient issues
  • Cache responses where appropriate to reduce the total number of requests

Creation quota

Object creation endpoints share a per-user creation quota that is separate from the per-endpoint request rate limit.

If you want to bulk import objects, we recommend to use the bulk import feature in the app instead.

Hard limit5,000 objects
Auto-increase+100 objects per month once the hard limit is reached

When the creation quota is exhausted the API returns 403 with the error code objectCreationQuotaReached.

Are you missing something in the documentation?

Create a ticket on our feedback board. - Let us know if you have an idea for a feature, improvement or think there is something missing.

Request additions to the documentation. - If your questions are not getting answered, let us know and we will extend the documentation.