Webhooks
A webhook allows you to be automatically notified when something happens in Front without having to constantly poll the API. For each event happening in Front, your webhook will receive a POST HTTP request with the event JSON representation in the request body.
Front offers two methods for configuring webhooks:
- By adding a webhook feature to an app (application webhooks)
- By setting up a webhook through rules (rule webhooks)
Use application webhooks for partner integrations
If you are building a partner integration available to all Front users, you should use application webhooks. The primary benefit of this method is that users of your integration will not have to configure the webhook themselves when they install your app. There is also less risk of disruption when using application webhooks, because rules can be accidentally deleted or re-arranged by other teammates. Application webhooks have access to events that occur in shared inboxes.
Application webhooks versus rule webhooks
If you are not building a partner integration, you can choose whether to use application webhooks or rule webhooks. Front recommends using application webhooks whenever possible, but setting up rule webhooks can sometimes be all you need. Application webhooks require that you have a server ready to respond to the webhook event at the time of configuration. This is not required when you set up a webhook through rules, so you can get up and running without first setting up a server. In addition, rule webhooks have access to the scope in which the rule was created. If the rule was created in a private inbox, then the rule webhook will have access to events in that private inbox.
Delivery reliability
For anything running in production, delivery reliability is usually the deciding factor.
Application webhooks retry failed deliveries, so a transient failure on your side does not mean a lost event. They also recover from Front-side incidents: events that error during an incident are generally retried once service is restored. Rule webhooks do not offer the same retry guarantees, so an event that fails to deliver may simply be missed.
Application webhooks also always send the full event payload. Rule webhooks send either the full payload or an event preview depending on how the rule is configured, which means your integration may need to make an additional API call to retrieve the complete event.
Scoping
Scoping is the one area where rule webhooks have a genuine advantage. If you need events from a private inbox, or you want to narrow delivery to a specific inbox rather than filtering on your side, a rule webhook is the way to do it. Additionally, rule webhooks can sometimes be triggered by more complex logic or by triggers that aren't yet available on application webhooks.
Summary table
The following table summarizes the differences between application webhooks and rule webhooks:
| Webhook type | Recommended for partner integrations | Recommended for initial testing | Benefits | Scope |
|---|---|---|---|---|
| Application webhooks | Yes | Once you have a server set up to respond to webhook events | Does not require the end user to configure the webhook through a rule when installing your app Retries failed deliveries, including after Front-side incidents Always sends the full event payload | Shared inboxes |
| Rule webhooks | No | Yes | Allows you to set up a webhook without having a server ready to respond during configuration, but would require users to configure the rule themselves if your app is ported to other Front instances Can be scoped to a specific inbox, including a private inbox Sends either the full event payload or an event preview. You can make a subsequent API call to retrieve the full event. Does not retry failed deliveries | Private or shared inboxes (the scope applies to the specific inbox the rule is created in) |
What events are not included in webhooks?
Webhooks alert you about most important events in Front. However, there are some events that webhooks do not apply to.
Webhooks exclude "mass action" events, such as:
- Moving inbox content to another team
- Mass updating inbox conversation statuses
- Importing historical messages to a channel
- Etc.
Updated about 14 hours ago