Front Webhooks & the Application API Explained (2026)

Two kinds of webhooks: application vs rule

Front gives you two separate ways to receive events, and picking the wrong one causes most of the early confusion.

Application webhooks are configured as a feature on an app you create under Company settings → Developers. Per Front's application webhooks documentation, they run alongside a Front app and are "recommended for partner integrations available to all Front users." Their defining trait: each request carries an authorization object, and "the ID of the customer is displayed in authorization.id." That's how a multi-tenant integration knows which Front company emitted the event. Application webhooks require a live server that can respond at configuration time — Front validates the endpoint during setup.

Rule webhooks are set up through a Front rule: you add a send to webhook action in the Then step. They can be created without a server standing by, they're scoped to the specific inbox (private or shared) the rule lives in, and they can send either the full event payload or a lighter event preview. They're the quick, no-code option; application webhooks are the durable, multi-customer one.

The practical rule of thumb: if you're wiring one workspace to one internal endpoint, a rule webhook is fine. If you're building something you'll ship to other Front customers, use an application webhook so authorization.id tells you who's calling.

What a webhook payload looks like

Every webhook is an HTTP POST with a JSON body. The top level has a type (the event name), a payload (the event object itself), and — for application webhooks — that authorization block.

{
  "type": "inbound_received",
  "authorization": {
    "id": "cmp_abc123"
  },
  "payload": {
    "id": "evt_55c8c149",
    "type": "inbound",
    "conversation": {
      "id": "cnv_55c8c149",
      "subject": "Where is my order?",
      "status": "unassigned"
    }
  }
}

The event type tells you what happened. Front emits a broad set — common ones include inbound_received, outbound_sent, conversation_moved, and message_delivery_failed, alongside conversation, comment, and tag events. The shape of payload changes with the event type, so your handler should switch on type first.

By default a payload is lean — often just IDs. Front's Send Full Event Data toggle changes that: switching it on exposes Subject, Status, Assignee, Recipient, Tags, and the message body directly in the webhook, so you don't have to fire a follow-up API call to hydrate the event. On a busy inbox that's the difference between one inbound request and hundreds of round-trips, and it's the first setting worth turning on.

Signing, timeouts, and retries

Here's the caveat the config screen states plainly: the webhook target is signed but not authenticated. Front doesn't send credentials — instead it signs each request so you can verify it genuinely came from Front.

Verify the signature. Front signs with HMAC-SHA256. You concatenate the request timestamp with the raw request body, compute the HMAC using your app secret, and compare against the x-front-signature header. If they don't match, drop the request — that's your only defence against a spoofed endpoint, since the URL itself is public.

Respect the timeout. Per the docs, "webhook requests issued by Front will time out after 5 seconds." Your endpoint must acknowledge fast. The correct pattern is to return a 2xx immediately and do the real work asynchronously on a queue — never process a slow database write or an LLM call inline before responding.

Plan for retries. Application webhooks "retry up to 3 times" when Front receives an error, a timeout, or a 429/500/408. Retries mean your handler must be idempotent — the same event can legitimately arrive more than once, so key off the event id and de-duplicate rather than double-processing.

The Application API and Plugin SDK

Webhooks are the outbound half of Front's platform. The inbound half is the Core API plus the Plugin SDK.

The Core API is Front's backend — it reads and writes almost every object: conversations, messages, contacts, channels, inboxes, teammates, tags, comments, and analytics. It's a REST API you call from your own server, and it's what you use to act on the events your webhook receives.

The Plugin SDK is different — it's a JavaScript SDK that renders your UI inside Front. Per Front's plugin overview, "a plugin is a small web application that can communicate with Front using a Javascript SDK." There are two flavours:

1. Sidebar plugins render in the integrations panel on the right of the Front UI — "roughly 25-30% of the screen width, but can be adjusted by the user." They receive the conversation context (which conversations the teammate has selected), so you can show the matching order, ticket, or CRM record beside the message.
2. Composer plugins live as an icon in the message composer toolbar and open in a modal, receiving the messageComposer context — handy for inserting a snippet or looking something up while replying.

