> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.jambonz.org/guides/features/api-rate-limits/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.jambonz.org/_mcp/server.

# API Rate Limits

> Understand jambonz API rate limits, how throttling is applied per account, and how to handle 429 responses in production workloads.

The API server applies rate limiting to protect the application from exessive load.

The limit applies to each client IP address regardless of the API key or Account in use, requests are limited using a fixed window (as opposed to a sliding window).
At the start of each window period the limit is reset, The default values for jambonz (and used on jambonz.cloud) are 600 requests per 5 minute window.

The use of a fixed window means that you could theoretically send more than 600 requests within a 5 min period if you were to send 600 just before the window reset and 600 just after.

All API responses contain headers indicating the limits:

`ratelimit-policy : "600;w=300"`
This header indicates the servers current policy, that shows a 600 request limit per 300second window (5 min)

`ratelimit-remaining: "580"`
This header indicates to the client how many request they have left in the current window, in this case 580

`ratelimit-reset: "39"`
This indicates to the client how many seconds remain in the current window until the limit will be reset. Here its 39 seconds

Self hosted customers can adjust their limits by setting the follwing environment variables in their API server `ecosystem.config.js`

`RATE_LIMIT_WINDOWS_MINS` - Number of minutes each window is (default 5)
`RATE_LIMIT_MAX_PER_WINDOW` - Number of requests allowed in each window (deafult 600)

> **Note**
>
> These limits apply to HTTP REST requests to the API, they are not the same as any calling limits that you have on the platform,

> Understand jambonz API rate limits, how throttling is applied per account, and how to handle 429 responses in production workloads.