Rate Limiting

Limit

The Ticket0 API is rate-limited to 60 requests per minute per workspace. The limit is shared across every API key in a workspace — adding more keys doesn't raise it.

For higher limits on a dedicated plan, contact support.

When you exceed the limit

Requests over the limit get a 429 response:

HTTP 429 Too Many Requests
Retry-After: 42

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests. Please slow down."
  }
}

The Retry-After response header holds an integer number of seconds to wait before retrying. Parse it rather than hard-coding a delay — the window resets based on the time of your first request in the current minute, not a fixed boundary.

Handling 429s

• Respect Retry-After. Sleep for at least that many seconds before the next request.
• Back off on repeat. If you get a 429 twice in a row, double the wait time on each retry (exponential backoff with a cap).
• Don't retry synchronously in user-facing code. Queue the work and retry off the request path.

Pagination

If you're polling lists, use cursor-based pagination rather than many small requests. Responses that support pagination include a nextCursor field; pass it as the cursor query parameter on the next request:

# First page
curl "https://app.ticket0.ai/api/v1/tickets?limit=100" \
  -H "Authorization: Bearer t0_your_api_key"

# Next page (using cursor from previous response)
curl "https://app.ticket0.ai/api/v1/tickets?limit=100&cursor=cur_01abc..." \
  -H "Authorization: Bearer t0_your_api_key"

When nextCursor is null, you've reached the last page.

Best practices

• Use the maximum limit (100) when fetching large datasets to reduce request count
• Implement exponential backoff when you receive a 429
• Cache responses that don't change frequently (tag lists, knowledge-base articles)
• Use webhooks for real-time events instead of polling the API — a single subscription replaces a continuous poll loop