How to Set Up a Webhook in Freshdesk

What a Freshdesk webhook actually is

A webhook is a "callback" — an HTTP request Freshdesk sends automatically when an event you've defined occurs. In practice it's an API call bolted onto an automation action. Freshdesk gives you two flavours, and picking the right one matters. Per Freshworks' Using webhooks in automation rules documentation:

• Trigger Webhook is fire-and-forget. Freshdesk sends the request and doesn't use the response for anything downstream. Use this to push data outward — updating an external CRM, notifying a channel, logging an event.
• Trigger API is used when you need the response for a subsequent action, or want to run JavaScript on ticket fields. It's the heavier tool for chained logic.

For most integration work — "when X happens, tell system Y" — Trigger Webhook is the one you want.

Before you start: plan gating and rate limits

Two facts to get straight before you build anything. First, the webhook action is plan-gated. Freshworks documents it as available on the Growth, Pro, and Enterprise plans (and their Freshdesk Omni equivalents) — not the free tier. If you're on a trial or a starter plan, the "Trigger Webhook" action simply won't appear in the action list, so this walkthrough is something you'll implement once you're on a qualifying plan.

Second, there's a ceiling. Freshdesk caps webhook calls at 1,000 per hour. Any request that comes back with a non-2xx/3xx status is treated as failed and retried every 30 minutes for up to 48 attempts — roughly a day of retries before Freshdesk gives up. That retry behaviour is a gift when your endpoint has a blip, but it means a genuinely broken endpoint will keep hearing from Freshdesk for a while, so build your receiver to be idempotent.

Step 1: Create the automation rule that hosts the webhook

The webhook doesn't live on its own — it's an action inside an automation rule, so you build the rule first.

1. Go to Admin → Workflows → Automations (in Freshdesk Omni: Admin Settings → Configuration and Workflows → Ticket Automations).
2. Choose the tab that matches when you want the webhook to fire — Ticket Creation for events at intake, or Ticket Updates for events on an existing ticket — and click New Rule.
3. Name the rule and set your conditions (the Event → Condition part of the builder) so the webhook only fires when it should — say, when status changes to Resolved, or when a ticket is tagged escalate.

This is the screen where the whole thing comes together. The rule builder is a three-part flow — event, condition, action — and the webhook is what you add in that final action slot.

Step 2: Add the Trigger Webhook action

Under "Perform these actions," select Trigger Webhook. Now you fill in the four pieces every webhook needs.

Request type. Choose the HTTP method that matches what you're doing:

