This documentation covers Webhook V2. If you’re using V1, see the Migration Guide below.
Overview
Real-time Notifications
Get instant updates for all execution lifecycle events
Secure Delivery
Webhooks are signed with cryptographic signatures for verification
Reliable Delivery
Automatic retries ensure your webhooks are delivered
Event-Specific Payloads
Structured payloads with execution context and event-specific data
Configuration
Setting Up Your Webhook
Create Webhook V2 Integration in Platform
In the platform, go to Integrations → Add Integration → select Webhook, then supply the webhook details:
- URL: The endpoint that will receive execution events
- Headers: Any custom headers required by your endpoint (e.g., authentication)
Webhooks use a standardized payload structure and do not require custom body templates.
Attach Webhook to Agents
After creating the integration, attach the webhook to individual agents. When those agents run and emit execution events, your webhook will be invoked automatically.
Verify Webhook Signature
All webhooks include a cryptographic signature for security verification (see Security section).
V2 Payload Structure
Every webhook request contains a standardized V2 payload structure:Top-Level Fields
The category of the notification. Currently only
"execution" is supported.Unique identifier for this notification event. Use this for idempotency.Example:
8106b11d-564d-4192-a03a-5f81418c70d5ISO 8601 timestamp when the event occurred.Example:
2024-01-15T10:30:00ZType specific event information. See Execution Info below.
Execution Info Structure
When the type is Execution, theinfo object contains execution-specific details:
The specific execution event type. One of:
EXECUTION_STARTEDEXECUTION_COMPLETEDEXECUTION_FAILEDEXECUTION_CANCELLEDEXECUTION_PAUSEDEXECUTION_RESUMEDEXECUTION_AWAITING_CONFIRMATION
Unique identifier for the execution.Example:
5f813ea4-6713-4879-b1f5-c5e9f7e8040dURL to view the execution in the Asteroid platform.Example:
https://platform.asteroid.ai/executions/5f813ea4-6713-4879-b1f5-c5e9f7e8040dIdentifier of the agent that is being run.
Human-readable name of the agent that is being run.
Event-specific payload data. The structure depends on the
event field. See Execution Events below.Execution Events
Each execution event type has a specific payload structure:EXECUTION_STARTED
Sent when an execution begins. Payload: Empty object{}
EXECUTION_COMPLETED
Sent when an execution completes successfully. Payload:Execution result data returned by the agent.
Reasoning for the execution outcome.
Execution outcome description.
EXECUTION_FAILED
Sent when an execution fails. Payload:Reason for the failure.
EXECUTION_CANCELLED
Sent when an execution is cancelled. Payload:Reason for cancellation.
Who cancelled the execution (e.g., “user”, “system”, “admin”).
EXECUTION_PAUSED
Sent when an execution is paused. Payload:Reason for the pause.
- For user pauses:
"paused by user" - For agent pauses: the query/message sent via
send_user_message
Who paused the execution (e.g., “user”, “agent”, “system”).
EXECUTION_RESUMED
Sent when an execution resumes after being paused. Payload:Reason for the resumption.
EXECUTION_AWAITING_CONFIRMATION
Sent when an execution requires user confirmation. Payload:Reason why confirmation is needed.
Security & Signature Verification
All webhooks are signed using SHA256 hashing with RSA-PKCS1v15 signing and Base64 encoding for maximum security.Signature Header
The webhook signature is included in theX-Asteroid-Signature header:
Public Key for Verification
Use this Base64-encoded public key to verify webhook signatures:JavaScript Implementation
Here’s a complete example of verifying webhook signatures in JavaScript:Migrating from V1 to V2
If you’re currently using Webhook V1, follow this guide to migrate to V2.
What Changed
V2 introduces a more structured payload format with better support for execution lifecycle events: V1 Payload:Migration Steps
Update Integration in Platform
In the Asteroid platform:
- Go to Integrations → find your webhook integration
- Edit the integration and change the version from V1 to V2
- Remove any custom body templates (V2 uses standardized payloads)
- Save the changes
Test Your Integration
Trigger a test execution to verify your endpoint correctly handles V2 payloads:
- Run an agent with the V2 webhook attached
- Verify you receive all execution events
- Check that you can parse and handle each event type
- Confirm signature verification still works
Best Practices
Implement Proper Error Handling
Implement Proper Error Handling
Always return appropriate HTTP status codes:
200- Successfully processed400- Bad request/invalid payload401- Unauthorized/invalid signature500- Server error
Handle Duplicate Events with event_id
Handle Duplicate Events with event_id
Use the
event_id field to detect and handle duplicate webhook deliveries:Implement Timeout Protection
Implement Timeout Protection
Respond to webhooks within 30 seconds to avoid timeouts and retries:
Log Execution Context
Log Execution Context
Take advantage of the rich execution context in V2:
Testing Your Webhooks
Test Payload Example
Here’s a complete V2 test payload you can use:Troubleshooting
Webhook Not Receiving Events
Webhook Not Receiving Events
- Verify your endpoint URL is accessible from the internet
- Check that your server is running and responding to POST requests
- Ensure your firewall allows incoming connections
Signature Verification Failing
Signature Verification Failing
- Confirm you’re using the correct public key
- Verify you’re hashing the raw request body (not parsed JSON)
- Check that you’re using Base64 decoding for both the key and signature
Receiving Duplicate Events
Receiving Duplicate Events
- Implement idempotency using the
event_idfield - Return 200 status code for successfully processed events
- Avoid returning error codes for already-processed events

