概述
1. shipmentConsolidationCreate → 開啟批次(傳回整合 ID)
2. 附加貨件 × n → 建立每件貨件 + 標籤,附加到批次
3. shipmentConsolidationUpdate(CLOSED) → 關閉批次(傳回分派單)
有兩種方式可以將貨件附加到批次 — 選擇適合您的整合方式(或混合使用):
- 在標籤建立時附加 — 將第 1 步的整合 ID 通過
shipmentConsolidationId欄位串接到每個shipmentCreateWorkflow呼叫。 - 按 ID 附加現有貨件 — 在
shipmentConsolidationCreate(用種子填充批次) 或shipmentConsolidationUpdate(添加到開啟批次) 時傳遞shipmentIds。每件貨件必須已有其日本郵便標籤。
無論哪種方式,每個標籤都會使用您的延期付款號碼建立,以便日本郵便在第 3 步關閉批次時將其接受到分派單。
為什麼使用分開的呼叫而不是一個突變? 第 2.1、2.2 ...、2.n 步在商家的整天內發生 — 隨著訂單的到來,標籤被列印,包裹被封存。批次無法像單件運費鏈那樣進行單一往返:開啟整合和關閉它之間有多個小時的間隔。
先決條件
此流程對於給定的驗證帳戶生效之前:
- 您的帳戶必須已儲存日本郵便延期付款號碼(後納お客様番号) — 一個像
1111111111-222222-3333333333-444444這樣的連字號格式值。在第 1 步通過shipmentConsolidationCreate上的accountNumber傳遞它。 - 您的 API 金鑰必須持有
SHIPMENT_WRITE,加上每件運費工作流程需要的標準範圍。
端點和驗證
以下三個步驟都是發送到同一個端點的 GraphQL 操作。您在標頭中傳遞的內容取決於您的設定 — 選擇您的索引標籤。
URL:
https://api.zonos.com/graphql
Headers:
您在您自己的驗證帳戶下運送自己的訂單。以自己身份驗證 — 不需要帳戶金鑰。
credentialToken: {{YOUR_API_TOKEN}}
尋找位置: Zonos Dashboard → 設定 → 整合 → 帳戶金鑰部分。複製API 金鑰列上的權杖;那就是您的 credentialToken。
第 1 步:shipmentConsolidationCreate
開啟整合。載體代碼將批次鎖定為日本郵便;所有成員貨件必須使用日本郵便服務等級。如果您已有標籤貨件準備好,通過 shipmentIds 用其 ID 種子填充批次 — 否則建立它為空並在第 2 步附加貨件。
突變:
mutation {
shipmentConsolidationCreate(
input: {
carrierCode: JAPAN_POST
accountNumber: "1111111111-222222-3333333333-444444"
name: "Tokyo dispatch — 2026-05-01"
externalId: "merchant-batch-20260501-001"
shipmentIds: ["shipment_01hxa...", "shipment_01hxb..."]
}
) {
id
status
accountNumber
carrierCode
shipments {
id
}
}
}
| 欄位↕ | 註記↕ |
|---|---|
carrierCode | 必需。使用 JAPAN_POST。 |
accountNumber | 連字號格式的延期付款號碼。格式在建立時驗證 — 不良值會立即被拒絕,而不是在關閉時。如果省略,將使用您日本郵便帳戶上儲存的預設帳戶號碼。 |
name | 選用。您的記錄的人類可讀標籤。預設為整合的產生 ID。 |
externalId | 選用。您的內部批次識別碼;如果省略,預設為整合的產生 ID。 |
shipmentIds | 選用。要附加的初始貨件的 ID。保留為空以先開啟批次,然後在第 2 步建立標籤時附加貨件。 |
shipmentId | 已棄用 — 改用 shipmentIds。 |
回應:
{
"data": {
"shipmentConsolidationCreate": {
"id": "shco_01hjk...",
"status": "OPEN",
"accountNumber": "1111111111-222222-3333333333-444444",
"carrierCode": "JAPAN_POST",
"shipments": [
{ "id": "shipment_01hxa..." },
{ "id": "shipment_01hxb..." }
]
}
}
}
保留 id(例如 shco_01HJK...) — 您將在下面的所有內容中使用它。status 是 OPEN,直到第 3 步。
第 2 步:附加貨件
對於您今天需要運費的每件包裹,執行完整的鏈接單件運費工作流程以建立貨件及其標籤。然後使用以下任一方法將貨件附加到批次。
選項 A:在標籤建立時附加
在鏈的最終 shipmentCreateWorkflow 步驟上傳遞整合 ID。鏈中的所有前面的突變與單件運費工作流程相同。
shipmentCreateWorkflow 上的相關欄位:
shipmentCreateWorkflow(
input: {
serviceLevel: "japan_post.air.ems_merchandise"
shipmentConsolidationId: "shco_01hjk..."
generateLabel: true
}
) {
id
trackingDetails {
number
}
shipmentCartons {
label {
labelImage
}
}
}
| 欄位↕ | 註記↕ |
|---|---|
shipmentConsolidationId | 來自第 1 步的 ID。告訴平台「將此貨件附加到該批次。」這是區分整合綁定貨件與獨立貨件的唯一欄位。 |
serviceLevel | 必須是日本郵便服務等級(japan_post.*)。不支援在單一整合內混合載體。 |
選項 B:按 ID 附加現有貨件
如果您的貨件已建立和標籤,使用 shipmentConsolidationUpdate 上的 shipmentIds 將它們添加到開啟批次:
mutation {
shipmentConsolidationUpdate(
input: {
id: "shco_01hjk..."
shipmentIds: ["shipment_01hxd...", "shipment_01hxe..."]
}
) {
id
status
shipments {
id
}
}
}
在添加貨件時,將 status 保留在輸入之外 — 批次保持 OPEN。每件貨件必須使用日本郵便服務等級並在第 3 步關閉批次之前有其標籤(追蹤號碼)。
附加對標籤的影響
無論您使用哪個選項,當日本郵便貨件是整合的一部分時:
- 貨件有一個追蹤號碼,和往常一樣。
- 運費標籤 PDF 不包括客戶/郵局收據副本。那些收據被推遲到第 3 步,其中它們被整合到整個批次的分派單文件中。
- 貨件與整合相關聯;您可以通過
shipmentConsolidation(id: ...)重新查詢它以查看其成員。
為批次中的每件包裹重複此步驟。每個整合最多250 件貨件;嘗試關閉更大的批次會在任何日本郵便呼叫之前失敗,並出現明確的驗證錯誤。
您也可以在關閉之前驗證批次的內容:
query {
shipmentConsolidation(id: "shco_01hjk...") {
status
shipments {
id
trackingDetails {
number
}
}
}
}
每件貨件都應該在這裡顯示追蹤號碼。如果沒有,其標籤永遠沒有建立 — 在關閉之前解決那個問題。status 是 OPEN,直到在第 3 步關閉整合。
第 3 步:shipmentConsolidationUpdate(status: CLOSED)
關閉批次。這是要求日本郵便產生涵蓋每個成員追蹤號碼的延期付款分派單,並將所得 PDF 附加到整合的呼叫。
GraphQL 操作命名為 CloseConsolidation 以描述其意圖,關閉批次。它使用 status: CLOSED 執行 shipmentConsolidationUpdate 突變。
突變:
mutation CloseConsolidation {
shipmentConsolidationUpdate(input: { id: "shco_01hjk...", status: CLOSED }) {
id
status
statusTransitions {
status
changedAt
note
}
customsDocuments {
documentType
fileUrl
}
}
}
| 欄位↕ | 註記↕ |
|---|---|
id | 來自第 1 步的整合 ID。 |
status | 設定為 CLOSED 以關閉批次並產生分派單。 |
shipmentIds | 選用。支援在同一呼叫中添加貨件和關閉 — 貨件首先附加,然後批次關閉。 |
在 CLOSED 請求上:
- 整合被驗證:≤250 件貨件,每個成員必須有追蹤號碼。如果貨件缺少其追蹤號碼(其標籤永遠沒有建立),呼叫被拒絕。
- 日本郵便被要求產生涵蓋每個成員追蹤號碼的延期付款分派單。
- 狀態短暫移動到
MANIFEST_CREATED,同時正在取得滑動 PDF,然後文件附加後移動到CLOSED。 - 分派單 PDF(一個包含滑動和每個成員的客戶/郵局收據的文件)作為
documentType: MANIFEST_DOCUMENT的CustomsDocument附加到整合。
回應:
{
"data": {
"shipmentConsolidationUpdate": {
"id": "shco_01hjk...",
"status": "CLOSED",
"statusTransitions": [
{
"status": "OPEN",
"changedAt": "2026-05-01T08:00:00Z",
"note": "Shipment batch created"
},
{
"status": "MANIFEST_CREATED",
"changedAt": "2026-05-01T17:30:12Z",
"note": "Dispatch slip created with Japan Post"
},
{
"status": "CLOSED",
"changedAt": "2026-05-01T17:30:14Z",
"note": "Dispatch slip downloaded and uploaded"
}
],
"customsDocuments": [
{
"documentType": "MANIFEST_DOCUMENT",
"fileUrl": "https://customs-docs.zonos.com/.../japanpost-dispatch-slip.pdf"
}
]
}
}
}
取得文件
分派單直接作為 documentType: MANIFEST_DOCUMENT 的 CustomsDocument 附加到整合 — 從上面的關閉回應中獲取 fileUrl,或稍後任何時間查詢它:
query {
shipmentConsolidation(id: "shco_01hjk...") {
status
customsDocuments {
documentType
fileUrl
}
}
}
列印 fileUrl 處的 PDF。它包含:
- 第 1 頁: 延期付款分派單 — 將此交給郵局。
- 第 2+ 頁: 每件包裹的客戶/郵局收據 — 一張訂在每件包裹上,另一張由郵局保留。
列印後,帶著包裹 + 分派單 + 收據一起去郵局。日本郵便在帳單期結束時向您的延期付款號碼開發票。
放在一起
商家運費 50 件日本郵便包裹的典型一天看起來像:
08:00 → shipmentConsolidationCreate(JAPAN_POST, accountNumber) → shco_01HJK...
08:30 → CreateDeclarationShipment( ... shipmentConsolidationId: "shco_01HJK..." ) parcel 1
09:15 → CreateDeclarationShipment( ... shipmentConsolidationId: "shco_01HJK..." ) parcel 2
...
16:45 → CreateDeclarationShipment( ... shipmentConsolidationId: "shco_01HJK..." ) parcel 50
17:30 → shipmentConsolidationUpdate(id: "shco_01HJK...", status: CLOSED)
17:32 → Print PDF
更喜歡在一天結束時進行批次?建立當天的標籤時不要有整合 ID,然後一次性開啟整合時帶著每個 shipmentIds 值(或通過 shipmentConsolidationUpdate 分塊添加)並在同一或後續呼叫中關閉它。
如果您在多個業務部門 / 帳單帳戶間運費,請為每個帳戶執行單獨的整合 — 在每個 shipmentConsolidationCreate 上傳遞不同的 accountNumber 並相應路由貨件。一天運費超過 250 件包裹?開啟第二個整合。
錯誤處理
驗證錯誤(在任何日本郵便呼叫之前捕獲)
accountNumber格式不正確 — 在第 1 步(shipmentConsolidationCreate)中被拒絕,甚至整合都不被儲存。錯誤消息識別有問題的段。- >250 件貨件 — 在第 3 步中被拒絕,在日本郵便呼叫之前。
- 成員貨件缺少追蹤號碼 — 在第 3 步中被拒絕。表示標籤建立在較早的時間默默失敗;通過
shipment(id: ...) { trackingDetails }調查受影響的貨件。 - 整合上沒有設定延期付款號碼 — 在第 3 步中被拒絕。在
shipmentConsolidationCreate上傳遞accountNumber,或在您的日本郵便載體帳戶上儲存預設帳戶號碼。
日本郵便 API 錯誤
如果日本郵便拒絕分派單請求,關閉突變會將載體的錯誤代碼和消息作為 GraphQL 錯誤出現。最常見的:
| 代碼↕ | 含義↕ | 要檢查的內容↕ |
|---|---|---|
E034 | 缺少延期付款客戶號碼 | 整合上的 accountNumber。 |
E035 | 追蹤號碼必須是 13 個字元,用 - 分隔 | 成員貨件以某種方式有格式不正確的追蹤號碼。 |
E036 | 追蹤號碼必須是英數字符 | 同上。 |
E037 | 不是有效的延期付款運費 | 成員的標籤是在沒有延期付款客戶號碼的情況下建立的。聯繫 Zonos 支援。 |
E046 | 需要總重量 | 上游標籤建立格式不正確。聯繫 Zonos 支援。 |
50 | 參數格式錯誤 | 輸入上的欄位長度或型別違反。 |
51 | 驗證錯誤 | 聯繫 Zonos 支援。 |
重試
如果關閉呼叫在日本郵便已接受分派單請求之後失敗(即在 PDF 檢索期間),重試 shipmentConsolidationUpdate(status: CLOSED) 是安全的 — 平台將跳過載體呼叫,只重新嘗試提取和附加文件。
如果關閉在日本郵便接受請求之前失敗(驗證錯誤、E0xx、網路逾時),沒有狀態改變 — 修復根本原因並重試。
批次分派(整合)
使用整合流程將一天的日本郵便包裹整合到單一延期付款分派單。
本文件介紹通過 Zonos GraphQL API 建立日本郵便延期付款分派批次的三階段流程:開啟整合、將
n個貨件附加到其中,然後關閉以取得日本郵便的分派單(清單文件)。