Shopify Admin API は、Shopify ストアの内部データ――商品とバリアント、注文、在庫、顧客、フルフィルメント――をプログラムから読み書きするための API だ。EC の運用を自動化したり、Shopify を在庫・注文の基盤として使いつつ表側を別で作るヘッドレス構成を組んだりするときの土台になる。
何ができるか
商品の一括登録・更新、注文ステータスの変更、外部の WMS や会計ソフトとの連携、在庫数の同期といった運用作業を API 経由で回せる。Webhook に対応しているので、注文作成や在庫変動をトリガーに自社処理を走らせるイベント駆動の仕組みも組める。
REST から GraphQL への移行
Shopify は API の主軸を REST から GraphQL へ移しており、新しい機能やバルク操作は GraphQL 側に揃っていく傾向がある。これから実装するなら GraphQL を前提に設計しておくと、後で書き直す手戻りが減る。GraphQL のレート制限はリクエスト数ではなく「クエリの計算コスト」で測られるため、欲しいフィールドだけを取る、深いネストを避ける、といったクエリ設計がそのままスループットに効く。
料金とレート制限の現実
API の利用自体に追加料金はなく、Shopify のサブスクリプション料金に含まれる。一方で実装上つまずきやすいのがレート制限で、大量の商品を一気に更新するような処理では制限に当たって弾かれることを前提に、リトライとバックオフ、可能なら GraphQL のバルクオペレーションを使う設計が要る。
バージョン更新への追従
Shopify の API はバージョンが定期的に切られ、古いバージョンは一定期間で利用できなくなる。一度組んだら放置、というわけにはいかず、バージョン更新時の差分を追って定期的にメンテナンスする運用コストを見込んでおきたい。当然ながらこの API は Shopify ストアありきの話で、Shopify を使っていない EC には適用できない。プラットフォームの選定が先にあって、その上での自動化・拡張の手段が Admin API だ、という順序になる。
アクセスできる範囲はアプリの種類で決まる
Shopify の API は、どのストアのデータにどう触れるかがアプリの形態で分かれる。特定の1ストアだけを扱うカスタムアプリと、複数ストアに配布する公開アプリでは、認証の流れも審査の要否もまったく違う。自社ストアの業務自動化が目的ならカスタムアプリで済み、審査もない。アプリストアで配布するなら審査が入り、要求するスコープの妥当性まで見られる。
Shopify の API は四半期ごとにバージョンが切られ、古いバージョンには利用期限があります。「動いていたコードが期限切れで止まる」という事故が起きうるため、使用中のバージョンと、その終了時期を把握しておく必要があります。放置して動き続ける類の API ではありません。
レート制限の考え方が独特
Shopify のレート制限は「単位時間あたり何回」ではなく、コストを消費して回復するバケット方式が基本になる。重いクエリほど多く消費するため、単純にリクエスト数を絞っても解決しない。GraphQL では要求するフィールドの量が消費コストに直結するので、必要なフィールドだけを取る書き方がそのまま安定性につながる。大量データを扱うなら、一括取得の仕組み（Bulk Operations）に寄せる判断も要る。