API Rate Limits

Actions such as rapidly reading or updating data, aggressive polling, or making highly concurrent API calls may result in your calls to S-360 public APIs being rate limited.

API endpoint limits

To ensure the quality of S-360 services, its public APIs are subject to rate limiting.

By default, usage of a given endpoint is limited by default to 60 calls per minute.

Some endpoints have specific limitations indicated on their own page.

Some specific methods of some endpoints (like getCatalogDetailed for the catalog service) have specific limitations (1 call every 10 minutes for the later, for example)

Exceeding this value may trigger a 509 (Bandwidth Limit Exceeded) http code or a 429 (Too Many Requests). (our current code is 509 but it will be migrated to 429).

If your system triggers one of those error codes, please refrain from making additional requests until the appropriate amount of time has elapsed.

What is an endpoint?

In S-360, an endpoint matches a published service (a consistant collection of methods concerning the same kind of entities).


is an endpoint matching contact service.


is matching another version of the same service, but is considered as the same endpoint as the previous one for rate limitations concerns. (it is not possible to call different versions of the same service to work around rate limits)


is matching the REST-RPC version of the same service, and is considered as being the same endpoint as above for rate limitations concerns. (it is not possible to use various protocols to work around the rate limits)

Handle rates limitations in code

You should add logic to handle cases in which you exceed the provided rate limits and receive the HTTP Status Code 509. In this case, if a retry is needed, it is best to allow for a back-off to avoid going into an infinite retry loop.

For scripts and rules that call S-360 APIs, you should always handle rate limiting by checking the HTTP Code.

Recommendations to reduce calls to S-360 endpoints

When you exceed your rate limits, you'll need to reduce the number of calls you make to S-360 endpoints. The specifics depend on your use case, but here are some recommendations:

  1. Implement a queuing mechanism to flatten your calls over time.
  2. If your frontend is receiving lots of visitors, build a mechanism restricting its access to a given controlled rate.

Recommendations to reduce calls to S-360 endpoints specifically for polling

It is an anti-pattern to use API calls to synchronize a full set of data from S-360 to another system (for example, all the tickets, all the orders…). You'll likely be calling the endpoint very often on a frequent basis, to retrieve a small amount of data.

S-360 offers many possibilities to build webhooks that can be used to POST the updated data that you need to your system, so that you receive events when tickets, resp. Contacts, resp. Orders… are created.

Please refer to our documentation: https://platform.secutix.com/webhook for more information.

What if the recommendations above are not sufficient?

Please reach out to us through our customer services portal, we can offer you a review of your integration architecture. It is also possible to increase the allowed rate limit for some endpoints, which may involve additional usage costs for the system.