Rate limits and quota

That makes the endpoint safe to call from a retrying pipeline. It does not, however, make it free to call in a loop — the per-IP limiter still counts every request that reaches it, whatever the answer.

A triggered capture is a capture. It is charged against your plan’s allowance exactly as a scheduled one is, and it is subject to the same feature gating.

HTTP/1.1 429 Too Many Requests
Retry-After: 24

{
  "success": false,
  "error_code": "rate_limited",
  "error_message": "Trigger limit reached, retry in 24 seconds.",
  "retry_after_seconds": 24
}

• Honour retry_after_seconds — it is also in the Retry-After header — before falling back to exponential backoff.
• Cap your attempts. An unbounded retry turns one throttled deploy into a stuck pipeline.
• Add jitter if several jobs share a key, or they will all wake at the same instant and be refused together.
• Retry 429 and 503. Everything else means the identical call will fail identically.

There are no X-RateLimit-* headers on successful responses. You learn your headroom by being refused, so pace your own calls rather than reading it off each answer.

Ten rejected keys from one address within a short window suspends further attempts for fifteen minutes, answering 429 with Retry-After: 900. A header that is not even shaped like a key is refused before it reaches the service and is not counted towards the lockout — there is nothing to enumerate with a value that could never be valid.