Skip to main content
Configure a relationship, process approved documents, review outbound fulfillment, and inspect transport and business evidence through the EDI API.
Reviewed October 20, 2026. The checked-in spec contains 202 operations, version 0.10.2, copied from source and matched byte-for-byte to its offline exporter before adding provenance metadata. Generated pages also apply handler-backed corrections. The deployment record has a dated, narrower verification scope; the contract does not establish every hosted integration.

Choose the workflow

Credentials and contracts

Tenant keys imply their workspace; partner keys further restrict access. x-tenant-id cannot widen either. Read-only and document-processing scopes differ. Key management needs organization-administrator authority; platform provisioning, global outbox flush, and metrics need platform authority. The server’s EDI_API_TOKEN configuration holds its platform token; that is not a customer credential. Most JSON results use {success,data}. Inspect each endpoint’s business verdict: inbound HTTP 200 can contain rejected documents. Outbound generation returns EDI wire, not JSON. Public health/liveness and transport-authenticated AS2 have distinct authentication rules. Retain a stable Idempotency-Key and exact payload before outbound dispatch. Reviewed order sends additionally preserve the preview’s If-Order-Revision and frozen overrides. PostgreSQL is required for durable retry receipts. After uncertainty, reuse the original request; a new key can create another document. See orders and recovery. The MCP server and CLI/SDK expose subsets with different client checks. Use REST for source routes outside their coverage.
Last modified on October 20, 2026