Preventing Duplicate Ticket Creation in Custom Ticketing Integrations via Webhooks

Preventing duplicate ticket creation in custom ticketing integrations via webhooks

Issue

Alerts sent from Site24x7 to a webhook fail with a 400 error and are marked as duplicate events by the third-party system. 

Common cause

This issue is likely caused by a possible misconfiguration in the Update URL and Close URL settings of the custom ticketing webhook:
  1. Missing ticket identifier:
    1. The [TICKET_ID] placeholder is not included at the end of the Update and Close URLs.
    2. Without this, the system cannot identify which ticket to update or close, leading to the creation of a new ticket instead.
  2. Incorrect HTTP methods:
    1. Update and close operations are often configured to use POST.
    2. Standard practice typically requires PATCH or PUT for updating existing tickets and PUT/PATCH for closing tickets, depending on the third-party API specification.
  3. Using the same parameters:
    1. The system might use the same parameters for both update and close operations, leading to conflicts or duplicate ticket creation.

Root cause (RCA)

In custom ticketing integrations:
  1. When a monitor status changes to UP, the standard workflow is:
    1. Update the existing ticket with the latest details.
    2. Close the existing ticket.
  2. If the webhook URLs do not include [TICKET_ID] or use the wrong HTTP method:
    1. The system creates new tickets instead of updating or closing existing ones.
    2. Subsequent operations detect that the parameters that are sent from Site24x7, such as incident_time, already exist, causing a duplicate event error.
This behavior affects both MSP users and standard Site24x7 users.

Solution

To prevent duplicate ticket creation and ensure proper ticket life cycle management:
  1. Log in to Site24x7.
  2. Navigate to Admin >Third-Party Integrations and choose your existing integration on the webhook that generates duplicate tickets.
  3. In the Manage Tickets Configuration section, under the Update Request and Close Request sections, include [TICKET_ID].
    1. Append $TICKET_ID to the end of the Hook URL.
      Example:
      Update Hook URL: https://example.com/api/rest/$TICKET_ID/notes
      Close Hook URL: https://example.com/api/rest/$TICKET_ID/notes
  4.  Choose the correct HTTP methods as shown below:
    1. Update: PATCH or PUT (depending on the API)
    2. Close: PUT or PATCH (depending on the API)
  5. Choose Custom Parameters if needed.
    1. Avoid using the same incident parameters for both Update and Close URLs.
    2. Configure custom parameters to differentiate operations and prevent conflicts.
  6. Test the workflow: After updating the URLs and methods, test the entire life cycle (alert > update > close) to confirm proper behavior.

Conclusion

Duplicate tickets typically occur due to a missing [TICKET_ID] in webhook URLs and incorrect HTTP methods. Correcting the URLs, using proper HTTP methods, and customizing parameters ensures seamless ticket updates and closures without generating duplicates.
    • Related Articles

    • How can I choose resources in a monitor group for third-party integration

      By associating the monitor group with a tag, you can select the resources in a monitor group for third-party integration. Read how to add a tag to a monitor group.    Once you have added a tag to the group, choose the tag to integrate the resources ...
    • How to integrate Site24x7 with an LLM

      You can integrate LLMs with Site24x7 monitors to derive an overall summary of your monitors. The Zia Bot can answer all your queries regarding the monitors to which you have access and answer basic questions about all monitors. The Zia Bot uses the ...
    • Site24x7 to ServiceNow CMDB integration: CI mapping reference

      Site24x7 provides integration with ServiceNow, allowing seamless population of Configuration Items (CIs) in your ServiceNow CMDB based on your monitored resources in Site24x7. This article provides a reference for the field mappings used during the ...
    • FAQ on Custom Roles

      What is the Created permission and what does it allow users to do? The Created permission is a specific type of access control that permits users to perform actions such as View, Write, or Delete solely on the modules, like dashboard, that they have ...
    • What are Incident Parameters and Custom Parameters?

      Incident and Custom parameters get passed along with the body of the URL during an HTTP request invocation. Incident Parameters Incident Parameters are predefined system parameters passed in the invoked URL's body. In the HTTP response, the Incident ...