Phala Cloud sends HTTP POST requests to your endpoint when events occur in your workspace — CVM deployments, updates, stops, deletes, and multisig approval requests. Each request includes an HMAC-SHA256 signature for verification.Documentation Index
Fetch the complete documentation index at: https://docs.phala.com/llms.txt
Use this file to discover all available pages before exploring further.
Supported Events
| Event | When |
|---|---|
cvm.created | CVM first deployment completed, now running |
cvm.started | Existing CVM started (after stop) |
cvm.create_failed | CVM deployment failed (boot error, timeout) |
cvm.restarted | CVM restart completed |
cvm.updated | CVM compose update completed, now running |
cvm.stopped | CVM stopped or shut down |
cvm.deleted | CVM deleted |
cvm.update.pending_approval | On-chain KMS update requires multisig approval |
Payload Format
data includes an error field:
HTTP Headers
| Header | Example |
|---|---|
Content-Type | application/json |
User-Agent | PhalaCloud-Webhook/1.0 |
X-Webhook-Id | evt_a1b2c3d4e5f67890 |
X-Webhook-Event | cvm.created |
X-Webhook-Timestamp | 1679012345 |
X-Webhook-Signature | sha256=a1b2c3... |
Verifying Signatures
Each webhook has a signing secret (starts withwhsec_). Use it to verify requests are authentic and untampered.
The signature is: sha256=HMAC-SHA256(secret, "{timestamp}.{raw_body}")
Using SDKs (Recommended)
The Phala Cloud SDKs provide built-in verification with timestamp tolerance checks and constant-time comparison.toleranceSeconds) and use constant-time comparison to prevent timing attacks.
Manual Verification (Python / Node.js)
Manual Verification (Python / Node.js)
X-Webhook-Timestamp is older than 5 minutes.Delivery Behavior
| Aspect | Behavior |
|---|---|
| Success | HTTP 2xx (200, 201, 202, etc.) |
| Failure | Any non-2xx status, network error, or timeout |
| Redirects | Not followed (3xx = failure) |
| Timeout | 10 seconds |
| Retries | Up to 3 retries: 1 min → 10 min → 1 hour |
| Total attempts | 4 (1 initial + 3 retries) |
| Recording | One delivery record per event (final result only) |
Secret Management
Webhook signing secrets follow a strict security model:- Shown once at creation — the full secret is returned only in the
POST /workspace/webhooksresponse - Masked afterward — subsequent
GET/LISTresponses return a masked value (e.g.whsec_****...xxxx) - Reveal requires 2FA — to view the full secret again, your account must have two-factor authentication enabled and recently verified
- Rotation requires 2FA — generating a new secret also requires 2FA verification
Reveal Secret
- Account with 2FA enabled (returns
403if not) - Recent 2FA step-up verification (returns
428if not verified)
Rotate Secret
URL Requirements
Webhook URLs must meet the following requirements:- HTTPS only — HTTP URLs are rejected
- Public addresses only — URLs resolving to private or reserved IP ranges are blocked:
127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16(private)169.254.0.0/16including169.254.169.254(cloud metadata)::1,fc00::/7,fe80::/10(IPv6 private/loopback)
- No localhost —
localhostand.localdomains are not allowed
Managing Webhooks
Dashboard
Settings → Webhooks in your workspace:- Create, edit, enable/disable, delete webhooks
- Select subscribed events
- Send test events
- View delivery history with stats (success rate, response time)
- Resend failed deliveries
API
Best Practices
- Verify signatures — always check
X-Webhook-Signaturebefore processing - Respond fast — return
200immediately, process asynchronously (10s timeout) - Be idempotent — use the
idfield to deduplicate retries - Check timestamps — reject events older than 5 minutes

