ひとつのAPIで、送り状作成をシンプルに。
WMS・OMS・ERP・ECシステムとShippSySをAPIで接続。複数配送会社の送り状を共通のリクエストで発行し、PDF・追跡番号・処理結果を取得できます。
無料トライアルでは、送り状を100件まで発行できます。

API連携の仕組みを、4つのポイントで理解
- 送る
- 配送会社、届け先、荷物、配送サービス
- 検証する
- 発行前に同じデータを
/labels/validateで確認 - 発行する
POST /labelsで複数件の発行をまとめて依頼- 受け取る
- 処理状況、PDF、追跡番号、標準化されたエラー
curl -X POST \
'https://api.shippsys.com/shippsys-api/label/v1/labels?client_key=YOUR_CLIENT_KEY' \
-H 'Authorization: Bearer YOUR_TOKEN' \
-H 'Content-Type: application/json' \
-d '{ "schema_version": 1, "items": [{ "carrier": "sagawa", "client_reference": "ORDER-10001", "ship_date": "2026-08-23", "service": { "method_code": "1" }, "recipient": { "name1": "株式会社テスト", "phone": "03-1234-5678", "postal_code": "100-0001", "prefecture": "東京都", "city": "千代田区", "address1": "千代田1-1" }, "parcel": { "quantity": 1, "items": [{ "name": "商品" }] }, "payment": { "type": "prepaid" } }] }'読みやすさのため任意項目を省略しています。利用可能な値と配送会社別の項目はQuickstart・API Referenceで確認してください。
API連携が適しているケース
- 複数の配送会社を使い分けている
- WMS・OMS・ERPなどに出荷データがすでにある
- 配送会社別のCSV作成やソフト操作が残っている
- 追跡番号を注文・出荷データへ自動で戻したい
- 荷主や倉庫ごとに配送会社の契約情報が異なる
- 発行エラーや再発行の履歴をシステムで管理したい
配送会社が1社のみで発行件数も少なく、既存ソフトで業務が完結している場合は、WebアプリなどAPI以外の方法が適することもあります。現在の出荷フローに合う方法をご案内します。
受注データから発行結果までをつなぐ
導入前に確認する5つのステップ
契約・サービスを確認
利用する配送会社、配送会社との契約情報、配送サービス、送り状用紙を整理します。
業務フローを整理
連携元、必須項目、印刷方法、追跡番号の戻し先を確認します。
APIを実装
APIキーを準備し、一意の管理番号を付けてshipmentデータを送信します。
無料枠100件で検証
配送サービス、用紙、プリンター、取消・再発行を無料トライアル内で確認します。
本番運用を開始
エラー監視、再処理、Webhook受信を確認しながら運用を開始します。
API連携における役割分担
配送ルールや現場の作業状態はお客様のシステムで管理し、ShippSySが配送会社ごとのデータ変換、送り状発行、結果返却を担当します。
配送ルール
注文条件や倉庫ルールから、配送会社・サービスを決定
指定された配送会社・サービスが利用可能かを確認
送り状発行
届け先や荷物情報に一意の管理番号を付けて送信
配送会社別の形式へ変換し、PDF・追跡番号・エラーを返却
印刷・出荷後
印刷・貼付・検品・引渡しなど、現場の作業状態を管理
発行結果と利用可能な照会・取消・再発行操作を提供
送り状発行の前後に必要な機能を、共通APIで提供
配送会社・サービスによる対応差はありますが、データ確認、非同期発行、結果取得、運用操作を同じ考え方で実装できます。
登録前の確認
- 配送会社・利用可能機能の取得
- 住所の正規化
- 送り状データの事前検証
登録・発行
- 複数件の一括受付
- 配送会社別データへの変換
- 非同期での送り状発行
結果の取得
- 処理状況・エラー確認
- PDF・追跡番号の取得
- 配送追跡情報の確認
運用・再処理
- 再発行・削除・印刷指示
- Webhookによる結果通知
- リクエスト・通知履歴の確認
「発行できた」で終わらない、倉庫運用まで考えた設計
注文と梱包を分けて管理
1注文を複数個口で出荷する場合に備え、注文番号とは別に梱包単位の管理番号を持たせます。追跡番号も梱包単位で連携元へ保存します。
重複発行を防ぐ
タイムアウトを「失敗」と決めつけて同じデータを再送せず、まず管理番号で処理結果を確認。未受付であることを確認してから再送します。
エラーを作業者へ返す
郵便番号・住所・電話番号・配送サービスなどのエラーを、倉庫担当者が修正できる言葉と場所で表示します。APIログだけに残さないことが大切です。
発行・印刷・貼付を区別する
PDF生成済みでも、印刷や商品への貼付が完了したとは限りません。システム上の発行状態と、現場の作業状態を分けて管理します。
取消・再発行の履歴を残す
同じPDFの再印刷と、配送条件を変更した新規発行を区別します。旧追跡番号を使用しない状態にし、誰がいつ再発行したかを残します。
非同期結果を取りこぼさない
Webhook受信に失敗した場合に備え、一定時間未完了のデータをAPIで再確認します。通知の再送や署名検証の結果も監視対象にします。
利用できる操作、必須項目、取消方法は配送会社・配送サービスによって異なります。実装前に配送会社別の対応機能を確認し、実際に使用する契約・用紙・プリンターで検証してください。
検討・開発を始める前に確認したいこと
APIを利用する前に、配送会社との契約は必要ですか?
原則として必要です。利用する配送会社との契約に加え、送り状発行に必要なお客様コードや接続情報をご準備ください。必要な情報は配送会社・サービスごとに異なります。
どの配送会社・サービスに対応していますか?
佐川急便、ヤマト運輸、西濃運輸、日本郵便のクリックポストなどに対応しています。利用可能なサービス、項目、操作は配送会社ごとに異なるため、最新情報は配送会社別の対応機能でご確認ください。
無料トライアルでは何を確認できますか?
送り状を100件まで発行し、APIリクエスト、PDF生成、用紙への印刷、追跡番号・処理結果の返却を確認できます。実際の運用で使用する配送サービスと印刷環境での確認をおすすめします。
無料トライアルはテスト環境ですか?
いいえ。現在、専用のサンドボックス環境はありません。無料トライアル中もAPIへ送信したデータは実際の送り状発行処理として扱われます。検証用データ、発行後の取消・破棄方法、社内の確認担当者を事前に決めてください。
開発前に準備する情報は何ですか?
利用する配送会社・サービス、契約情報、送り状用紙、プリンター、出荷元・届け先・商品名などの入力項目、追跡番号の保存先をご確認ください。複数荷主の場合は、契約情報を切り替える単位も整理します。
送り状の処理結果はどのように取得しますか?
APIで処理状況を照会し、発行完了後に送り状PDF、追跡番号、エラー内容を取得できます。Webhookで完了通知を受け取る場合も、通知を受信できなかったデータを再照会する仕組みを推奨します。
同じ出荷データによる二重発行を防げますか?
APIでは出荷データごとに一意の管理番号を付け、同じ管理番号の受付・処理結果を確認できるようにします。タイムアウト時も、未受付であることを確認してから再送することで二重発行を防ぎます。
届け先を修正して送り状を再発行すると、追跡番号はどうなりますか?
上位システムで内容を修正して再連携すると、新しい送り状と追跡番号が発行されます。新しい追跡番号はAPIまたは連携機能を通じて上位システムへ返却・更新されます。再発行分は送り状発行件数に含まれます。
APIの料金はどこで確認できますか?
基本料金と送り状発行件数に応じた料金は料金ページで確認できます。連携開発や運用条件については、現在のシステム構成を伺ったうえでご案内します。
導入方法について相談できますか?
はい。利用中のWMS・OMS・ERP、配送会社、月間発行件数、印刷環境、現在の出荷手順をお知らせください。APIが適しているかを含め、連携範囲と進め方をご案内します。
仕様を確認し、そのまま実装へ進める開発者サイト
認証方法、リクエスト・レスポンス、配送会社別の項目、エラー、Webhook、OpenAPI仕様を公開しています。cURL、JavaScript、Python、PHPのサンプルから実装方法を確認できます。
旧版APIをご利用中のお客様へ
既存連携の仕様確認には、旧版APIドキュメントをご利用ください。新規開発には上記のShippSyS Label APIを推奨しています。
無料トライアル時のご注意:専用のサンドボックス環境はありません。無料トライアル中も、APIへ送信した内容に基づいて実際の送り状発行処理が行われます。