Rate limits

The Chatway API enforces per-account rate limits to keep the platform stable for all customers.

Limits

Limit Counts Window Scope
60 requests Every authenticated request Per minute Per account
30 resolves Each conversation resolved Per minute Per account
30 unresolves Each conversation unresolved Per minute Per account

All API keys of an account share the same budgets, so creating another key does not raise them.

Resolve and unresolve are counted per conversation, in addition to the request limit. Each has its own budget. These budgets are also shared with the account's MCP connections: resolving conversations through an AI assistant uses the same allowance as the Resolve Conversation endpoint. Assigning conversations through MCP has a separate budget of the same size.

Each window starts with the first counted request and resets one minute later.

When you exceed the limit

Requests over the limit receive:

HTTP/1.1 429 Too Many Requests

The response body includes a JSON error message. When provided, honor the Retry-After header (seconds until you should retry).

Example response for the request limit:

{
  "message": "Too many requests."
}

Example response for the resolve or unresolve limit, with a Retry-After header set to the same number of seconds:

{
  "message": "Conversation action limit reached: up to 30 conversations per minute for this action. Try again in 42 seconds.",
  "retry_after": 42
}

A rejected request does not resolve or unresolve the conversation.

Recommended client behavior

Pace requests across all workers and API keys of the account. On a 429 response, wait at least the number of seconds in Retry-After when that header is present. Otherwise, increase the delay between retries and add a small random delay so workers do not all retry together.

Set a maximum retry count. Cache reusable read results and use webhooks for new-message notifications instead of frequent polling.

Use separate keys to identify integrations and manage their access. Separate keys do not get separate budgets, so keep the account's combined traffic within the limits.

Be careful when retrying writes after a timeout or connection failure. Check whether the message, invitation or change already exists before repeating the request. This guide does not document duplicate protection for repeated writes.

Webhooks vs polling

Webhook deliveries are separate from REST API rate limits. Design integrations to react to webhook events rather than calling list endpoints on a short interval.

Related pages