Rate limits

Requests are rate-limited per service account. The limits are generous enough for continuous delta polling — they exist to protect the platform from runaway clients, not to meter normal integration traffic.

The contract

When you exceed your limit, the API answers:

• Status 429
• Problem type https://api.secutec.com/errors/rate-limit/exceeded
• A Retry-After header stating, in seconds, when to try again

{
  "type": "https://api.secutec.com/errors/rate-limit/exceeded",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "Rate limit exceeded."
}

Client guidance

• Honour Retry-After. Wait at least that long before retrying; do not hammer the endpoint on a fixed short interval while it answers 429.
• Back off on repeated 429s — exponential backoff with jitter is the safe default for any automated client.
• Prefer fewer, larger pages. limit=500 with the delta cursor moves the same data in a fifth of the requests of the default page size — see Pagination & deltas.
• A 429 is never a data error: nothing was consumed or lost, and the same request succeeds once the window clears.
• Retrying early does not make it worse. A rejected request costs you nothing, so Retry-After is always achievable — it will not creep upward because you asked too soon. It is still the shortest wait that works, so polling faster than it only wastes your own requests.

If you are hitting the limits

Get in touch with your customer-success representative or support, with the service account and the request pattern you are running. The limits are sized for continuous delta polling, so hitting them usually means there is a more efficient way to pull the same data — larger pages, a longer poll interval, or resuming from the last cursor instead of re-reading from the start. We would rather fix that with you than paper over it.

Limits are platform-wide and are not configured per customer.