%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
APIの基本構造とWebhookの仕組みから、連携パターン・セキュリティ設計・開発の進め方まで。「どこまでコードを書くべきか」の判断軸が手に入ります。
APIの基本構造とWebhookの仕組みから、連携パターン・セキュリティ設計・開発の進め方まで。「どこまでコードを書くべきか」の判断軸が手に入ります。
「受注した取引データをHubSpotからスプレッドシートにエクスポートし、基幹システムへ移し替える作業が定型業務になっている」「標準連携やiPaaSでは要件を満たせず、開発を検討し始めた」「エンジニアはいるが、HubSpot側の設計の勘所がわからない」——HubSpotの活用が進んだ企業ほど、こうした声がよく聞かれます。
HubSpot API・Webhook開発とは、HubSpotが公開するREST APIとWebhookを使い、自社の基幹システムや外部サービスとCRMデータを直接やり取りさせる開発手法です。コンタクト・会社・取引・チケットといったCRMオブジェクトの操作から、イベントのリアルタイム検知まで、標準機能やノーコード連携では実現できない「自社独自の処理」を実装できます。
この分野の体系的な情報はHubSpot連携・エコシステムガイドでまとめています。
本記事は「HubSpot × BigQuery連携ガイド｜CRMデータを分析基盤に集約する設計」シリーズの一部です。
本記事はHubSpotゴールドパートナーのStartLinkの「HubSpot完全ガイド」関連記事です。
この記事でわかること
HubSpotと自社システムの連携開発を検討しているエンジニアやCRM管理者に向けて、仕組みの理解から開発着手の順序までを整理した記事です。
- HubSpot APIの基本構造 — CRM APIを中心としたエンドポイント体系と、認証方式の選び方がわかります。
- Webhookの仕組みとイベント設計 — ポーリングとの違い、検知できるイベント、2つの設定方法を解説します。
- 主要な連携パターン5選 — 基幹システム同期からカスタムオブジェクトまで、開発で実現できることを整理します。
- セキュリティとレート制限への対応 — トークン管理、プラン別のレート制限、Webhookの再送と署名検証の要点を押さえます。
- 受注連携の設計例 — 取引が「受注」になった時点で基幹システムへ渡す連携を、プロパティ名・再実行の方針まで具体例で示します。
- 正直な限界と進め方 — API連携が向かないケースと、スモールスタートで進める具体的なステップを示します。
社内にエンジニアがいる方にも、外部パートナーに開発を依頼する予定の方にも読んでいただける内容です。最後まで読むと、自社の連携要件を「ノーコードで済ませる部分」と「APIで開発する部分」に切り分け、最初の一歩を決められるようになります。
HubSpot API・Webhook開発の全体像
APIとWebhookは似た言葉に見えますが、役割は対称です。連携設計の最初の一歩は、この2つが「どちらが動いて」「何を運ぶのか」を区別することから始まります。
APIは「取りに行く」、Webhookは「届けてもらう」
APIは、こちらからリクエストを送ってCRMデータの取得・作成・更新・削除を行う仕組みです。対してWebhookは、HubSpot側でイベントが起きたとき、指定したURLへHTTPリクエストを送ってもらう仕組みです。
実際の連携は、この2つの往復でできています。例えば「取引が受注ステージになったことをWebhookで検知し、APIで取引の詳細を取得し、基幹システムへ登録し、処理結果をAPIでHubSpotのタイムラインに書き戻す」という流れです。片方だけで完結するケースは少なく、この往復の設計が連携の肝になります。
REST APIとWebhookの組み合わせは、Salesforceなど他のCRMにも共通する連携の考え方です。別のCRMで連携開発を経験した方には、仕組みの骨格として馴染みがあるはずです。
CRMの全体フローのどこに効くのか
HubSpotでは、コンタクト（見込み客）から取引（商談）、顧客、請求へとデータが育っていきます。API連携はこの各段階に効きます。リード情報を外部データでエンリッチする、受注取引を基幹システムへ登録する、請求・出荷ステータスをHubSpotへ書き戻す、といった具合です。
「どの段階のデータを、どちら向きに動かすか」を最初に決めると設計がぶれません。ここが曖昧なまま開発に入ると、「作ったけれど誰も使わない連携」になりがちです。
ノーコード連携・iPaaSとの使い分け
API開発は万能ではありません。まず標準連携やiPaaSで実現できる範囲を切り分けてから、残りを開発する順番が現実的です。
| 手段 | 向いているケース | 限界 |
|---|---|---|
| 標準連携・アプリマーケット | 主要SaaSとの定型連携 | 対応していないシステムや独自処理には使えません |
| iPaaS | 複数システムをコードを書かずにつなぐ | 細かい条件分岐や大量処理ではコスト・性能が課題になるケースがあります |
| API・Webhook開発 | 独自ロジック、リアルタイム性、大量データ | エンジニアリソースと継続的な保守が必要です |
ただし「開発できそうだから」という理由でAPIを選ぶと、保守を抱え込んで後悔しがちです。私たちは、ノーコードで済む部分はノーコードで済ませ、コードが必要な部分だけを開発するハイブリッドをおすすめしています。
HubSpot APIの基本構造
HubSpotは包括的なREST APIを提供しており、CRMのほぼすべてのデータにプログラムからアクセスできます。まず押さえるのは「どのAPI群があるのか」と「どう認証するか」の2点です。
APIの種類と主要エンドポイント
| API カテゴリ | 主要なエンドポイント | 用途 |
|---|---|---|
| CRM API | /crm/v3/objects/contacts, deals, companies | コンタクト・取引・会社のCRUD。連携開発の中心になります |
| CMS API | /cms/v3/blogs/posts | ブログ記事などコンテンツの管理 |
| Marketing API | /marketing/v3/forms | フォーム・メール配信まわり |
| Conversations API | /conversations/v3 | 受信トレイ・チャット管理 |
| Automation API | /automation/v4/actions | ワークフロー・カスタムアクション |
自社システム連携で主に使うのはCRM APIです。ほかのAPIは、サイトやコンテンツも含めてHubSpotで運用している場合に出番が増えます。
認証方式の選び方
| 認証方式 | 用途 | 推奨シーン |
|---|---|---|
| プライベートアプリトークン | 自社システム連携 | 社内ツールとの連携に向いています |
| OAuth 2.0 | 第三者向けアプリ開発 | HubSpot App Marketplaceへの公開 |
| 開発者APIキー | 開発・テスト用 | 開発環境でのテスト |
自社システムとの連携であれば、プライベートアプリトークンがシンプルで選びやすい方式です。HubSpotの「開発（Development）」＞「レガシーアプリ（Legacy apps）」から「レガシーアプリを作成」を選び、種類で「プライベート」を選ぶと作成できます。「スコープ」タブで必要な権限だけを追加し、「認証」タブでトークンを表示して使います。
運用面の仕様は公式ドキュメントで次のように定められています（出典：Private apps）。
- 作成できる数 ── 1アカウントあたり最大20個です
- トークンの更新 ── 「ローテーション」から、旧トークンを即時に失効させる方法と、7日後に失効させる方法を選べます。HubSpotは6か月ごとの更新を推奨しています
- 作成者の削除に注意 ── アプリを作成したユーザーを削除すると、一部の呼び出しが権限エラーになることがあります。その場合はトークンのローテーションで復旧します
なお、公式は、レガシーアプリは引き続きサポートされるものの、最新のアプリ機能は使えないと説明しています。新規に開発基盤を選ぶ場合は、公式の開発者向けドキュメントで最新の推奨を確認してください。
スコープは必要最小限に
ここが要点になりますが、スコープの設定は必要最小限にすることが重要です。HubSpotのプロパティ設定でも「ユーザーは管理者のみ変更できるようにする」という権限管理の考え方がありますが、これはAPIアクセスにもそのまま適用できます。
読み取りで済む処理に書き込み権限まで付けておくと、誤操作や漏洩時の被害範囲が広がります。「この連携はコンタクトの読み取りと取引の書き込みだけできればよい」と言語化してから発行するのがコツです。
上の画面は、HubSpot公式のAPIリファレンスです。エンドポイントごとにリクエスト形式と必要スコープが公開されており、連携実装時の正本となる仕様書です。
以下の画面は、HubSpotのAPIリファレンスドキュメントです。連携実装時に参照する公式仕様です。
Webhookの仕組みと設計
APIが「取りに行く」仕組みなら、Webhookは「届けてもらう」仕組みです。「受注した瞬間に動く」のようなリアルタイム連携では、こちらが主役になります。
Webhookとは
Webhookは、HubSpot内で特定のイベント（コンタクト作成、取引ステージ変更など）が発生した際に、指定したURLに自動的にHTTPリクエストを送信する仕組みです。ポーリング（定期的なAPI問い合わせ）と異なり、イベント発生時にリアルタイムでデータを受信できます。
| 観点 | Webhook | ポーリング |
|---|---|---|
| データ取得の契機 | イベント発生時にHubSpotから送信 | 自社側が定期的にAPIを呼び出す |
| リアルタイム性 | 高い | 呼び出し間隔に依存する |
| API消費 | イベント分だけで済む | 変更がなくても呼び続ける |
| 向いている処理 | 受注通知・ステージ連動の自動処理 | 差分確認のバックアップ的な同期 |
実務では「Webhookを主軸に、取りこぼし対策として夜間バッチのポーリングを併用する」構成が堅牢です。Webhookだけに頼ると届かないケースがあるためです（後述します）。
Webhookで検知できるイベント
- コンタクトの作成・更新・削除
- 取引の作成・ステージ変更・削除
- 会社の作成・更新
- チケットの作成・ステージ変更
- フォームの送信
- メールの開封・クリック
例えば「取引ステージが受注に変わった」イベントを検知して請求処理につなげる設計は、受注から請求を一気通貫で回す定番パターンです。
設定方法は2つある
方法1: ワークフローのWebhookアクション
HubSpotのワークフローに「Webhookを送信」アクションを追加し、任意のURLにデータをPOSTできます。ワークフローの条件分岐と組み合わせることで、特定の条件を満たした場合のみWebhookを発火させられます。設定が画面操作で完結するため、最初の試行にも向いています。
方法2: HubSpotアプリのWebhookサブスクリプション
プライベートアプリまたは公開アプリの設定で、Webhookサブスクリプションを作成し、特定のイベントを監視できます。イベントの種類が多い本格運用では、こちらのほうが管理しやすい構成です。
| 方法 | 特徴 | 向いているケース |
|---|---|---|
| ワークフローのWebhookアクション | 画面操作で設定でき、条件分岐と一体で設計できる | 特定条件のときだけ通知したい、試行段階 |
| Webhookサブスクリプション | アプリ設定でイベントを購読する | イベント種類が多い、本格運用 |
Webhookの再送と受け口の設計値
Webhookの受け口（受信するURL）は、HubSpotが送る回数と速度を前提に作ります。公式ドキュメントに記載されている数値は次のとおりです（出典：Webhooks v3 API guide、Error handling）。
| 項目 | 公式ドキュメントの記載 | 設計への影響 |
|---|---|---|
| 受信URL | HTTPSで公開されたURLが必要です | 開発用の自社PCのURLは使えないため、検証用の公開URLを用意します |
| 1リクエストのイベント数 | 最大100件です | 1件ずつ処理する前提にせず、配列を順に処理する作りにします |
| 同時送信数 | 既定で10リクエストです | 取り込みや一括更新の直後に、待たされた分が遅れて届くことがあります |
| 再送 | 接続失敗、5秒を超える応答、4xx・5xxの応答で、最大10回、24時間にわたって再送されます | 同じイベントが複数回届く前提で、重複して処理しない作りにします |
| 購読の上限 | 1アプリあたり1,000件です | イベントの種類を絞って購読します |
特に重要なのは、5秒以内に応答することと、重複を許容することです。受け取ったら先に2xxを返し、本処理は別のキューで行う構成にすると、応答の遅れによる再送を避けられます。再送で同じイベントが届いても二重に請求を作らないよう、イベントID、または外部システムの注文番号を保存して照合します。
購読の作成場所も確認しておきます。レガシーアプリでは、「開発（Development）」＞「レガシーアプリ（Legacy apps）」で対象のアプリを開き、左のメニューの「Webhooks」から「Create subscription」を選びます。コンタクト、会社、取引、チケット、商品、明細のそれぞれで、作成・削除・統合・復元・関連付けの変更・プロパティの変更を購読できます。
ワークフローのWebhookアクションの設定
ワークフローから送る場合は、「オートメーション（Automation）」＞「ワークフロー（Workflows）」でワークフローを開き、アクションを追加して、「データオペレーション（Data ops）」の「Send a webhook」を選びます。公式ナレッジでは次のように説明されています（出典：HubSpotナレッジ「Use webhooks with HubSpot workflows」）。
- メソッドを選ぶ ── POSTはHubSpotのデータを外部へ送り、GETは外部のデータを取得してHubSpotの更新に使います
- URLを入力する ── HTTPSで始まるURLが必要です
- 認証を選ぶ ── 「リクエスト署名をヘッダーに含める」（アプリIDを入力）か、APIキー（名前と送信場所を指定）を選びます
- 本文を決める ── 「すべてのプロパティを含める」か、「Customize request body」で必要なプロパティだけを指定します
- テストして公開する ── テスト実行では既存のレコードは変更されません
この機能は Data Hub の Professional または Enterprise で利用できます。失敗時の再試行は最大3日間で、4xx系の応答では再試行されません（429は再試行されます）。アプリのWebhookの再送（24時間）とは仕様が異なるため、混同しないようにします。
主要な連携パターン5選
ここからは、実際の開発でよく使われる連携パターンを5つ紹介します。どれも「コンタクト→取引→顧客→請求」というCRMの流れのどこかに位置づくもので、自社のどの段階を強化したいかで選び方が変わります。
| パターン | 何をつなぐか | フロー上の位置づけ |
|---|---|---|
| 1. 基幹システムとの双方向同期 | 取引とERP・会計 | 受注から請求まで |
| 2. カスタムリードスコアリング | 外部データとコンタクト | リード獲得・育成 |
| 3. カスタムレポート・ダッシュボード | HubSpotとBIツール | 全工程の可視化 |
| 4. ワークフローのカスタムコード | ワークフローと外部API | 各工程の自動処理 |
| 5. カスタムオブジェクト | 業種固有データとCRM | 顧客データの拡張 |
パターン1: 受注から請求へつなぐ基幹システム同期
HubSpotで受注した取引データを自社の基幹システム（ERP）に自動連携し、請求・出荷プロセスを開始するパターンです。
設計のポイントは次の3点です。
- 取引のステージ変更をWebhookで検知する
- 基幹システム側のAPIを呼び出してデータを登録する
- 処理結果をHubSpotのタイムラインにメモとして記録する
「HubSpotを1個の業務アプリケーションとして、会計までつながるので販売管理システムのような形で使っていただくこともできる」——この思想をAPI連携で実現するパターンです。処理結果をタイムラインに残す設計にしておくと、連携が動いたかどうかを営業担当者自身がレコード上で確認できます。
以下の画面は、会計システムと連携した取引レコードの例です。取引上に見積・取引先の連携カードと、発行済み・予測の請求イベント一覧が表示されています。
パターン1の設計例: 受注を基幹システムへ渡す
パターン1を具体的な設計にすると、次のようになります。名称はあくまで例ですので、自社の用語に合わせて決めます。
| 設計項目 | 例 | 決める理由 |
|---|---|---|
| トリガー | 取引ステージが「受注」（標準パイプラインの内部値はclosedwon）になったとき | ステージ名を変えても、内部値で判定できます |
| 外部IDのプロパティ | 取引に単一行テキスト「基幹システム注文番号」（内部名の例: erp_order_id）を作る | 再送や再実行で二重登録しないための照合キーになります |
| 連携の状態 | 取引に「連携ステータス」（未連携・連携済み・エラー）の列挙型プロパティを作る | 営業担当が取引レコード上で結果を確認できます |
| 失敗時 | 連携ステータスをエラーに更新し、担当者へタスクを作成する | 失敗に気づける経路を、処理本体とは別に用意します |
| 取りこぼし対策 | 夜間に「受注かつ連携ステータスが未連携」の取引を検索して再処理する | Webhookが届かなかった分を補います |
- プロパティを作る ── 設定（歯車）＞ プロパティで対象に「取引」を選び、「プロパティを作成」から上の2つを作ります
- Webhookを受ける ── 取引のプロパティ変更を購読するか、ワークフローで受注時にWebhookを送ります
- 外部IDで照合する ── 基幹システム側でIDが既にあれば更新、なければ登録し、採番したIDを取引に書き戻します
- 結果を記録する ── 連携ステータスを更新し、失敗時はタスクを作成します
パターン2・3: データを育てて読み解く連携
カスタムリードスコアリングは、HubSpot標準のリードスコアリングでは実現できない、自社独自のスコアリングロジックをAPI経由で実装するパターンです。外部のデータソース（業界DB、企業情報DB等）を参照してスコアを算出し、プロパティに書き戻します。ライフサイクルステージの昇格条件と組み合わせれば、「スコア到達→MQL昇格→営業通知」まで一気通貫で回せます。
カスタムレポート・ダッシュボードは、HubSpotのデータをAPIで取得し、BIツール（Tableau、Looker Studio等）に連携してカスタムレポートを作成するパターンです。HubSpotの標準レポートでは表現できない複雑な分析や、クロスプラットフォームのデータ統合が可能になります。
パターン4・5: HubSpot内で完結させる開発
ワークフローのカスタムコードアクションは、ワークフロー内でNode.jsまたはPythonのコードを実行し、外部APIの呼び出しやデータ変換を行うパターンです。iPaaSを使わずに、HubSpotのワークフロー内で外部連携を完結させられます。
「取引が請求書発行ステージに移行したら、カスタムコード（Node.js/Python）で12ヶ月分の請求レコードを自動分割作成する」——こうした複雑な処理もカスタムコードアクションで実現できます。
カスタムオブジェクトは、標準のオブジェクト（コンタクト・会社・取引・チケット）では管理できないデータを、カスタムオブジェクトとしてAPIで作成・管理するパターンです。不動産の物件データ、SaaSのライセンス情報など、業種固有のデータをCRMに統合できます。ただし作成にはEnterpriseプランが必要な点にご留意ください。
セキュリティ設計のポイント
API連携はCRMの中身を外部から操作する仕組みなので、セキュリティは設計段階で組み込んでおきます。押さえるべきはトークン管理・レート制限・署名検証の3点です。
APIトークンの管理
- 環境変数で管理し、ソースコードにハードコーディングしない
- 定期的にトークンをローテーション（更新）する
- 不要になったアプリは速やかに削除する
前節の「スコープは必要最小限」と合わせて、渡す鍵を小さく、使わない鍵は回収する運用を決めておきます。担当者が変わっても安全な状態を維持できるよう、発行済みアプリの一覧と用途は一覧化しておくのがおすすめです。
レート制限への対応
HubSpotのAPIには、プラン別のレート制限があります。公式ドキュメントでは次のように示されています（出典：API usage details）。
| 配布形態・プラン | 10秒あたりの上限 | 1日あたりの上限（アカウント単位） |
|---|---|---|
| 非公開配布のアプリ（プライベートアプリ）: Free・Starter | アプリごとに100 | 250,000 |
| 同: Professional | アプリごとに190 | 625,000 |
| 同: Enterprise | アプリごとに190 | 1,000,000 |
| 公開配布のOAuthアプリ | インストールしたアカウントごとに110（CRM検索APIを除く） | 記載なし |
10秒あたりの上限はアプリごと、1日あたりの上限はアカウント内の全アプリで共有です。上限を超えると429（エラー種別は「RATE_LIMIT」）が返り、1日の上限は、アカウントのタイムゾーンの午前0時にリセットされます。残りの回数は、レスポンスヘッダーの X-HubSpot-RateLimit-Remaining や X-HubSpot-RateLimit-Daily-Remaining で確認できます。CRM検索APIは上記とは別の、より厳しい制限があるため、検索を多用する処理は別に見積もります。エラー応答は、1日のリクエスト全体の5%未満に抑えることが公式に求められています。
大量データの処理時はバッチAPIを活用し、10秒の上限を超えないよう送信を絞り、429が返った場合はリトライロジック（エクスポネンシャルバックオフ）を実装しましょう。1件ずつ同期する設計だと上限に張り付きやすいため、更新をまとめて送る作りが重要です。
Webhookの署名検証
Webhookリクエストが本当にHubSpotから送信されたものかを検証するため、リクエストヘッダの署名検証を実装してください。受け口のURLは外部に公開する以上、第三者からの偽装リクエストを弾く仕組みが連携の信頼性を支えます。
公式ドキュメントが示す最新の方式（v3）は、次の手順です（出典：Validating requests）。
- リクエストのURIにあるURLエンコードされた一部の文字（例: %3A）を元に戻します。クエリ文字列の先頭の「?」は戻しません
- HTTPメソッド、URI、リクエスト本文、
X-HubSpot-Request-Timestampヘッダーの値を、この順に連結します - アプリのクライアントシークレットを鍵に、HMAC SHA-256を計算し、Base64でエンコードします
X-HubSpot-Signature-v3ヘッダーの値と照合します。比較には定数時間の比較関数を使います- タイムスタンプが5分より古いリクエストは拒否します
署名のバージョンは送信元で異なります。CRMオブジェクトのイベント購読はv1、ワークフローのWebhookアクションとカスタムCRMカードはv2が送られると、公式に記載されています。受け口が複数ある場合は、どのバージョンが届くかを先に確認します。
API開発の正直な限界と向かないケース
ここまで「できること」を中心に説明してきましたが、導入判断には限界の把握も同じだけ重要です。率直にお伝えします。
開発・保守には継続的なコストがかかる
API連携の開発には、エンジニアリングリソースと保守コストが発生します。「一部システムで解決できない部分は運用面で解決するとか、そういった検討は必要になってくる」——すべてをAPI連携で解決しようとせず、費用対効果を見極めた上で開発範囲を決定しましょう。
次の連携は、開発より運用やiPaaSのほうが合うケースがあります。
- 月に数件しか流れないデータ連携
- 要件が頻繁に変わる連携
APIの仕様は変わることがある
HubSpotのAPIはバージョンアップにより仕様が変更される場合があります。v1、v2、v3と複数のバージョンが混在しているエンドポイントもあるため、常に最新のドキュメントを参照しましょう。開発して終わりではなく、仕様変更への追随を保守計画に織り込んでおく必要があります。
Webhookには届かないケースがある
ネットワークの一時的な障害などでWebhookリクエストが失敗する可能性があり、HubSpot側のリトライもありますが、すべてのイベントが届くわけではありません。重要なデータ連携では、定期的なバッチ同期を補完的に実装してください。「検知→処理」の経路が1本しかない設計は、障害時の取りこぼしに気づけない点も要注意です。
自社に最適な連携設計の進め方
最後に、ここまでの部品をどう組み立てて開発を進めるかを整理します。パイプラインの設計と同じで、連携にも「自社に最適な形」が答えになります。汎用の正解はないので、要件の棚卸しから始めます。
要件を「データの向き」と「タイミング」で棚卸しする
連携要件は、次の3軸で書き出すと整理しやすくなります。
- 何のデータを動かすか（コンタクト・会社・取引・チケット）
- どちら向きに動かすか（HubSpot→外部 / 外部→HubSpot / 双方向）
- いつ動かすか（リアルタイム / 日次などのバッチ）
この3軸で表にすると、「Webhookが要る部分」と「APIだけで足りる部分」が自然に分かれます。例えば受注通知はリアルタイムのWebhook案件、マスタの整合確認は日次バッチのAPI案件、という具合です。
スモールスタートで段階的に広げる
いきなり双方向の本格同期を組むと、つまずいたときに切り分けが難しくなります。次の順で広げるのがおすすめです。
| ステップ | やること | 確認ポイント |
|---|---|---|
| 1 | プライベートアプリを作成し、読み取りAPIを試す | 必要なスコープでデータが取れるか |
| 2 | ワークフローのWebhookアクションで1イベントを送る | 自社側で受信・記録できるか |
| 3 | 片方向の小さな連携を本番化する | エラー通知とログの見え方 |
| 4 | バッチ同期や双方向連携へ拡張する | レート制限と保守体制 |
小さく動かして確認しながら広げると、問題が起きたときの原因箇所を特定しやすいまま進められます。
仕組み化で属人化を防ぐ
連携開発は、担当エンジニアの頭の中に仕様が残りがちな領域です。トークンの保管場所、付与したスコープ、呼んでいるエンドポイント、エラー時の再実行手順をドキュメント化しておきましょう。
さらに「処理結果をHubSpotのタイムラインに記録する」「失敗時はチケットを起票する」といった形で、動作確認そのものを仕組みに組み込んでおくと、担当が変わっても回る連携になります。個人の力量に頼らず仕組みで解決するのが、長く使える連携の条件です。
StartLinkの連携開発支援の進め方
StartLinkは、HubSpotゴールドパートナーとして150社以上のHubSpot支援に携わっています。API・Webhookの連携は、HubSpotの導入・構築支援の一部として、次の順で伴走します。企業様によって最適な形は異なります。
- 現状の整理・要件定義 ── 連携要件を「データの向き」「タイミング」で表にし、ノーコードで済む部分と開発する部分を切り分けます
- 設計・構築 ── 外部IDのプロパティ、連携ステータス、署名検証、再実行の方針を設計し、構築します
- データ移行 ── 既存データに外部IDを付与し、重複を確認してから連携を開始します
- テスト・検証 ── 再送の重複、5秒超過、429、Webhookの未達を、テスト環境で意図的に起こして確認します
- 定着・運用改善 ── 同期エラーの確認担当と手順を決め、準委任で伴走しながら運用を改善します
標準連携で足りない部分は、自社開発のSyncシリーズ（Sync for freee、Sync for Notionなど）で補えないかを先に確認します。そのうえで、独自要件だけを開発します。連携方式全体の選び方はHubSpot連携ガイド、ノーコードで済ませる場合はZapier・Makeの記事を参照してください。
よくある質問
Q1. HubSpot API開発にはどのプログラミング言語が適していますか？
HubSpotのAPIはREST APIなので、あらゆるプログラミング言語から利用可能です。公式SDKはNode.js、Python、Ruby、PHPで提供されており、特にNode.jsとPythonは情報量が多くおすすめです。HubSpotのカスタムコードアクションもNode.jsとPythonに対応しています。
Q2. APIの利用に追加料金はかかりますか？
HubSpotのAPIは、利用しているプランの範囲内で追加料金なしで利用可能です。ただし、APIでアクセスできるデータの範囲はプランによって異なります。カスタムオブジェクトの作成にはEnterpriseプランが必要です。
Q3. Webhook経由のデータ送信でデータが欠損するリスクはありますか？
ネットワークの一時的な障害などにより、Webhookリクエストが失敗する可能性はあります。HubSpotは失敗したWebhookリクエストをリトライしますが、すべてのイベントが届くわけではありません。重要なデータ連携では、定期的なバッチ同期を補完的に実装することをおすすめします。
Q4. HubSpotのサンドボックス環境でAPI開発のテストはできますか？
はい、EnterpriseプランのサンドボックスではAPI開発のテストが可能です。本番データに影響を与えずに開発・テストを行えるため、API連携の開発時はサンドボックスの活用をおすすめします。
Q5. APIとiPaaSはどちらを選ぶべきですか？
連携の複雑さ、処理件数、社内の技術リソースで判断します。シンプルな連携や処理件数が少ない場合はiPaaSが効率的です。複雑なビジネスロジック、大量データの処理、リアルタイム性が求められる場合はAPI開発を選びましょう。
まとめ
HubSpot API・Webhook開発は、「APIで取りに行き、Webhookで届けてもらう」という役割分担の往復で成り立っています。標準連携やiPaaSでは実現できない自社独自の連携を組める一方で、開発・保守コストと仕様変更への追随は続きます。だからこそ、ノーコードで済む部分とコードで書く部分を切り分け、自社に最適な範囲を決めることが成功の要点です。
最初の一歩としては、次の3ステップから始められます。
- 連携したいデータを「向き」と「タイミング」の3軸で書き出してみる
- プライベートアプリトークンを作成し、小さな読み取り処理を試す
- ワークフローのWebhookアクションで1つのイベントを送信してみる
まずは読み取りAPIから始めて、段階的に連携の範囲を広げていきましょう。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
