Events are Buttondown's way of telling you that something interesting has happened to your newsletter, and webhooks are Buttondown's way of letting you react to various incoming events. For example, when a new subscriber signs up for your newsletter, Buttondown creates and emits a subscriber.created event; when that subscriber unsubscribes, Buttondown creates a subscriber.unsubscribed event. If you wanted to, say, create a Slack notification or run some application code whenever something in Buttondown happens, you'd create a webhook for the concomitant event and point it towards your application.
The payload of most events is fairly simple, and looks something like this:
For the full list of event types, see Webhook external events. For instructions on creating a webhook in the Buttondown UI, see Events & webhooks.
Webhook security with HMAC signing
For additional security, you can enable HMAC signing on your webhooks to verify that requests are genuinely coming from Buttondown. When you set a signing key on a webhook, Buttondown will include an X-Buttondown-Signature header with each request.
Setting up HMAC signing
To enable HMAC signing for a webhook:
- Go to your webhook settings
- Add a signing key in the "Signing key" field
- Save the webhook
The signing key can be any string you choose—make it long and random for best security.
Verifying the signature
When Buttondown sends a webhook with a signing key enabled, it includes an X-Buttondown-Signature header in the format:
To verify the signature on your end:
Example verification in different languages
Node.js:
Ruby:
The signature is computed using HMAC-SHA256 over the raw request body (before JSON parsing), so make sure to verify the signature using the original bytes you received.
Using signing keys in automation actions
You can also use signing keys when sending post requests via automation actions. Simply add a signing_key field to your action's metadata: