Skip to content
Garuda
Configuring

Sending leads to your CRM with a webhook

Add an HTTPS endpoint under Webhooks on the Integrations screen, subscribe it to the events you care about, copy the signing secret it shows you once, and verify that signature in your receiver.

Last checked against the running product on 30 August 2026.

A webhook means Garuda posts a small JSON message to a URL you own the moment something happens. Every automation tool and most CRMs accept one, which is how a captured lead ends up as a contact, a calendar hold or a row in a sheet.

This is the outbound half of integrations

Webhooks push what happened in Garuda out to your own tools. Connecting a third-party account so that it belongs to your workspace is a separate thing, covered in Connecting an integration.

  1. Open the Integrations screen

    It lives at /app/integrations in the workspace. Settings, Integrations links to it as Open integrations if you would rather not type the path.

  2. Get a destination URL

    In Zapier create a Catch Hook trigger; in Make a Custom webhook; in n8n or Pipedream a webhook trigger. Some CRMs publish an inbound URL of their own. Copy whatever URL the tool gives you.

    It has to be https on the default port and resolve to a public address. Garuda refuses anything else, including a private or internal address.

  3. Add the endpoint

    Paste the URL into Add an endpoint, give it a label you will recognise later, tick the events you want, and choose Add endpoint. At least one event is required.

    The events an endpoint can subscribe to
    EventWhen it fires
    lead.createdA visitor completed the lead form on one of your agents.
    conversation.startedA visitor sent their first message to one of your agents.
    conversation.endedA conversation went quiet and is considered finished.
  4. Copy the signing secret now

    The secret is shown once, immediately after the endpoint is created. Copy it into your receiver before you leave the page. If you lose it, Rotate secret issues a new one — which invalidates the old one.

  5. Send a test

    Send test queues a webhook.test event. It is delivered in the background and goes to the endpoint whatever it is subscribed to, because its whole job is to prove the wiring. Open Recent deliveries on the endpoint a moment later to see the attempt, its status and any response code.

  6. Verify the signature in your receiver

    Garuda signs every delivery. The scheme is identical to Stripe's, so a Stripe verifier works unchanged.

    How a Garuda webhook delivery is signed and delivered
    DetailValue
    Signature headerGaruda-Signature
    Header formatt=<unix seconds>,v1=<hex HMAC-SHA256>
    Signed value<t>.<raw request body>
    Clock tolerance300 seconds
    MethodPOST, application/json
    Retries5 retries with exponential backoff after the first attempt
    GuaranteeAt least once. De-duplicate on the Garuda-Event-Id header.
    Expected replyAny 2xx. Reply 410 Gone to have Garuda stop retrying immediately.

    Sign the raw bytes

    Verify against the body exactly as it arrived, not against a re-encoding of the parsed JSON, and reject a timestamp further than the tolerance from your own clock.

  7. Build the rest in your own tool

    Once the payload is arriving, everything downstream is the automation tool's job: create the HubSpot contact, add the Google Calendar event, append the sheet row. Garuda's part ends at a signed, retried POST.

An account may register up to 10 endpoints. An endpoint that exhausts its retries five times in a row is suspended for an hour, so a receiver that goes down does not keep costing deliveries; the log shows the failures and the endpoint resumes on its own.

Webhooks fire after the fact

A webhook tells your tools what already happened. It is not a way for the agent to look something up mid-conversation — nothing in the chat pipeline calls out to a third-party tool — so be careful what you promise a visitor on the strength of one.

If it still does not work

The URL is rejected when you add it

It must be https, on the default port, and resolve to a public address. Localhost, a private range and a custom port are all refused.

Deliveries show as failed

Open Recent deliveries and read the response status and error. A 401 or 403 usually means your receiver is rejecting the signature; a 404 means the URL has moved; a 5xx means the receiver itself is failing.

The endpoint shows failures in a row and nothing new arrives

It has been suspended by the circuit breaker. Fix the receiver, then use Send test to confirm it is answering again.

You want an account connection rather than a webhook

That is the other half of the Integrations screen. See Connecting an integration.

Back to all help articles

Still stuck?

Every article here is written from the product as it works today. If something on this page does not match what you see in your workspace, trust the product and tell us — include the page you were on and what you expected.