You can create an Observer rule to trigger a webhooks call as soon as the events you specify occur.


What is a webhooks? Why does it matter?


A Webhook is a “callback” to an application or web service that is triggered when a specific event occurs. What that means is that a webhook lets you look for a specific update, change or action to occur and automatically pushes the information you specify to the place you want.


The Observer can be used to trigger a Webhook when a specific Event occurs.


What can you do with a webhooks call from the Observer?


The Observer is a trigger-automation that gets fired when a specific event occurs on a ticket. Using just the Observer, you can update, modify, send notifications and run actions within Freshservice. For example, you could update ticket priorities, send out escalation emails, etc.


Webhooks come handy when you want to trigger an action in an external application or tool. Here are some example scenarios when you might want to use Webhooks:


What you want to do

Conditions to look for

What the Webhook should call

Send out a SMS/ text message when customer replies to ticket

Customer replies to ticket (or adds comment)

Send comment content to 3rd party SMS tool

Update inventory when a Product Return request is updated

Ticket category (a custom field) is updated to "Product Return"

Update product info in store inventory

Sync status for Feature Requests with internal Product Management tool

Status is Updated for Tickets of type "Feature Request"

Update product management tool with ticket information

Sound alarm bells and sirens when Bad Customer Satisfaction rating is received

Customer Feedback is Received, and Rating is "Not Good"

Customize a Smart Bulb (like this or this) and a siren sound board to fire up triggered by this Webhook



Quick guide to setup a webhook request with the Observer:

  • Create a new Observer rule and select the Triggers and Conditions (learn how).

  • Under Actions, select the "Trigger Webhook option from the drop-down.

  • Choose the Callback Request Type.

  • While each 3rd party app may use a request type in a different way, most applications follow standard methods:

    • GET Requests are typically used to retrieve one or all resources.

    • POST Requests usually create new resources.

    • PUT and PATCH Requests are used to update a resource.

    • DELETE Requests are usually used to delete a resource.

  • Specify the callback URL (configured for webhook) of the application you want to hit. You can make the URLs dynamic using placeholders.

    • For example, if you want to pass along a callback url of the form: http://yourapp.com/yourInfo?email=[user email], you can substitute the user email part with the {{requestor.email}} placeholder.

  • Pick the encoding of your request that the resource application supports (JSON, XML or XML-Encoded).

  • To simply send a list of ticket properties that you want in this webhook, select the Simple content option.

  • If you would like to customize the content that is being sent, select Advanced.

    • The advanced option lets you write custom API requests. These requests have to be encoded in the format you chose in the previous step.

    • You can use requestb.in or postman - REST client (a google chrome extesion) for testing out APIs.

  • The {{Triggered event}} placeholder is available only in Webhooks, and returns the name of the event that triggered the rule.

  • Webhook Callback Request Limits: The number of webhook requests you can use in 1 hour is limited to 1000 calls. If the status codes are between 200 and 299, the callback is a success and status codes between 300-399 will be taken as callback redirects. When a callback fails (status codes other than 2xx and 3xx), the webhook will automatically be retried once every 30 minutes, totalling 48 calls. Calls requested after the rate limit will be buffered until fresh calls are available after 1 hour.