Freshdesk Webhooks Explained (Triggers & Payloads)

What a Freshdesk webhook actually is

Freshworks defines a webhook as "a callback to an application or web service that is automatically triggered in response to a specified event." In practice, that means Freshdesk makes an outbound API call for you as part of an automation action. You do not poll Freshdesk's API on a timer waiting for something to change; Freshdesk pushes the change to you the moment it happens.

There is one important distinction worth getting straight before you build anything. Per Freshworks' Using webhooks in automation rules documentation, there are two related actions:

• Trigger Webhook — "when the API response is not needed for further automations." Fire-and-forget: notify an external system, sync a record, post to a channel.
• Trigger API — when you do need the response, for example to fetch a customer's subscription plan and then branch on it, or to run a small JavaScript transformation on a ticket field.

If all you want is to send ticket data outward, Trigger Webhook is the action you reach for. If you need to read something back and act on it inside the same rule, that is Trigger API territory.

Where webhooks live: automation rules

Webhooks in Freshdesk are not a standalone menu — they are an action inside an automation rule. You build the rule under Admin → Workflows → Automations, on a rule that runs either on ticket creation or on ticket updates, and then add "Trigger Webhook" as one of the actions the rule performs when its conditions match.

The mental model is the same three-part shape as any Freshdesk automation:

1. Event — what starts the rule (a ticket is created, or a specific field changes).
2. Conditions — which tickets qualify (priority is Urgent, tag contains vip, group is Billing).
3. Actions — what happens, one of which is your webhook call.

Be aware of the plan gating up front, because it is easy to lose an afternoon to it: Trigger Webhook is available on the Growth, Pro, and Enterprise plans (for both Freshdesk and Freshdesk Omni), and the response-aware Trigger API is Pro onward. On lower tiers the webhook action simply does not appear in the "Choose action" dropdown — as the screenshot above shows, a trial or entry-level plan lists only the built-in actions (set priority, set type, set status, add note, add tag). If you do not see it, that is a billing question, not a configuration bug.

Configuring the webhook action

Once you add a Trigger Webhook action to a rule, Freshdesk asks for a handful of settings. Here is what each one does.

Request type. You choose the HTTP method for the callback. Freshworks lists the standard five — GET (retrieve), POST (create), PUT/PATCH (update), and DELETE (delete). One gotcha the docs call out explicitly: if you make a GET call with a webhook, "your automation rules won't be able to use the response" — reach for Trigger API if you need to read what comes back.

Callback URL. The endpoint Freshdesk calls. It can be dynamic: you interpolate ticket data with double-brace placeholders. The documented example is:

https://acme.freshdesk.com/api/v2/tickets/{{ticket.id}}/notes

Encoding. JSON, XML, or XML-Encoded. JSON is the sane default for almost every modern endpoint.

Content. Simple lets you tick a list of ticket properties to send; Advanced lets you write a custom request body by hand — which is how you shape the payload to match whatever the receiving API expects.

Authentication and headers. Toggle Requires authentication to attach an API key, and toggle custom headers to add things like an API version or a signing secret. The documented header format is X-Sample-CustomHeader1: VALUE, entered one per line, and header names are not case-sensitive.

What the payload looks like

This is the part people actually want to see. With JSON encoding and Advanced content, you write the body yourself and drop in placeholders that Freshdesk resolves at send time. Straight from Freshworks' automation examples using webhooks, here is a payload that creates a new ticket in response to a customer reply (a POST to the Create Ticket API):

{
  "email": "{{ticket.from_email}}",
  "description": "{{ticket.latest_public_comment}}",
  "subject": "{{ticket.subject}}",
  "status": 2,
  "priority": 1,
  "group_id": {{ticket.group_id}},
  "responder_id": {{ticket.agent.id}},
  "type": "{{ticket.ticket_type}}"
}

Two details to notice. String values wrap the placeholder in quotes ("{{ticket.subject}}"), while numeric fields like group_id reference the placeholder without quotes so the result stays a number. And you can prefix or combine placeholders with static text — a documented PUT example that re-titles a ticket sends:

{
  "subject": "{{ticket.company.name}} | {{ticket.subject}}"
}

You can reach nested and custom fields the same way — for instance writing a timestamp into a custom field:

{
  "custom_fields": {
    "cf_last_updated_time": "{{ticket.modified_on}}"
  }
}

The available placeholders mirror the ticket object — ticket.id, ticket.subject, ticket.from_email, ticket.requester.email, ticket.company.name, ticket.group_id, ticket.agent.id, ticket.ticket_type, and so on — which means most webhook bodies are just the fields of the ticket that changed, plus whatever static values the receiving endpoint needs. If you are stitching several of these rules together, it is worth reading up on how to automate Freshdesk with AI before your rule list gets unwieldy.

