Documentation Index
Fetch the complete documentation index at: https://docs.cyberdesk.io/llms.txt
Use this file to discover all available pages before exploring further.
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:- Activate Webhooks in the Dashboard (creates a Svix Application for your org).
- Add an endpoint URL and subscribe to
run_complete. - Implement your endpoint to verify signatures and process events.
- 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 full Run object (see API reference for RunResponse).
Adding an Endpoint
- Go to Dashboard → Webhooks.
- Click “Add Endpoint” and enter your publicly reachable HTTPS URL.
- Select the
run_completeevent type (or accept all for initial testing). - 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 timestampsvix-signature– signature over the raw request body
Install dependencies
- TypeScript / Node
- Python
Endpoint handlers
- TypeScript / Node
- Python
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
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)
- 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.statusandoutput_data - Persist
output_attachment_idsand fetch/download files as needed - Correlate
input_valuesto your original request (e.g., patient_id) - Understand sensitive inputs: plaintext secrets are never included in the payload.
run.sensitive_input_aliasesmaps 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_checksis an array, not an object keyed by name- each item includes
name,status,error_message,messages, andmatched_filenames - if you want to access a specific check by name, keep names stable and unique in the workflow editor
- TypeScript / Node
- Python
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_idsin your database with their step order. - In your
run_completewebhook, 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.
- Python / FastAPI
- Node.js / Express
Idempotency
Deduplicate usingsvix-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:- Removing the
run.run_message_historyfield, which can be very large - Extracting only the fields your system needs
- Reformatting data to match your expected schema
See Also
- Webhooks Quickstart
- API Reference → Event types and Run schema
- Webhook Transformations — Modify payloads before delivery