Calls to our API are limited to 2500 per day per organisation account to avoid abuse or negligent integrations that degrade platform performance.

API limits reset upon the first API request made after midnight of the time zone specified on your Organization Setup page.

We also have a soft limit of 3 concurrent API connections per organisation account.

Please contact our support team if these limits pose a problem for your application.

Actions that do not count towards API limits

• All Connector actions are not counted – e.g, Form connectors, Data Source connectors etc
• GET requests to download files from our File APIs
• All interaction between our platform and your app

Checking your API usage

We provide a daily log of your API usage on the Organization Setup page of every client account.
If any metered calls have been made to our API, you will see an “API Calls Today” label on the right-hand side of the page.
Click the “view logs” link to see some details on the last 100 calls.

Ways that you can reduce API calls

1. 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.
   
   
2. 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.
3. On the Data Source API, you can to 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.
   
   
4. 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 synchronises.
   
   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.