If you provideDocumentation Index
Fetch the complete documentation index at: https://docs.offloadapi.com/llms.txt
Use this file to discover all available pages before exploring further.
clientWebhookUrl when creating a case, Offload sends JSON POST requests when the case reaches one of its outward-facing async states.
Events You Can Receive
| Event | When it is sent |
|---|---|
case.completed | The worker marked the case COMPLETED. |
case.failed | The worker or AgentMail event handler marked the case FAILED. |
case.input_needed | The worker paused the case and needs input from your app. |
- case creation
- case accepted
- case resumed after input
- case currently running
Delivery Behavior
The current implementation sends webhooks like this:- method:
POST - header:
content-type: application/json - body: serialized JSON event envelope
- success rule: any HTTP
2xx - retry behavior: none in application code
- signing: none
2xx, Offload logs the failure and drops it.
Event Envelope
event_id is deterministic for a specific case update:
- it includes the case ID
- it includes the event type
- it includes the case
updatedAttimestamp
Recommended Handler Pattern
Attachment Handling
Webhook payloads include attachment metadata indata.attachments, but not a durable file URL.
If you need the file:
- read
attachmentIdfrom the webhook payload - call
GET /cases/{id}/attachments/{attachmentId} - use the returned
downloadUrlbeforeexpiresAt
Metadata Handling
If you passedmetadata when creating the case, Offload includes it in webhook payloads. This is useful because GET /cases/{id} does not currently return metadata.
Reconciliation Strategy
For production use, a reliable pattern is:- use webhooks for low-latency updates
- store
event_id - periodically poll active or recently updated cases
- repair any missed terminal or input-needed transitions from polling results