Webhook とイベント

左上のスペースメニューを開き、Webhooks を選ぶと自動化ルールを設定できます。シンプルなケースならコードは不要で、必要なときだけ小さなサンドボックス関数を書けます。

Webhooks ダイアログ。3 つの異なるアクションを持つルールが並び、そのうち 1 つは実行に成功している。

ルールを起動するもの

ルールを作成するときにイベントを選びます。ルールを特定の Base に絞ることも、スペース全体に対して有効にすることもできます。

ルールにできること

ルールは次の 3 つのいずれかを行います。

Webhook と Notify agent は URL さえあれば動きます（任意で、Busabase がリクエストの署名に使うシークレットを設定でき、受信側で本当に Busabase から送られたものかを検証できます）。

関数を書く

Run function は最も柔軟な選択肢です。短いスクリプトを書くと、イベントを input として受け取り、fetch(url, options) を直接呼び出して他のサービス — Slack、チケットシステム、自分の API、URL を持つものなら何でも — に到達できます。

関数エディタ：コード、利用できる機能を説明する補足メモ、タイムアウト設定。

関数でできること：

• input を読む — イベントのデータ（レコードのフィールドや、発生した Base など）
• console.log(...) を呼ぶ — ログに出力した内容は後で配信ログに表示され、ルールをデバッグする一番簡単な方法になる
• fetch(url, options) を最大 10 回まで呼ぶ — 他のシステムへの通知、何かの照会、複数のリクエストの連結などに使える
• 値を return する — 参考のために記録されるだけで、それ以上は何も起こらない

関数全体（内部で行う fetch 呼び出しも含めて）がどれだけ実行を許されるかは、タイムアウト（100ms〜5000ms）で設定します。

安全性を保つ

関数は隔離されたサンドボックス内で実行され、あなたのファイルや環境変数、サーバー上の他の何にもアクセスできません。触れられるのはネットワークだけで、それも fetch を通じてのみ、しかもガードがかかっています。自分自身の内部ネットワーク（localhost、プライベート IP レンジ、クラウドインフラのアドレスなど）に向けたリクエストは自動的にブロックされます。関数は外の世界と話すためのものであり、自分自身のインフラを探るためのものではありません。

うまくいったかどうかを確認する

すべてのルールは、直近の実行の簡単な履歴を保持しています — ルールを展開すると確認できます。Success（成功）のエントリにはログに出力した内容が表示され、Failed（失敗）のエントリにはエラー内容が表示されるので、何がうまくいかなかったかを正確に把握して修正できます。

あるルールの配信ログ。成功した実行とそのログ出力を示している。

Test now（今すぐテスト）ボタンを押せば、いつでもリアルなサンプルデータでルールを即座に発火できます。実際のイベントが起きるのを待つ必要はなく、ルールがまだ無効になっていてもテストできます。

関連: コアコンセプト · クイックスタート · REST API