Together these three surfaces — webhooks out, Core API in, Plugin SDK on-screen — are the whole developer platform. A typical integration uses all three: a webhook wakes it up, the Core API acts, and a sidebar plugin shows the result to the agent.

The honest limits — and where an AI layer picks up

The platform is capable, but it has real edges worth naming before you build against it.

Rate limits are per company and plan-gated. Front's Core API caps requests per minute by tier: 50 rpm on Starter, 100 on Professional, 200 on Enterprise, enforced per company rather than per token. There's a burst allowance of roughly half the standard limit, and if you blow through the burst it takes about 10 minutes to replenish. A 429 comes back with retry-after, x-ratelimit-remaining, and x-ratelimit-reset headers — you're expected to back off. A chatty integration on a Starter plan hits this ceiling faster than you'd think, which is exactly why the Send Full Event Data toggle matters.

A webhook delivers an event, not an answer. This is the structural limit. Front tells you "an inbound message was received" with the subject and body — but the payload can't read the customer's real intent, look up their order, or write a reply. Everything past delivery is code you have to build and maintain: parsing, business logic, drafting, sending. The platform is deliberately a transport and data layer, not a reasoning one.

That seam is where an AI agent layer fits — not to replace the platform, but to be the smart consumer on the other end of the webhook. The broader category of AI agents for customer service exists for exactly the reasoning a raw payload can't do. Macha is one such layer: it runs on top of the Front you already use through the live Macha–Front connector — it does not replace Front, your shared inboxes, your API, or your webhooks. Front's webhook delivers the conversation; Macha's agent reads it, understands intent rather than keywords, pulls a real order or account status through a custom tool that turns your REST API into something the agent can call, and drafts or sends a grounded reply. You keep Front as the shared inbox and system of record; you skip writing the handler that turns an event into a resolution. Macha's credits are consumed per AI action, never per resolution — transport and reasoning have different costs, and it's honest to price them that way.

The clean division of labour: let Front's webhooks and Core API be the deterministic plumbing, and layer an agent on top for the part a payload can't do — reading the conversation and answering it well. For how the collaborative side works, see Front shared inbox explained and Front comments and mentions explained.

FAQ

What's the difference between application webhooks and rule webhooks in Front? Application webhooks are configured as a feature on an app under Company settings → Developers, carry an authorization.id identifying the customer instance, and require a live server at setup — they're built for partner integrations shipped to many Front customers. Rule webhooks are set up inside a Front rule's Then action, are scoped to a single inbox, can be created without a server ready, and can send a full or preview payload. Use rule webhooks for one-off internal wiring and application webhooks for products.

How do I verify a Front webhook is genuine? The webhook target is signed but not authenticated, so Front doesn't send credentials — it signs each request. Compute an HMAC-SHA256 over the timestamp concatenated with the raw request body using your app secret, and compare it against the x-front-signature header. Reject any request that doesn't match.

What are Front's webhook timeout and retry rules? Front webhook requests time out after 5 seconds, so return a 2xx immediately and process asynchronously. Application webhooks retry up to 3 times on an error, timeout, or a 429/500/408 response — which means your handler must be idempotent and de-duplicate on the event id.

What are the Front Core API rate limits? Rate limits are per company by plan: roughly 50 requests per minute on Starter, 100 on Professional, and 200 on Enterprise, with a burst allowance of about half the standard limit. Exceeding the limit returns a 429 with retry-after, x-ratelimit-remaining, and x-ratelimit-reset headers.

Can I add AI on top of Front's webhooks without replacing Front? Yes. An AI agent layer like Macha connects to Front as a live connector and acts as the smart consumer of your webhook events — it reads the delivered conversation, understands intent, pulls live data through custom tools, and drafts or sends a reply. Front stays your shared inbox, API, and system of record; the agent just does the reasoning a raw payload can't.

Ready to turn a webhook event into an actual answer? Start a free trial of Macha and connect it to your Front in minutes.