Developer ToolsFree calculatorPDF, Excel, Word export

ERP API Initial Data Sync Duration Calculator

Before promising a go-live date for a data feed, work out how long the first full pull takes. Rate limits, page sizes and daily quotas all cap throughput, and the slowest one wins.

Your numbers

records
500 records per call

Respect the API maximum page size.

ms

Grows with page size on most ERPs. Measure with your chosen size.

4 workers
calls per second

Hard cap enforced by the ERP or gateway.

calls per day

Your results

Wall-clock time at effective rate
0 hrs
Days needed by quota
1 days
API calls needed
5,000
Worker throughput
5
Calls per second the workers can produce.
Effective rate
5
Whichever of rate limit or workers is the bottleneck.
Records per second
2,500

Latency usually rises with page size, so the chart is optimistic at large pages. Re-measure latency at each size.

Save results:

Extraction hours as page size grows (latency held constant)

Sweeps Page size from 50 to 5000, holding your other inputs fixed.

Sync plan review

Tell us the ERP and volumes and we will suggest an extraction approach. Optional.

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

How to use it

Enter the record count from a SELECT COUNT on the source object, the page size you plan to use and the latency you measured at that size. Add worker count, the published rate limit and any daily call quota. The tool computes pages, the effective call rate (the lesser of the limit and what workers can produce) and total hours. A separate line shows the days needed if a daily quota is the true ceiling, which is common with cloud ERP APIs.

Formula

Pages equal records divided by page size, rounded up. Worker throughput is workers times 1000 divided by latency in milliseconds. Effective rate is the minimum of that and the rate limit. Hours equal pages divided by effective rate divided by 3600. Quota days equal pages divided by the daily quota, rounded up. The larger of the hours-based and quota-based durations is your plan.

  • More workers do nothing once the rate limit is the bottleneck.
  • Bigger pages cut calls but raise latency and memory.
  • Keyset or cursor paging avoids slow deep OFFSET scans.

ERP notes and mistakes

Run extracts off-peak so you do not starve interactive users of the same limit. Do not assume the published page maximum is fast: some ERPs slow sharply on wide objects with many child lines. Plan for retries and for the delta catch-up after the initial load finishes. Where an API is too slow, consider the vendor's bulk export, a database replica or a file-based interface instead of pushing the REST limit.

Frequently Asked Questions

Should I always use the maximum page size?

Not necessarily. Larger pages reduce call count but raise per-call latency, memory use and the cost of a failed call. Test two or three sizes and pick the one with the best records per second that still retries cleanly.

Why does adding workers not speed things up?

Because a rate limit or concurrency cap on the ERP side caps total calls per second. Once workers can produce more than the limit, the effective rate equals the limit and extra workers only queue.

How do I get the record count?

Use a count query or the API's total count header or parameter if it offers one. For large objects, an approximate count from database statistics is enough for planning.

What about incremental sync after the initial load?

Use a modified-date filter or change tracking and run it on a schedule. The incremental volume is usually a small fraction, so the same calculator with changed record counts sizes it.

Netray builds ERP connectors and read-only data pipelines for private AI. If your first load is blocked by limits, we can look at alternatives with you.