Peachdesk offers two kinds of webhooks. They are independent โ€” use either, both, or neither.

Event webhooks

Agent-level, signed notifications Peachdesk sends you when a call starts, ends, and is analyzed. Configured once per agent. Retell-envelope compatible.

Webhook nodes

A node inside a workflow that POSTs a payload you template. Fires when the node is reached. See the Webhook node guide.

Event webhooks

Event webhooks are configured once per agent, in Webhook Settings (available in both the single-prompt and conversational-flow editors). Peachdesk then notifies your endpoint automatically over the lifecycle of every call the agent handles.

Configuration

Dynamic variables in the URL. The url supports {{variable}} placeholders, rendered per call from the callโ€™s dynamic variables (the dynamic_variables you passed on the trigger API, plus built-ins). This lets you route events per call, e.g. https://example.com/hook?customer={{customer_name}}&call={{call_id}}. A placeholder with no matching variable is left as-is and never blocks delivery.

Events

Because call_ended fires after cost computation and call_analyzed fires after extraction, the two may arrive in either order. Correlate them with call.call_id.

Envelope

call_ended and call_analyzed use a Retell-compatible envelope: an event field plus a call object. A receiver that already speaks Retell can consume Peachdesk calls unchanged.
call_started is a lighter, flat payload:

The call object

Present on call_ended and call_analyzed.
string
Stable per-call identifier. Matches the call_id returned by the trigger endpoint and the {{ call_id }} dynamic variable.
integer
ID of the agent (workflow) that handled the call.
string
ended when the call completed normally, error otherwise.
string
phone_call for telephony calls, web_call for browser / embed calls.
string
inbound or outbound.
string
Originating legโ€™s phone number (null for web calls).
string
Dialled legโ€™s phone number (null for web calls).
integer
Call start time, milliseconds since the Unix epoch.
integer
Call end time, milliseconds since the Unix epoch.
integer
Call duration in milliseconds.
string
The full conversation as plain text.
array
The conversation as an ordered array of { "role": "agent" | "user", "content": string } turns.
string
A signed, time-limited URL to the call recording. Download promptly; the link expires.
string
A signed, time-limited URL to the transcript file.
string
A token-gated public URL to download the transcript (does not expire while the token is valid).
string
Why the call ended (for example agent_hangup, user_hangup, unknown).
object
The dynamic variables that were passed when the call was triggered.
object
The metadata object you passed to the trigger API, echoed back unchanged.
object
Post-call analysis. Always present on call_analyzed, and on call_ended once analysis is ready. See The call_analysis object.
object
Cost breakdown. Present on call_ended (after cost computation); typically absent on call_analyzed. See The call_cost object.

The call_analysis object

string
A concise LLM summary of the call.
string
One of Positive, Negative, Neutral, or Unknown.
boolean
Whether the agent accomplished the callโ€™s task.
boolean
Best-effort detection of whether the call reached voicemail.
string[]
The open items the call left for a follow-up, as short phrases. An empty list when nothing is outstanding. Carried into the callerโ€™s next call by Pre-Call Context as previous_call_next_steps.
object
Your post-call extracted fields (configured in post-call extraction).

The call_cost object

number
Total cost of the call, in USD.
number
Billable call duration in seconds.
array
Per-product breakdown, each { "product": string, "cost": number }.
object
Token usage attributed to the call.

Example payloads

Signature verification

When a secret is configured, Peachdesk computes an HMAC-SHA256 over the raw request body and sends the hex digest in two headers: To verify, compute the HMAC-SHA256 of the raw body with your secret and compare it to the header using a constant-time comparison. Always hash the raw bytes, not a re-serialized object โ€” reformatting the JSON changes the signature.

Delivery and retries

  • Requests are POSTed with Content-Type: application/json.
  • Peachdesk retries up to 3 attempts on a non-2xx status, a timeout (about 10s each), or a transport error.
  • Respond with a 2xx quickly; do heavy work asynchronously.
  • Handle deliveries idempotently โ€” a retry can deliver the same event more than once, and call_ended / call_analyzed may both describe the same call_id.
  • A dead endpoint never affects call handling: persistent failures are logged and dropped.
Event webhooks return the dynamic variables and metadata you supplied at trigger time. To correlate an event with the call you started, match call.call_id against the call_id returned by the trigger endpoint. Pass a metadata object at trigger time to carry your own correlation keys through to the webhook.

Webhook nodes

Peachdesk also executes webhook nodes asynchronously after a workflow run completes. Unlike event webhooks, a webhook node lives inside a specific workflow, and you template its target URL, method, headers, and payload directly in the workflow definition. See the Webhook node guide for the editor UI.

How webhook nodes work

  1. A call completes (or a run finishes).
  2. Peachdesk executes any webhook nodes in the workflow asynchronously.
  3. The payload template is rendered with the runโ€™s context and sent as a JSON POST (or your configured method) to your endpoint.
  4. Non-200 responses are logged but do not block or retry by default (configure retry_config to change this).

Payload context variables

The following variables are available in your payload_template using double-brace syntax (for example {{workflow_run_id}}). These are the same dynamic variables available elsewhere, plus run-level fields:

Example payload template

Authentication

Webhook node requests support the following authentication methods, configured via a stored credential:

Receiving webhook nodes

Your endpoint should:
  • Accept POST requests with Content-Type: application/json
  • Respond with a 2xx status code promptly (within 30 seconds)
  • Handle duplicate deliveries idempotently (retries may deliver the same payload more than once)

Webhook node in a workflow definition

See Workflow Definition Schema for the full configuration reference.