When a customer says that they have configured a webhook but it did not perform the desired action, you can get the below details from the customer:


  1. The screenshot of the rule configuration including the rule ID
  2. The screenshot of the ticket activities
  3. The use case they are trying to solve via the webhook action


Once you have obtained these details, you can examine the API call being triggered and the payload being sent. If any discrepancies or errors are found, you can advise the customer on the necessary changes.


For instance, consider the following scenarios:

  • The customer intends to create a new ticket whenever a customer responds to a closed ticket, but they have provided an incorrect callback URL. If they are using "https://domain.freshdesk.com/api/v2/tickets/{{ticket_id}}", which is incorrect because it is the endpoint for updating a ticket, you can inform the customer to use "https://domain.freshdesk.com/api/v2/tickets" instead, as it is the correct endpoint for creating a ticket.


  • The customer aims to update ticket properties through a webhook and has provided the following payload:

{

    "description": "{{ticket.latest_public_comment}}",

    "subject": "{{ticket.subject}}",

    "email": "{{ticket.from_email}}",

    "priority": {{ticket.priority_id}},

    "status": 2,

   “cf_ticket_handled_by”: “{{ticket.cf_ticket_handled_by}}”

}


Here “cf_ticket_handled_by” is a custom field but this has to be passed under the “custom_fields” section as below:


{

    "description": "{{ticket.latest_public_comment}}",

    "subject": "{{ticket.subject}}",

    "email": "{{ticket.from_email}}",

    "priority": {{ticket.priority_id}},

    "status": 2,

     “custom_fields”:{

     “cf_ticket_handled_by”: “{{ticket.cf_ticket_handled_by}}”

}

}


If you are unable to locate the issue, you can follow the below steps:


1. Fetch the backend ticket ID (https://companyname.freshdesk.com/helpdesk/tickets/.xml) for the affected ticket under the section. The “id” attribute will give you the backend ticket ID.


2. Navigate to the POD-specific Haystack application and enter the below search query:


AND and narrow down using the event ID you are receiving:



3. Search for “x-request-id” and drill down the logs using it:





4. The x-request-id logs will give you a more detailed explanation of why the webhook failed:



This error message will be returned when the syntax of the payload is incorrect or if a NULL value is passed to any of the fields.


You can find if any NULL values are passed under the WEBHOOK: TRIGGERED event:



As you can see, a NULL value is passed in the “group_id” field.