File lifecycle
The states a webhook file goes through, from the moment your notification is accepted to delivery.
Every notification you send creates one webhook file, tracked from acceptance to delivery. If you registered a notification_config, some of these states are pushed to your endpoint.
The happy path
| State | What just happened |
|---|---|
PENDING_DOWNLOAD | Your notification was accepted and the file was queued. This is the state at the moment you receive your reply. |
DOWNLOADING | The download from your URL started. |
DOWNLOADED | The file was fetched in full. Its size is recorded here. |
PROCESSING | The file is being delivered to the source. |
COMPLETED | Delivered, and reconciliation notified. End state. |
Failures
| State | What it tells you |
|---|---|
DOWNLOAD_FAILED | Your URL couldn't be fetched — unreachable, expired, rejected the credentials, or took longer than 300 seconds. |
PROCESSING_FAILED | The file was downloaded but couldn't be delivered, or reconciliation couldn't be notified. |
Both keep the error message alongside the file, and both are pushed to your endpoint if you subscribed to them.
What reaches your endpoint
| State | Event you receive |
|---|---|
DOWNLOADED, PROCESSING | download_status.processing |
COMPLETED | download_status.completed |
DOWNLOAD_FAILED | download_status.download_failed |
PROCESSING_FAILED | download_status.processing_failed |
PENDING_DOWNLOAD and DOWNLOADING produce no event — you already know about them, since you're the one who triggered them.
This flow never emits download_status.validation_failed. That event belongs to file ingestion, where the file's content is parsed. Here the file is delivered as published, so a content problem surfaces downstream in reconciliation, not in JaaS.