To keep Tres fast and reliable for everyone, we limit how many API requests a single client can make in a given period. Most integrations never come close to these limits — they're designed to stop runaway scripts and accidental request loops, not normal usage.
What the limits are
Two limits apply to every request, and whichever you reach first takes effect:
Per API token — 2,000 requests per 5-minute window, which is roughly 400 requests per minute sustained. Each token has its own independent budget, so one integration can't consume another's.
Per IP address — 5,000 requests per 5-minute window, roughly 1,000 requests per minute. This is counted across every token used from that address.
The per-IP limit is worth noting if you run several integrations from the same server or NAT gateway: they share a single IP budget even though their tokens are separate.
What happens if you exceed a limit
Requests over the limit are rejected with HTTP 403 Forbidden. Two things to be aware of:
We return 403, not the 429 Too Many Requests you may expect, and the response does not include a Retry-After header. So if you start seeing 403s specifically under heavy load — while the same request succeeds when sent on its own — treat it as rate limiting rather than an authentication or permissions problem.
Nothing is locked or suspended. Once your request rate falls back under the limit, requests are accepted again automatically. You don't need to contact support or rotate credentials to recover.
AI agent limits
The Tres AI agent has its own, much lower limit: 20 messages per minute per user. If you exceed it you'll see a message reading Rate limit exceeded. Maximum 20 messages per 60s. Wait a moment and send again. This limit is per user, so it isn't affected by other people on your account.
Staying within the limits
A few practices that keep well-behaved integrations comfortably under the ceiling:
Request only the fields you need. Our API is GraphQL, so narrowing your query is usually faster than filtering the response on your side.
Prefer fewer, larger pages over many small paginated requests when you're pulling history.
Cap your concurrency. Unbounded parallel requests are the most common cause of hitting a limit. A fixed worker pool of a handful of concurrent requests is plenty for most workloads.
Retry with exponential backoff and jitter. Retrying immediately, or on a fixed interval across many workers, tends to reproduce the burst that triggered the limit.
Schedule bulk backfills outside your busy hours so a one-off historical import doesn't starve your live sync.
Requesting a higher limit
If your use case genuinely needs more throughput, contact Tres support with your expected peak request rate, the token or integration involved, and a short description of the workload. We can review and raise limits on a per-account basis.