Skip to main content

Introduction

Webhooks are HTTPS POST requests sent from Cyberdesk to your service when events happen (e.g., a workflow run completes). They eliminate polling and let you react in real-time. The high-level steps:
  1. Activate Webhooks in the Dashboard (creates a Svix Application for your org).
  2. Add an endpoint URL and subscribe to run_complete.
  3. Implement your endpoint to verify signatures and process events.
  4. Test and monitor via the embedded Webhooks portal.

Events and Event Types

Cyberdesk webhooks are organized by event types (e.g., run_complete). You can browse the full, always-up-to-date list and their schemas in the Event Catalog inside the Webhooks portal. As of today, run_complete is the most commonly used type and fires when a workflow run reaches a terminal state (success, error, task_failed, or cancelled). Its payload includes the completed Run object, excluding run_message_history to keep webhook deliveries small and reliable. If you need message history, retrieve the run later through the API or SDK.

Adding an Endpoint

  1. Go to Dashboard → Webhooks.
  2. Click “Add Endpoint” and enter your publicly reachable HTTPS URL.
  3. Select the run_complete event type (or accept all for initial testing).
  4. Copy the generated endpoint signing secret (whsec_...).
Keep separate endpoints/secrets for each environment (dev, staging, prod).

Testing Endpoints

Use the “Testing” tools in the Webhooks portal to send example events to your endpoint. Inspect payloads, responses, and message attempts under Logs/Activity. You can replay messages individually or recover all failed messages since a timestamp.
We’re building a managed Webhooks SDK with built‑in verification and typing. If you want this prioritized, please let the team know.

Verifying Signatures

Always verify signatures to ensure messages originate from Cyberdesk. We use Svix headers and signing format. Headers sent with every webhook:
  • svix-id – unique message id (use for idempotency)
  • svix-timestamp – Unix timestamp
  • svix-signature – signature over the raw request body

Install dependencies

Endpoint handlers

Verify against the exact raw request body. Do not re-stringify JSON before verification.

Retry Mechanism

Cyberdesk (via Svix) retries failed deliveries using exponential backoff:
  • Immediately
  • 5 seconds
  • 5 minutes
  • 30 minutes
  • 2 hours
  • 5 hours
  • 10 hours
  • 10 hours
A response with HTTP 2xx is considered success. Avoid long processing in the webhook handler—enqueue work and return 200 quickly to prevent timeouts. Manual retries: from the portal you can resend single messages or recover all failed messages since a given time.

Troubleshooting & Failure Recovery

Common pitfalls:
  • Not using raw body for signature verification
  • Using the wrong endpoint secret (each endpoint has its own secret)
  • Returning non-2xx status for successful processing
  • Handler timeouts (do heavy work asynchronously)
Failure recovery:
  • Re-enable disabled endpoints in the portal
  • Replay failed messages individually or recover all since a timestamp

Using run_complete Data

run_complete includes the full RunResponse. Useful patterns:
  • Trigger the next workflow in your pipeline
  • Update your job table with run.status and output_data
  • Persist output_attachment_ids and fetch/download files as needed
  • Correlate input_values to your original request (e.g., patient_id)
  • Understand sensitive inputs: plaintext secrets are never included in the payload. run.sensitive_input_aliases maps each sensitive input key (for example, password) to the secure secret identifier used during execution, so you can audit which sensitive variables were referenced without exposing their values.

Example: TypeScript handler

Example: Python handler

React to Post-run Check failures

run_complete is the best place to react to Post-run Checks, because the event fires only after those checks finish. The result data lives on run.post_run_checks. Important details:
  • run.post_run_checks is an array, not an object keyed by name
  • each item includes name, status, error_message, messages, and matched_filenames
  • if you want to access a specific check by name, keep names stable and unique in the workflow editor

Advanced example: dynamic workflow chain webhook

Some production integrations build the entire Cyberdesk chain up front, but the steps included in that chain depend on the initial request. For example, a charge-entry integration might always run an encounter setup workflow, skip remove/update/add workflows when their input arrays are empty, and always finish with a finalization workflow. In this pattern:
  • Create the chain with client.runs.chain(...) from your normal POST endpoint.
  • Store the returned run_ids in your database with their step order.
  • In your run_complete webhook, branch on every terminal status.
  • Treat non-success statuses before the final step as early chain stops; later runs may never emit webhooks.
  • When the final run has release_session_after: true, clean up any local locks or resources tied to that Cyberdesk session.

Idempotency

Deduplicate using svix-id (header) or event_id (payload). Store processed ids and ignore duplicates.

Finding webhooks by run ID

In the Svix dashboard, you can search for webhooks by their message ID. For most runs, the message ID equals the run ID, making it easy to find the webhook for a specific run.
Retried runs: If you retry a run (same run_id), the second webhook will have a timestamped message ID (e.g., abc123..._1702310400000) to ensure uniqueness. The first webhook for any run will always use just the run ID.

Security Checklist

  • Verify signatures and timestamp
  • Use HTTPS only
  • Rotate secrets when needed
  • Return 2xx promptly; process work asynchronously

Payload Transformations

If your webhook payloads are too large or you need to reshape the data before it reaches your endpoint, you can use transformations to modify the payload server-side. This is particularly useful for:
  • Extracting only the fields your system needs
  • Reformatting data to match your expected schema
See Webhook Transformations for setup instructions and examples.

See Also

  • Webhooks Quickstart
  • API Reference → Event types and Run schema
  • Webhook Transformations — Modify payloads before delivery