BubbleのAPI Connector入門｜外部サービス連携で気を付けること

BubbleのAPI Connectorは、アプリから外部サービスへリクエストを送り、その結果を表示やワークフローに使うための機能です。接続できた後も、認証情報と失敗時の扱いを設計しておく必要があります。

01API Connectorの役割

連携先のデータを取得したり、外部サービスへ処理を依頼したりできます。相手サービスによって認証方式、入力項目、返答形式は異なるため、設定を始める前に公式API文書を確認します。まずは読み取りだけの小さな呼び出しで接続を確かめると、問題を切り分けやすくなります。

02具体例：公開APIを初期化して投稿タイトルを表示する

最初の接続確認には、架空データを返すJSONPlaceholderを使います。顧客情報やAPIキーを送らず、GETで投稿を1件読む練習です。実業務の配送データではありません。以下は2026年10月21日に確認したBubble公式マニュアルの項目名を基準にしています。エディターの表示が異なる場合は、末尾の公式資料と照合してください。

開発用アプリのAPI Connectorを開き、APIのまとまりを追加して名前を「PracticePosts」にします。Authenticationは「None」にします。この認証なし設定は、今回の公開練習用APIに限ったものです。
呼び出しを追加し、名前を「GetPost」、Use asを「Data」、返り値の形式を「JSON」にします。Methodは「GET」、URLは「https://jsonplaceholder.typicode.com/posts/1」です。HeadersとBodyは追加しません。
「Initialize call」を実行します。これは本物のHTTPリクエストです。返却フィールドのidとuserIdがnumber、titleとbodyがtextとして読み取られていることを確認して保存します。
ページにText要素を置き、「Insert dynamic data」から「Get data from an external API」を選び、PracticePostsのGetPostを指定して、そのtitleを表示します。固定の文字列を入力するのではなく、取得結果のtitleを選びます。
開発用プレビューでタイトルが表示されることを確認します。URL末尾を「/posts/2」に変更して再初期化し、プレビューを再読み込みします。別の投稿タイトルになることまで確認すると、固定テキストを見て成功と判断する取り違えを防げます。

表示されないときは、まずAPIをブラウザーで開いてJSONが返るか、次に初期化が保存できたか、最後にText要素がGetPostのtitleを参照しているかを順に確認します。外部サービスが停止していれば、接続設定だけを変えても解決しません。確認後は練習用URLを「/posts/1」に戻してください。

03エラー時に確認する場所を決める

初期化で404：URLのホスト・パス・末尾のIDを、連携先の仕様と照合します。練習用と業務用のURLを混ぜていないか確認します。
業務用APIで401・403：認証方式、キーの有効性、対象データの権限を確認します。認証を外して成功させようとしないでください。JSONPlaceholderの認証なしGETでは、この認証試験はできません。
429・5xx・タイムアウト：取得失敗を空の正常結果と混同せず、「取得できませんでした」と表示する経路を用意します。連打や無制限の再試行で負荷を増やさないようにします。
初期化は成功するが画面が空：Use asがDataか、表示要素が正しい呼び出しとフィールドを参照しているかを確認します。

業務用のWorkflowでエラー応答を扱う場合は「Include errors in response & allow workflow actions to continue」の利用を検討します。有効化するとエラー時にも処理が続くため、返却エラーの有無を条件にして、成功表示やデータ更新へ進めない分岐が必要です。設定変更後は返却形式が変わるため、再初期化と失敗ケースの再試験を行います。

04鍵と初期化に注意する

APIキーは画面のテキストやURLに埋め込まず、秘密として扱います。Bubbleの公式文書も、認証情報を利用者側に露出させない設定を強調しています。また、呼び出しの初期化は実際のAPIリクエストを送ります。作成・削除を伴うAPIなら、テスト用データと環境を用意してから操作しましょう。

05失敗時の動きまで設計する

外部サービスは一時的に応答しない場合があります。タイムアウト、認証切れ、利用上限、重複実行を想定し、利用者に何を伝えるか、再試行してよいかを決めます。重要な更新では、Bubble側だけで成功表示を出さず、相手側で処理されたことを確認できる流れを考えます。

06連携前に決める三つの境界

まず、どのデータを外部へ渡す必要があるかを絞ります。次に、APIキーをどこで管理し、誰が更新するかを決めます。最後に、連携先が停止したときに画面や業務をどう扱うかを整理します。画面で入力できる項目をそのまま全て送る設計は避け、送信する項目と目的を明示しましょう。

テストでは正常応答だけでなく、認証エラー、想定外のレスポンス、連続クリック、同じ処理の再送も確認します。外部システムとの境界を明確にすると、公開後の障害調査や仕様変更にも対応しやすくなります。

07具体例：配送状況の「照会」だけを連携する

ECの管理画面で注文番号を入力し、配送サービスから状態を読む例を考えます。連携先の公式API文書でURL、HTTPメソッド、認証方式、応答例を確認し、API Connectorでまず読み取り専用の呼び出しを設定します。注文番号は利用者が変更できる入力ですが、APIキーは認証用の秘密値としてPrivateなパラメーターに置きます。URLや画面のテキスト、初期化用の公開値へキーを直書きしてはいけません。

「注文番号Aなら配送中、存在しない番号なら該当なし」という二つの例で初期化と表示を確認します。次に、別の利用者が注文番号Aを入力しても、その注文を閲覧する権限がないなら結果を表示しない設計にします。外部APIが429や5xxを返す場合は、画面に「確認できませんでした」と出し、配送済みと推測して保存しないようにします。追跡番号や住所などの個人情報を、画面に不要なら取得・保存しないことも重要です。

更新系APIへ進むなら、同じボタンの連打で二度処理されないかを別に検証します。API Connectorの初期化も実リクエストを送るため、実データの作成・削除を伴う呼び出しは試験環境・試験用データで行ってください。

SURUDAKE

API接続を、日々の業務改善につなげる

接続の先にある転記・照合・確認も整理したい方へ。SURUDAKEでは、今使っているツールやAPIの仕様に応じて、業務の自動化を支援します。

SURUDAKEの支援内容・導入の流れを見る

参考資料

内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。