Webhook spam / DDOS

You must design your application to handle 1000's of webhooks, we do not throttle them and the influx can very easily cause a webhook endpoint to fail.

Scenario: event.created or message.created when connecting an account.

When an account authenticates the application webhook endpoint is flooded with event.created webhooks, this is due to us retrieving all the events and creating every recurring event up to 5 years in the future.

This is especially heavy on accounts with multiple calendars, especially shared colleagues calendars.

Scenario: multiple event.updated when updating a single event receive duplicate webhook.

This is due to the customer having multiple shared calendars, the same event exists on every shared calendar resulting in webhooks from all the other shared calendars. Everytime someone RSVP's an updated webhook is sent from every calendar.

An application with 20 connected users all on the *same domain*, i.e. work colleagues, with 50 shared calendars can easily generate >20k event.updated webhooks over a few seconds. Follow the best practices below to ensure you can ingest and these while replying with a 200 response within 10 seconds.

In V3 we limit webhooks to only those created in the primary calendar by default, to prevent this behavior. If you would like to limit the webhooks by source, i.e. those created by scheduler, please reach out to our product team.

Resources

Build your environment to scale

Pre-launch checklist

Webhook Best Practices

Updated May 14, 2024 09:53