Go-live checklist

Work through this list before switching an integration on for real documents.

Parser

• Tested on at least 10–20 real documents, including messy scans and unusual layouts, not just the sample.
• Field names are final. Your code, mappings and exports depend on them.
• Number fields are typed as Number so amounts arrive as numbers.
• A unique field is set (such as the invoice number) if the same document could be sent twice.
• Validation rules cover every field your code reads.
• Maximum Pages fits your longest legitimate document.
• Block Invalid Documents is set the way you want for webhooks.

Authentication

• A dedicated production token, stored in your secrets manager.
• Separate tokens for staging and production.
• The token is only used server-side.

Requests

• Unattended or bulk traffic uses the async endpoint.
• Sync calls have a client timeout of at least 180 seconds, and so does every proxy in between.
• Every response is checked for "status": "success", not just HTTP 2xx. See Errors and retries.
• Only 5xx, network errors and file_upload_error are retried, with backoff and an attempt cap.
• Each document_id is stored with your own record.
• environment is set per deployment (production, staging).

Webhooks

• The production webhook's environment matches what production sends.
• The endpoint uses HTTPS, checks a secret header and verifies signatures.
• The handler responds 2xx fast and does the real work in a background job.
• Handling is idempotent: upsert by entry_id.
• A polling safety net picks up documents with no webhook after a few minutes.

Operations

• Someone is alerted on insufficient_balance, and the balance is topped up ahead of busy periods.
• Invalid entries have an owner: a review queue, a dashboard, or a person checking View data.
• Logs capture endpoint, HTTP status, code, message and document_id for every failure.
• Retention settings match your data policy.