BubbleのAPI Connectorは、アプリから外部サービスへリクエストを送り、その結果を表示やワークフローに使うための機能です。接続できた後も、認証情報と失敗時の扱いを設計しておく必要があります。
01API Connectorの役割
連携先のデータを取得したり、外部サービスへ処理を依頼したりできます。相手サービスによって認証方式、入力項目、返答形式は異なるため、設定を始める前に公式API文書を確認します。まずは読み取りだけの小さな呼び出しで接続を確かめると、問題を切り分けやすくなります。
02鍵と初期化に注意する
APIキーは画面のテキストやURLに埋め込まず、秘密として扱います。Bubbleの公式文書も、認証情報を利用者側に露出させない設定を強調しています。また、呼び出しの初期化は実際のAPIリクエストを送ります。作成・削除を伴うAPIなら、テスト用データと環境を用意してから操作しましょう。
03失敗時の動きまで設計する
外部サービスは一時的に応答しない場合があります。タイムアウト、認証切れ、利用上限、重複実行を想定し、利用者に何を伝えるか、再試行してよいかを決めます。重要な更新では、Bubble側だけで成功表示を出さず、相手側で処理されたことを確認できる流れを考えます。
04連携前に決める三つの境界
まず、どのデータを外部へ渡す必要があるかを絞ります。次に、APIキーをどこで管理し、誰が更新するかを決めます。最後に、連携先が停止したときに画面や業務をどう扱うかを整理します。画面で入力できる項目をそのまま全て送る設計は避け、送信する項目と目的を明示しましょう。
テストでは正常応答だけでなく、認証エラー、想定外のレスポンス、連続クリック、同じ処理の再送も確認します。外部システムとの境界を明確にすると、公開後の障害調査や仕様変更にも対応しやすくなります。
05具体例：配送状況の「照会」だけを連携する
ECの管理画面で注文番号を入力し、配送サービスから状態を読む例を考えます。連携先の公式API文書でURL、HTTPメソッド、認証方式、応答例を確認し、API Connectorでまず読み取り専用の呼び出しを設定します。注文番号は利用者が変更できる入力ですが、APIキーは認証用の秘密値としてPrivateなパラメーターに置きます。URLや画面のテキスト、初期化用の公開値へキーを直書きしてはいけません。
「注文番号Aなら配送中、存在しない番号なら該当なし」という二つの例で初期化と表示を確認します。次に、別の利用者が注文番号Aを入力しても、その注文を閲覧する権限がないなら結果を表示しない設計にします。外部APIが429や5xxを返す場合は、画面に「確認できませんでした」と出し、配送済みと推測して保存しないようにします。追跡番号や住所などの個人情報を、画面に不要なら取得・保存しないことも重要です。
更新系APIへ進むなら、同じボタンの連打で二度処理されないかを別に検証します。API Connectorの初期化も実リクエストを送るため、実データの作成・削除を伴う呼び出しは試験環境・試験用データで行ってください。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。