GoHighLevel（以下GHL）の API V2 連携は、正直に言って「数日溶ける」レベルで厄介です。実際、400件以上のインテグレーションを構築してきた開発者でも、解決までに何日もかかったと語っているほど。この記事では、その試行錯誤の末にたどり着いた「実際に動く設定方法」を、コードを書かずに（ノーコードで）再現できる形にまとめます。
なぜV2 APIはこんなに面倒なのか
旧APIは廃止予定のため、これからはV2を使うしかありません。ところが厄介なのが、V2にはカレンダーを扱う標準アクションが存在しないこと。
make.com の標準GHLコネクタを開いても、カレンダー予約のエンドポイントはありません。「calendar」で検索しても出てくるのはGoogleカレンダー連携だけ。APIそのものはカレンダー操作に対応しているのに、コネクタ側がそれを拾えていないのです。
つまり、カレンダーの空き状況を取得したり予約を入れたりしたい場合、自分でAPI連携を組むしかないというのが出発点になります。
make.com 標準コネクタでは足りない理由
GHLのドキュメント（Spotlight）を見ると、膨大な数のエンドポイントが用意されています。一方、make.com標準コネクタが対応しているのはそのごく一部。「Make an API Call」というアクションもありますが、これも一部のエンドポイントでしか機能しません。
実際にmake.com標準コネクタが持つスコープを確認すると、ほとんどが「read only（読み取り専用）」。カレンダーやイベントの作成といった操作はできません。
そこで必要になるのが、GHLマーケットプレイスで作る 「カスタムアプリ」 です。
ステップ1：GHLマーケットプレイスでカスタムアプリを作る
「GoHighLevel Marketplace」で検索すると開発者向けダッシュボードにたどり着きます。開発者用ポータルですが、コードは一切書きません。
「Create App」から作成し、以下のように設定します。
| 項目 | 推奨設定 | 理由 |
|---|---|---|
| App Name | 自社名など分かりやすい名前 | 管理しやすくするため |
| App Type | Private（非公開） | Publicにすると権限変更のたびにGHLの審査が入り、数日待たされる |
| Distribution Type | Both（両方） | エージェンシー・サブアカウント両対応にしておけば、アプリを2つ作らずに済む |
| Listing Type | White Label | すべての機能に対応するため。迷ったらこれ一択 |
White Labelアプリは、ホワイトラベル／非ホワイトラベルの両ドメインで、エージェンシー・サブアカウント両レベルから利用できます。トラブルを減らしたいなら、この設定にしておくのが安全です。
ステップ2：スコープ（権限）を設定する
スコープとは「このアプリにどの操作を許可するか」を定義するものです。カレンダーを扱いたいので、最低限こちらを追加します。
calendars.readonly（カレンダー読み取り）calendars.write（カレンダー書き込み）locations.readonly（ロケーション読み取り）※後で必須になります
⚠️ ここで多くの人がハマる「プランの壁」
ドキュメントの「Scopes」一覧を見ると、各エンドポイントに アクセスタイプ（Sub / Company） が記載されています。
- Sub（サブアカウント） → ほとんどのプランで利用可能
- Company（カンパニー） → GHLの上位プランでないと使えない
小さいプランを使っている場合は、「Sub」が使えるエンドポイントに絞るのが鉄則です。設定した権限とプランが噛み合っていないと、原因不明の権限エラーで時間を溶かします。
ステップ3：リダイレクトURLとクライアントキー
リダイレクトURL
make.com連携の場合、決まったコールバックURLを登録します。これはmake.com（旧Integromat）側が用意しているもので、表記に「integromat」と入っていても問題ありません。リブランディング前の名残で、現在もこのドメインでホストされています。登録後は 必ず有効化（activate） してください。
クライアントキー
「Add」からキーを生成すると、Client ID と Client Secret が発行されます。
Client Secretのサンプル画像↓
重要：Client Secret は一度「OK」を押すと二度と表示されません。必ずメモ帳などに控えておくこと。控え忘れたら、削除して作り直すしかありません。
ここまでで、マーケットプレイス側のアプリ設定は完了です。
ステップ4：make.com 側の認証設定（サブアカウント版）
ここからが本番。最も時間がかかるパートです。標準のGHLコネクタは使わず、HTTPモジュールの「Make an OAuth 2.0 request」 を使います（V2 API は OAuth 2.0 のみ対応）。
まず変数を3つ用意する
ツール（Set multiple variables）で以下を定義します。
- location_id … 操作したいサブアカウントのID。GHLのURL内、
location/の後ろの文字列をコピー - calendar_id … 対象カレンダーのID
- company_id … 今は空でOK（後で自動取得します）
GHLでは「location（ロケーション）＝サブアカウント」と理解すると分かりやすいです。
OAuth 2.0 コネクションを作る
「Add」から新しいコネクションを作成し、以下を設定します。
- Flow type：Authorization code
- Authorize URI：ドキュメントの「Get the apps authorization page URL」から、
?（クエスチョンマーク）より前の部分だけをコピー。White Label版（lead connector HQドメイン）を使うのが推奨 - Token URI：「Get Access Token」のURLをコピー（末尾の余計な空白を削除すること。GHL側の表示バグで空白が混入し、URLが壊れます）
- Scope：
calendars.writecalendars.readonlylocations.readonlyを入力 - Client ID / Client Secret：先ほど控えたものを貼り付け
⚠️ スコープの区切りは「カンマ」ではなく「スペース」
GHLはスコープをスペース区切りで要求します。詳細設定（Show advanced settings）から「Scope separator」を comma → space に変更してください。これを忘れると、ひたすら 400 エラーに悩まされます。
認証を実行
「Save」を押すと認証ポップアップが開きます。エージェンシーとサブアカウントの選択肢が出るので、対象のサブアカウントを選択。成功すれば接続完了です。
カレンダーを取得してみる
ドキュメントの「Get Calendar」エンドポイントのURLを貼り付け、プレースホルダーを calendar_id 変数に置き換えます。さらにヘッダーに Version（ドキュメント記載の値）を追加。
実行して ステータス200 が返り、カレンダーのデータが取得できれば、サブアカウント連携は成功です。
ステップ5：エージェンシー版は「2段階認証」になる
サブアカウントを1つだけ扱うなら上記で十分ですが、エージェンシー配下の複数サブアカウントをまとめて扱いたい場合は設定が変わります。
認証時に「エージェンシー」を選び、「すべてのサブアカウントへのアクセスを許可」を選択します。ただし、この状態ではロケーション単位の操作権限がないため、いきなりカレンダーを取得しようとすると 401（このトークンタイプはアクセス不可）が返ります。
これは仕様であり、サポートに連絡する必要はありません。解決には、もう1段階の認証を挟みます。
流れ
- エージェンシートークンを取得（最初のOAuthフロー）
- そのトークンを使って
/oauth/locationTokenエンドポイントにPOSTリクエスト - ボディに
companyIdとlocationIdを送信し、ロケーション単位のアクセストークンを取得
このリクエストはボディに情報を含めるため、標準のOAuthフローでは表現できず、カスタムリクエストとして組む必要があります。Body type は application/x-www-form-urlencoded を選ぶと、フィールドを視覚的に追加できて簡単です。
company_id はどこにある？
GHLのダッシュボードからは見つけにくいため、「Get Location」エンドポイントを使ってロケーション情報を取得し、その中に含まれる companyId を抜き出します。
- Get Location を実行（Parse responseをオンに）
- 返ってきた
companyIdを、Set variableモジュールでcompany_id変数に格納 - その変数を使って
/oauth/locationTokenにリクエスト → ロケーションのアクセストークン取得（成功すると 201）
最後にカレンダーを取得
ロケーションのアクセストークンが手に入ったら、標準HTTPモジュール（Make a Request）でGet Calendarを叩きます。今回は自前で認証ヘッダーを付ける必要があるため、ヘッダーに以下を追加します。
Authorization: Bearer {取得したアクセストークン}
実行して 200 が返れば、エージェンシーレベルからサブアカウントのカレンダーを取得できた、ということになります。
仕上げ：トークンの有効期限に注意（最適化のすすめ）
ここまでで動作はしますが、取得したアクセストークンは24時間で失効します。このままだと、リクエストのたびに新しいトークンを発行してしまい、スケールするとレート制限に引っかかる恐れがあります。
本番運用では、以下の最適化を強く推奨します。
- 取得したアクセストークンを Googleスプレッドシート / Airtable / make.com内蔵DB などに保存
- あわせて 失効時刻のタイムスタンプ（現在時刻＋有効時間から数分マイナスした安全マージン付き）も記録
- リクエスト前に「失効していないか」を比較するモジュールを追加
- 失効していたら、リフレッシュトークンを使って新しいアクセストークンを再発行
これで、無駄なトークン発行を避けつつ安定運用できます。
まとめ
| やること | ポイント |
|---|---|
| カスタムアプリ作成 | Private / Both / White Label で作る |
| スコープ設定 | プラン（Sub / Company）と必ず噛み合わせる |
| クライアントキー | Secretは一度きり表示。必ず控える |
| make.com認証 | スコープ区切りはスペース。Token URIの末尾空白に注意 |
| サブアカウント | 1段階認証でOK |
| エージェンシー | 2段階認証（エージェンシー→ロケーション） |
| 本番運用 | トークンをDB保存＋リフレッシュトークンで再発行 |
GHL V2 APIは、エラーハンドリングの表示が貧弱（とにかく「400」しか返さない）で、つまずきポイントが多いのが実情です。ですが、ここで紹介した手順をなぞれば、標準コネクタでは触れなかった全エンドポイントを自社のワークフローに組み込めるようになります。サポートと何日も往復する前に、まずはこの設定を試してみてください。
コメント