• GET — retrieve a resource (note you won't be able to use the response in a Trigger Webhook).
• POST — create a new resource.
• PUT / PATCH — update an existing resource.
• DELETE — remove a resource.

Callback URL. This is where the request goes, and it's the most powerful field because it accepts placeholders. To act on the ticket that triggered the rule, you interpolate its ID straight into the path. Freshworks' own example for adding a note to a ticket is:

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

Any placeholder that resolves at runtime works here — {{ticket.id}}, {{ticket.group_id}}, and webhook-only extras like {{Triggered event}}, which returns the name of the event that fired the rule.

Step 3: Authentication, headers, and encoding

Authentication. Toggle "Requires authentication" and supply your API key. If your endpoint is Freshdesk's own API (a common pattern — using a webhook to update the very ticket that triggered it), the key is the one from your agent profile settings.

Custom headers. Toggle "Add custom headers" to pass along API versions, security tokens, or content negotiation. The format is a header-value pair, one per line, like:

X-Sample-CustomHeader1: VALUE

Header names are not case-sensitive, and you can stack several on separate lines.

Encoding. Pick the encoding your receiving application expects — JSON, XML, or XML-Encoded. JSON is the default choice for most modern endpoints.

Step 4: Build the body — Simple vs Advanced

The last piece is the payload. Freshdesk gives you two content modes:

• Simple lets you tick a list of predefined ticket properties to include — quick, no templating required.
• Advanced lets you write the exact request body yourself, with placeholders, which is what you want for anything non-trivial.

Here are real, documented Advanced bodies from Freshworks' webhook examples. To create a follow-up ticket when a customer responds (POST to the Create ticket endpoint):

{
  "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}}"
}

Note the templating detail that trips people up: string fields wrap the placeholder in quotes ("{{ticket.subject}}"), while numeric fields like group_id do not ({{ticket.group_id}}) — because the value must land as a JSON number, not a string. Get that wrong and your endpoint rejects the payload.

A simpler PUT that prefixes the company name onto the subject line:

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

All the documented examples use JSON encoding with Advanced content and API-key authentication enabled.

Step 5: Test with a request-bin before you trust it

Never point a new webhook at production first. Use a throwaway request-bin — a free service like Webhook.site, RequestBin, or Beeceptor that gives you a unique URL and shows you every request it receives, headers and body included.

1. Generate a bin URL from your chosen service and copy it.
2. Paste it as the callback URL in your Trigger Webhook action (temporarily), keep the method and body you plan to use, and save the rule.
3. Trigger the condition on a real ticket — change the status, add the tag, whatever your rule watches for.
4. Refresh the bin and inspect what arrived: the HTTP method, the resolved URL, the headers, and the fully-rendered JSON body with placeholders substituted.
5. Confirm the placeholders resolved to real values (no stray {{ticket.id}} text) and the JSON is valid, then swap the bin URL for your real endpoint.

This one habit catches the majority of webhook bugs — malformed JSON, an unquoted string, a placeholder that didn't resolve — before they ever hit a live system.

The honest limits — and where an AI layer picks up

Freshdesk's webhook engine is genuinely capable: it's deterministic, it retries on failure, and with placeholder templating you can shape almost any payload. Credit where it's due — for "when X happens, send this exact request to Y," it's the right tool, and you shouldn't reach for anything heavier.

But be clear about what it is: a fire-and-forget messenger. A Trigger Webhook sends a fixed, templated request and moves on — it can't read the customer's message, decide what the right action is, branch on nuance, or use the response to do something smart next. It fires the same shaped payload every time its condition matches. The moment your logic becomes "look at what the customer actually asked, check three systems, and take a different action depending on the answer," a webhook alone can't carry it — you're into custom middleware, or a Trigger API with hand-written JavaScript, and the maintenance that implies.

The other constraint is the gating itself: the webhook action is a Growth-and-above feature, so teams on lower plans can't use it at all, and the 1,000-calls-per-hour ceiling means very high-volume, per-ticket fan-out needs planning.

This is the seam where an AI agent layer fits, and it's worth understanding the build-versus-buy tradeoff before you wire up a pile of brittle webhooks. The broader category of AI agents for customer service exists to do the reasoning a static webhook can't. Macha is one such layer: it runs on top of the Freshdesk you already use as a native connector — it does not replace your help desk or your automation rules. You connect Macha to Freshdesk with your subdomain and API key, and it reads and writes the same tickets, but instead of firing a fixed payload it reasons: it reads the ticket, decides what's needed, and calls your external APIs through a custom tool — the same REST endpoints a webhook would hit, except the agent chooses when and how based on the ticket's actual content. If you're weighing that against native rules, our guide to automating Freshdesk with AI maps out where each approach wins. (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.)

The clean division of labour: keep Freshdesk's webhooks for deterministic, "always do this exact thing" outbound calls, and layer an agent on top for the parts that need judgement — reading intent, deciding the action, and calling the right API with the right arguments.

FAQ

Where do I set up a webhook in Freshdesk? A webhook is an action inside an automation rule. Go to Admin → Workflows → Automations, open the Ticket Creation or Ticket Updates tab, create a New Rule, and under "Perform these actions" choose Trigger Webhook. The action is available on the Growth, Pro, and Enterprise plans.

What's the difference between Trigger Webhook and Trigger API? Trigger Webhook is fire-and-forget — Freshdesk sends the request and ignores the response. Trigger API is for when you need the response for a later action or want to run JavaScript on ticket fields. For pushing data to an external system, Trigger Webhook is the right choice.

How do I put ticket data into the webhook URL or body? Use placeholders. In the callback URL, {{ticket.id}} interpolates the triggering ticket's ID (e.g. https://acme.freshdesk.com/api/v2/tickets/{{ticket.id}}/notes). In the JSON body, wrap string values in quotes ("{{ticket.subject}}") and leave numeric values unquoted ({{ticket.group_id}}) so they render as JSON numbers.

Are there rate limits on Freshdesk webhooks? Yes. Freshdesk allows up to 1,000 webhook calls per hour. Requests that return a non-2xx/3xx status are retried every 30 minutes for up to 48 attempts, so design your receiving endpoint to be idempotent.

Can I add AI-driven actions to Freshdesk without replacing it? Yes. An AI agent layer like Macha connects to Freshdesk as a native connector and runs on top of your existing help desk and automation rules — it doesn't replace them. Where a webhook fires a fixed payload, an agent reads the ticket, decides what to do, and calls your APIs through custom tools based on the actual content.

Ready to move from fire-and-forget webhooks to agents that reason over your tickets? Start a free trial of Macha and connect it to your Freshdesk in minutes.