API reference

Confirm upload

Verify stored object metadata and queue the document for processing. Uploading bytes alone never starts processing. File inspection and final billing admission happen asynchronously before extraction.

On this page

POST/v1/documents/{document_id}/upload-complete

Path parameters

document_idstringrequired

The doc_… identifier returned by create document.

Request body

None. The call inspects the stored object server-side; it never downloads or parses the invoice through the public API.

The SDK handles confirmation inside submit() and process(). The TypeScript example shows the complete SDK flow; use the cURL example for this individual HTTP operation. Calling wait() alone does not confirm an upload.

Responses

202 - accepted: source metadata passed the upload checks and the document is queued. Processing begins asynchronously.
200 - confirmation replay: returns the existing queued, processing, or terminal document. No second processing run is created. Poll the document while it is pending, or handle its terminal result; do not upload again.
402 - entitlement expired after upload. The source is retained until normal expiry so you can upgrade and retry the confirmation without re-uploading.
409 - upload_not_complete: no usable source at the immutable path. Re-upload only after this authoritative response.
4xx/5xx - typed error envelope with stable code, request_id, and retryable.

Ambiguous PUT recovery

A 200 awaiting_upload response from create document is different: source presence is still unknown. Probe this confirmation endpoint before any PUT. A successful confirmation never returns awaiting_upload.

If the direct PUT outcome is ambiguous (timeout, dropped connection), probe this endpoint before re-uploading: a 202/200 means the source was already complete and must not be uploaded again. Wrong-size or wrong-type objects cannot be repaired by overwrite - the path is immutable and non-upsert, so create a new document instead.

The full recovery walkthrough

[data-code-tabs-interactive] { display: none !important; }

cURLBash / Zsh syntax (macOS, Linux, or WSL).

curl --fail-with-body --no-location -X POST \
  https://api.temlavo.com/v1/documents/doc_9f3kc28d/upload-complete \
  -H "Authorization: Bearer inv_live_your_key"

SDK: full lifecycle

import { readFile } from 'node:fs/promises';
import { InvoiceClient } from '@temlavo/sdk';

const client = new InvoiceClient({
  apiKey: process.env.INVOICE_API_KEY!,
});

// High-level SDK flow: create → upload → confirm → wait.
// There is no separate public SDK confirmation method.
const document = await client.documents.process({
  file: await readFile('./invoice.pdf'),
  filename: 'invoice.pdf',
  contentType: 'application/pdf',
});

if (document.status === 'completed') {
  // continue automation
} else if (document.status === 'needs_review') {
  // route for review
} else {
  // terminal processing failure
}

TerminalBash / Zsh syntax (macOS, Linux, or WSL).

curl --fail-with-body --no-location -X POST \
  https://api.temlavo.com/v1/documents/doc_9f3kc28d/upload-complete \
  -H "Authorization: Bearer inv_live_your_key"

The SDK's process() waits for completed, needs_review, or failed. The response below belongs to this HTTP endpoint.

HTTP endpoint response

202 Accepted
{
  "id": "doc_9f3kc28d",
  "object": "document",
  "status": "queued",
  "document_type": "invoice",
  "schema_version": "invoice.v1",
  "policy": { "required_fields": [], "line_items": "advisory", "checks": { "duplicate_detection": true } }
}