Cirro B2B API — Proposed Field Adjustments (v2 — 2026-06-01)¶
Cirro sent an updated B2B API Adjustment doc on 2026-06-01, superseding the 2026-05-26 version. Nothing here is wired yet. This page captures what they're asking us to send and what they intend to send us, so we can sequence the work when we're ready. Prior version preserved in git history.
Out of scope today
We are not generating or pushing 856/945 EDI to Amazon yet. CI-397 is scoped to mark-as-shipped on edi_docs only — no downstream EDI output.
Changes from v1 (2026-05-26 → 2026-06-01)
Outbound:
carton_list[]— new top-level array (sibling oflabel_template) for label attachments and label-application metadatapacking_slip_label— restructured: now hasdc,dept,shipment_id(plusname/company_namein their JSON sample, not in their field table). v1 haddc+phone.
Inbound (SendOrder):
Order_type— now documented as enum:0=B2C,10=FBA,20=disposal,30=self-pickup,50=VC,60=WFS,70=B2Bdispatch_info[]— new array replacing the v1 flat top-level fields. Containspro_number,arn,load_id,Carrier,carrier_scac,bol. v1 had these as separate top-level keys onmessage.customer_po_codeandproduct_carrier(v1 top-level) appear dropped —Carriernow lives insidedispatch_info[]; PO mapping needs clarification.order_box_info[]— gainssscc_code
1. Outbound — v1/order/create-b2b¶
We already POST request_data to Cirro. They're proposing two new top-level keys inside it — and the same shape applies to v1/order/update-b2b.
At a glance — po_number, the label_template object, and the new carton_list[] all live inside the request_data we already send:
request_data
├── po_number
├── label_template
│ ├── ucc_label { dept, dc, store, type, items[]{ upc, product_sku, platform_sku, style, color, size } }
│ ├── pallet_label { dept, dc, store, type, items[]{ upc, product_sku, … } }
│ ├── packing_slip_label { dc, dept, name, company_name, shipment_id, items[]{ upc, product_sku, gtin14 } }
│ └── gtin14_label { items[]{ product_sku, color, size_style, gtin14 } } // Walmart only
└── carton_list[].label_list[] { file_id, label_type (1=UCC, 2=Gtin14), box_mark_num (1/2/4), label_source (always 2) }
1.1 po_number¶
| Field | Type | Required | Notes |
|---|---|---|---|
po_number |
string | optional | Purchase Order Number — we already have this in edi_docs from the 940. |
1.2 label_template (object)¶
Wrapper for four sub-templates Cirro will print on our behalf. Each sub-template is itself optional.
Not yet final
Cirro's source doc flags label_template as "still being double-confirmed internally." Treat the shape below as proposed, not locked — confirm before we build to it.
1.2.1 ucc_label¶
UCC-128 carton labels.
| Field | Type | Notes |
|---|---|---|
dept |
string | Department number |
dc |
string | DC# |
store |
string | STORE# |
type |
string | TYPE |
items[] |
object[] | per-SKU detail (see below) |
items[] shape: upc, product_sku (Customer SKU), style, color, size, platform_sku.
1.2.2 pallet_label¶
Same shape as ucc_label (dept / dc / store / type / items[]).
1.2.3 packing_slip_label¶
| Field | Type | Notes |
|---|---|---|
dc |
string | DC# |
dept |
string | Department number |
shipment_id |
string | Shipment ID |
items[] |
object[] | upc, product_sku, gtin14 |
Sample-vs-table discrepancy
The v2 source-doc JSON sample also shows name and company_name on packing_slip_label, but their field-definition table only lists dc/dept/shipment_id/items[]. Confirm with Cirro whether name/company_name are required, optional, or sample-only filler.
1.2.4 gtin14_label (Walmart only)¶
Flagged in source as "Walmart Gtin Label".
items[] shape: product_sku, color, size_style, gtin14.
1.3 carton_list[] (new in v2)¶
Top-level array, sibling of label_template. Each entry has a label_list[] describing labels Cirro should apply per carton.
label_list[] fields:
| Field | Type | Notes |
|---|---|---|
file_id |
string | ID from Cirro Attachment API. Required only if we upload our own UCC or Gtin14 label artwork. |
label_type |
int | 1 = UCC label, 2 = Gtin14 label |
box_mark_num |
int | Total labels to apply on the order. Values: 1, 2, or 4. |
label_source |
int | 1 = manual upload, 2 = system-generated. Cirro instructs PopSockets to always send 2. |
1.4 platform_sku mapping¶
| Platform | platform_sku source |
|---|---|
| Walmart | WMIT |
| Best Buy | platform sku |
| Target | Target SKU |
1.5 Sample outbound payload (from Cirro v2 doc)¶
The new keys live inside request_data alongside everything we already send:
{
"po_number": "PO-2024-06201",
"label_template": {
"ucc_label": {
"dept": "DEPT-01",
"dc": "DC-001",
"store": "STORE-01",
"type": "STANDARD",
"items": [
{
"upc": "012345678905",
"product_sku": "SKU-001",
"style": "Classic",
"color": "Red",
"size": "M",
"platform_sku": "WM-SKU-001"
}
]
},
"pallet_label": {
"dept": "DEPT-01",
"dc": "DC-001",
"store": "STORE-01",
"type": "STANDARD",
"items": [
{
"upc": "012345678905",
"product_sku": "SKU-001"
}
]
},
"packing_slip_label": {
"dc": "DC-001",
"name": "Packing Slip Q1",
"company_name": "Example Corp",
"dept": "DEPT-01",
"items": [
{
"upc": "012345678905",
"product_sku": "SKU-001",
"gtin14": "10012345678905"
}
]
},
"gtin14_label": {
"items": [
{
"product_sku": "SKU-001",
"color": "Red",
"size_style": "M/Classic",
"gtin14": "10012345678905"
}
]
}
},
"carton_list": [
{
"label_list": [
{
"file_id": 12345,
"label_type": 1,
"box_mark_num": 2,
"label_source": 1
}
]
}
]
}
2. Inbound — SendOrder ship event¶
Cirro already sends us SendOrder events. They're proposing additions inside message, a new dispatch_info[] array, and an enriched order_box_info[].
2.1 New / changed top-level fields on message¶
| Field | Notes |
|---|---|
Order_type |
Order type. Enum (per v2 doc): 0 = standard B2C, 10 = FBA, 20 = disposal, 30 = self-pickup, 50 = VC, 60 = WFS, 70 = standard B2B. Note capital O in source. |
dispatch_info[] |
New array. See 2.2. |
2.2 dispatch_info[] (new in v2)¶
Array of dispatches per shipment. v1 had these as flat top-level fields on message; v2 wraps them in an array — implying potentially multiple dispatches per order.
| Field | Notes |
|---|---|
pro_number |
Pro Number |
arn |
ARN / ASN |
load_id |
Load ID |
Carrier |
Carrier name. Note capital C in source. |
carrier_scac |
SCAC code |
bol |
BOL Number |
2.3 Enriched order_box_info[]¶
| Field | Example |
|---|---|
box_no |
"1" |
box_mark |
"prepack order number" |
fn_box_no |
"reference box number" |
sscc_code |
SSCC barcode (new in v2) |
ob_qty |
1 |
ob_length |
"50.00" |
ob_width |
"40.00" |
ob_height |
"30.00" |
ob_weight |
"30.00" |
tracking_number |
"MO201017498MO" |
product_barcode |
"EL122-F5846293533" |
2.4 Sample payload (from Cirro v2 doc)¶
{
"app_token": "abc123",
"sign": "md5string",
"message_type": "StockChangeRecord",
"message_id": "6daf1a43-283b-42a2",
"send_time": 1727712000,
"message": {
"Order_type": "70",
"dispatch_info": [
{
"pro_number": "Pro Number",
"arn": "",
"load_id": "",
"Carrier": "carrier name",
"carrier_scac": "",
"bol": ""
}
],
"order_code": "EL1038-250529-0037",
"reference_no": "112-8525766-8344247",
"order_status": 0,
"tracking_number": "1234567890",
"sm_code": "",
"add_time": "2000-01-02T13:48:19-05:00",
"sc_id": "21",
"warehouse_id": "1",
"outStock_time": "2000-01-02T13:48:19-05:00",
"so_weight": "1166.667",
"order_weight": "1166.667",
"so_shipping_fee": "2571.870",
"property_label": "",
"item": [{
"product_barcode": "G1038-H3166419678",
"product_sku": "GR580010",
"qty": 1,
"fba_product_code": "",
"transaction_id": ""
}],
"fee_details": {
"totalFee": "5618.340",
"SHIPPING": "2571.870",
"OPF": "8.100",
"FSC": "8.100",
"DT": "3038.370",
"RSF": "3038.370",
"OTF": "3038.370",
"currency_code": "USD"
},
"order_box_info": [{
"box_no": "1",
"box_mark": "prepack order number",
"fn_box_no": "reference box number",
"sscc_code": "SSCC",
"ob_qty": 1,
"ob_length": "50.00",
"ob_width": "40.00",
"ob_height": "30.00",
"ob_weight": "30.00",
"tracking_number": "MO201017498MO",
"product_barcode": "EL122-F5846293533"
}]
}
}
3. PopSockets-side open questions¶
- Outbound label fields (
dept/dc/store/type/style/color/size) — are these already on the parsed 940, or do we need a customer/SKU master lookup? platform_sku— confirm where WMIT / Best Buy / Target values live (OMS product master? Arena? per-customer mapping table?)carton_list[].label_list[].file_id(v2) —label_source: 2(system-generated) is what Cirro tells us to send, so when do we ever populatefile_id? Confirm the Attachment-API upload path is optional.packing_slip_label.name/company_name(v2) — appear in JSON sample but not the field-definition table. Required or optional?dispatch_info[]as array (v2) — confirm semantic. Multiple dispatches per order (split shipments)? Or always single-entry?- PO mapping inbound (v2) — v1 had
customer_po_codetop-level; v2 sample doesn't include it. Where does PO number land on inbound now? - Inbound persistence — do we want to land
dispatch_info[]fields (carrier_scac/bol/arn/load_id) onfulfillment_trackingnow (even before 856 push) so the data is ready when we are? - Inbound
order_box_infodims/weight/tracking/sscc_code— same question: persist now for future 856, or wait? fee_detailssub-codes (OPF, FSC, DT, RSF, OTF) — source doc lists them without definitions. Ask Cirro what each represents.- Source-doc wording quirks to clarify with Cirro:
Order_typecapitalOandCarriercapitalCindispatch_info— typos in source doc, or are they sending mixed-case keys?pallet_label.items.product_skuis labeled "Popsockets SKU" while the same field onucc_labelis "Customer SKU" — likely a typo, confirm.gtin14_label.items.size_styleis described as "Customer SKU" in their column — confusing given the field name. Confirm intent.- They call
label_templatea "Waybill Template" (面单模板) — confirm that's the intended naming for our docs/code.
4. Related¶
- CI-397 — Mark
edi_docsshipped on Cirro ship event (does not push 856/945) - CI-319 — Persist shipped event payload on
prepack_tracking(parent;ship_eventalready persisting in prod) - Cirro B2B by Vendor — Overview —
label_templatestructure, the three data gaps, and the open questions for Cirro - Design: Cirro B2B
label_template— config-driven build (CI-433) — send-side build design (proposed, Phase 1.5) - Design: Cirro B2B — enriched ship confirmation & 856/945 (CI-434) — receive-side design (proposed, Phase 1.5)
- Cirro B2B by Vendor — real 850 + 940 + what we send Cirro, per retailer: Amazon · Walmart · Best Buy · Target · Superior
- EDI Pipeline — full 850→810 lifecycle context