Rate Limits
FrontDeskOS applies rate limits to ensure fair usage and protect service stability.
Limits by Plan
| Plan | Tool Calls | Resource Reads | Webhook Events | Burst Limit |
|---|---|---|---|---|
| Free | 100/hour | 60/hour | 1,000/day | 20/min |
| Pro | 1,000/hour | 300/hour | 10,000/day | 100/min |
| Business | 5,000/hour | 1,000/hour | 100,000/day | 500/min |
| Enterprise | Custom | Custom | Custom | Custom |
Rate Limit Headers
Every response includes rate limit headers so you can track your usage:
Response headerstext
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 987
X-RateLimit-Reset: 1705312800
X-RateLimit-Burst-Limit: 100
X-RateLimit-Burst-Remaining: 95Handling Rate Limits
When you hit a rate limit, the server returns a 429 status with the RATE_LIMITED error code. Implement exponential backoff to handle this gracefully:
Exponential backofftypescript
async function callWithRetry(toolName: string, args: any, maxRetries = 3) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await mcp.callTool(toolName, args);
} catch (error: any) {
if (error.code === "RATE_LIMITED" && attempt < maxRetries) {
const delay = Math.pow(2, attempt) * 1000; // 1s, 2s, 4s
await new Promise(resolve => setTimeout(resolve, delay));
continue;
}
throw error;
}
}
}MCP Clients Handle This
Most MCP-compatible clients (including Claude Desktop) handle rate limiting automatically. You only need to implement retry logic if you are building a custom MCP client or calling tools programmatically.
Optimizing Usage
- Use filters to reduce the amount of data returned by list tools.
- Cache resource reads -- business info and staff directory change infrequently.
- Batch related operations when possible rather than making individual calls.
- Use webhooks instead of polling for real-time updates.
- Set appropriate
limitvalues on paginated requests.