販売・顧客のシステムはどこまで繋がるのか — モール型と自社ショップ型の違い
販売・顧客のシステムを繋ぐ相談は、たいてい「会計に売上を流したい」「在庫を揃えたい」から始まります。この分野では、製品を比べる前に外から確かめられる範囲が 2 つに分かれます。
確かめられる範囲が 2 つに分かれる
| 型 | 例 | 公開の面から確かめられること |
|---|---|---|
| 自社ショップ型 | Shopify・BASE | 仕様書・上限・認証・CSV の出口まで誰でも読める |
| CRM 型 | Salesforce Sales Cloud・HubSpot・Zoho CRM・BowNow | 仕様書と上限は読める。契約の段で使えるかが変わる例がある |
| モール型 | 楽天 RMS・Yahoo! ショッピング ストアクリエイターPro | 出店者でないと確かめられない（仕様・上限・持ち出しのいずれも公開の面では読めない例がある） |
モール型は「API が無い」という意味ではありません。公開の面からは確かめられない、という意味です。見積もりの前提を置くには、出店者向けの資料に当たる必要があります。
調査記録から横に並べる
下の表は RenkeiMap の調査記録 から機械で描いています（記号や札をクリックすると原文・出典）。
比較項目:
| システム | 業務ワークフロー円滑度 | ||
|---|---|---|---|
| API/MCP | API の認証方式 | レート制限 | |
| BASE | ◎無料で申請や利用が可能Webhook 誰でも申し込める公開 API 編集部確認 誰でも申し込める公開 API がある。申請も利用も無料で、申し込みから登録が終わればすぐ使えると案内している。取れるのはショップ情報・商品・カテゴリー・注文・振込申請・配送業者の情報で、商品と注文は更新もできる。注文が確定したことを知らせる仕組み（Webhook）は用意されていない。 ベンダー公表ヘルプ（BASE APIの利…()ほか 3 件
BASE ヘルプ（よくある質問の区分・フッター） 編集部確認 ℹ️確かめ方: 開発者向けサイト（developers.thebase.com）から、ドキュメント・利用規約・申請の 3 つの導線と、ヘルプセンターの「BASE APIについて」の 18 の記事を開いて読んだ（2026-09-03）。
採取元: BASE ヘルプ（ショップ向けヘルプの区分）・ヘルプ（BASE APIの利用は無料ですか）・ヘルプ（利用申請後、どのくらいで利用開始できますか）・ヘルプ（見出し）・ヘルプ（Webhook 機能について）
調査日 | ◎OAuth2.0アクセストークンリフレッシュトークン OAuth2.0（アクセストークン） ベンダー公表 OAuth2.0 に対応していて、Authorization ヘッダーにアクセストークンを載せて認証する。アクセストークンの有効期限は1時間程度、リフレッシュトークンの有効期限は30日で、期限が切れたらリフレッシュトークンで取り直せる。権限は範囲（scope）で分かれていて、ショップ情報・メールアドレス・商品・注文・振込申請の取得と、商品・注文の更新を別々に指定する。既定で付くのはショップ情報の取得だけ。つなぐ側が client_id と client_secret を受け取るには、BASE Developers への利用登録と利用許可が要る。 ベンダー公表BASE API ドキュメン…()ほか 2 件
採取元: BASE API ドキュメント（認証）・BASE API ドキュメント（scope）・oauth/access_token・oauth/access_token（解説）・oauth/authorize
調査日 | 5000回100000回1,000件 1時間5000回・1日100000回 ベンダー公表 呼び出しの上限が数字で公開されている。ユーザーごとに1時間の上限が5000回、1日の上限が100000回で、超えるとエラーが返り、00分になると回数が戻る。商品の登録にはこれとは別の上限があり、API を使うかどうかに関係なく1日1,000件まで。上限を緩めてもらえるかは個別の対応で、急ぐときは問い合わせるよう案内している。 ベンダー公表BASE API ドキュメン…()ほか 2 件
採取元: BASE API ドキュメント（APIの利用制限）・ヘルプ（商品情報の登録は、上限がありますか）・ヘルプ（APIの利用制限に達したら）
調査日 |
| BowNow | ○フリープランWebhook 全プランで追加料金なし ベンダー公表 APIは基本機能として提供され、フリープランでも有料プランでも追加の費用なく使える。オプション契約は要らない。使えるようになるのはトラッキングコードを登録した後で、認証もトラッキングコード単位。データ操作を外部へ知らせるWebhookも同じ管理画面から設定する。 | ◎APIキーアクセストークンリフレッシュトークン APIキーでトークンを取る ベンダー公表 管理画面のトラッキングコード設定にあるトラッキングIDとAPIキーを使い、アクセストークンを発行する。アクセストークンの有効期限は6時間、更新用のリフレッシュトークンは1か月。APIキーを再発行すると発行済みのトークンは消え、そのキーを使っていた連携は止まる。認証はトラッキングコード単位で、利用者ごとに権限を分ける仕組みは案内されていない。 | 1,000回10,000回300回 1日と1分で上限がある ベンダー公表 1日に投げられるリクエスト数は、フリープランが1,000回、有料プランが10,000回。この日次の枠はライセンス単位で数え、日本時間の0時に戻る。1分あたりはどちらのプランも300回で、こちらは接続元のIPアドレス単位。上限を超えたリクエストは受け付けられず、429が返る。 |
| HubSpot | ◎api.hubapi.com2026-03公開API 公開 API がある。すべて `https://api.hubapi.com/` の下にあり、2026-03 版から日付で版を切る方式に変わった（旧版は次の版が出ても提供終了日まで動く）。 | ◎OAuthSuper Admin OAuth。複数アカウントに入れるアプリやマーケットプレイス掲載アプリは OAuth が必須。入れる側の利用者は Super Admin か、マーケットプレイスへのアクセス権限が要る。 | 110 requests10 secondsAPI Limit Increase 公開配布の OAuth アプリ（legacy public app と、developer platform 2025.2／2026.03 で OAuth を使いマーケットプレイス配布するアプリ）は、導入先アカウントごとに 10 秒あたり 110 リクエスト。CRM Search API はこの枠の外。非公開配布アプリは 10 秒あたり 100〜190（プラン別）、日次はアカウントあたり 250,000〜1,000,000。API Limit Increase の追加購入は、上の公開配布アプリには効かないと原文が明記している。 ベンダー公表HubSpot develo…()
採取元: HubSpot developers（API usage guidelines and limits）・HubSpot developers（公開配布アプリの枠の外）・HubSpot developers（追加購入が効かない範囲）
調査日 |
| 楽天RMS | ― RMS の API 文書に、公開の面からは到達できなかった（2026-09-09）。webservice.rms.rakuten.co.jp は素性を名乗る UA に対して 403 を返し、/merchant-portal/view は出店者ログイン（R-Login）の向こうにある。UA を偽って回避することはしない（規約の内側で許された口を探すのと、規制を回避するのは別物）。⟹「API が無い」ではなく 「出店者でなければ確かめられない」 が今日の事実。出店者の協力が得られたときに再訪する。 ベンダー公表RMS（ログインの壁）()ほか 1 件
RMS の API 文書に、公開の面からは到達できなかった（2026-09-09）。webservice.rms.rakuten.co.jp は素性を名乗る UA に対して 403 を返し、/merchant-portal/view は出店者ログイン（R-Login）の向こうにある。UA を偽って回避することはしない（規約の内側で許された口を探すのと、規制を回避するのは別物）。⟹「API が無い」ではなく 「出店者でなければ確かめられない」 が今日の事実。出店者の協力が得られたときに再訪する。
採取元: RMS WEB SERVICE（403 応答・見出し）・RMS WEB SERVICE（403 応答・本文）・RMS（ログインの壁）
調査日 | ― 認証の方式は、公開の面からは確かめられなかった。RMS の API 文書は、サーバの拒否と出店者ログインの向こうにあるため、この位置からは中身に届かない。出店者の協力が得られたときに再訪する。 認証の方式は、公開の面からは確かめられなかった。RMS の API 文書は、サーバの拒否と出店者ログインの向こうにあるため、この位置からは中身に届かない。出店者の協力が得られたときに再訪する。 調査日 | ― 呼び出しの上限は、公開の面からは確かめられなかった。RMS の API 文書は、サーバの拒否と出店者ログインの向こうにあるため、この位置からは中身に届かない。出店者の協力が得られたときに再訪する。 呼び出しの上限は、公開の面からは確かめられなかった。RMS の API 文書は、サーバの拒否と出店者ログインの向こうにあるため、この位置からは中身に届かない。出店者の協力が得られたときに再訪する。 調査日 |
| Salesforce Sales Cloud | △WebAPIEnterprise上位プランから Web API は Enterprise 以上のプランに含まれる — 下位プランでは外から繋げない。 | ◎OAuth 2.0アクセストークン API 認証は OAuth 2.0。外部クライアントアプリまたは接続アプリ（connected app）を組織に登録し、OAuth 認可フローでアクセストークンを取得して API を呼び出す。 | 24時間あたり100,000タイムアウトは 10 分 24時間あたりの総 API リクエスト枠はエディションとライセンス数で決まる（例: Enterprise Edition・Salesforce ライセンス 15 の場合 100,000＋15×1,000＝115,000 リクエスト。Developer Edition は 15,000）。20 秒以上かかる同時リクエストは本番組織で 25 まで、タイムアウトは 10 分。 ベンダー公表Salesforce Dev…()
採取元: Salesforce Developer Limits Quick Reference（開発者向け公式・2026-08-10 描画取得）
調査日 |
| Shopify | ◎Admin APIGraphQLREST API Admin API で管理画面の機能を外から扱える。REST Admin API は legacy 扱いになり、新規の公開アプリは GraphQL でしか作れない。 | ◎OAuthアクセストークンアクセススコープ API 認証はアクセストークン方式。公開アプリ・カスタムアプリは OAuth でトークンを発行し、全リクエストに X-Shopify-Access-Token ヘッダーを付与。アプリはインストール時にアクセススコープを申請して権限を絞る。 | leaky bucket1,000 回数ではなく「クエリの重さ」で制限する（leaky bucket）。GraphQL は 1 クエリの上限が 1,000 ポイントで、これはプランに関係なく効く。大量処理は Bulk operations を使う（こちらは上限の対象外）。 ベンダー公表Shopify API ra…()
採取元: Shopify API rate limits（leaky bucket）・Shopify API rate limits（1 クエリの上限）
調査日 |
| Yahoo!ショッピング | △出店ストア向け API利用申請ありID連携必須利用申請と審査が要る 出店ストア向けの API が公開されている。利用には Yahoo! ID連携によるアクセストークンが必要で、注文・定期購入・問い合わせ管理の各 API は利用申請が要る。とくに本番環境の注文関連 API は審査のうえで出店ストアに提供される。 ベンダー公表Yahoo!デベロッパーネッ…()ほか 1 件
Yahoo!デベロッパーネットワーク ショッピング ベンダー公表 ℹ️Yahoo!ショッピング用の Client ID（アプリケーションID）には「ストア向け操作関連の機能（開示先限定スコープ）」の記載が必要で、通常のアプリケーションIDでは申請できない旨がドキュメント冒頭に注意書きされている。
採取元: Yahoo!デベロッパーネットワーク ショッピング・注文に関するAPI
調査日 | ○アクセストークンYahoo! ID 連携 Yahoo! ID連携のアクセストークン ベンダー公表 Yahoo! ID連携（OAuth 2.0 準拠）のアクセストークン ストア向け API は Yahoo! ID連携で取得したアクセストークンを使う。ID連携は OAuth 2.0 に準拠していると利用制限のページに明記されている。アプリケーションには Yahoo!ショッピング用の Client ID（ストア向け操作関連スコープ付き）が必要。 ベンダー公表Yahoo!デベロッパーネッ…()ほか 1 件
採取元: Yahoo!デベロッパーネットワーク ショッピング（Yahoo! ID連携とは）・利用制限について（ユーザーの認可による制限）
調査日 | 1クエリ/秒アプリ登録は10個まで 同一URLへ短時間に大量のリクエストを行うと一定時間利用できなくなる旨と、目安として「1クエリ/秒」が明記されている。あわせて、1つの Yahoo! JAPAN ID につきアプリケーションは10個まで登録できるという上限もある。 ベンダー公表Yahoo!デベロッパーネッ…()ほか 1 件
Yahoo!デベロッパーネットワーク ショッピング（Web APIの利用方法） ベンダー公表 ℹ️この注意書きはショッピング API のトップだけでなく、注文 API など個別のストア向け API システムのページにも同じ文言で掲載されている（編集部が保存済みの両ページで確認・2026-08-05）。1日あたりの総リクエスト数のような上限値は示されていない。
採取元: Yahoo!デベロッパーネットワーク ショッピング（Web APIの利用方法）・利用制限について（アプリケーションの登録上限数）・利用制限について
調査日 |
| Zoho CRM | ◎公開 API無料プランでも利用可ドキュメント一般公開Webhook REST の公開 API があり、ログインなしで読めるドキュメント一般公開。レート枠は版で差があるが無料プランでも利用可。通知（Webhook）や一括処理用の Bulk API も用意されている。 ベンダー公表Zoho CRM V8 AP…()ほか 1 件
Zoho CRM V8 APIs（グローバル開発者ドキュメント） ベンダー公表 ℹ️ドキュメントはグローバル（英語）のみで、日本語版は確認できなかった。日本データセンターのアカウントはエンドポイントのドメインが異なる（accounts.zoho.jp 系）ため、英語ドキュメントの例をそのまま使うと繋がらない点に注意。
採取元: 同上・API Limits（グローバル）
調査日 | ◎OAuth 2.0アクセストークンは1時間リフレッシュトークンは無期限スコープ指定 OAuth 2.0。アクセストークンは1時間で失効し、リフレッシュトークンは無期限（利用者が失効させるまで）。権限はスコープ指定で絞る。 ベンダー公表OAuth 2.0 Auth…()
OAuth 2.0 Authentication（グローバル） ベンダー公表 ℹ️認可リクエストの発行先は登録データセンターごとに異なる。日本データセンターのアカウントは accounts.zoho.jp を使う。
採取元: 同上・同上（Access Token）・同上（Refresh Token）
調査日 | レート制限を公開クレジット制24時間単位残量をヘッダーで返す レート制限を公開しており、呼び出し回数ではなくクレジット制。24時間単位の上限で、無料版は 5000 クレジット、有償版は 50,000 クレジット＋ユーザー数比例＋アドオン。使用量が半分を超えると残量をヘッダーで返す。 ベンダー公表API Limits（グロー…()
API Limits（グローバル） ベンダー公表 ℹ️1回の呼び出しで引かれるクレジットは操作の重さで変わる（Convert Lead は 5、Send Mail は 20、Merge Records は 50 など）。上限のほかに同時実行数（Concurrency）の制限も別に設けられている。
採取元: 同上（Credit System）・同上（表の見出し）・同上（上限表）・同上
調査日 |
◎ 条件なしで当てはまる ○ 条件つき・一部 △ 限定・要申請・無いと明記 × 当てはまらないと明記 ？ 編集部がまだ確認していません ― 提供元が公開していない（編集部が調べた） — 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。
材料の調査日（最新）: 2026-09-09
欄が空でも「無い」とは限りません。この分野は、公開度と契約の壁の 2 軸で読むと意味が確定します。
読み方の例を 3 つ。BASE は誰でも申し込める公開 API で、上限は 1 時間 5,000 回・1 日 100,000 回と書いてあります。HubSpot はマーケットプレイスに載せるアプリは OAuth（パスワードを渡さずに連携を許可する仕組み） が必須で、上限は 10 秒あたりの回数が製品の段で変わります。Shopify は REST を 2024 年 10 月以降 legacy とし、2025 年 4 月以降の新規公開アプリは GraphQL だけで作る決まりにしています。
この分野で特に効く「出口」
販売の器は、乗り換えのときに一番揉めます。Yahoo! ショッピングは「一度退店すると、同じアカウントで再開することはできません。以前のデータを復活させることはできません」と明記しています。Zoho CRM は「サービスデータの所有権がお客様にある」と書き、定期的な書き出しを利用者側で行うよう案内しています。HubSpot は解約後 30 日以内の書面請求で提供する、という形です。
こう繋ぐ — 手順
| 順 | 手順 | こう判定する |
|---|---|---|
| 1 | 自分の器が 3 つの型のどれかを決める | モール型なら、以降の調べ物は出店者向け資料が前提になる |
| 2 | 会計・在庫の側から見た受け入れ口を確かめる | 相手の純正連携の一覧に自分の器の名前があれば、手段は相手が決めている |
| 3 | 上限と認証を読む | 上限が読めない器では、夜間の一括投入の件数を先に決められない |
| 4 | 出口を読む | 退店・解約で戻らないデータがあるなら、日常の書き出しを運用に入れる |
| 5 | 残った不明を問い合わせの項目にする | 「公開の面では確かめられなかった」は、そのまま質問リストになる |