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


What is a webhooks call?


A webhook is a 'callback' to an application or web service that is triggered when a specific event occurs; essentially, a webhook lets you look for a specific update, change or action and, once it occurs, it automatically pushes the information you specify wherever you want.


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


The Observer is a trigger-based automation that fires when a specific event occurs on a ticket. Using just the Observer, you can update, modify, send notifications and run actions within Freshdesk. For example, you can update ticket priorities, send out escalation emails and so on.


Webhooks also come handy when you want to trigger an action in an external application or tool (as well as some updates that the Observer can't perform, such as updating the time entry on a ticket or adding a note to a ticket). Here are some examples of scenarios in which you could use webhooks:


What you want to do
Conditions to look for
What the webhook should call
Send out a SMS/text message when a customer replies to a ticket
Customer replies to ticket (or adds comment)
Send comment content to third-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 the alarm when a Bad Customer Satisfaction rating is received
Customer feedback is received, and the rating is 'Not Good'
Customize a Smart Bulb and a siren soundboard to fire up triggered by this webhook


 

           

A quick guide to setting up a webhook request with the Observer

  • Create a new Observer rule and select Triggers and Conditions (learn how).
  • Under perform these actions, select the Trigger Webhook option.
    • Choose the Callback Request Type. While each third-party app may use a request type in a different way, most applications follow these 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.

If you want to set up a rule to add a note to a ticket based on certain conditions and triggers, it's POST because you're adding a note (more info here).

  • Specify the callback URL (configured for webhook) of the application you want to hit. You can make the URLs dynamic using placeholders.
  • Add custom headers to convey additional information such as security details, API version details and so on. A custom header has to be entered as a header-value pair following the specified format X-Sample-CustomHeader1: VALUE.

    Note: The trigger will not be executed when a header is given with spaces in between, like X-Sample Custom Header1: VALUE. Although, if a space is entered at the end of the header, it will be skipped.

  • A header containing more than one value should be separated by delimiters (commas and colons cannot be used as delimiters). To add a second header, enter the custom header and value pair in the next line.
  • Pick the encoding of your request that the resource application supports (JSON, XML or XML-Encoded). For the note addition example, it's JSON.
  • To simply send a list of ticket properties that you want in this webhook, select the Simple content option. Adding a note doesn't require any of the usual ticket properties so you'll have to write a custom API request.
  • 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. For our note addition example, this is what the API request would look like: 

                

      {
                         "helpdesk_note": {
                          "body":"Hi {{ticket.requester.name}}, we're looking into this. Sit tight.",
                          "private": false
                          }
       }

  

If you'd like to add a private note, put 'private: true' in the request. You can also customize the content in your API requests by making them dynamic using placeholders. If you'd like to do more with the Freshdesk API than just add a note, a multitude of options are available. You can use requestb.in or postman - REST client (a Google Chrome extension) 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 an 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, totaling 48 calls. Calls requested after the rate limit will be buffered until fresh calls are available after 1 hour. 


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


What is a Webhooks call? 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 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 in Freshdesk 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-based 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 Freshdesk. For example, you could update ticket priorities, send out escalation emails, etc. 


Webhooks also come handy when you want to trigger an action in an external application or tool (as well as some updates that the Observer can't perform, like update time entry on a ticket or add a note to a ticket). 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 and a siren soundboard to fire up triggered by this Webhook


 

           


A 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.

          If you want to set up a rule to add a note to a ticket based on certain conditions and triggers, it's POST because you're adding a note (How did I know that?).

  • Specify the callback URL (configured for webhook) of the application you want to hit. You can make the URLs dynamic using placeholders.         
  • Add custom headers to pass along some additional information with the content such as security details, API version details and so on. A custom header has to be entered as a header-value pair following the specified format X-Sample-CustomHeader1: VALUE.         

    Note: The trigger will not be executed when a header is given with spaces in between, like X-Sample Custom Header1: VALUE. Although, if a space is entered at the end of the header, it will be skipped.

  • A header containing more than one value should be separated by delimiters (Comma and colon cannot be used as delimiters). To add a second header, enter the custom header and value pair in the next line.
  • Pick the encoding of your request that the resource application supports (JSON, XML or XML-Encoded). For the note addition example, it's JSON.
  • To simply send a list of ticket properties that you want in this webhook, select the Simple content option. Adding a note doesn't require any of the usual ticket properties so you'll have to write a custom API request.
  • 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. For our note addition example, this is what the API request would look like: 

                

      {
                         "helpdesk_note": {
                          "body":"Hi {{ticket.requester.name}}, we're looking into this. Sit tight.",
                          "private": false
                          }
       }

  

                   If you'd like to add a private note, put 'private: true' in the request. You can also customize the content in your API requests by making them dynamic using placeholders. If you'd like to do more with the Freshdesk API than just add a note, a multitude of options are available. You can use requestb.in or postman - REST client (a google chrome extension) 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, totaling 48 calls. Calls requested after the rate limit will be buffered until fresh calls are available after 1 hour.