Choosing a 1inch API plan by traffic pattern

A 1inch plan must cover both monthly request consumption and bursts. A product can fit comfortably within its monthly quota yet fail when many users refresh quotes at the same time.

The plan page, checked September 24, 2026, displays Dev at 60 requests per minute and paid tiers with higher per-second capacity. It also states that keys share account limits. Creating more keys is therefore not a way to multiply the organization's purchased capacity.

A workload can be small and spiky

Imagine a product with 30 users opening the swap screen together, each triggering two immediate requests. That creates 60 requests in a short burst. The monthly total may remain tiny, but an average-per-day estimate says little about whether that burst is acceptable. This is a planning example, not a measurement of the provider.

Measure peak concurrent sessions, requests per interaction and automatic refresh behavior. Include monitoring, retries and other API products used by the same account. A quote-only estimate can undercount a screen that also fetches balances, prices and token data.

What to request commercially

• The applicable rate window and account-sharing rule.
• Monthly allowance across the products you use.
• Production and staging allocation.
• Upgrade timing and support escalation.
• Any product-specific custom capacity.

Do not assume a minute allowance permits every request to arrive at once. If the public plan summary and an older help article describe different units, obtain confirmation for the current account rather than turning one number into a burst guarantee.

Rejected traffic is still a product problem

The pricing FAQ says excess short-window traffic receives a 429 response rather than automatic overage billing. That may limit surprise invoices, but it can still interrupt the user's quote flow. Choose capacity with the expected experience in mind, then have engineering handle the documented limit behavior.