Skip to main content
Preview feature. Webhooks are currently in preview. Seamless delivery is not guaranteed, and the API, payload shape, and behaviour are likely to change in future releases.
Quarterzip can notify your systems in real time when an event happens in your workspace. You register an HTTPS endpoint and Quarterzip sends a signed POST request to it whenever a relevant event occurs. Today there is a single event — call.completed — sent once a call has finished and its transcript and metadata are available.

Set up an endpoint

  1. In the Quarterzip dashboard, go to Settings → Webhooks.
  2. Enter the HTTPS URL that should receive events.
  3. Toggle Enabled on and save.
When you save a URL for the first time, Quarterzip generates a signing secret and displays it once. Copy it immediately and store it somewhere secure, such as a secrets manager — never in source control. You’ll need it to verify that incoming requests genuinely came from Quarterzip, and it will not be shown again.
The endpoint URL must use https and must resolve to a public IP address. Localhost, private-network, and link-local addresses are rejected.
You can configure one endpoint per workspace.

Rotating the secret

If a secret is ever leaked, click Rotate secret on the same settings page. A new secret is generated and shown once.
Rotation takes effect immediately. The old secret stops verifying as soon as you rotate, so update your endpoint with the new value promptly to avoid rejecting deliveries in between.

Verify the signature

Always verify the signature before trusting a webhook. It proves the request came from Quarterzip and wasn’t tampered with in transit.
Quarterzip signs every delivery using the open Standard Webhooks specification, so you can use the official standardwebhooks libraries to verify with a few lines of code. Each request includes three headers:
Verify against the raw request body, exactly as received. Do not parse and re-serialize the JSON first, or the signature won’t match.
The library also enforces a timestamp tolerance, which protects you against replayed deliveries.

Delivery, Retries & Timeouts

Return any 2xx status code to acknowledge a webhook. Anything else — 4xx, 5xx, a connection error, or a timeout — is treated as a failed delivery and will be retried. Acknowledge first, process later. Your endpoint should do the minimum needed to persist the event (write it to a queue or a table) and return 2xx immediately. Doing the work inline risks hitting the timeout, and a timeout means redelivering an event you have already processed. Each delivery attempt is given 30 seconds. An attempt that hasn’t completed in that window is abandoned and retried. A failed delivery is retried up to 10 times with exponential backoff, starting at ~10 seconds and capping at 1 hour. After the final retry the event is dropped. Retries reuse the same webhook-id header as the original attempt. You should expect duplicates even when nothing looks wrong. A response we never received — because it arrived after the timeout, or the connection dropped mid-response — is indistinguishable from a failure, so we may retry an event your endpoint already processed successfully.

Events

call.completed

Quarterzip sends this event after a call finishes processing. The request is a JSON POST with Content-Type: application/json.

Example payload

Payload size and transcript truncation

Payloads are capped at 1 MB. Transcripts are omitted if the payload would otherwise exceed this limit. When this occurs, transcript_truncated will be set true.

Troubleshooting