Sha256: fff3e462c37fcca1ed4863d90bec679a7265b145a37896f34adb11a6008d86d5
Contents?: true
Size: 1.72 KB
Versions: 141
Compression:
Stored size: 1.72 KB
Contents
# 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](https://guides.rubyonrails.org/active_record_callbacks.html). ## 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: ```yaml payment: - attempting - succeeded - failed ``` Once the event type is configured, you can make your code actually issue the webhook like so: ```ruby 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 for `Post` objects created within a certain `Project`. - Integrate [Hammerstone Refine](https://hammerstone.dev) to allow even greater configurability for filtering webhooks.
Version data entries
141 entries across 141 versions & 1 rubygems