Webhook integrations

Oct 20, 2026 को अपडेट किया गया5 मिनट में पढ़ें
हिन्दी
इस पेज पर

Webhooks push real-time event data from Deskwoot to your own endpoint. Conversation created, message sent, contact updated: pick the events you care about, give us a URL, we POST JSON to it as events happen. Each delivery is HMAC-signed so you can verify it actually came from Deskwoot. Useful for syncing to a CRM, triggering custom workflows, or logging events into your data warehouse.

Webhook Integrations

Webhooks in Deskwoot are HTTP callbacks that fire when something happens in your inbox (new conversation, new message, status change) so you can sync support events to a CRM, trigger an outside automation, or log them in your own database, all without polling the API. Whether you want to update a CRM, trigger a notification in a third-party tool, or log support events in your own database, webhooks provide a lightweight, event-driven way to keep everything in sync.

This guide walks you through creating a webhook, choosing the right events, and troubleshooting common issues.

Creating a Webhook

  1. Navigate to Settings > Webhooks in your Deskwoot dashboard.
  2. Click Add Webhook.
  3. Enter the URL of the endpoint that should receive the event data. This must be a publicly accessible HTTPS URL.
  4. Select the event types you want to subscribe to (for example, conversation created, message created, or contact updated). If you select none, every event is sent.
  5. Click Create Webhook to activate the webhook.

Once saved, Deskwoot will send an HTTP POST request containing a JSON payload to your specified URL every time a matching event occurs.

Best-Practice Tips

  • Use HTTPS endpoints only. This ensures event data is encrypted in transit and protects sensitive customer information.
  • Subscribe selectively. Only choose the event types you actually need. Subscribing to every event can generate a high volume of requests and make debugging harder.
  • Respond quickly. Your endpoint should return a 2xx status code as fast as possible. Offload any heavy processing to a background job to avoid timeouts.
  • Log incoming payloads. During initial setup, log the raw JSON so you can inspect the payload structure and build your integration accurately.
  • Keep your endpoint idempotent. In rare cases a webhook may be delivered more than once. Design your handler so that processing the same event twice does not cause duplicate actions.

Troubleshooting

  • Not receiving events? Verify that your endpoint URL is correct, publicly accessible, and returns a 2xx response. Firewalls or IP-allowlisting rules can silently block incoming requests.
  • Unexpected payload format? Make sure you are parsing the request body as JSON (Content-Type: application/json). Check your server logs for parsing errors.
  • Events arriving late? Brief delays can occur during high-traffic periods. If delays persist, confirm that your server is not throttling or queuing incoming connections.

Frequently asked questions

What events can I subscribe to?
Conversation created, conversation updated, conversation assigned, conversation resolved, message created, contact created, contact updated and CSAT submitted. If you select no event, the webhook receives every event. Each event has its own data payload; see the API docs.
Is the webhook delivery signed?
Yes. Each request has an X-Deskwoot-Signature header (sha256= followed by the hex HMAC-SHA256 of the raw body, signed with your webhook's secret) and an X-Deskwoot-Event header with the event name. The dashboard does not show the secret; a webhook created through the REST API returns it once in the response. Verify the signature before processing to protect against forged requests.
Will Deskwoot retry failed deliveries?
Once. If the first POST fails or your endpoint returns an error, we retry after 5 seconds. If that also fails, the event is dropped: build your endpoint to be idempotent and tolerant of brief outages. For mission-critical sync that has to survive longer outages, mirror events into your own queue on the first delivery.
How fast are webhooks delivered?
Deskwoot sends each event right when it happens, without a queue. Your endpoint has 10 seconds to answer; a slower answer counts as a failed delivery and gets the single retry.
Do I need HTTPS?
Yes. We only POST to HTTPS URLs. HTTP is rejected at config time. This is non-negotiable since the payloads contain customer data.
What's the request format?
POST with Content-Type: application/json. The body is a JSON object with event, data (the payload of that event), timestamp and accountId. See the API docs for the data of each event.
Will I get duplicate events?
Rarely, but possible during retries (network blips, your endpoint returning ambiguous status). The body has no event ID, so use the event name together with the ID of the object in data (for example the message ID) to skip events you have already processed.
Can I filter events server-side before sending?
Subscribe-time filtering: yes, pick which event types. Content-based filtering ('only conversations on inbox X'): not built-in; subscribe to all, filter on your endpoint.
What happens if my endpoint goes down for a few hours?
Events delivered during the outage are lost: we don't queue them server-side beyond the single retry. After your endpoint recovers, backfill through the REST API (Enterprise): list conversations sorted by newest activity and reconcile state.
Can I send webhooks to multiple endpoints?
Yes. Create multiple webhooks each pointing to a different URL. Useful when one tool needs all events and another needs only a subset.
How do I test before going live?
Use a temp URL service like webhook.site or RequestBin during setup. Inspect the actual payloads coming in, validate your parser, then switch to your production endpoint once confident.

क्या यह गाइड मददगार थी?

आगे पढ़ें

इस गाइड के बारे में Fynn से पूछें

इस गाइड और बाकी सहायता केंद्र से छोटा जवाब पाएं।

अब भी मदद चाहिए?

Fynn चैट में इन गाइड से जवाब देता है, और वहीं आप टीम से भी बात कर सकते हैं।

हमें ईमेल करें