Rate limiting
The Tella public API and MCP server implement rate limiting to ensure fair usage and protect the service for all users.Current limits
All API keys and external MCP connections used by the same user in a workspace
share one 100-request-per-minute limit.
Rate limit headers
Every REST API response includes headers with rate limit information:RateLimit-Policy and RateLimit use the structured HTTP rate-limit fields. The X-RateLimit-* headers remain available for compatibility with existing integrations.
Example response headers
Handling rate limits
REST API requests
When a REST API request exceeds the limit, you’ll receive a429 status code:
Retry-After with the number of seconds to wait before retrying.
MCP tool calls
When an MCP tool call exceeds the limit, the server returns a tool error instead of an HTTP429 response. The result includes the number of seconds to wait and marks the error as retryable:
Best practices
Check remaining requests
Check remaining requests
Monitor the
X-RateLimit-Remaining header and slow down before hitting the limit.Respect retry timing
Respect retry timing
When you receive a REST API
429, respect Retry-After. For a retryable MCP error, wait for the duration in its text content before retrying:Use the reset timestamp
Use the reset timestamp
The
X-RateLimit-Reset header tells you exactly when your limit resets, in Unix epoch milliseconds:Batch requests efficiently
Batch requests efficiently
Instead of making many small requests, use pagination efficiently:
Rate limit scope
Rate limits are calculated per user within an organization:- All API keys and external MCP connections used by the same user share the same 100 requests per minute limit
- Different users in the same organization have independent limits
- REST API requests and MCP tool calls draw from the same limit