Amazon's Vendor API is the EDI cycle wearing REST

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the integration engineer who owns the marketplace channel wiring.

One thesis: Amazon's SP-API vendor surface is the EDI transaction cycle re-skinned as REST — order retrieval, shipment confirmation, invoice submission, operation for operation — which means the compile that lands an 850/856/810 flow as event context lands Amazon's JSON the same way, and Amazon's catalog throws in something no EDI VAN ever did: a free, enormous product-identifier oracle.

Two businesses, one API family

First the distinction that sorts every Amazon integration conversation: the seller side and the vendor side are different businesses wearing one API family. A seller sells on the marketplace and may hand fulfillment to FBA; a vendor sells to Amazon, wholesale, purchase orders and all. The seller side compiles usefully — Orders API v0 gives the po-analog demand, Fulfillment Outbound gives desadv-grade shipment context, Fulfillment Inbound (the v2024-03-20 generation) is a real custody chain into FBA with inbound-shipment context on both the desadv and receiving sides.

But the vendor side is where the thesis lives, because the vendor side is trading-partner commerce, and Amazon modeled it accordingly:

• Vendor Orders: getPurchaseOrders — Amazon's PO to you, the analog of an inbound X12 850
• Vendor Shipments: SubmitShipmentConfirmations — your ASN back, the analog of an 856
• Vendor Invoices: submitInvoices — your bill, the analog of an 810

The names alone make the argument. This is the purchase-order cycle — the ask and the settle, with the promise between them — that the transaction layer compiles from every dialect: po, desadv, inv references on conformant EPCIS events, whether the wire form was a fixed-width envelope or a JSON body with an LWA token. (For the X12 originals we describe structure in our own prose and link Stedi's licensed reference for element detail — the same rule as everywhere on this site.)

The compile map, then, holds no surprises, and that is the point: getPurchaseOrders payloads → po references; shipment confirmations → desadv on shipping-side events, with the same tree-shaped carton-and-item structure the 856 taught us to read; submitted invoices → inv. Party identity arrives as PartyIdentification.partyId — vendor and warehouse codes, the closest thing to structured party identity anywhere in ecommerce, though still a private code space rather than GLN, so the compile grades it and resolves it against the party master like everything else that isn't a GLN.

The identifier oracle

Now the part that makes Amazon more than one connector among forty. The Catalog Items API's identifier search takes an identifiersType drawn from an enumeration that includes ASIN, EAN, GTIN, ISBN, JAN, UPC — and listings carry externally_assigned_product_identifier, the 12/13/14-digit UPC/EAN/GTIN a product was listed under, immutable once set. Amazon requires a GTIN to list (absent an exemption), which has a consequence Amazon never advertised: its catalog is the industry's largest free crosswalk between marketplace identity and GS1 identity.

Why that matters beyond Amazon: the SKU↔GTIN crosswalk is the maintained asset that upgrades every weak-identity connector in the matrix. When a Shopify barcode field is free text and a 3PL item master carries only a upc, a checksum-validated lookup against Amazon's catalog is the cheapest authoritative-ish source of the real GTIN that exists — populated opportunistically, validated on every entry, graded honestly. The gated alternative (a GDSN data-pool subscription) is authoritative and costs a contract; Amazon's oracle costs a registration.

The gate, stated at its real height

Speaking of which — access honesty. SP-API is a MEDIUM-tier connector and the gate is the registration, not the code: a developer profile review with a security questionnaire, required even for self-authorized private apps, on a Professional seller account. Data access is LWA OAuth2 with buyer PII behind Restricted Data Tokens; eventing is real (Notifications API into SQS or EventBridge — ORDER_CHANGE and FULFILLMENT_ORDER_STATUS are in the official schemas); and there is a sandbox. Budget the review into the timeline before byte one, and the rest is ordinary engineering.

The proof artifact: one confirmation, both grains

One vendor shipment confirmation, compiled to the shipping-side event skeleton it contextualizes:

{
  "type": "ObjectEvent",
  "action": "OBSERVE",
  "bizStep": "shipping",
  "disposition": "in_transit",
  "quantityList": [
    {
      "epcClass": "urn:epc:class:lgtin:0614141.107346.AMZLOT1",
      "quantity": 144,
      "uom": "EA"
    }
  ],
  "bizTransactionList": [
    { "type": "desadv", "bizTransaction": "urn:epc:id:gdti:0614141.00001.SC77120" },
    { "type": "po", "bizTransaction": "urn:epc:id:gdti:0614141.00001.AZPO5501" }
  ]
}

The GTIN inside epcClass is the listing's externally_assigned_product_identifier, checksum-verified — oracle and connector in one join. The document references are CBV core fields, the event validates against the pinned official EPCIS 2.0 schema, and the whole object is superset where Amazon's payload says more than the standard models and conformant always.

Where it composes

For an ISV, the Amazon connector earns its place twice: once as the marketplace channel's po/desadv/inv source for every brand customer who sells there, and once as the identity bridge that raises the join grade of every other connector you wire. The receiving side of the same record comes from the WMS layer; the reconcile between Amazon's paperwork and captured events is a typed verdict; the executive reading of all of it lives at visibility.cloud.

Marketplace channel in your stack — seller side, vendor side, or both? Say which; the access flow branches on exactly that answer.

---

855 words. The access flow is at /get-access/; the family's event door is epcis.dev.