Calls to our API are limited to 2500 a day per organization account to avoid abuse or negligent integrations that degrade platform performance.
We also have a soft limit of 3 concurrent API connections per organization account. Please contact our support team if these limits pose a problem for your application.
EXEMPTED API CALLS:
- Any POST actions where our system pushes to yours are not counted towards API limits
- GET requests to download files from our Media File API are not counted towards API limits
Ways that you can reduce API calls
- The single easiest way is to increase the time period between repetitive/polling API calls that you are making. For example, if you are updating a Data Source every 5 minutes, try changing to once every 10 minutes - this would halve the average number of API calls per day you are making.
- Check whether you have any API calls that could be removed altogether from your processing. For example, if you are pushing Data Source changes to our platform, then your system would be expected to be the "source of truth". So if your code was making an API call simply to check the size of the Data Source on our side, then this is probably unnecessary and could be removed.
- On the Data Source API, you can issue incremental inserts and deletes in one API call. So, if you have deletions to be done, these can be sent in the same API call as a set of inserts - possibly saving a few API calls.
- Have considered using a Hosted GET connector on your data sources? (See the documentation on this subject under the Data Source Connectors section.)
Hosted GET means that the app connects directly to a web service that you define, which bypasses our platform altogether for retrieving rows, meaning you don't need to push any rows to us. The added benefit of Hosted GET is that you can identify who the user is as well - so you can do filtering of rows on your side as part of your response direct to the app. Plus you get "on demand pull" from the app rather than needing to use some kind of time period interval for updating the rows, since the app will check in with your web service every time it synchronizes.
The Hosted GET API has a lot of similarities to the existing Data Source API that you are using, so it might not be a big code change? Even if you moved a few of your most actively changing data sources to use this approach, that could solve the API limit problem too.
If you'd like to know more about this, contact our support team for help or information.