Our partners use our API for different purposes. API access is included on all partner plans at no charge because we believe that you are the owner of your data and you should never feel like your data is ‘locked up’.
However, because the API means there is little or no user-interaction, it can be very easy to create a program or routine that causes an unnecessarily high burden on our system. Even small accounts can generate huge numbers of expensive API requests by accident.
In order to maintain a high quality of service for everyone, we ask that you be cautious when implementing your API integration to avoid run-away usage that is disproportionate to the size of your account.
Here are some tips and best-practices to help keep both your site and ours running smoothly:
Periodically exporting company, device, job, and log data is a common use case. It’s perfectly okay to do this as needed. But it should generally only be relied upon in exceptional circumstances or for periodic reconciliation (usually no more than once a month).
When doing a large synchronization or retrieving a large amount of data, you may trigger a security failsafe used to prevent abuse and protect our site from attacks.
We don’t want to block small bursts in usage. So instead of immediately rejecting your requests, we will slow and throttle them. If you see your responses coming in slower, do not parallelize your requests or try to make more concurrent requests to speed things up. You’ll only have to wait longer for your requests to get through.
If you have too many slowed requests, or your individual account queue gets too full with too many concurrent requests, you’ll likely receive an HTTP “429 Too Many Requests” response code with a message `Your request was denied due to a usage violation. You can track this request with support by referencing …` with a reference code. Please feel free to contact support so we can help describe what happened and why the request was blocked.
If you receive a “429 Too Many Requests” response, your code should be prepared to handle it by pausing its queries, waiting a few minutes, and then proceeding slower (or with less concurrency).