Skip to main content

​
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.
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 ahead of enforcement — see If this changes below.

​
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 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.
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 as every other error on this API, not a one-off shape.
  • The change would show up on the 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.