There are two ways to get call data into your own system:
  • The Webhook node posts one call’s data to a web address when that call ends. You add it to an agent’s flow.
  • Webhook endpoints receive events for the whole workspace: a call ended, a call’s outcome arrived, a campaign finished, the agent asked for a human. You register them in Settings → Webhooks or through the public API.
Both sign every request the same way, so your server can check it came from your workspace. See Check the signature.

The Webhook node

For Zapier or Make, set Send to on the Webhook node to Zapier or Make and paste the hook address from your Zap’s Catch Hook trigger or your scenario’s Custom Webhook module. The payload is the same.

Add it

  1. Open Components and click Webhook under Post Processing.
  2. Connect End to it. That includes the transcript.
  3. Optionally connect a Structured Output or Summarization node to it as well. Their results are included.
  4. Enter the URL. It must be an https:// address on the public internet.

What is sent

One POST request with a JSON body. The keys depend on what is connected: A Structured Output node’s result is the object it extracted. A Summarization node’s result is { "summary": "...", "style": "bullet" }, where style is bullet, paragraph or brief. Each turn in transcription has the speaker, the text, the time and the Skill that was active:
role is user or assistant. timestamp is ISO 8601 in UTC, or empty when unknown. stepId is the id of the Skill the turn belongs to, or null before the first Skill. There is no wrapper object: a Structured Output named customerFeedback arrives as the top-level key customerFeedback. callOutcome is built from the Structured Output and Categorize results before the webhook runs; when the flow says nothing about success, all three values are null. channel is where the call came from: sip_in, sip_out, campaign, api, share or playground (see the public API’s sessions). A node you name call or callOutcome keeps that key for its own result.

Delivery

The request is sent once the call and the steps before the webhook are done, with a 10-second timeout. A timeout, a connection error, or an answer of 408, 429 or 500 and above is retried three times, after 1, 2 and 4 seconds: the request is sent while the call is closing, so it cannot wait longer. For retries over minutes, use a webhook endpoint. Any other answer is final: a 2xx counts as delivered, a redirect is not followed, and another 4xx is not retried. A delivery that still fails is written to the worker log; it does not affect the call or the other after-the-call steps. The node signs with the workspace signing secret. Make it in Settings → Webhooks, under Signing secret for Webhook steps and alerts: it is shown once, so copy it then. Until the workspace has one, Webhook node requests are sent unsigned. Alert webhooks sign with the same secret.

Webhook endpoints

An endpoint is an https:// address that receives events for every agent in the workspace. Add one in Settings → Webhooks: paste the address, tick the events it should receive (leave all clear for every event), and copy its signing secret. The secret is shown once; replace it from the endpoint’s row if it leaks. Signing secrets are stored encrypted, and Settings shows only their last four characters. The same panel lists recent deliveries with their status. Developers can manage endpoints with a developer token too (GET, POST /v1/webhook-endpoints, GET, PATCH, DELETE /v1/webhook-endpoints/{id}, POST /v1/webhook-endpoints/{id}/rotate-secret); see the public API reference.

Events

Every event has the same envelope. Times are milliseconds since the epoch:
Playground tests send no events. Fetch a call’s transcript with GET /v1/sessions/{sessionId}.

Delivery

Events are queued and posted within a few seconds, with a 10-second timeout. The retry rule is the same as the node’s, on a longer schedule: three retries after 1, 5 and 30 minutes. A paused endpoint receives nothing, and events queued for it before the pause are dropped. Delivery is at least once: use X-GF-Event-Id (the same as the envelope’s id) to ignore a repeat. Events can arrive out of order; use createdAt and the ids to order them. Not yet available: ringing and answered events, replaying a delivery, and pausing an endpoint automatically after repeated failures.

Alerts

An alert rule in Alerts can post to a webhook, send email, or both. Its webhook sends either signed JSON or a Slack message: for Slack, create an incoming webhook in your Slack workspace and paste its https://hooks.slack.com/services/… address. Email goes out through the server’s mail settings; if there are none, Send test says so for each address. A rule notifies when it fires, every hour while it keeps firing until someone acknowledges it, and once when it recovers. Silencing a rule for 1, 4 or 24 hours holds all of these back; the history still lists every alert. Send test sends the rule’s current reading to each of its channels at once and adds nothing to the history. The JSON body:
status is firing, resolved or test; reminder appears on the hourly reminders only, and value is null only on a test with no data in the window. Alert webhooks are retried like the node: three retries after 1, 2 and 4 seconds. X-GF-Event-Id is alert_<eventId>_<status>, with a new id for each reminder. Model cost covers language-model tokens only; a model with no known price is left out rather than counted as free.

Check the signature

Every request carries these headers: The signature is the hex HMAC-SHA256 of the timestamp, a full stop and the raw request body, keyed with the secret exactly as shown (it starts with whsec_). Each attempt is signed with its own timestamp. To check a request:
  1. Take t and v1 from X-GF-Signature.
  2. Refuse a t more than five minutes from your clock.
  3. Compute the HMAC of <t>.<raw body> and compare it with v1 in constant time. Use the body as received: parsing and re-serialising the JSON changes the bytes.
Node.js (Express):
Python:
A Webhook node or alert request carries no X-GF-Signature until the workspace has a signing secret, and neither does one from an agent that belongs to no workspace.

Patterns

Use cases

  • Push every call into your data warehouse with a call.ended endpoint.
  • Update your CRM when call.analyzed brings the outcome.
  • Post a summary to a team chat through its incoming webhook.
  • Kick off a follow-up in Zapier or Make with the matching preset.