# Amazon's Vendor API is the EDI cycle wearing REST

> transactions.dev · by visibility.cloud — 2026-07-31
> Written for 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](/blog/the-850-asks-the-810-settles/), with the
promise between them — that
[the transaction layer compiles from every dialect](/blog/biztransaction-is-a-core-field/):
`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](https://www.stedi.com/edi/x12) 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](/blog/the-856-is-already-an-aggregation-tree/);
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](/blog/the-gtin-gap/).

## 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](/blog/ecommerce-has-no-invoice-object/)
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:

```json
{
  "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](/blog/shipbob-wro-is-a-receiving-advice/);
the reconcile between Amazon's paperwork and captured events is
[a typed verdict](/blog/reconcile-is-a-verdict/); the executive reading of
all of it lives at
[visibility.cloud](https://visibility.cloud/asn-po-context-in-traces).

Marketplace channel in your stack — seller side, vendor side, or both?
[Say which](/get-access/); the access flow branches on exactly that
answer.

---
Access: https://transactions.dev/get-access/ · All posts: https://transactions.dev/blog/ · Machine face: https://transactions.dev/llms.txt