> ## Documentation Index
> Fetch the complete documentation index at: https://integration.delogue.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> Current rate-limiting behavior for the Delogue API and fair-use guidance for integrators.

## No enforced rate limiting today

The Delogue API does not enforce request-rate limits, quotas, or concurrency caps. There is no
`429 Too Many Requests` response, no `Retry-After` header, and no `X-RateLimit-*` response
headers — every authenticated request is served regardless of how many requests came before it.

<Note>
  This is the current behavior, not a permanent guarantee. If enforced limits are introduced,
  they'll be announced on this page and on the [Changelog](/concepts/changelog) ahead of
  enforcement — see [If this changes](#if-this-changes) below.
</Note>

## Fair-use guidance

Because there's no enforced ceiling, well-behaved integrations self-regulate:

* **Avoid tight polling loops.** Poll on a sensible interval (minutes, not seconds) rather than
  as fast as the client can loop.
* **Use [pagination](/concepts/pagination)** instead of requesting unbounded result sets, and
  stop paging once `pagination.hasMore` is `false` instead of guessing a page count.
* **Batch writes** with the bulk create/update endpoints where one exists, instead of one request
  per record.
* **Cache reference data** that changes rarely (seasons, groups, colors, categories) instead of
  re-fetching it on every operation.
* **Handle transient failures with backoff** regardless of rate limiting — network errors and
  `5xx` responses can still happen; see [Errors & responses](/concepts/errors).

Traffic that looks automated but ignores these guidelines (very high request rates, repeated
identical requests, ignoring `hasMore: false`) is the kind of pattern a future limit would target
first.

## If this changes

Rate limiting is on the API team's list of best practices still to be formalized — it isn't built
today. If it is introduced:

* Any `429` response would use the same [response envelope](/concepts/errors) as every other
  error on this API, not a one-off shape.
* The change would show up on the [Changelog](/concepts/changelog) as an entry before or
  alongside enforcement, not silently.

Until then, treat the absence of a documented limit as "unbounded but not unconditional" — build
the fair-use habits above in from the start so adopting a future limit is a non-event.