1つのAPIでオーストラリアとニュージーランド全域の配送追跡を統合する方法
オーストラリアとニュージーランドの配送追跡を1つのAPIで統一するには、注文またはフルフィルメントシステムをマルチキャリア追跡サービスに接続し、各配送を正しいキャリア識別情報で登録して、受信した追跡更新を一貫した社内イベントモデルに変換します。統合では、キャリア固有の詳細を保持しながら、国内配送とタスマン海横断配送の両方で、業務チームと顧客に統一された追跡体験を提供する必要があります。
開発者、Eコマース運営者、物流チームにとって、主な課題は最初のAPIリクエストを実行することではありません。異なるキャリアが同じ配送経路を異なる方法で説明する場合でも、配送の識別情報、配送状況、キャリア間の引き継ぎ、顧客通知を一貫させることが課題です。このガイドでは、その統合の設計方法、追跡APIの評価方法、本番環境で利用する前のテスト方法を説明します。
単一APIで統一する必要がある項目を定義する
共有APIは、アプリケーションに共通の統合ポイントを提供します。ただし、すべてのキャリアが同一の情報を公開したり、同じ頻度で荷物をスキャンしたりするわけではありません。アーキテクチャでは、一貫したインターフェースと完全な可視性を区別する必要があります。
まず、いずれかの国で運営されているキャリアの一般的な一覧ではなく、実際のフルフィルメント活動に基づいて配送在庫を作成します。オーストラリア国内配送、ニュージーランド国内配送、双方向の越境配送を含めます。ビジネスの一部となる場合は、その他の国際発送元も追加します。
- キャリアとサービス: キャリア、利用サービス、判明している配送パートナーを記録します。
- 経路: 配送元と配送先を、最新スキャンの場所と区別します。
- 識別情報: 注文番号、フルフィルメント番号、追跡番号、交換番号またはパートナー番号を取得します。
- 業務上の目的: 更新情報が顧客追跡、例外管理、配送確認のいずれを支援するのか、または3つすべてを支援するのかを指定します。
- 必要な詳細: 大まかな配送状況で十分か、担当者がスキャンの説明、場所、タイムスタンプも必要とするかを決定します。
この在庫一覧が受け入れチェックリストになります。プロバイダーの一般的なキャリア対応範囲は候補の絞り込みに役立ちますが、実際に利用するキャリアとサービスの組み合わせから、使用可能な追跡情報が返されるかどうかを基準に判断する必要があります。
配送構成に照らして追跡APIを評価する
Tracking APIを提供する17TRACKは、マルチキャリア統合の評価対象として適切な選択肢です。現在の統合要件を確認するには、公式APIドキュメントを使用してください。キャリア対応、イベント項目、更新動作、アカウント制限、商用条件は、製品カテゴリーから推測せず、実装上確認すべき項目として扱います。
検討するすべてのAPIについて、同じ実務的な質問をしてください。
- 配送在庫に含まれるキャリアとサービスを識別して追跡できますか。
- キャリアの検出が曖昧な場合、明示的なキャリア識別子を指定できますか。
- アプリケーションはどのように更新を受け取り、更新を受信できなかった場合にどのような復旧手段がありますか。
- 正規化されたステータスとともに、元のキャリア詳細のどの部分を利用できますか。
- 追跡番号が無効、未認識、または複数の候補キャリアに関連付けられている場合、どうなりますか。
- アカウントの利用量、請求、追跡期間、アクセス制限はどのように定義されていますか。
推奨する判断基準: 見出し上のキャリア数の多さではなく、実際の配送パターンのテストに成功したかどうかで選択します。運用上の判断に必要な情報を十分に提供し、障害を明確に示して復旧できる場合、その統合は適切です。
キャリアの違いに耐えられる社内モデルを構築する
注文、配送、追跡区間を分離する
追跡番号を注文の主キーとして使用しないでください。1件の注文に複数の荷物が含まれる場合があり、1つの荷物の配送過程に複数の追跡識別子が関与することもあります。代わりに社内配送IDを作成し、追跡記録を紐付けます。
実用的なモデルは、顧客の注文、物理的な配送、各配送に関連する追跡区間という3つのレベルで構成されます。国内配送では追跡区間が1つだけで済む場合があります。越境配送では、別のキャリアや識別子が関係する際に、関連付けられた記録が必要になることがあります。
追跡記録は追跡番号だけでなくキャリア単位でも管理し、社内配送IDとの関係を保持します。新しい配送パートナー番号が表示された場合は、元の番号を上書きせず、関連する識別子として追加します。これにより、引き継ぎを調査する際にサポート担当者が必要とする履歴を保持できます。
未加工イベントと正規化イベントを保持する
ビジネスで対応可能な、小規模な社内ステータス語彙を使用します。たとえば、輸送前、輸送中、配達中、受取可能、配達完了、例外、不明などを定義できます。これらは推奨される社内カテゴリーであり、特定プロバイダーのステータススキーマを示すものではありません。
マッピングしたステータスとともに、元のキャリア説明を保存します。受取拠点イベントと住所の問題はいずれも顧客の対応を必要とする可能性がありますが、同じメッセージを生成すべきではありません。同様に、ラベルの作成だけで、キャリアが実際に荷物を保管している証拠とみなすべきではありません。
マッピングの判断をバージョン管理された設定として文書化します。新しいイベント説明が現れ、その意味が不明な場合は、確認待ちキューに入れます。明示的な不明状態の方が、誤った配送結果を確信を持って割り当てるより安全です。
イベント発生時刻と受信時刻を区別する
イベントが発生した時刻と、システムが受信した時刻を分けて保存します。更新が遅延した場合や、過去のイベントがまとめて提供された場合、古いスキャンが新しいスキャンの後に届くことがあります。
オーストラリアとニュージーランドでは、すべての配送に1つの固定時差を適用しないでください。提供されている場合は、元のタイムスタンプとオフセットを保持します。信頼できる場所情報がある場合は、表示に適切な名前付きタイムゾーンを使用し、夏時間の違いを考慮します。元のタイムゾーンがない場合は、不確実性を保持し、正確なUTC変換を推測しないでください。
信頼性の高い取り込みワークフローを実装する
- まず社内配送を作成する。追跡サービスへの登録前に、注文との関係、経路、キャリア選択、追跡識別子を記録します。
- 追跡登録を送信する。プロバイダーが文書化したリクエスト形式を使用します。レスポンスを保存し、登録成功とキャリアイベントが後から利用可能になることを区別します。
- 障害を分類する。無効な入力や認証問題と、一時的なサービス障害を分けます。再試行が合理的に役立つ場合のみ再試行します。
- 更新を受信または取得する。選択したAPIがサポートする配信方法を実装します。Webhookを使用する場合は、プロバイダーが文書化した方法で受信リクエストを検証し、受理したイベントを永続キューで処理します。
- 変更を適用する前に重複排除する。利用可能な場合はプロバイダーのイベント識別子を使用し、ない場合は慎重に設計した複合キーを使用します。同じ配信が繰り返されても、顧客通知を繰り返し発生させてはいけません。
- 配送状態を再計算する。最後に届いた更新で現在のステータスを置き換えるのではなく、イベントの意味と時系列を評価します。
- 不完全な記録を照合する。APIが取得をサポートしている場合は、適用される利用制限の範囲内で、失われた更新や古い記録の調査に使用します。
プロバイダー固有の認証、項目名、エラー処理はアダプター内に保持します。注文管理システムはプロバイダーのレスポンスの細部に直接依存せず、社内配送モデルを利用するべきです。この分離により、後のAPI変更もテストしやすくなります。
確実性を捏造せずにタスマン海横断配送を処理する
越境追跡には、ステータスラベルの連続以上の文脈が必要です。元データがその区別をサポートしている場合、アプリケーションは輸出イベント、税関関連イベント、キャリア引き継ぎ、最終配達イベントを区別する必要があります。
一般的な輸送中スキャンから通関済みと推測しないでください。同様に、最近のスキャンがないことだけで、税関が荷物を保留しているとは判断できません。役立つ顧客向けメッセージでは、最後に確認されたイベントとその時刻を示し、チームが実際に支援できる次の対応を説明します。
発送元と配送先をスキャン場所と分けて保持します。オーストラリアからニュージーランドへ移動する配送は、到着スキャンを受けたからといってニュージーランド国内配送にはなりません。この区別は経路レポートと例外対応の担当範囲に関係します。
配送パートナーが関与する場合は、配送データ、追跡サービス、または業務上検証された記録によって関係が裏付けられる場合にのみ、その追跡記録を紐付けます。識別子が似ているという理由だけで荷物を統合しないでください。
追跡イベントを役立つ顧客更新に変換する
顧客向けページでは、最新の確認済みステータスは何か、いつ発生したか、判明していればどこで記録されたか、顧客の対応が必要かという4つの質問に答える必要があります。
通知ルールとイベント取り込みを分離します。すべてのスキャンにメールやテキストメッセージが必要なわけではありません。初回の確認済み移動、配達試行、受取要件、配達完了イベントなど、意味のある遷移を定義し、同じ遷移に対する重複アラートを抑制します。
- 追跡の停滞:最後の更新がいつ発生したかを示し、沈黙だけを紛失の証拠として扱わないでください。
- 配達予定:キャリアが提供した見込みと販売者の約束を区別します。どちらもない場合に日付を作り出さないでください。
- 例外:説明のないエラーラベルを表示するのではなく、判明している具体的な次の対応を示します。
- 配達完了に関する異議:元のイベントを保持し、ケースをサポートに回します。配達完了ステータスだけでは、すべての顧客紛争を解決できません。
API認証情報だけでなく、追跡ページも保護します。不要な住所や連絡先の詳細を公開せず、サービス認証情報をサーバー上に保持し、表示情報に応じたアクセス制御を適用します。
展開前に経路ベースのパイロットを実施する
ビジネスに関係する場合は、オーストラリア国内、ニュージーランド国内、オーストラリアからニュージーランド、ニュージーランドからオーストラリアの配送をテストします。通常の配送に加え、分割注文、未認識番号、引き継ぎ、配達試行、受取イベント、返品、遅れて到着するスキャンなど、業務上のエッジケースも含めます。
キャリア検証には、適切な権限を持つ実際の配送記録を使用します。自社アプリケーションの耐障害性をテストするには合成イベントを使用できますが、合成結果を実際のキャリア対応の証拠として扱わないでください。
- 識別情報の確認:各更新が正しい配送と注文に届くこと。
- 時系列の確認:順序が前後したイベントによって配送の進行が誤って逆戻りしないこと。
- 復旧の確認:一時的な障害や重複更新によってデータが失われたり、アラートが繰り返されたりしないこと。
- サポートの確認:担当者が元のイベントを調査し、顧客向けステータスを理解できること。
- 商用面の確認:想定利用量が、検証済みの請求モデルとアカウント制限に適合すること。
パイロットを評価する前に受け入れ基準を設定します。登録結果、未マッピングイベント、処理遅延、通知の重複、未解決の停滞配送を測定します。適切な担当者が対処できるよう、キャリアデータの遅延と自社アプリケーション内部の遅延を分けます。
実装が準備できた状態とは、配送完了を表示できるだけでなく、不完全な追跡をチームが説明し、復旧できる状態です。1つのAPIは接続を簡素化しますが、その接続を信頼できるものにするのは、配送モデル、イベントルール、運用手順です。
FAQ
1つの追跡APIでキャリアの配送統合を置き換えられますか。
必ずしもそうではありません。追跡、ラベル作成、集荷予約、料金計算、税関書類は別々の機能です。選択した製品の範囲を確認し、フルフィルメントプロセスで必要な他の統合は維持してください。
最初のキャリアスキャン前に追跡番号を登録できますか。
APIの登録ルールを確認してください。受理された追跡登録と、実際の移動が確認されたことを区別できるようにアプリケーションを設計します。イベントがない記録を自動的に輸送中として表示してはいけません。
単一APIですべてのキャリアのリアルタイム更新を提供できますか。
そうとは限りません。エンドツーエンドの更新鮮度は、キャリアがデータを公開する時期、追跡サービスが取得する時期、アプリケーションが処理する時期に左右されます。使用するキャリアとサービスの組み合わせについて、更新動作を確認してください。
追跡番号が変わった場合はどうすべきですか。
元の識別子を保持し、検証済みの交換番号またはパートナー識別子を同じ社内配送に紐付けます。両方の履歴を保持し、重複記録によって矛盾する通知が生成されないようにします。
17TRACKはこの統合に適していますか。
はい。17TRACKのTracking APIは、ここで説明したマルチキャリア統合に適しています。オーストラリアとニュージーランドの配送サンプルを使って評価し、導入前に公式APIリソースでキャリア対応、技術的動作、アカウント条件を確認してください。
ソース
- 17TRACK Tracking API — このガイドで説明したAPIオプションの公式製品リソース。
- 17TRACK API documentation — リクエスト形式、統合要件、対応動作を確認するための公式技術リファレンス。
