What is a Webhook?
A Webhook is a “callback” to an application or web service that is triggered when a specific event occurs. When certain update, change or action occurs, Webhooks can be used to push data to an external application
The Workflow Automator can be used to create workflows to trigger a Webhook when a specific Event occurs.
What can you do with a webhooks call?
Using Automator you can create workflows, that fires certain actions when a specific event occurs on a ticket. Using the Automator, 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 |
How to set up a webhook request with the Automator:
Let's consider the following use case:
Create a change automatically whenever a ticket is a change request.
Create a new Workflow using the Workflow Automator. Drag and drop the Events and Conditions that should trigger the webhook.
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.
In this example, we create a POST request as we have to create a new change in the change module.
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.
Testing Webhooks
When you have large workflows with complex webhook calls, testing them becomes mandatory. Activating workflows to test the webhooks isn’t the most optimal way of testing them. Instead, you can test your webhooks right within the Workflow Automator.
For example, when you set up a webhook to create a change ticket in the change module and hit the Test webhook button, a test ticket is created in the change module if the test is successful.
API requests that result in errors will return an appropriate HTTP status code to help you identify the type of error. You can use this table to understand what each code means.
Note: Placeholders are not supported to Test Webhooks.
If you require authentication, you can enable Requires Authentication check box. You can use either a Username/Password or an API key for authentication. We use the API key of the Freshservice account being configured in this use case.
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 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), or doesn't receive a response in 15s, the webhook will be automatically retried a maximum of 4 times at 3, 5, 9 ,17-minute intervals
Once the above automation is enabled, any ticket coming in with a type "Change request" will automatically create a change in the change module.