Developer ToolsFree calculatorPDF, Excel, Word export

ERP API Rate Limit Calculator for AI Agents

AI agents call APIs far more often than a person clicking through screens, and one question can trigger a dozen tool calls. This calculator estimates peak calls per minute against your ERP limit so you can size agents, caching and batching before you go live.

Your numbers

Concurrent agents or users

Sessions active in the busiest hour.

Tasks per agent per hour

tasks

API calls per task

calls

Tool calls the agent makes to finish one task.

Cache hit rate

30 %

Peak to average factor

Burst multiplier within the hour.

ERP limit

calls/min

Check your vendor documentation or contract.

Your results

Peak calls per minute

126

Compare this with your limit.

Limit utilization at peak

21%

Stay under about 70 percent to leave room for other integrations.

Average calls per minute

Peak calls per second

2.1

Headroom

474

Limit needed with 30% margin

164

Agents supported at 70% utilization

A planning estimate only. Real limits may be per user, per integration record, per concurrency slot or per day, and vendors change them. Confirm against your own vendor documentation and test under load.

Save results:

Peak calls per minute vs calls per task

Sweeps API calls per task from 1 to 40, holding your other inputs fixed.

Capacity plan my agents

Optional: we can review your call traces and recommend caching, batching and limits.

Optional. The tool and every export work without this. No spam.

How to use the calculator

Enter how many agents or users are active in the busiest hour, how many tasks each completes, and how many API calls one task needs. Reduce the load by the share your cache will absorb, apply a peak factor to reflect bursts, and enter the limit in calls per minute. The primary results are peak calls per minute and utilization. The chart shows how quickly peak load grows when agents make more calls per task.

Count calls per task from real traces, not guesses
Include scheduled jobs sharing the same limit
Test with the peak factor at 2x your estimate

The formula

Average calls per minute equals agents times tasks per hour times calls per task, divided by 60, times one minus the cache hit rate. Peak equals average times the peak factor. Utilization is peak divided by the limit. Supported agents solves the same equation for the agent count at 70 percent utilization. The 70 percent target is a common planning margin, not a vendor rule, because retries and other integrations also consume quota.

Worked example

With 20 agents, 30 tasks per hour, 6 calls per task and a 30 percent cache hit rate, the average is about 42 calls per minute and the peak at a factor of 3 is about 126. Against a limit of 600 that is roughly 21 percent. Doubling calls per task to 12 doubles load to about 252, still fine. If the real limit were 100 per minute, the same plan would exceed it, and you would add caching, batch endpoints or queueing.

Ways to stay under the limit

Cache reference data such as item and customer masters for minutes, not milliseconds. Prefer list endpoints with filters over many single gets. Use webhooks or change feeds instead of polling. Queue and smooth requests, and honor Retry-After headers with exponential backoff and jitter. Give agents a small shared token budget so one runaway loop cannot consume the whole quota. Also check whether the limit is concurrency based rather than rate based.

Frequently Asked Questions

What is a realistic peak factor?

Between 2 and 5 for most office workflows, higher for shift start or month end. Measure requests per minute across a busy day from your gateway logs and divide the peak by the average.

Do all ERPs limit by calls per minute?

No. Some limit concurrent requests, some daily quotas, some governance units per script. Convert your vendor's rule to an equivalent per minute figure for planning, then test the real behavior.

Why include a cache hit rate?

Agents repeatedly request the same master data. Even a short lived cache removes many calls, and it also lowers latency and ERP load. Start conservative and raise it only after measuring.

What should an agent do on a 429 response?

Stop retrying immediately. Read Retry-After if present, wait with exponential backoff and random jitter, cap the number of retries, and report a clear failure to the user instead of looping.

Netray can trace your agents' real call patterns, add caching and queueing, and keep the ERP within its limits. Ask for a capacity review.

Talk to an Expert Explore More Free Tools

Related Tools

Developer Tools

More Developer Tools tools

See all

Back to All Tools