Buttondown Documentation
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 are fairly simple, and look something like this:
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.
To enable HMAC signing for a webhook:
The signing key can be any string you choose—make it long and random for best security.
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:
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.
You can also use signing keys when sending post requests via automation actions. Simply add a signing_key field to your action's metadata:
We retry up to 3 times if a webhook fails.