DataShift EDI API

• Public JSON Schema contracts for the supported canonical EDI documents.

• Human-readable document guidance for lifecycle position, required fields, validation notes, mapping notes, and common implementation pitfalls.

• Field-level models generated from the same public contracts used by the schema download endpoints.

• Operational guidance for validation errors, retries, idempotency, webhook delivery, and versioning.

The canonical lifecycle starts with a Purchase Order (PO), continues through a Purchase Order Acknowledgement (POA), may include one or more Advance Shipping Notices (ASN), and is reconciled by an Invoice (INV). Not every trading relationship uses every document, but when documents are present they should preserve the same business references and line correlation keys across the lifecycle.

Every canonical document uses the same top-level envelope: `docType`, `correlationId`, `timestamp`, `metadata`, and `data`. The `data` object contains the business payload for the specific document type. Partner-specific values that are not part of the canonical core belong in `extrinsics`.

Use `correlationId` to trace a document across systems and support workflows. For line-level lifecycle matching, preserve `data.lineItems[].uniqueLineKey` from the purchase order into downstream POA, ASN, and INV documents whenever it is available. Treat array position, item description, and display line number as presentation details unless the document page says otherwise.

Validate payloads against the JSON Schema before sending test or production traffic. Required fields, enum values, numeric precision, date formats, and `additionalProperties: false` constraints are part of the public contract. Validation errors should be logged with `correlationId`, business document number, document type, and affected line key where available.

The Schemas section exposes downloadable JSON Schema contracts. The Models section expands each canonical object and nested component. Schema properties are ordered to match the public contract rather than alphabetically.

Webhook and error documentation describes delivery expectations, retries, idempotency, validation failures, and manual-resolution cases. Treat webhook delivery as at-least-once and make receivers idempotent before enabling production event handling.

Start with the document page for the payload you are implementing, then inspect the corresponding model and schema download endpoint. For a full order lifecycle implementation, work in this order: PO, POA, ASN, then INV. Validate representative examples locally before sending test traffic, and include `correlationId`, business document numbers, and line keys in your logs.