This guide walks through the batch document outcome tracking API, showing how to upload a batch of documents, monitor per-file processing progress, and interpret the results.
For API reference details, see [API Documentation - Batch Document Operations](./03-api-documentation.md#batch-document-operations-documentsservice).
At this point, `submitted` means the file was extracted from the ZIP and uploaded to S3 but has not yet been processed by the document pipeline. Files that have not yet been extracted will not appear in `document_outcomes`.
## 3. Extraction Complete, Pipeline in Progress
Once ZIP extraction finishes, `status` changes to `completed` and all files appear in `document_outcomes`. Individual documents may still be progressing through the pipeline runners.
Note: `status: "completed"` means the ZIP extraction is done. Individual documents may still be progressing through the pipeline. Check each file's `outcome` for its current stage.
## 4. Pipeline Fully Complete
When all documents have reached a terminal outcome, the batch is fully processed.
```json
{
"document_outcomes":[
{
"filename":"invoice.pdf",
"outcome":"clean_passed",
"document_id":"...0001"
},
{
"filename":"receipt.pdf",
"outcome":"clean_passed",
"document_id":"...0002"
},
{
"filename":"duplicate_invoice.pdf",
"outcome":"duplicate",
"document_id":"...0001"
},
{
"filename":"corrupt.pdf",
"outcome":"clean_failed",
"document_id":"...0003",
"error_detail":"PDF validation failed",
"clean_fail_reason":"invalid PDF structure: missing xref table"
Each terminal outcome indicates a specific action for the caller:
- **`clean_passed`** -- Success. The document is fully processed. Use the `document_id` to retrieve it via `GET /document/{id}`.
- **`duplicate`** -- The file hash matches a document already in the system for this client. Use the returned `document_id` to reference the existing document. No resubmission needed.
- **`clean_failed`** -- The document was corrupt or failed validation. Check `clean_fail_reason` for the specific failure detail. Possible reasons include `invalid_mimetype`, `password_protected`, `contains_macros`, `empty_content`, `binary_content`, `unsupported_encoding`, `contains_attachments`, dimension/DPI issues, and more. Fix the source file and resubmit.
- **`invalid_type`** -- The file extension is not in the accepted list. Accepted extensions: `.pdf`, `.tiff`, `.tif`, `.jpeg`, `.jpg`, `.png`, `.bmp`, `.docx`, `.xlsx`, `.pptx`, `.txt`, `.eml`. Macro-enabled formats (`.docm`, `.xlsm`, `.pptm`) are not accepted.
- **`failed_s3_upload`** / **`failed_upload`** -- An infrastructure error occurred during processing. `failed_upload` is also used for ZIP archives that contain no processable files after directories, hidden metadata, and unsafe paths are skipped.
- **`sync_skipped`** -- The client's sync configuration prevents processing. Contact an administrator.
- **`init_duplicate`** -- A duplicate was detected during the init processing stage (rather than at extraction time). The returned `document_id` references the existing document. No resubmission needed.
## 6. Outcome Lifecycle
Each file in a batch starts at extraction and progresses through the document processing pipeline. Terminal outcomes (marked below) are final states that will not change.
Non-terminal outcomes (`submitted`, `init_complete`, `sync_complete`) indicate the document is still being processed. Poll the batch details endpoint to see updates as files progress through each stage.
Legacy ZIP batch uploads still create folders during extraction. For batch uploads, the backend records touched folder segments in `batch_folder_candidates` and finalizes cleanup when the batch has terminal outcome evidence.
Accepted terminal outcomes (`clean_passed`, `sync_skipped`) keep their folder assignments. Rejected outcomes (`duplicate`, `init_duplicate`, `invalid_type`, `failed_open`, `failed_read`, `failed_s3_upload`, `failed_upload`, `clean_failed`) detach current-batch documents/uploads from auto-created candidate folders. Empty auto-created folders are then deleted only when they are not root, did not pre-exist, were not renamed, have no documents/uploads/children/chatbot scopes, and are not pending cleanup for another batch.
If outcome persistence fails before any outcome row exists, cleanup remains pending instead of marking `folder_cleanup_completed_at`. This keeps failed zero-outcome batches visible for retry/diagnosis and prevents cleanup from closing before rejected artifacts can be detached.