Request limiting

Billwerk+Optimize imposes the following request limits on the usage of API.

  • 25 req / sec for read requests (GET) with the possibility to burst up to 50 req / sec for shorter periods of time.
  • 10 req / sec for write requests (POST | PUT | DELETE) with the possibility to burst up to 25 req / sec for shorter periods of time.
  • 10 concurrent read requests.
  • 10 concurrent write requests.

In the case these limits are exceeded a 429 HTTP error response is returned. The code in the error response indicates if rate or concurrent limit has been exceeded (122 and 123 respectively).

It is unlikely to experience request limits with normal usage of the API, even at high volume. The most common causes for exceeding the limits are bugs, bulk data processing or load testing. Should your requests begin to receive 429 HTTP errors, reduce the frequency of your requests. Each failed request is perfectly safe to retry as rate limiting takes place before any other action and prevents the request from being processed. When reducing your request frequency, we recommend an exponential backoff by first waiting one second before trying again. If your request continues to receive the same response, wait two seconds, then four seconds, etc.

Rate limits for both test and live modes are identical. Requests made in test mode are an accurate representation of what to expect when making live requests. If you are experiencing rate limits but are unable to determine why, please contact us at support@Billwerk+Optimize.com.

We urge you to use the API in a fair manner, not introducing unnecessary load. E.g. to use webhooks instead of polling for events, and limit the number of threads to use for bulk operations. We consider it unfair API usage if the API usage is not proportional to the number of entities managed at Billwerk+Optimize. Constantly retrieving all data from Billwerk+Optimize is an example of what we would consider unfair API usage.

Billwerk+Optimize monitors API usage over longer periods to identity excessive API usage. We will try to get in contact on excessive use, but we may be forced to reduce limits until the matter has been resolved.