Overview
Webhooks are an event-driven push mechanism provided by Qoder Cloud Agents. When resources such as Agents or Sessions undergo lifecycle changes, the system delivers structured events via HTTP POST to developer-registered URLs — no polling required. Core Features:- Event-driven push — Proactive notifications on resource state changes, no client polling needed
- Envelope structure — Uniform
BetaWebhookEvent { id, created_at, data, type:"event" }format - Delivery semantics — At-least-once guarantee; HMAC-SHA256 signature verification; exponential backoff retry
- Wildcard subscription — Use
*to subscribe to all event types, simplifying integration
Domain Types
This section defines the data structures of Webhook events. Thedata field of each event type follows a uniform object format containing the resource ID, event type, and event-specific additional fields.
Session Lifecycle Events
Webhook Session Created Event Data
-
WebhookSessionCreatedEventData object { id, type }-
id: stringThe Session ID that triggered the event. -
type: "session.created""session.created"
POST /sessions.
-
Webhook Session Updated Event Data
-
WebhookSessionUpdatedEventData object { id, type }-
id: stringThe Session ID that triggered the event. -
type: "session.updated""session.updated"
-
Webhook Session Archived Event Data
-
WebhookSessionArchivedEventData object { id, type }-
id: stringThe Session ID that triggered the event. -
type: "session.archived""session.archived"
-
Webhook Session Deleted Event Data
-
WebhookSessionDeletedEventData object { id, type }-
id: stringThe Session ID that triggered the event. -
type: "session.deleted""session.deleted"
-
Session Status Events
Webhook Session Status Run Started Event Data
-
WebhookSessionStatusRunStartedEventData object { id, type }-
id: stringThe Session ID that triggered the event. -
type: "session.status_run_started""session.status_run_started"
-
Webhook Session Status Idled Event Data
-
WebhookSessionStatusIdledEventData object { id, type }-
id: stringThe Session ID that triggered the event. -
type: "session.status_idled""session.status_idled"
-
Session Thread Events
Applicable to multi-Agent collaboration scenarios. Thread events carry an additionalsession_thread_id field on top of the base fields, identifying the specific execution thread.
Webhook Session Thread Created Event Data
-
WebhookSessionThreadCreatedEventData object { id, type, session_thread_id }-
id: stringThe Session ID that triggered the event. -
type: "session.thread_created""session.thread_created"
-
session_thread_id: stringThe associated Session Thread ID.
-
Webhook Session Thread Idled Event Data
-
WebhookSessionThreadIdledEventData object { id, type, session_thread_id }-
id: stringThe Session ID that triggered the event. -
type: "session.thread_idled""session.thread_idled"
-
session_thread_id: stringThe associated Session Thread ID.
-
Webhook Session Thread Terminated Event Data
-
WebhookSessionThreadTerminatedEventData object { id, type, session_thread_id }-
id: stringThe Session ID that triggered the event. -
type: "session.thread_terminated""session.thread_terminated"
-
session_thread_id: stringThe associated Session Thread ID.
-
Agent Lifecycle Events
Agent events carry an additionalversion field beyond the base fields, indicating the Agent’s configuration version number.
Webhook Agent Created Event Data
-
WebhookAgentCreatedEventData object { id, type, version }-
id: stringThe Agent ID that triggered the event. -
type: "agent.created""agent.created"
POST /agents. -
version: integerAgent version number. Set to1on initial creation.
-
Webhook Agent Updated Event Data
-
WebhookAgentUpdatedEventData object { id, type, version }-
id: stringThe Agent ID that triggered the event. -
type: "agent.updated""agent.updated"
versionincrements with each update. -
version: integerAgent version number.
-
Webhook Agent Archived Event Data
-
WebhookAgentArchivedEventData object { id, type, version }-
id: stringThe Agent ID that triggered the event. -
type: "agent.archived""agent.archived"
-
version: integerAgent version number.
-
Webhook Agent Deleted Event Data
-
WebhookAgentDeletedEventData object { id, type, version }-
id: stringThe Agent ID that triggered the event. -
type: "agent.deleted""agent.deleted"
-
version: integerAgent version number.
-
Webhook Endpoint API
CRUD endpoints for managing Webhook endpoints. Use these to create, query, update, and delete Webhook endpoints, as well as send test events and control endpoint enable/disable state. Base URL:
Authentication:
All endpoints require a Personal Access Token in the request header:
POST /webhook_endpoints
Create a new Webhook endpoint. Request Parameters:
Response:
201 Created
Note: signing_secret is only returned once at creation time. Store it securely. Subsequent query endpoints will not return this field.
Status Codes:
Example:
GET /webhook_endpoints
List all Webhook endpoints under the current account. Request Parameters: None Response:200 OK
Example:
GET /webhook_endpoints/{id}
Retrieve details of a specific Webhook endpoint. Path Parameters:
Response:
200 OK
Returns a single endpoint object with the same structure as elements in the list endpoint.
Status Codes:
Example:
PUT /webhook_endpoints/{id}
Update the configuration of a specific Webhook endpoint. Path Parameters:
Request Parameters:
Response:
200 OK
Returns the full updated endpoint object.
Status Codes:
Example:
DELETE /webhook_endpoints/{id}
Permanently delete a Webhook endpoint. All undelivered events will be discarded. Path Parameters:
Response:
204 No Content
Status Codes:
Example:
POST /webhook_endpoints/{id}/test
Send a test event to the specified endpoint to verify connectivity and signature verification logic. Path Parameters:
Request Parameters: None
Response:
202 Accepted
Status Codes:
Example:
POST /webhook_endpoints/{id}/enable
Enable a disabled Webhook endpoint. Once enabled, the endpoint will resume receiving event deliveries. Path Parameters:
Request Parameters: None
Response:
200 OK
Returns the endpoint object after enabling (active: true).
Status Codes:
Example:
POST /webhook_endpoints/{id}/disable
Disable a Webhook endpoint. Once disabled, the endpoint will stop receiving event deliveries but will not be deleted. Path Parameters:
Request Parameters: None
Response:
200 OK
Returns the endpoint object after disabling (active: false).
Status Codes:
Example:
GET /webhook_events
List Webhook event delivery records for auditing and troubleshooting. Request Parameters: None Response:200 OK
Returns an event list containing delivery status, timestamps, and other information.
Example:
GET /webhook_events/{id}
Retrieve detailed information for a single Webhook event. Path Parameters:
Response:
200 OK
Status Codes:
Example:
Error Response Format
All endpoints return a uniform error structure when an error occurs:Note: 401 responses from the authentication layer (e.g., invalid or missing Token) may not follow the business error structure above, as they are returned directly by the gateway.
Webhook Delivery
Delivery Method
The system delivers events to registered URLs via HTTP POST with the following format:- Method:
POST - Content-Type:
application/json - Body: JSON envelope structure (see Envelope Structure)
Request Headers
Each delivery includes the following HTTP headers:Signature Verification
To ensure event authenticity and data integrity, every delivery carries an HMAC-SHA256 signature. Developers should verify the signature before processing events. Signature Format:signing_secret— The secret returned when creating the endpoint (whsec_prefix)t— Unix timestamp at signing time (seconds)raw_body— Raw byte content of the request body (unparsed)
- Extract
tandv1from theWebhook-Signatureheader - Check that the timestamp is within the tolerance window (recommended 600 seconds) to prevent replay attacks
- Compute HMAC-SHA256 of
"<t>.<raw_body>"using thesigning_secret - Compare the result with
v1using timing-safe comparison
Signature Verification Code Examples
Node.js:Retry Strategy
When delivery fails, the system uses exponential backoff for retries:
A total of 4 attempts (1 delivery + 3 retries). After all failures, the event enters the dead letter queue.
Response Code Handling
Automatic Degradation
When an endpoint’sconsecutive_fail count exceeds 20, the system triggers a degradation warning. Developers should monitor this metric and check the following when failures persist:
- Is the endpoint URL reachable
- Is the SSL certificate valid
- Is the server responding normally
- Are there bugs in signature verification logic
Supported Event Types (Complete List)
Event Type Overview
Special Event Types
Status Labels
Envelope Structure
All Webhook events are wrapped in a uniform envelope structure for delivery.Base Envelope Structure
Thread Event Envelope
Thread events include an additionalsession_thread_id field in data:
Agent Event Envelope
Agent events include an additionalversion field in data:
Field Descriptions
Idempotency Handling
Theid field in the envelope can be used as a deduplication key. Since delivery semantics are at-least-once, the same event may be delivered multiple times. Receivers should:
- Use
idas a unique key for deduplication - Check whether the
idhas already been consumed before processing - Ensure event processing logic is idempotent
Planned Events (Coming Soon)
The following event types have been aligned at the API design level and will be rolled out as their respective resource features go live. Specific timelines depend on product requirements.deployment.* (Deployment Lifecycle, 6 events)
deployment_run.* (Deployment Run Status, 3 events)
environment.* (Environment Management, 4 events)
memory_store.* (Memory Store, 3 events)
vault.* (Vault, 3 events)
vault_credential.* (Credential Management, 5 events)
Appendix A: Quick Start Guide
Step 1: Create a Webhook Endpoint
Step 2: Save the signing_secret
Retrieve thesigning_secret from the creation response and store it securely for later signature verification.
Step 3: Implement the Receiver
Implement the Webhook receiver endpoint in your service, ensuring:- Verify the
Webhook-Signaturesignature - Use the event
idfor idempotent deduplication - Return
200 OKto acknowledge receipt - Process business logic asynchronously (avoid timeouts)