Webhooks

Webhooks are the channel ingress backbone for live support traffic in Jardine. If webhook contracts are healthy, conversations flow into operations predictably. If webhook contracts are misconfigured, even a fully configured knowledge and routing setup can appear broken.

A practical rule is simple: treat webhook setup as production infrastructure, not as optional integration plumbing.

Channel-Specific Inbound Endpoints

Jardine uses channel-specific webhook endpoints because each provider has different payload shape, auth expectations, and operational failure patterns.

Current inbound routes are:

• Intercom: POST /webhooks/intercom/{org_id}
• Zendesk: POST /webhooks/zendesk/{org_id}
• Shared Email Inbox: POST /webhooks/email/inbound

Keeping these ingress paths separate makes debugging faster and reduces cross-channel ambiguity during incidents.

Why Separation Matters

If all channels shared one generic ingress endpoint, troubleshooting would be slower and filtering logic would be noisier. Provider-specific routes let teams isolate failures by channel immediately.

When Intercom is failing, you investigate Intercom contract and config. When Zendesk is failing, you investigate Zendesk trigger and secret handling. When Email is failing, you investigate domain verification and forwarding chain.

This separation is a reliability advantage, not an implementation detail.

Webhook Security Expectations

Webhook security is provider-specific but should follow one consistent principle: verify authenticity before processing.

In Zendesk setup, signing secret configuration is explicit in the settings UI because inbound authenticity depends on it.

In Email and Intercom flows, secure webhook handling and configuration completeness are equally important for trustworthy ingress behavior.

Operationally, if authenticity checks fail, it is correct for inbound processing to reject or ignore requests rather than accept untrusted payloads.

Event Flow Expectations by Channel

For Intercom, expect inbound conversation events to arrive through the org-specific route after connection and webhook setup are complete.

For Zendesk, expect inbound delivery only when OAuth, webhook endpoint configuration, trigger setup, and secret handling are all aligned.

For Email shared inbox, expect inbound routing only after domain verification and forwarding setup are complete.

In all cases, “connected integration” is necessary but not sufficient. End-to-end event flow testing is the real readiness check.

Testing Webhooks Before Rollout

A reliable webhook test process includes:

1. Trigger one known test event per channel.
2. Confirm event arrival in Conversations.
3. Confirm conversation details reflect expected channel source.
4. Confirm policy behavior (answer vs escalation) matches expectations.

This test should be repeated after major integration changes, not just at initial setup.

For teams launching multiple channels, test each channel independently before combining traffic. This keeps root cause obvious when something fails.

Common Webhook Failure Patterns

One common failure is configuration mismatch between provider and Jardine, such as outdated endpoint URLs, missing secrets, or stale trigger/webhook links.

Another is partial setup completion, where OAuth is done but inbound triggers are not.

A third is upstream delivery assumptions. Teams sometimes test with message types that do not actually trigger the configured webhook path.

A fourth is treating one successful event as full validation. Real readiness requires repeated controlled tests across realistic message patterns.

Incident Triage for Webhook Issues

When inbound traffic stops or becomes inconsistent, use a layered sequence:

• verify integration/channel connection state,
• verify endpoint and secret configuration,
• verify provider-side trigger or forwarding behavior,
• verify conversation ingestion outcomes in Jardine,
• verify downstream handling behavior only after ingress is confirmed.

This prevents misdiagnosing an ingress problem as a knowledge or routing issue.

Operational Practices for Long-Term Stability

Webhook reliability improves when teams maintain a regular integration health check rhythm.

A short weekly check can include:

• one synthetic or controlled inbound event per active channel,
• confirmation that events appear in Conversations,
• spot-check of escalation and ownership behavior,
• review of recent channel-specific anomalies.

This is lightweight, but it catches drift before customer impact grows.

Final Guidance

Webhooks are where support automation becomes real. They are the entry point for customer intent, and everything else in the system depends on their reliability.

If your team treats webhook contracts as first-class operational assets, channel behavior becomes stable and predictable. If webhook setup is treated casually, downstream systems will appear unreliable no matter how strong your knowledge or routing design is.

For full endpoint grouping and adjacent integration routes, return to API Overview or continue to Key Endpoints.