Overview

The solution implements governance rules on system APIs published as per the previous sections. The governance rules implemented has the objective of protecting the system against malicious and non-optimal usage. One of the governance approaches implemented in the solution APIs is to enforce specific rate limiting (throttling) rules. Throttling is a risk management technique which is configured based on the system scale parameters to make sure the system provides the best performance possible.

Why is API rate limiting necessary?

API rate limiting can be used as a defensive security measure for the API, and a quality control method. As a shared service, the API must protect itself from excessive use to encourage an optimal experience for anyone using the API. Rate limiting on both server-side and client-side is extremely important for maximizing reliability and minimizing latency. Part of the rate limiting functionality that is implemented in the solution is a rate limiting technique called the selective rate limiter. The selective (or specific) rate limiting technique has the objective of enforcing specific APIs rate limiting parameters per each ERP or POS system. This would enforce fare usage among the different systems calling the solution. Part of the development performed when integrating with the solution should cater for this rate limiting technique and handle any error messages that are expected to be returned by the solution in the case of being rate limited. The rate-limit functionality prevents API usage spikes on a per ERP/POS system basis by limiting the call rate to a specified number per a specified time period. When the call rate is exceeded, the caller receives a 429 Too Many Requests response status code.

How will this change your integration?

The integration implementation will have to change in two ways,

1. Your integration implementation should now cater for making sure you are not hitting any of the APIs rate limits that are listed later in this page as much as possible. This would be done by implementing proper integration techniques and following the integration recommended practices as listed here https://sdk.invoicing.eta.gov.eg/integrationpractices/
2. Handle any errors being returned from the rate limiting functionality in a proper way. The system returns two types of standard HTTP responses in the case of hitting rate limits, HTTP 503 and HTTP 429. Handling each error response would require proper implementation, the recommended handling approaches for each error response is provided below.

Error Reponses and Error Handling Approaches

The following are a list of standard errors being returned in case of being rate limited.

APIs Throttling Specifications

This section provides an overview of the detailed configuration for the rate limiting specifications per API provided for the ERP integration. Please, find in the below table a breakdown of the APIs rate limiting specifications per API provided in the solution and applies a rate limiting functionality that requires the systems integrating with the solution to handle.