Rate Limiting and Quotas
Bounds enforces per-session rate limits and per-session quotas to protect your backend from abuse and to keep costs predictable. All limits are configurable per agent.
Default limits
| Limit | Anonymous session | Signed session |
|---|---|---|
| Messages per minute | 10 | 30 |
| Max messages per session | 50 | |
| Max session duration | 60 minutes | |
How the rate limit works
Limits are enforced using a sliding-window counter keyed on the session's public ID. Each message send decrements the available count for the current minute window. When the limit is exceeded, the API returns HTTP 429 Too Many Requests. The widget surfaces a friendly message asking the user to slow down.
What happens when quotas are hit
| Quota | What happens |
|---|---|
| Messages per minute exceeded | HTTP 429. Request is rejected. The user can retry after the window resets (within one minute). |
| Max messages per session reached | Further messages are rejected. The session is not automatically closed - the user can still read the conversation history but cannot send new messages. |
| Max session duration reached | The session is marked expired. The user must start a new session to continue. |
Configuring limits per agent
In the console open the agent, go to Settings → Session, and adjust the values for your use case. Higher limits are appropriate for power users on signed sessions; lower limits help control costs on public-facing anonymous widgets.
Your own endpoint should rate limit independently
If you use actions to call your own API, do not rely on Bounds's session-level limits as your only protection. Apply rate limiting on your endpoint as well, keyed on the session ID or the user's external ID. This prevents a single compromised or abusive session from hammering your backend even if Bounds's limits are temporarily raised.