> For the complete documentation index, see [llms.txt](https://docs.enate.net/enate-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enate.net/enate-help/integrations/enate-integrations/webhooks/webhook-troubleshooting.md). # Webhook Troubleshooting A list of commonly asked questions regarding Enate Webhooks. ## Webhook Troubleshooting **Q: In the event of the external system being down, or a failure response, does the Enate system retry?**\ A: YES, up to a point. Enate makes up to 10 delivery attempts in total for each message, including the first. A failed attempt puts the message back on the queue and Enate tries again. After the tenth failed attempt the message is moved to a dead letter queue, so it isn't retried further and won't reach your endpoint. There's no notification that it happened, and the subscription itself stays active, so the next event is attempted normally. See Webhook Delivery and Failure Handling for the detail. **Q: Can I see or replay messages that failed?**\ A: Not yourself. Messages that fail all 10 attempts go to a dead letter queue, but there's no feed of them and no replay option in the UI or through the API. If completeness matters for your process, reconcile against the Enate APIs rather than relying on having received every message, and raise a support ticket if you need to know what was in a gap. **Q: My endpoint returned a 400 to reject an event. Why does Enate keep sending it?**\ A: Because Enate treats every non-2xx response the same way. A 400, a 404 and a 500 are all just failures, and all of them are retried up to the limit. You can't decline an event by replying with a client error code. If you want to stop receiving an event, unsubscribe. If you want to ignore one message, return a 2xx and discard it at your end. **Q: How long does my endpoint have to respond?**\ A: Enate doesn't set a timeout of its own, so the platform default of around 100 seconds applies. An endpoint that takes longer is treated as a failure and the message is retried, even if your system went on to process it successfully. Reply with a 2xx quickly and do your processing afterwards. **Q: Can I tell whether a Webhook message came from a test work item or a live one?**\ A: NO, not currently. Work items running against a process version in Testing state raise the same Webhook events as live ones, and the message body has no field that distinguishes them. The Enate APIs don't expose one either, so you can't look it up afterwards. If you need to keep test activity out of a downstream system, scope your subscriptions so it never matches, for example by running process trials under a Contract or Service you haven't subscribed to, or keep the subscription pointed at a non-production endpoint until the process goes live. **Q: Is there a possibility of duplicate events?**\ A: YES. Duplicate events can occur, for instance multiple updates to a work item occurring in quick succession, or when an email is received, which triggers a NewCommunication Webhook and may very likely then trigger a PacketUpdated one too if the incoming email changes the work item's state. A retry will also resend a message your endpoint had already processed, if it failed to return a 2xx response in time. Build your endpoint to handle the same event arriving more than once. **Q: Will messages arrive in the order the events happened?**\ A: NO, that isn't guaranteed. A retried message can arrive after a later one has already been delivered. Treat each message as a snapshot of the moment it was produced, and call the Enate API if you need the authoritative current state of a work item. **Q: I started several hundred work items at once. Will my endpoint get hit with all of them together?**\ A: No. Enate delivers Webhook messages with limited concurrency per Enate instance, so a large batch arrives as a stream spread over a short period rather than all at once. The limit scales with the size of your Enate instance. A slow endpoint will still hold up the messages queued behind it, so accept quickly and process asynchronously if you're integrating at volume. **Q: Is there a standard response structure for Enate Webhooks?**\ A: NO. Response structures can be different between Webhooks. Please see the List of Enate's Webhooks for the specifics of each response structure, with a worked example of each. **Q: Why are the enum values in my message numbers rather than names?**\ A: That's expected. Enate sends enumerations as their integer values in both Webhook messages and API responses, so a Case arrives as `"ProcessType": 1` rather than `"ProcessType": "Case"`. The same applies to requests, so send `"Webhook": 0` when subscribing, not `"Webhook": "PacketCreated"`. The Message Returned Explanation table lists every value. **Q: If I've unsubscribed from a Webhook, what is the procedure for re-subscribing. Is there some kind of 'reactivation' approach?**\ A: NO, this is a simple case of adding a subscription again, as you did when first subscribing to it. The new subscription gets a new GUID and a new signature, so update whatever your endpoint checks the `x-enate-signature` header against. **Q: Is it mandatory to supply an Entity for a Webhook?**\ A: `FilterObjectType` is always mandatory. `FilterObjectGUID` depends on the Webhook. PacketCreated, PacketUpdated, NewCommunication and SpecificBusinessObjectUpdated all need one. BusinessObjectCreated and BusinessObjectTypeUpdated don't, because they're scoped by object type rather than to an individual object. **Q: Can the same subscriber URL be used in multiple subscriptions?**\ A: Yes, it is possible for the same subscriber URL to be used in multiple subscriptions. However, it may be preferable to create different URLs for each subscription to prevent bottlenecks and to create more logical routes for messages into downstream systems. Note that you can't create two subscriptions that are identical in every respect, so if you're reusing a URL something else about the subscription has to differ. Bear in mind that Enate sends one POST per event per matching subscription, so two subscriptions that both match an event will both fire. **Q: How can I identify whether the Webhook update is for a Case or Ticket or Action?**\ A: The ProcessType field will indicate the type of work item, i.e. 1 = Case, 2 = Ticket, 3 = Action. A more informative approach would be to add some identifying information to the custom header when creating the Webhook subscription. This header information will then be included with every message sent out, i.e.: * "CustomHeader": "Update-ticket-200243-T-subscription" * "CustomHeaderValue": "Ticket 200243-T has been updated" **Q: My custom header name came back different to the one I supplied. Why?**\ A: Spaces aren't valid in HTTP header names, so Enate replaces any space in `CustomHeader` with a hyphen when the subscription is saved. A header name of "Update ticket subscription" is stored and sent as `Update-ticket-subscription`. **Q: Can Webhook Subscriptions be seen by other users?**\ A: Yes. The Get All Webhook Subscriptions operation returns every Webhook subscription in your Enate instance, not just the ones your account created. What each subscription actually delivers is a separate matter: the permissions of the account that created the subscription are applied every time a message is prepared, so a subscription only sends messages about data that account can see. **Q: My subscription stopped sending messages and I didn't change anything. What happened?**\ A: There are three likely explanations, in rough order of how often they come up: * **The work item closed.** PacketUpdated subscriptions are deleted automatically once the work item reaches Closed. The closure event is the last message you receive. * **The subscribing account lost permission.** Enate re-checks the account's permission on the scoped object each time it prepares a message, and skips the message silently if the permission has gone. Restoring the permission resumes delivery. * **The Action definition changed.** A PacketCreated subscription scoped to a specific Action definition is tied to that definition's identifier, which can change when the parent Case process is republished. See the FAQ on the List of Enate's Webhooks page. **Q: Can I subscribe to a Case and get events for the Actions inside it?**\ A: No. Actions are matched by their own definition and by their Company, Contract and Service, not by their parent Case. Subscribe at Service scope and filter on `ProcessType` (Action = 3), or subscribe against the specific Action definition. There's a fuller explanation in the FAQ on the List of Enate's Webhooks page. **Q: In which scenarios will a New Communication event be triggered for a packet?**\ A: A New Communication event is triggered when a Packet Communication is written against the work item you've subscribed to. A Packet Communication may be: * A note written by an Agent * A note written in Self Service * An email coming in * An email going out * An existing email being "duplicated" onto another Work Item, for instance a Ticket merge into a Ticket, Case or Action causes a "new" email in the target work item The timing isn't the same for all of them. An outgoing email raises the event once it's actually been sent, not when it's drafted. An incoming email raises it at the point the email becomes linked to a work item, which is also why a merge produces one. Everything else raises it as soon as it's written. A communication that's never linked to a work item never raises the event at all. See When NewCommunication Fires. **Q: Can I create a Webhook subscription in Builder?**\ A: No. Webhook subscriptions are created and managed entirely through the API. See API Webhook Subscription. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.enate.net/enate-help/integrations/enate-integrations/webhooks/webhook-troubleshooting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.