Outgoing Webhooks
Introduction
Webhooks allow for users to be notified via HTTP request when activity takes place on their team in your application. Bullet Train applications include an entire user-facing UI that allows them not only to subscribe to webhooks, but also see a history of their attempted deliveries and debug delivery issues.
Default Event Types
Bullet Train can deliver webhooks for any model you've added under Team
. We call the model a webhook is being issued for the "subject".
An "event type" is a subject plus an action. By default, every model includes created
, updated
, and destroyed
event types. These are easy for us to implement automatically because of Active Record Callbacks.
Custom Event Types
You can make custom event types available for subscription by adding them to config/models/webhooks/outgoing/event_types.yml
. For example:
payment:
- attempting
- succeeded
- failed
Once the event type is configured, you can make your code actually issue the webhook like so:
payment.generate_webhook(:succeeded)
Delivery
Webhooks are delivered asyncronously in a background job by default. If the resulting HTTP request results in a status code other than those in the 2XX series, it will be considered a failed attempt and delivery will be reattempted a number of times.
Future Plans
- Allow users to filter webhooks to be generated by a given parent model. For example, they should be able to subscribe to
post.created
, but only forPost
objects created within a certainProject
. - Integrate Hammerstone Refine to allow even greater configurability for filtering webhooks.