Hi -
Hoping someone can provide a suggestion about how to throttle webhook requests. I'd like to invoke a one-time webhook call for each record in our database. The API I'm calling has a rate-limit of 10 requests per second, so I'm trying to find the best way to make the calls in small batches -- ideally in an automated way. Any suggestions?
Thanks in advance.
Peter
Peter,
There is no way to automate throttling in a single flow step, but instead of the regular "call webhook" flow step, you can use "request campaign" instead. Create another smart campaign triggered by "webhook is called" and that smart campaign's flow steps will be to "call webhook" as follows:
1. Call Webhook
Choice 1: If random sample is 5%
Default Choice: Do nothing
2. Remove from flow
Choice 1: If webhook was called
Default Choice: Do nothing
3. Call Webhook
Choice 1: If random sample is 5%
Default Choice: Do nothing
4. Remove from flow
Choice 1: If webhook was called
Default Choice: Do nothing
5. Call Webhook
At every "call webhook" step, only a certain small percentage of the leads will call the webhook and they will subsequently be removed from the flow so they do not call the webhook again. Repeat steps #3 and #4 as necessary depending on how small of a percentage you want to qualify each time. The last step (#5) will be to call the webhook for all remaining leads.
Thank you very much Devraj!
Also make a note that in the "remove from flow" steps, leads will be removed if the webhook has ever been called, not just if the webhook was called in this smart campaign flow. If the webhook will only ever be called once for a lead, then the above flow will work.
Unfortunately, this won't truly throttle the requests. Not only is 5% not guaranteed to be < 10, all you're doing is introducing an infinitesimal pause before running the webhook on the next step... no reason there couldn't be 10 webhook calls per sec in this setup.
A more accurate setup would use the Webhook is Called trigger, with an HTTP response code constraint, to remove people from the flow.
Assume that any well-constructed web service will return a non-200 response (like 429) when it's over limits. The first Smart Campaign builds in a certain number of retries:
While the second Smart Campaign makes sure nobody continues if they've already fired the 'hook successfully:
However, even with the above logic in place, if you have a sustained flood of requests that doesn't abate by the time the last wait step finishes (say 12 x 5 min = 1 hours), you will still have dropped requests. This is kind of inevitable. After all, if a remote service has a rate limit, your sustained inbound rate can't exceed that.