新しい案件が登録されたらチャットに知らせる、受注が確定したら別のシステムに伝える、といった連絡を、人が転記・連絡しなくても自動で行えます。アプリでの記録の追加や更新をきっかけに、ほかのシステムへ自動で通知を送ります (これを Webhook と呼びます)。
Webhookは、アプリ内でレコード操作が発生したときに外部のHTTPエンドポイントへ自動通知する機能です。 Slack、Microsoft Teams、独自システムなどと連携できます。
| イベント | 発生タイミング |
|---|---|
| record.create | 新規レコードが登録されたとき |
| record.update | レコードが編集されたとき |
| record.delete | レコードがゴミ箱へ移動されたとき（通知ルールの「レコード削除時」トリガーと同じタイミング。完全削除では発火しません） |
| record.status | ワークフローのステータスが変更されたとき |
| record.comment | レコードにコメントが投稿されたとき |
複数のイベントを同じWebhookで購読できます。
CSVインポートで作成・更新した行は Webhook を発火しません。取り込みは数万件規模になり得るため、都度の外部送信には対応していません （詳細はレコードの CSV インポートを参照）。
| 項目 | 説明 |
|---|---|
| 名前 | Webhookの識別用名称 |
| URL | 通知先のエンドポイント（HTTPS推奨） |
| イベント | 購読するイベント種別（複数選択可） |
| シークレット | HMAC署名用のシークレット文字列（任意、空なら署名なし） |
Webhookはレコードの値をアプリの外へ送るため、送信先を決められるのは、そのアプリのレコードと項目を全部見られる人だけです （行や項目のアクセス権で見えないものが1つでもあると決められません。アプリの管理者・システム管理者でも同じです）。 対象になるのは、作成・URLの変更・イベントの変更・無効から有効へ戻す操作で、保存した人が「送信先を決めた人」として記録されます。 名前・シークレットの変更、無効にする・削除するは、誰でも（Webhookを設定できる人なら）行えます。
イベントが発生すると、配信は即座に送信されるのではなく一旦待ち行列に積まれ、 順に送信されます（同時送信数は内部で制限されており、大量のレコード操作が 重なっても送信先への負荷が急増しません）。通常は数秒以内に配信されますが、 待ち行列が混み合っている場合は多少の遅延が生じることがあります。
送信先のURLを変えると、変える前に待ち行列に積まれた配信（再送を含む）も、送る直前に新しいURLへ送られます（配信ログのURLも新しい値になります。既に送信中のものだけは前のURLで終わることがあります）。 Webhookを無効にした場合は、送信中のものを除いて送られません（配信ログでは「スキップ」になります）。
送信に失敗した場合、指数バックオフ方式で自動的に再送されます。初回送信 + 再送最大5回（合計最大6回。再送間隔は指数的に延び、全試行の完了まで最短でも約30分、送信先の状態により最大1時間程度）まで試行します。
本文は送る直前に作ります。自動・手動の再送では、出来事が起きた時点の値ではなく、送る時点の最新のレコードの値が送られます（そのため再送では本文と署名が初回と変わることがあります）。 送る時点でレコードがゴミ箱に入っている・削除されている場合、作成・更新・ステータス・コメントの配信は送信されず「スキップ」になります （削除の配信はレコードを読まないので送られます）。コメントが削除されている場合のコメントの配信も同じです。
Webhookは「少なくとも1回」の配信を保証する設計のため、まれに同じ通知が 2回以上受信側に届くことがあります（再送は同一の配信IDで行われます）。受信側では 次項の X-Webhook-Delivery ヘッダーを使って重複を排除することを 強く推奨します。
| ヘッダー | 説明 |
|---|---|
X-Webhook-Delivery | 配信ID。1つの配信（イベント×購読）に対して発行され、再送しても同じ値のまま変わりません。重複排除のキーとして使用してください |
X-Webhook-Attempt | 試行回数（1始まり）。再送のたびに増加します |
X-Webhook-Event | イベント種別（本文のeventと同じ値） |
X-Webhook-Signature | シークレット設定時のHMAC-SHA256署名（詳細は次項） |
X-Webhook-DeliveryX-Webhook-AttemptX-Webhook-Eventeventと同じ値）X-Webhook-Signature1つのWebhookで配信の最終的な失敗（再送を使い切った、または再送対象外の 失敗が確定した場合）が連続10回発生すると、そのWebhookは 自動的に無効化され、アプリの管理者とシステム管理者に通知が送られます。送信先の状態を確認し、 Webhook設定画面から有効に戻すと再開されます（有効に戻せるのはプランにWebhookが含まれる場合です。有効化時に失敗回数のカウントは リセットされます）。
配信ログの「失敗」または「スキップ」行には「再送」ボタンが表示されます。 自動再送の窓（30分〜1時間程度）を過ぎてしまった配信や、送信先が長時間ダウンしていた 間の配信を、手動で取り戻したい場合に使用してください。手動再送も、送る時点の最新の値を送ります （送信先を決めた人が全部を見られない・レコードが無い場合は、再送しても「スキップ」になります）。
イベント発生時、POSTリクエストのボディに以下の構造のJSONが送信されます。
event — イベント種別（record.create / record.update など）appId — アプリIDtimestamp — 発生時刻（ISO 8601）payload.recordId — 対象レコードIDpayload.userId — 操作したユーザーのID（文字列）。公開フォームの送信など、 ユーザーによらない操作では null になりますpayload.actor — ユーザーによらない操作のときだけ付きます （例: 公開フォームの送信は { "kind": "non_user", "source": "public_form" }）。 ユーザーの操作では含まれませんpayload.data — record.create / record.update では、送る時点のレコードの値のうち、 送る時点でアプリにある項目だけ（削除した項目・テーブルの中の削除した列の値は入りません）。record.status では変更前後のステータス名（fromStatus / toStatus）。record.comment では送る時点のコメントの commentId・body・replyToId・attachmentIds。record.delete には含まれません（レコードが既に削除済みのため）アプリ名やユーザーの氏名・メールアドレス等は Webhook ペイロードには含まれません。 必要な場合は appId / userId を元に REST API で追加取得してください。
シークレットを設定すると、リクエストヘッダー X-Webhook-Signature にHMAC-SHA256署名が付与されます。 受信側で署名を検証することで、正規のRaxelからのリクエストかを判定できます。
各Webhookの配信履歴を確認できます。
localhost / ループバック / プライベートIPアドレス （RFC1918）/ クラウドメタデータエンドポイント （169.254.169.254 等）への送信は拒否されますWebhook設定画面の「テスト」ボタンで、サンプルペイロードを手動送信できます。 URLやシークレット設定の動作確認に使用してください。テスト送信も通常の配信と同じ送信先の検査を通ります （ホスト名が内部アドレスに解決される場合は送信しません）。テスト送信は1つのWebhookにつき1分に10回までです （画面とAIエージェント（MCP）からの送信を合わせて数えます。送信できなかった試みも数えます）。
WebhookはAI エージェント連携（MCP）からも設定できます （settings:webhooks を許可したトークンが必要です）。AI が作る・送信先を変える・有効に戻すときは、保存した後の送信先 （URL・イベント・有効かどうか）を AI に書き写して申告させる関門を通ります。シークレットは AI からは設定・確認できません（画面だけ）。 送信先を決められる人の決まり（アプリのレコードと項目を全部見られる人だけ）は AI からの保存にも同じく効き、トークンの持ち主で判定します。