Limitations

Limitations for data Queries and Mutations in place to protect against excessive usage of Ergonode servers.

Rate limits are designed to diversify the server traffic and ensure stable operation of all Ergonode servers. The limits are plan-based and counted per minute per entire Tenant.

Scale: 1000 requests/minute

Advance: 400 requests/minute

Free: 100 requests/minute

All older plans (Essential, Start, Start+, Pro) have a limit of 500 requests/minute.

GraphQL provides great flexibility for accessing complex PIM data, allowing you to fetch details of multiple resource types in a single request.

We try not to put immoderate API restrictions that would decrease GraphQL possibilities; however, this comes with certain responsibilities on the client.

Occasionally, with large Queries, it is possible to reach server processing limits, as thousands of different objects will be generated as a result. On such an occurrence, it is vital to try to simplify the Query and fetch only required fields or filtered data to reduce the size of the generated response.

A similar case can be encountered with Mutations - it is possible to send a large set in one batch, which may end up in a 504 HTTP error (Gateway Timeout). Some strategies to avoid the issue are discussed in the Batching mutations section of this documentation.

Every API response will contain the Ratelimit-Remaining header describing the current available limit and Ratelimit-Limit defining the overall limit.

On overusage, the API will return HTTP response code 429 - Too Many Requests. The response will contain Retry-After header after how many seconds the limit resets.

The API is also limited to 6 concurrent requests per Tenant.

Media API limits

GraphQL, as a query language by definition, handles text data (JSON format), which means it does not provide Media files (binaries) directly but URLs.

Media API has a separate limitation in place to protect the server's bandwidth. As with the GraphQL API, the limits are plan-based and in place per minute.

Scale: 500 requests/minute

Advance: 200 requests/minute

Free: 50 requests/minute

All older plans have a limit of 250 requests/minute.

Media API limits handling

Next to rate limit handling, additional strategies can be applied to improve integration performance.

The API endpoints implement an ETag header.

Every response provides ETag HTTP header. This header uniquely represents the response content - a binary file. It allows us to improve API usage - on the following request to the same resource, the API can be prompted with the request HTTP header If-None-Match containing an ETag value - if this is the same file as on the previous fetch, the API will return a 304 response (Not Modified), and the client is certain that it has the current Media file version.

Such requests not only allow limiting bandwidth usage and the time needed to process the data but also, on success (304 response code), are not counted towards the usage limits.