Batch Webhooks

November 19, 2015

We’ve provided webhooks that enable you to have your server be notified of events occurring within Pusher for some time. We currently offer three different types of webhook: channel existence, presence, and client event webhooks.

These webhooks have allowed customers to keep servers in sync with who is connected to their service, track which channels are occupied, and receive client-triggered events on their server. If you’d like more specific information about how you can use webhooks with Pusher you can take a look at our docs.

However, for some customers, the volume of webhooks that we were sending them was causing them to use more resources than was otherwise ideal.

As a result, we’ve implemented a new feature that sends your webhooks batched in groups, and can therefore result in significantly fewer HTTP requests! ? Some of our beta testers have reported seeing a reduction in resources required to handle the webhooks by as much as 97%.

Who might need this?

Customers with a lot of traffic and who are currently using webhooks will benefit the most from this change. Actions such as clients constantly connecting and disconnecting generates a lot of events that need to be communicated back to your servers. Likewise, if you rely heavily on presence or client event webhooks then we strongly encourage you to give it a try.

While heavy users of webhooks will see the effects the most, it’s a feature that will benefit everyone, and we are therefore making it the default for all customers as of today, November 19th 2015.

How to enable this

For existing customers who want to make use of this feature, you’ll need to head into your dashboard and toggle batching on the webhooks page for the app you want to change. Anyone who’s been on the webhooks page in the last few days may have already noticed this extra toggle appear.

batch webhooks

Things to check before you enable

It’s important to note that the format of webhooks hasn’t changed, and that they’ve always contained a list of events (it’s just that they used to contain only a single event in each HTTP POST request). For clarity, this is what a typical webhook payload looks like with batch webhooks disabled (the old default):

{
  "time_ms": 1327078148132
  "events": [
    { "name": "event_name", "some": "data" }
  ]
}

With batch webhooks enabled the webhook payloads will look something like this (if you’re sending webhooks at a fast enough rate to have them be batched):

{
  "time_ms": 1327078148132
  "events": [
    { "name": "event_name", "some": "data" },
    { "name": "event_name", "different": "data" },
    ...
    { "name": "another_event_name", "more": "data" }
  ]
}

You’ll need to ensure that you iterate through the list of events, rather than just targeting the first one, which would have been sufficient up until now.

If your app has the potential to generate a lot of events in each request, or if your processing of the event is in anyway resource expensive, you may want to consider processing each event asynchronously.

Try it out

Head over to your dashboard now and let us know how you get on. If there’s anything we could do to improve it or if you run into any issues, please get in touch.

About Hamilton Chapman

Hamilton works as a Growth Engineer at Pusher. He works on the customer facing parts of Pusher - the website, the dashboard, support and events, along with some internal tools as well.