← Back to Adapters

Document Archive

Archive case documents to long-term storage — one document per request with a minimal metadata envelope

Document Archive Adapter

Provider-agnostic archive adapter API for storing case documents in long-term storage after disbursement. The adapter maps this payload to the underlying archive provider.

Endpoint:

  • POST /archive/document — Archive a single document

The adapter receives one document per request together with a small metadata envelope, uploads it to the underlying archive provider, and returns a provider reference.


Archive Document

POST /archive/document — Upload a single document to the archive provider with a minimal metadata envelope.

Called once per document.

Requestmultipart/form-data with two parts:

  • metadata (application/json) — ArchiveDocumentMetadata
    • caseId (required): Flow flowId, used by the archive provider to group documents per case
    • documentId (required): Document identifier, used to correlate back to case state
    • documentType (required): Document type identifier (e.g., ACCEPTANCE_LETTER). Not an exhaustive list.
    • documentName (required): Human-readable filename, e.g., acceptance-letter-signed.pdf
    • mimeType (required): MIME type of the document (e.g., application/pdf, image/png, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
  • file — The raw document binary, sent with a Content-Type matching mimeType

Response:

  • archivedAt — Timestamp when the document was committed to the archive

Design Notes

Why multipart/form-data? Sending the document as a raw binary part avoids the ~33% size overhead of base64 and keeps metadata cleanly structured as JSON (more evolvable than headers).

Why one document per request? A mortgage case can carry 5–15 documents at a few MB each. Batching them into one request risks very large payloads; per-document requests retry independently and are simpler for the adapter to stream through to the provider.