API rate limits: estimate integration capacity before choosing a plan

Describe the business events

Count ordinary events and peak bursts separately. Include the first import, ongoing changes and a catch-up after downtime. A daily average can hide a short period in which the integration receives far more work than it can complete.

For a fictional ecommerce operation, routine order updates may be modest while a catalogue import creates a large batch. The buying brief should state both workloads and how quickly each must finish. Keep the desired completion time distinct from a vendor guarantee until the proposed setup has been evaluated.

Count the calls behind one event

One order or contact may require a search, several detail reads, an update and a final confirmation. Pagination, linked records and attachments can add requests. Write the steps and their expected frequency instead of assuming one business event equals one API call.

For the ecommerce operation, a repeated lookup on every line item may dominate the workload. Ask whether supported batching, caching or a different data path can reduce unnecessary work. Verify that any cached information remains suitable for the decision; a cheaper stale lookup can create a different operational problem.

Check the limit model for the exact API

GitHub’s REST API guidance distinguishes primary and secondary limits and documents response information used to handle them. Shopify’s API-limit guidance shows that limit mechanics vary across APIs, including calculated query cost.

Record the API, version, authentication method and relevant plan. Do not apply a REST request allowance to a cost-based GraphQL query. A connector’s own task or operation allowance is another dimension and may be charged even when the connected application imposes a separate technical limit.

Use a hypothetical capacity calculation

Suppose a fictional integration handles 600 changed records, each requiring three requests. That is 1,800 requests before retries or pagination. At a hypothetical sustained allowance of 60 requests per minute, the arithmetic minimum is 30 minutes. These figures are invented to illustrate planning, not a current vendor allowance.

The actual completion time can be longer because of processing, concurrency rules, other integrations sharing capacity and failed attempts. Add those dependencies explicitly. If the business requires the batch to finish in ten minutes, the proposal needs a different supported design or a changed requirement, rather than a more optimistic spreadsheet.

Plan throttling and recovery

Respect the selected API’s documented retry instructions. Use a bounded recovery path and preserve event references. Retrying faster after a limit response can make the problem worse. The automation recovery guide covers the difference between repeated attempts and verified outcomes.

Measure the actual integration during a trial

Use an approved test dataset and inspect completed work, queued work, failed steps and downstream records. Record the configuration and workload so the result can be reproduced. Do not infer capacity from a demonstration containing only one clean record.

Ask how the operator sees a growing backlog and who receives the relevant alert. Check whether a manual rerun starts from the failed step or repeats earlier effects. A higher product tier may help some constraints but will not necessarily repair an inefficient request pattern or a broken recovery design.

Compare total cost and operational fit

Include application plans, connector operations, integration maintenance and support effort. Separate a technical rate limit from a billing allowance. Both can matter, but they are not the same unit. Keep uncertain workload growth visible as a scenario rather than a fixed forecast.

Research the Shopify, GitHub, Zapier and n8n profiles. Choose an integration design that can meet the business timing requirement and expose its unfinished work when a service slows down.

Frequently asked questions