Freshdesk Webhook Setup Guide

Sign in to your Freshdesk account as an admin, then open Admin.

• Click Workflows in the left menu to jump to the ticket routing and resolution settings.

In the Workflows group, click Automations — the card described as “Eliminate repetitive tasks such as categorization and routing by creating rules”.

On the Automations page, select the Ticket Creation tab and click New rule. Give the rule a name such as StackOne Ticket Created.

• Note: check the execution mode shown above the rule list. When it reads Executing first matching rule, only the first matching rule runs — place this rule first, or an earlier rule will stop it from firing.

Under Condition, set one row to In Tickets > if Created > During > Business Hours and leave Match ANY of the below selected. A ticket creation rule cannot be saved without at least one condition.

• Tickets raised outside your business hours do not match this condition, so no event is sent for those. Business hours are set under Admin > Business Hours.
• To deliver every ticket instead, use a condition every ticket satisfies — for example Priority with all four values Low, Medium, High, and Urgent selected.

Under Action, open Choose action.

Select Trigger webhook from the action list. Typing Trigger filters the list, which holds 22 actions.

Paste the Native Webhook URL you copied earlier into URL, and leave Encoding set to JSON.

• Leave Requires authentication off — the secure key in the URL authenticates the delivery.
• Leave Add custom headers off.

Leave Content set to Simple, then open Placeholders. Ticket ID and Triggered Event are required — select both. Every other property in the list is optional; add any you also want on the event.

• Neither required property has a fallback. Ticket ID becomes the event’s record id, and Triggered Event becomes the event type and decides whether the delivery is handled as a created or an updated ticket.
• Without Triggered Event, the delivery matches no event handler and is not emitted at all. Without Ticket ID, the event is emitted with an empty record id and consumers cannot tell which ticket it refers to.
• Add any other properties you want included in the event payload.

Click Preview, check the summary, then click Save and enable.

On the Automations page, select the Ticket Updates tab and click New rule. Name it something like StackOne Ticket Updated.

Under Action performed by, choose who has to make the change for the rule to fire. This is your decision — it decides which updates reach StackOne.

• Agent — changes made by an agent in Freshdesk
• AI Agent — changes made by Freddy AI
• Requester — changes made by the customer, such as a reply
• Agent or requester — either of the two above, the widest human coverage
• System — changes Freshdesk makes automatically, such as an SLA escalation
• Collaborator — changes made by a collaborator on the ticket
• Only the performers you select here produce events. If you pick Agent alone, a customer reply that changes the ticket will not be delivered.

Under Event, open Choose event and select a change to watch. Click Add new event to watch more than one.

• A ticket update rule fires only on the changes you select here — a rule watching Priority is changed does not fire when the status changes.
• Available changes include Priority is changed, Status is changed, Type is changed, Group is updated, Agent is updated, Note is added, Reply is sent, and Due date is changed.

Unlike a ticket creation rule, an update rule saves with an empty Condition block — you are not forced to add one. Leave it empty to receive every change you selected above, and add conditions only when you want to narrow which tickets qualify.

Configure the action exactly as you did on the Ticket Creation rule, using the same Native Webhook URL. Nothing here differs between the two rules.

• Under Action, open Choose action and select Trigger webhook.
• Set Request type to POST.
• Paste the same Native Webhook URL into URL.
• Leave Encoding set to JSON, and leave Requires authentication and Add custom headers off.
• Leave Content on Simple and select both Ticket ID and Triggered Event — the same two required properties, plus any optional ones you want.

Click Preview, check the summary, then click Save and enable.

Two kinds of delivery are possible, one per rule type.

• Ticket Created — sent by a ticket creation rule when a newly raised ticket matches its conditions.
• Ticket Updated — sent by a ticket updates rule when a ticket change matches the events and conditions it watches.

The event type on each delivered event is the Triggered Event value exactly as Freshdesk produced it.

• A created ticket delivers the event type {ticket_action:created}
• A ticket change delivers a change descriptor naming the changed property with its old and new values, for example {priority:{from:1,to:3}} or {status:{from:2,to:3}}
• Because an update value carries the values that changed, it differs on every delivery — match on the event’s record id or the handler that produced it rather than on the event type.

Freshdesk sends one POST per matching ticket, with content-type: application/json. Deliveries are not batched. The ticket properties you selected arrive inside a freshdesk_webhook object.

• The selected properties are passed through to the event unchanged, so any extra property you tick is available on the event as well.
• Freshdesk sends no signature header and performs no verification handshake — the secure key inside the Native Webhook URL is what authenticates the delivery.

Freshdesk offers no placeholder for a ticket’s created or updated timestamp, so neither can appear in the payload. Fetch the ticket by its id if you need those values.

A failed delivery is retried every 30 minutes for up to 48 attempts. Freshdesk allows a maximum of 1000 webhook calls per hour per account, shared across every automation rule.

Only ticket creation and ticket updates rules can send a webhook. Hourly Triggers rules cannot, so time-based events such as SLA breaches and ticket ageing cannot be delivered.