商品情報は表示されているのに受注や在庫が更新されない。このようなとき、最初から連携を解除すると原因を追いにくくなります。API連携の停止は、認証、権限、対象データ、サービス側の障害を分けて確認しましょう。この記事では、モールをまたいで使える一次確認の順番を整理します。
この記事のポイント
確認すべき項目、実務での対応例、再発を防ぐチェックリストを紹介します。
目次
まず止まった機能と時刻を記録する
受注取得、在庫更新、価格変更、出荷通知は別の処理です。「連携が全部止まった」と一括りにせず、最後に正常だった注文番号や更新時刻、最初に失敗した時刻を残します。同じ店舗でも商品登録だけ成功する場合があるため、機能ごとの成功・失敗を表にします。
認証と操作権限を区別する
ログインできることは、APIで必要なデータを操作できることの証明にはなりません。キーやトークンの期限、アプリの承認状態、許可されているAPIを管理画面で確認します。楽天市場についてはクロスマのマニュアルにライセンスキー更新の説明があります。期限や画面はサービスごとに確認し、他モールへ同じ条件を当てはめないようにします。
対象商品と連携元を照合する
同じ商品名でも商品コードやSKUが違えば別の対象です。問題の店舗ID、商品コード、SKU、注文番号を固定して調べます。取得対象外、非公開、出荷方法の違いで処理されない場合もあるため、直近の正常商品と比較すると原因を絞りやすくなります。
確認のコツ
一括処理へ広げる前に、対象1件と変更前の記録を用意しましょう。
すぐに再送・再取込を繰り返さない
エラー後に何度も再処理すると、既に成功していた処理を重ねるおそれがあります。再処理が同じ注文を更新するのか、新しく作成するのかを確認し、影響範囲を決めて実施します。接続情報を一時的に空にする方法も、再接続後の未処理や削除処理を制御できるとは限らないため、復旧手段として安易に使わないことが大切です。
復旧は接続表示だけで判定しない
認証が有効に戻ったら、受注取得、在庫反映、必要な出荷情報を対象1件で確認します。停止中の注文が自動でさかのぼって取得されるかは別問題です。停止時間帯の注文を一覧化し、未取得、重複、反映待ちを照合してから通常運用へ戻します。
サポートへ渡す情報をそろえる
問い合わせには発生日時、店舗、機能、エラー全文、対象コード、正常だった最終時刻、直前の変更、実施済み確認をまとめます。APIキーやパスワードは本文やスクリーンショットへ載せません。権限不足で見えない情報は推測せず、その旨を記載しましょう。
実務例：受注は止まり、商品登録は動いている場合
商品登録が動くことだけで接続全体を正常と判断せず、受注取得に必要な認証と権限を確認します。停止開始から復旧までの注文一覧をモール側から照合し、未取得の扱いをサポートへ確認します。再取得する際は重複が生じない方法を先に決めます。
運用チェックリスト
- 止まった機能と時間帯を記録した
- キー期限・権限を管理画面で確認した
- 停止中の注文一覧を確保した
- 復旧後の実データ反映を確認した
よくある質問
APIキーを更新したら完了ですか？
実際のデータ反映と停止期間中の欠けを確認してから完了とします。自動再取得の範囲は接続先の仕様確認が必要です。
まとめ
まず現状を整理し、対象商品・担当者・確認結果を記録して運用を整えましょう。複数モールでは、商品情報、在庫、受注、出荷のつながりを確認することが、効率化の土台になります。
参考情報
