Webhook送信
FBP側の登録、更新、完了を外部システムへ通知します。
Webhook送信は、FBPで起きた登録、更新、完了、取消、入金、承認などの業務イベントを、外部システムへ通知する機能です。Roundtableでは「どの状態になったら送るか」「どの項目を渡すか」「失敗時に再送するか」を先にそろえると、発注者、実装者、AIに指示する人が同じ前提で連携後の運用を設計できます。
この機能でできること
FBP側でレコードが登録、更新、完了、承認、キャンセルされたタイミングで、外部システムへHTTP通知を送れます。通知先ごとに送信する項目、イベント名、対象レコード、外部ID、送信日時、結果、エラー理由を記録し、外部CRM、予約管理、在庫管理、会計、分析、AI処理基盤などへ業務状態を渡せます。
FBPで確定した業務状態を、外部側へ知らせます。
保存処理や完了処理と外部通知を分けて設計し、送信ログ、失敗時の再送、通知先ごとのpayloadを残すと、外部連携の確認と復旧がしやすくなります。
よくある利用場面
申込や予約の確定を通知する
公開フォームや管理画面で確定した申込、予約、注文を、外部CRM、予約台帳、在庫管理へ送ります。
完了や入金を外部処理へ渡す
請求の入金済み、タスク完了、承認完了などをきっかけに、外部ワークフローや分析基盤を動かします。
失敗分を管理側から再送する
タイムアウト、認証エラー、外部側の一時停止などで送れなかった通知をログで確認し、条件を見て再送します。
プロンプト例
通知する業務イベント、通知先、送信項目、認証方式、送信ログ、失敗時の扱いをまとめて伝えると、実装範囲を決めやすくなります。
プロンプト
申込レコードが完了ステータスになったら外部CRMへWebhook送信してください。イベント名、申込ID、顧客名、メールアドレス、完了日時、担当者、合計金額をJSONで送信し、送信日時、HTTPステータス、結果、エラー理由をWebhook送信ログに保存してください。送信に失敗した場合は業務レコードの保存自体は完了させ、管理画面から失敗ログを確認して再送できるようにしてください。通知先URLや認証トークンは設定値から読み、テンプレートやdocsへ直接書かないでください。
この機能を使うときのポイント
送信トリガー登録時、更新時、完了時、承認時、決済後など、どの業務状態で送るかを明確にします。
payloadの範囲外部側で必要な項目だけを送り、個人情報や内部メモを不要に含めないようにします。
ログと再送送信内容、応答、結果、エラー理由を残し、同じ通知を安全に再実行できる条件を決めます。
失敗時の業務影響外部送信が失敗してもFBP側の登録を完了するか、エラーとして止めるかを業務ごとに決めます。
この機能を実装するときのコツ
Webhook送信では、業務データの保存と外部通知の成功を同じものとして扱わない設計が重要です。保存後に送信ログを作成し、送信成功、再送待ち、送信不要、失敗の状態を管理すると、外部側の一時障害があっても業務データを失わずに復旧できます。通知先URL、認証ヘッダー、署名キー、タイムアウト秒数は設定値で持ち、送信payloadはイベント種別ごとに組み立てます。再送処理では、同じイベントIDや対象レコードを使って外部側が重複処理しないよう、冪等性のためのキーを含めると安定します。