- update UI state in near real time
- trigger downstream workflows after ingestion
- avoid polling document status endpoints
Delivery contract
- At-least-once delivery: duplicate events are possible
- No strict ordering guarantee: events can arrive out of order
- Per-vault subscriptions: subscriptions are scoped to a single vault
- HTTPS only: callback URLs must use
https://and cannot target localhost/private networks
Use
event.id as your idempotency key. Persist processed event IDs and ignore repeats.Event payload
Every webhook delivery includes a stable envelope:Delivery headers and signing
Case.dev includes these headers on webhook requests:X-Case-EventX-Case-Event-IdX-Case-Delivery-IdX-Case-TimestampX-Case-Webhook-VersionX-Case-Signature(only whensigningSecretis configured)
TypeScript signature verification example
Create a subscription
Endpoint
objectIds is optional. If provided, only events for those vault objects are delivered.
Test your endpoint
Endpoint
Manage subscriptions
List subscriptions
Update subscription
Delete subscription
PATCH supports:
callbackUrleventTypesobjectIdsisActivesigningSecretclearSigningSecret
Event types
Vault lifecycle events currently include:vault.upload.initiatedvault.upload.completedvault.upload.failedvault.ingest.startedvault.ingest.completedvault.ingest.failedvault.ingest.extraction.startedvault.ingest.extraction.completedvault.ingest.extraction.failedvault.ingest.chunking.startedvault.ingest.chunking.completedvault.ingest.chunking.failedvault.ingest.embedding.startedvault.ingest.embedding.completedvault.ingest.embedding.failedvault.ingest.storage.startedvault.ingest.storage.completedvault.ingest.storage.failed
Retry behavior
If delivery fails, Case.dev retries with a lightweight backoff policy.- Max attempts: 3
- Retryable failures: network errors,
408,429, and5xx
Next step
If you have not integrated upload/ingest yet, start withUpload & Process →