Rate Limit in Pluga

In this article, we will explain in detail what a rate limit is and how it functions as a security measure here at Pluga.

When a large volume of notifications is captured or sent by an app via API, it can cause an overload on that app and this can significantly impact the processing of data.

Therefore, it is common for web apps (which have some method of integration) to set a limit for their API to be triggered or consumed, both for capturing and for sending data, in order to prevent an overload and, consequently, destabilization of the API.

The limitations themselves may vary according to the app and with the methods of data capture. Currently, here at Pluga we have two forms of capture.

There is no rule by category or type of app that defines what the capture method of each one is. However, if you have any questions about what the capture method of your source app is, you can ask us. 🙂

Data capture methods.

Currently, there are two different data capture methods in the apps that we have integrated here at Pluga and they may vary according to the app. The methods are:

Polling

This is a method in which the source app of the data remains passive waiting for Pluga to fetch the data from the API. Then, every 15 minutes Pluga conducts a search in the source app and checks if there are new details since the last search to be captured. If there are, this data will be processed and sent to the next step of your flow.

It is possible that your events are captured before the 15 minutes, since the search occurs every 15 minutes, that is, if the data that should be captured are inserted close to the next capture, they will be captured in less time.

The 15-minute option is because we believe it to be a satisfactory interval for the automatic transmission to be fast without overloading our system and especially the APIs of the partners who deal with our constant checks.

Webhook/ Resthook

This is a method in which Pluga remains passive waiting for the app to send us the data via the webhook URL. In this case, the capture time does not depend on Pluga, as it is the source app that sends the data. Typically, in this method, events are processed in a much shorter time than 15 minutes, as soon as the trigger is activated at the source, Pluga receives the data and immediately sends it to the next stage of your flow.

However, if the source app goes through some instability and takes longer to send the events, Pluga cannot perform this search in the app's API and continues to be passive waiting to receive them.

In this method, Pluga should receive the data from the source app via a URL, which corresponds to the “virtual address” of your automation. It can be compared to an email address, and everything sent to this URL, will be received by your automation.

While we receive all the information at the URLs, not all the notifications we receive will be processed, as Pluga's automations have filters for status, IDs, etc., and they can filter events. For example, if you have an automation whose trigger is “Order approved”, even though we receive notifications of “Refunded orders”, they will not be processed, because we will only process the notifications that match the defined trigger.

Rate Limit

In both methods, your automation may generate a very large number of events in a short period of time. Therefore, Pluga reserves the right to limit the number of notifications it must process in a capture window.

In the case of integration via webhook, we define the following behavior:

• We set the limit to receive up to 30 notifications per second on each individual URL;
• If this limit is reached, a status code 429 indicating the rate limit will be returned;
• Notifications received while this code is returned should be resent after a few minutes;
• It is essential that your source app has a logic to resend these notifications. Otherwise, they will be lost.

This limit on API consumption is important to prevent it from becoming overloaded and causing a greater impact on event processing.

It is worth considering that after we receive the data and begin processing, they will be sent to your destination app. However, if your app sends information to Pluga and receives a return with the code 429, we do not guarantee the receipt and processing of these data. If this happens, your app must resend that notification. 

These are measures taken to prevent negative impacts on the API and, consequently, on the data processing system of Pluga.

We strive, as our product and infrastructure evolve, to further optimize these processes. It is an ongoing effort in which we dedicate ourselves to continually provide a better experience for our clients.

Questions?

If you still have questions, just request support and our support team will get in touch within a few hours ;)