Revision Status

Async build completion and revision results are delivered via webhook in addition to being polled via GET /v1/sites/:id. Configuring a revision-status webhook is optional but strongly recommended — it removes the need to poll and avoids race conditions where the AI claims a revision succeeded before the deploy actually landed.

Configuration

Currently configured per-account in the dashboard at app.warpweb.ai → Webhooks. One revision-status URL covers all sites on the account.

A V1.5 update will let you configure per-site revision URLs via a dedicated endpoint.

Events

`event_type`	When it fires
`site.build_complete`	An initial `POST /v1/sites` build finished and the site is live.
`site.build_failed`	An initial build failed. No credits were charged.
`site.revision_complete`	A `POST /v1/sites/:id/revisions` revision deployed successfully.
`site.revision_failed`	A revision failed. No credits were charged.

Outbound request

Same headers as Form Submissions:

POST https://api.yourapp.com/webhooks/warpweb-events
Content-Type: application/json
User-Agent: Warpweb-Webhook/1.0
X-Warpweb-Event-Id: <uuid>
X-Warpweb-Signature: sha256=<hex>

Signed with HMAC-SHA256 using your account-level revision-status secret. See Verifying Signatures.

Body — build complete

{
  "event_id": "<uuid>",
  "event_type": "site.build_complete",
  "site_id": "8f3c2a1b-5d47-4c9e-b820-1f8a3e7d9c4f",
  "deployed_url": "https://brookside-plumbing.warpweb.app",
  "occurred_at": "2026-05-17T14:24:38Z"
}

Body — revision complete

{
  "event_id": "<uuid>",
  "event_type": "site.revision_complete",
  "site_id": "8f3c2a1b-5d47-4c9e-b820-1f8a3e7d9c4f",
  "revision_id": "rev_2a8f1c3b-4e92-4d51-a724-9f3e8d2c1b6a",
  "model": "sonnet",
  "deployed_url": "https://brookside-plumbing.warpweb.app",
  "occurred_at": "2026-05-17T15:11:48Z"
}

Body — failed

{
  "event_id": "<uuid>",
  "event_type": "site.revision_failed",
  "site_id": "8f3c2a1b-5d47-4c9e-b820-1f8a3e7d9c4f",
  "revision_id": "rev_2a8f1c3b-4e92-4d51-a724-9f3e8d2c1b6a",
  "failed_reason": "loop_crashed",
  "occurred_at": "2026-05-17T15:11:48Z"
}

`failed_reason`	Meaning
`iteration_cap`	The model couldn’t converge within the iteration budget. Often fixable by rephrasing the revision instructions.
`loop_crashed`	An infrastructure error during the build loop. Safe to retry the revision.
`audit_log_failed`	Build completed but the audit step failed. Contact support with the `revision_id`.
`unknown`	Catch-all. Contact support with the `revision_id`.

Retry + idempotency

Same contract as form submissions: 2xx done, 4xx not retried, 5xx/network → immediate / +30s / +5min / dead-letter. Use event_id as the dedupe key.

Why use this over polling

Faster. Events fire within seconds of the underlying state change; polling adds latency proportional to your poll interval.
Cheaper. No spent rate limit on poll churn.
Correct. Avoids the AI-claims-success-before-deploy-lands failure class — the event is the source of truth.

Polling stays supported. Use it for one-off scripts; use webhooks for production.

Verifying Signatures Pricing & Credits