Understanding Kayako Webhook (Endpoint) Logging, Failure Reasons, and Resending Data

Solution

How outbound webhooks work in Kayako

Outbound integrations involve two distinct layers, so the question "did the webhook fire?" is really two questions — did the automation rule run, and did the endpoint's send succeed:

• Endpoint (Admin area → Integrations → Endpoints): the component that actually sends the HTTP request to your external system.
• Trigger or Monitor (Admin area → Automation): the rule that decides when Kayako sends the request.

For background on defining endpoints, see Sending Messages and Notifications to External Systems With Endpoints. For how automation rules are built, see Creating Automations with Triggers and Monitors.

1. Does Kayako log webhook activity (did a specific webhook fire)?

Kayako does not keep a full historical activity log of endpoint sends. For each endpoint, it stores only the single most recent attempt: the result (success/failure), the message the destination returned, and the time of that attempt. Every new send overwrites the previous one.

• Review this under Admin area → Integrations → Endpoints. If the last attempt for an endpoint failed, an error indicator appears next to it; click it to view the latest attempt time and failure message. This is the same view described in Kayako Stopped Sending Messages to Slack Through Endpoints.
• Because only the latest attempt is retained, you cannot look back in Kayako to confirm whether a webhook fired for a specific past conversation or timestamp.
• If the automation's conditions did not match, the endpoint never ran and nothing is recorded against it — in that case, check the trigger/monitor conditions and the conversation's own activity timeline.
• For true per-event history, your external system's execution log (for example, n8n → Executions) is the authoritative source; it records each request the destination actually received.

2. If it failed, can you see why?

Yes, but only for the latest attempt of the endpoint. Kayako records the reason, which is typically one of the following:

• The destination returned a non-success HTTP status — Kayako stores the response body (for example, the 404 The requested webhook is not registered).
• The request timed out or the host could not be reached.
• The URL responded with a redirect — Kayako intentionally does not follow redirects, so a 3xx response is recorded as a failure.
• The URL points to a private/local address, which Kayako blocks.

Note: There is no per-occurrence failure history; the reason is overwritten on the next send to that endpoint.

3. Can you resend the data if a webhook failed?

Kayako has no built-in resend/retry. Each send is attempted once; on failure Kayako records the result but does not automatically retry, and there is no "resend" action for a past payload. Recovery options:

• If the request reached the destination (it appears in the destination's execution log), re-run it there using the captured payload.
• If it never reached the destination, re-run the business action that fires the trigger, or build a small manual "resend" rule in Kayako (for example, a trigger keyed off a specific tag) that re-sends to the correct endpoint.
• To make future misses easy to trace and recover: include the Kayako conversation ID in the payload you send, and retain both successful and failed executions in your destination system.

Common root cause: a test endpoint attached to a production trigger

A frequent cause of recurring endpoint failures is a test endpoint being attached to a production trigger alongside the production endpoint. When this happens:

• The production endpoint delivers successfully.
• The test endpoint fails each run, typically with the destination's 404 "webhook is not registered", and leaves the error indicator behind.

This is expected behavior of many destination systems: a Test URL (for example, a /webhook-test/… path) only listens briefly right after you click Execute workflow in the editor, whereas the Production URL (for example, a /webhook/… path) stays active once the workflow is published/active.

Resolution / Recommendation:

1. Go to Admin area → Automation → Triggers/Monitors and open the production rule.
2. Confirm the rule is enabled and its conditions match the intended scenario.
3. Ensure only the production endpoint is attached to the production trigger.
4. Remove any "…test" endpoints from the production trigger, or repoint them at the destination's Production URL.
5. Keep test endpoints for manual testing only.

This clears the recurring failures recorded against the endpoint.

Diagnosing genuinely rare misses

Because Kayako keeps only the latest attempt per endpoint and does not retry, a rare transient failure on the production endpoint will not be visible once the next successful send overwrites it. The reliable place to confirm whether a specific event actually arrived is your destination system's execution log.

If a specific event misses, gather the following to investigate:

• the Endpoint name,
• the Trigger or Monitor name,
• the affected conversation ID,
• the exact date, time, and timezone,
• whether an execution appears in the destination for that same moment,
• a screenshot of any endpoint error shown in Kayako.

Warning: Do not include a full webhook URL that contains a private token.

Best-practice safeguards:

• Keep only the active production endpoint attached to the production trigger.
• Include the Kayako conversation ID in the payload.
• Retain both successful and failed executions in your destination system for as long as practical.
• Never leave a test webhook connected to a production trigger unless intentional.