EC プラットフォーム連携の選び方
既存の EC プラットフォームと連携する場合、できることはプラットフォームが公開している範囲に限られる。自社の業務フローに合わせて API を選ぶのではなく、API の制約に業務を合わせる場面が出てくる。実装前に仕様を読み込む工程が不可欠だ。
事前に確認すべき制約
- 取得できる項目 — 注文・商品・在庫・顧客のどこまで触れるか
- 更新の可否と粒度 — 一括更新ができるか、1件ずつしか触れないか
- API のバージョン — 定期的にバージョンが切られ、旧版に利用期限があるか
- アプリの形態 — 自社店舗専用か、他社にも配布するかで審査要件が変わる
注文イベントは複数回発生します
ひとつの注文に対して、作成・支払い・出荷・更新と複数の通知が届くのが一般的です。どのイベントを処理の起点にするかを決めないと、同じ注文を重複して処理してしまいます。起点を一つに定め、他は状態更新に留める設計にしてください。
レート制限の考え方を確認する
「単位時間あたり何回」という単純な制限とは限らず、クエリの重さに応じてコストを消費する方式が使われることがある。この場合、リクエスト数を減らすだけでは解決せず、取得するフィールドを絞る書き方がそのまま安定性につながる。大量データを扱うなら、一括取得の専用の仕組みに寄せる判断も要る。
在庫同期の難しさ
複数チャネルで販売する場合、在庫の同期が最大の課題になる。API 経由の更新には遅延があり、その間に別チャネルで売れると在庫がずれる。完全な整合は難しいため、安全在庫を設けて超過販売を防ぐ運用と組み合わせるのが現実的だ。