1Tool

Blog · 02 July 2026

API access with rate limits that fit the use case

API access with rate limits that fit the use case

Anyone connecting systems via an API can't avoid one question: how many requests per unit of time are allowed before the system slows things down? Many providers answer this with a single, flat number for all endpoints. That sounds simple, but it misses the reality of how APIs are used — because not every API area is used in the same way, and not every area carries the same risk. 1Tool therefore takes a more differentiated approach: the limits on requests per minute are based on the actual use case.

Why a single number for all endpoints doesn't work

A flat rate limit always has to strike a compromise between two opposing requirements: it should be high enough that legitimate, heavily used integrations aren't throttled — and low enough that a single faulty or abusive client can't overload the system. The problem: an area such as task management is, in practice, often polled by external systems every second, for example to mirror status changes promptly. An area such as sending emails, on the other hand, should be limited much more tightly for security reasons, even if demand is normally low. A single global number cannot reflect both realities at the same time without being too generous in one place and too restrictive in another.

How 1Tool tiers rate limits by area

By default, the 1Tool API allows 1,500 requests per minute — per authenticated user, or per IP address if there is no authentication. That comfortably covers the vast majority of integrations. For the tasks and invoices areas, there is currently no separate limit at all, because these two areas are queried automatically particularly often in practice, for example by syncs with accounting or project management tools. For sending emails via the API, however, a much tighter limit of 100 requests per minute applies to tenants with a particularly high security level.

Security first: stricter limits for sensitive operations

The lower limit for sending emails is no coincidence but a deliberate security measure. If an account is ever compromised, email sending is one of the first attack vectors to be abused — for example for mass spam or phishing campaigns in the name of the affected company. A tight rate limit in this area significantly limits the potential damage without affecting normal business operations, since 100 requests per minute are generally more than enough for regular use. This logic — plenty of freedom where automation is expected and uncritical, tight limits where abuse would be costly — simply cannot be achieved with a single global number.

Frequently asked questions

How many API requests per minute does 1Tool allow?
By default, 1,500 requests per minute per authenticated user or per IP address. Different rules apply to certain areas. Are there areas without a limit?
Yes. For tasks and invoices, there is currently no separate rate limit, as these areas are queried automatically particularly often. Why is email sending limited more strictly?
For tenants with a particularly high security level, a limit of 100 requests per minute applies to sending emails via the API, to make abuse — for example through a compromised account — more difficult. Would you like to find out how your existing integrations fit with 1Tool's API limits?

Read more

Book a demo

Read more