Rate Limits

To protect the platform, Kiket enforces per-organization and per-token rate limits.

REST API Limits

• User tokens – 1200 requests per minute per organization.
• Service/OAuth tokens – 2400 requests per minute per organization.
• Extension tokens – 600 requests per minute per installation.

Responses include headers: - X-RateLimit-Limit - X-RateLimit-Remaining - X-RateLimit-Reset

When you exceed a limit you receive 429 Too Many Requests with a Retry-After header in seconds.

Programmatic Introspection

Extensions can query their live quota without spending an API call on a business operation:

GET /api/v1/ext/rate_limit
X-Kiket-API-Key: ext_live_xxx
Accept: application/json

Example response:

{
  "rate_limit": {
    "limit": 600,
    "remaining": 599,
    "reset_in": 52,
    "window_seconds": 60
  }
}

• The request itself counts against the window, so remaining is already decremented by one.
• The same values are echoed via the standard rate-limit headers.
• If an extension overrides rate_limit_requests / rate_limit_window, those numbers appear instead of the plan defaults.

When you hit zero remaining calls you receive:

{
  "error": "Rate limit exceeded",
  "retry_after": 42
}

with status 429 and a matching Retry-After header.

Webhook Limits

• Maximum payload size: 500 KB.
• Concurrent deliveries to a single endpoint are capped at 5 to avoid overload.

Best Practices

• Batch list requests with pagination.
• Cache workflow and board metadata locally when possible.
• Use webhooks instead of polling for state changes.
• Queue outgoing API calls in your extension infrastructure to respect limits.

Contact support for higher quotas if your use case demands it; we recommend sharing dashboards that illustrate expected traffic.