Salesforce API rate limits are not a per-second limit. The main one is an allocation of calls per rolling 24 hours for the whole org, set by the edition and grown by each user license and any API call add-on. A second limit caps how many long-running calls may run at once.
The numbers above come from Salesforce's Platform API limits, with the day we last checked them.
How to work out your org's day
Take the base number for your edition, add the per-license figure for each license you hold, then add any add-ons. That total is what every integration, script and admin shares. Developer Edition and the sandboxes have fixed allocations of their own.
The window rolls: it counts back 24 hours from each call, not from midnight. Usage from yesterday afternoon still counts this morning.
The concurrency cap only touches long-running calls, and it is smaller on Developer Edition and trials than on production orgs. Short calls have no concurrency cap.
How to leave room for everyone else
Give each integration a share of the day and alert when it passes it, since Salesforce will not do that per integration for you. Batch writes with composite or sObject Collections requests, which count once however many records they change; the REST API limits page has the sizes. Read only the records modified since the last run.
Bulk API calls draw on the same allocation, and the Bulk API limits add a batch allowance of their own. A 403 with REQUEST_LIMIT_EXCEEDED means the day is spent, and retrying only adds to the count.
What to do next
If Salesforce feeds another tool, look that tool up too and plan around the tighter limit.
In Oneprofile, Salesforce connects as a source or a destination, and each export can be held to a rate you set in requests per minute, so a sync takes only its share of the org's day.
