Skip to main content
Webhooks provide a way for notifications to be delivered to an external web server whenever certain sandbox lifecycle events occur. This allows you to receive real-time updates about sandbox creation, updates, and termination without having to poll the API. All webhook requests require authentication using your project API key.

Webhook management

Register webhook

Register a new webhook to receive sandbox lifecycle events. The webhook will be registered for the project associated with your API key. All events specified during webhook creation will be sent to URL provided during registration with following payload.

List webhooks

List all registered webhooks for your project.

Get webhook configuration

Retrieve the current webhook configuration for your project.

Update webhook configuration

Update an existing webhook configuration. The update will replace the previous configuration fields with provided fields.

Delete webhook

Unregister the webhook.

Webhook payload

When a webhook is triggered, your endpoint will receive a POST request with a JSON payload containing the sandbox event data. The payload structure matches the event format from the API:
event_data.execution contains sandbox execution details and is included on sandbox.lifecycle.killed and sandbox.lifecycle.paused events:
  • started_at - UTC RFC3339 timestamp when the current sandbox execution started
  • vcpu_count - Number of vCPUs assigned to the sandbox
  • memory_mb - Memory assigned to the sandbox in MB
  • execution_time - Sandbox runtime in milliseconds
event_data.kill_reason is included on sandbox.lifecycle.killed events and describes why the sandbox was terminated. Possible values:
  • request - stopped by an explicit kill request
  • timeout - the sandbox reached its timeout
  • admin - stopped by an E2B administrative action
  • orphaned - the sandbox was orphaned and cleaned up
  • base_template_missing - the sandbox’s base template was unavailable
  • unknown - the reason was not recorded
events_ttl_days is the number of days the event is retained and remains available through the lifecycle events API.

Webhook verification

To ensure the authenticity of webhook requests, each request includes a signature in the e2b-signature header. You can verify the signature using the signature secret you provided when registering the webhook. This confirms that the request originated from E2B and has not been tampered with.

Webhook request headers

When a webhook is sent, E2B adds headers to help you verify the authenticity of the request and make debugging easier.
  • e2b-webhook-id - Webhook ID that triggered the event
  • e2b-delivery-id - Unique ID for the delivery attempt. A new value is generated for each retry of the same event
  • e2b-signature-version - Currently always v1, reserved for future use
  • e2b-signature - Signature for verifying the request authenticity

Delivery and retries

E2B attempts each delivery up to 3 times in total. A delivery attempt is treated as failed when your endpoint returns a 4xx or 5xx status code, the request times out, or it fails with a network error. Because a delivery can be retried, the same event may be delivered more than once. Make your webhook handler idempotent and use the event id field in the payload to deduplicate deliveries you’ve already processed.

Available event types

The following event types can be subscribed to via webhooks, they are used as the type field in the payload.
  • sandbox.lifecycle.created - Sandbox creation
  • sandbox.lifecycle.killed - Sandbox termination
  • sandbox.lifecycle.updated - Sandbox configuration updates
  • sandbox.lifecycle.paused - Sandbox pausing
  • sandbox.lifecycle.resumed - Sandbox resuming
  • sandbox.lifecycle.checkpointed - Sandbox snapshot created