Skip to main content

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
Use Cases:

Domain Types

This section defines the data structures of Webhook events. The data 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: string The Session ID that triggered the event.
    • type: "session.created"
      • "session.created"
      Triggered when a Session is successfully created. The system sends this event immediately after a Session is created via POST /sessions.

Webhook Session Updated Event Data

  • WebhookSessionUpdatedEventData object { id, type }
    • id: string The Session ID that triggered the event.
    • type: "session.updated"
      • "session.updated"
      Triggered when Session metadata (such as title, metadata, etc.) is modified.

Webhook Session Archived Event Data

  • WebhookSessionArchivedEventData object { id, type }
    • id: string The Session ID that triggered the event.
    • type: "session.archived"
      • "session.archived"
      Triggered when a Session is archived. After archival, the Session no longer accepts new messages, but historical data remains queryable.

Webhook Session Deleted Event Data

  • WebhookSessionDeletedEventData object { id, type }
    • id: string The Session ID that triggered the event.
    • type: "session.deleted"
      • "session.deleted"
      Triggered when a Session is permanently deleted. All data for the Session becomes unrecoverable after deletion.

Session Status Events


Webhook Session Status Run Started Event Data

  • WebhookSessionStatusRunStartedEventData object { id, type }
    • id: string The Session ID that triggered the event.
    • type: "session.status_run_started"
      • "session.status_run_started"
      Triggered when an Agent starts a run. Signals that the Session has entered the running state and is executing user instructions.

Webhook Session Status Idled Event Data

  • WebhookSessionStatusIdledEventData object { id, type }
    • id: string The Session ID that triggered the event.
    • type: "session.status_idled"
      • "session.status_idled"
      Triggered when a turn completes and the Session returns to idle state. At this point it is safe to read the Session’s latest output.

Session Thread Events

Applicable to multi-Agent collaboration scenarios. Thread events carry an additional session_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: string The Session ID that triggered the event.
    • type: "session.thread_created"
      • "session.thread_created"
      Triggered when a new Session Thread is created. Common in sub-Agent collaboration scenarios where the main Agent spawns child threads to execute tasks.
    • session_thread_id: string The associated Session Thread ID.

Webhook Session Thread Idled Event Data

  • WebhookSessionThreadIdledEventData object { id, type, session_thread_id }
    • id: string The Session ID that triggered the event.
    • type: "session.thread_idled"
      • "session.thread_idled"
      Triggered when a Session Thread finishes a run and enters idle state. Indicates the thread has completed its current task and results can be read.
    • session_thread_id: string The associated Session Thread ID.

Webhook Session Thread Terminated Event Data

  • WebhookSessionThreadTerminatedEventData object { id, type, session_thread_id }
    • id: string The Session ID that triggered the event.
    • type: "session.thread_terminated"
      • "session.thread_terminated"
      Triggered when a Session Thread is terminated. A terminated Thread cannot be recovered; a new Thread must be created to continue work.
    • session_thread_id: string The associated Session Thread ID.

Agent Lifecycle Events

Agent events carry an additional version field beyond the base fields, indicating the Agent’s configuration version number.

Webhook Agent Created Event Data

  • WebhookAgentCreatedEventData object { id, type, version }
    • id: string The Agent ID that triggered the event.
    • type: "agent.created"
      • "agent.created"
      Triggered when an Agent is successfully created. The system sends this event after an Agent is created via POST /agents.
    • version: integer Agent version number. Set to 1 on initial creation.

Webhook Agent Updated Event Data

  • WebhookAgentUpdatedEventData object { id, type, version }
    • id: string The Agent ID that triggered the event.
    • type: "agent.updated"
      • "agent.updated"
      Triggered when an Agent’s configuration is updated. The version increments with each update.
    • version: integer Agent version number.

Webhook Agent Archived Event Data

  • WebhookAgentArchivedEventData object { id, type, version }
    • id: string The Agent ID that triggered the event.
    • type: "agent.archived"
      • "agent.archived"
      Triggered when an Agent is archived. After archival, the Agent no longer accepts new Session creation requests.
    • version: integer Agent version number.

Webhook Agent Deleted Event Data

  • WebhookAgentDeletedEventData object { id, type, version }
    • id: string The Agent ID that triggered the event.
    • type: "agent.deleted"
      • "agent.deleted"
      Triggered when an Agent is deleted. All configuration data for the Agent becomes unrecoverable after deletion.
    • version: integer Agent 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
Response Fields: 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
Response Fields: 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:
Error Fields:
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:
Signature Algorithm:
Where:
  • 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)
Verification Steps:
  1. Extract t and v1 from the Webhook-Signature header
  2. Check that the timestamp is within the tolerance window (recommended 600 seconds) to prevent replay attacks
  3. Compute HMAC-SHA256 of "<t>.<raw_body>" using the signing_secret
  4. Compare the result with v1 using timing-safe comparison

Signature Verification Code Examples

Node.js:
Python:
Go:

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’s consecutive_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 additional session_thread_id field in data:

Agent Event Envelope

Agent events include an additional version field in data:

Field Descriptions

Idempotency Handling

The id 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:
  1. Use id as a unique key for deduplication
  2. Check whether the id has already been consumed before processing
  3. 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 the signing_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:
  1. Verify the Webhook-Signature signature
  2. Use the event id for idempotent deduplication
  3. Return 200 OK to acknowledge receipt
  4. Process business logic asynchronously (avoid timeouts)

Step 4: Send a Test Event

Step 5: Verify and Go Live

After confirming test events are received correctly, you’re ready for production use.

Appendix B: Best Practices