Throughput Policy

Throughput policy represents a setting and a scope that throughput of webhooks is limited to.

When multiple webhooks share a single Throughput policy, throughput of all webhooks will be throttled up to maximum number of concurrent connections defined in the policy. This policy is created on project level similar to Frequency policy.

📘

This policy should be used when 3rd party API imposes some limitations on requests per minute or number of concurrent requests.

How to Set Up a Throughput policy

  1. Create a Throughput policy in the Project settings > Campaigns > General > Throughput policies. There you can set individual parameters of the specific policy such as the 'Concurrency limit' or the limit of concurrent requests

🚧

Remember that the concurrency limit is just an approximation of the requests per second, as the actual limit always depends on the latency of the API on the other side. It is always better to use sub-optimal requests per second to ensure you won't go over the limit, and it is also good practice to be aware of what happens if the limit is reached.

  1. Then in the settings of the individual webhook, you can choose which among the established Throughput policies. You can also create a new throughput policy by clicking on the Cog button and setting it there.

📘

When deleting a Throughput Policy, a window will pop up, informing you of active campaigns in which it is being used. In order to delete it, you will have to find a new Throughput policy for these active campaigns or stop them.

Technical details

On-event campaigns are generally processed with higher priority compared to the rest of campaigns. However, setting a Throughput policy for webhooks in on-event campaigns may negatively affect the priority in which these webhooks are processed. This will change the order in which they are processed in order to keep the fairness across all the simultaneously running campaigns that have the same throughput policy.

Changing Throughput Policy in Running Scenarios

When changing from policy A to policy B in a webhook that is actively running, policy B will be applied only to newly executed webhooks, while already scheduled and running webhooks will use policy A. If you want to ensure that changes are applied immediately, the scenario must be restarted.
When changing a concurrency limit in a policy within a running scenario, the change is applied immediately.

🚧

Migration

If the webhook was previously using the old Speed limits, they can be still used there. However, it is not possible to create a new webhook with old Speed limits. All new webhooks must use new Throughput policy to limit their speed.