Retries, rate limits, and delivery

A webhook is only useful if it actually arrives, and endpoints go down. Freshworks documents sensible-but-modest guarantees here, and they are worth committing to memory.

Retries. If a callback returns anything other than a 2xx or 3xx status, Freshdesk retries it automatically — "once every 30 minutes, totalling 48 calls." That works out to roughly a 24-hour retry window. It is a safety net, not a queue with strong ordering guarantees, so treat your receiver as something that must be idempotent (handle the same ticket update arriving twice without double-acting).

Rate limits. Webhook calls are capped at 1,000 calls per hour; anything over the limit is buffered "until fresh calls are available after 1 hour." For most teams that ceiling is invisible, but a noisy bulk update — re-tagging thousands of tickets at once — can bump it. This sits alongside Freshdesk's broader API ceilings, which we break down in Freshdesk API rate limits.

The honest limits — and where an AI layer picks up

Webhooks are genuinely good infrastructure. They are deterministic, low-latency, and they mean you never poll. If you have an endpoint and a clear rule, Freshdesk will faithfully push the right JSON to it every time. Credit where it is due — this is native, reliable plumbing, and for straightforward "when X, notify Y" jobs you do not need anything more.

But be clear-eyed about the shape of what a webhook is. First, it is plan-gated: Trigger Webhook needs Growth or above, and the response-aware Trigger API needs Pro or above, so the capability may simply be out of reach on your tier. Second, a webhook is dumb by design — it fires a fixed payload you hand-authored to a URL you hard-coded. It does not read the ticket, understand intent, or decide whether the action even makes sense; it does exactly what the rule says, every time, whether or not it is the right thing. Third, when you need to react to a response — fetch an order status, branch on a subscription tier, transform a value — you are into Trigger API and hand-written JavaScript, which is real engineering to build and maintain.

That third gap is where an AI agent layer fits, and it is worth weighing the build-versus-buy tradeoff honestly. The broader category of AI agents for customer service exists to do the reasoning a static webhook can't. Macha is one such layer, and the framing matters: it runs on top of the Freshdesk you already use as a native connector — it does not replace your help desk, its automation rules, or its webhooks. You connect Macha to Freshdesk with your subdomain and API key, and instead of hand-authoring a payload for every branch, an agent reads the ticket, decides what to do, and calls your external systems through a custom tool that wraps a REST endpoint into something it can invoke with the right arguments — including reading the response back and acting on it, which is precisely the part a fire-and-forget webhook can't do.

The clean division of labour: keep Freshdesk webhooks for deterministic, one-way "when this, tell that" pushes, and layer an agent on top for the reasoning-heavy calls where the payload, the endpoint, and the decision all depend on what the ticket actually says. (Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller. And credits are consumed per AI action, not per resolution — see the pricing breakdown.)

FAQ

What is a webhook in Freshdesk? A webhook is a "Trigger Webhook" action inside an automation rule that makes Freshdesk send an outbound HTTP request to a URL you specify when a ticket is created or updated, carrying ticket data in the body. It lets external systems react to ticket events without polling Freshdesk's API.

Which plans support Freshdesk webhooks? The Trigger Webhook action is available on the Growth, Pro, and Enterprise plans (for both Freshdesk and Freshdesk Omni). The response-aware Trigger API action is available from the Pro plan onward. On lower tiers the webhook action does not appear in the automation rule's action list.

How do I customise the webhook payload? Choose JSON encoding and "Advanced" content, then write the request body by hand using double-brace placeholders such as {{ticket.id}}, {{ticket.subject}}, and {{ticket.from_email}}. Wrap string placeholders in quotes and leave numeric ones (like group_id) unquoted so they stay numbers.

What happens if a Freshdesk webhook fails? If the callback returns anything other than a 2xx or 3xx status, Freshdesk retries it automatically once every 30 minutes, totalling 48 calls (roughly a 24-hour window). Because retries can deliver the same event twice, your receiving endpoint should be idempotent.

Can I add AI to Freshdesk webhooks without replacing Freshdesk? Yes. An AI agent layer like Macha connects to Freshdesk as a native connector and runs on top of your existing automation rules and webhooks — it doesn't replace them. Where a static webhook fires a fixed payload, an agent reads the ticket, decides what to do, and calls your APIs (reading the response back), while Freshdesk stays the system of record.

Ready to go beyond fire-and-forget payloads? Start a free trial of Macha and connect it to your Freshdesk in minutes.