署名付きの送信・自動再送・順番の保証
イベントの発生時に API を呼び出すことで、登録済みの送信先へ Standard Webhooks 形式の署名付きで送信します。送信先がエラーを返した場合や応答がない場合は、間隔を空けて再送します。再送の回数と間隔、受け付けた順に 1 通ずつ送る順番の保証は、送信先ごとに設定できます。
- 順番の保証は送信先ごとに設定可能
- 再送期間は約 28 時間
- Node.js・Go・PHP の SDK で送信と署名検証が可能
Standard Webhooks・MCP に対応 Webhook 統合インテグレーション
Webhook の送信・署名・再送・配信記録の管理を一括して提供するサービスです。複数のサービスの送信先、配信記録、送信の失敗を、管理画面でまとめて確認できます。
署名と自動再送
Standard Webhooks 形式の署名付きで送信し、失敗した場合は自動で再送します。再送の回数と間隔、順番の保証は送信先ごとに選べます。
全プロジェクトの一覧
全プロジェクトの送信数、成功率、対応が必要な送信先を組織単位で確認できます。
登録後すぐに API キーを発行
メールアドレスまたは GitHub・Google アカウントで登録でき、登録後すぐに API キーを発行できます。
動作イメージ
3 つのプロジェクトのイベントを配信する様子です。送信先がエラーを返した配信は自動で再送し、担当者に Slack で通知します。
AI エージェントから組み込む（MCP）:https://api.webhookadmin.com/mcp
主な機能
障害の通知と全プロジェクトの一覧
失敗が続く送信先について、Slack・Microsoft Teams・Chatwork・メール・Webhook で担当者に通知します。組織の画面では、全プロジェクトの送信数、成功率、対応が必要な送信先を確認できます。
- 通知は送信先ごとに 1 時間に 1 回まで
- 通知先はプロジェクト単位・組織単位で設定可能
- 5 日間失敗が続いた送信先は自動で停止
顧客向けの設定画面と Webhook 以外の送り先
送信先の登録や配信記録の確認を顧客自身が行える画面を、自社サービスに埋め込むことができます。送り先は Webhook のほか、Amazon SQS・Amazon EventBridge・Google Cloud Pub/Sub・Amazon S3 などにも対応し、受信側からのポーリングも選べます。送信先ごとに JavaScript で本文を書き換え、受信側の形式に合わせることも可能です。
- 顧客向けの設定画面・固定の送信元 IP アドレス・ポーリング
- Webhook 以外の送り先・本文の書き換え（使えるプランは製品サイトに掲載）
- 設定画面は iframe で自社サービスに埋め込み可能
導入の流れ
登録から本番までの進め方です。
-
アカウント登録
メールアドレスまたは GitHub・Google アカウントで登録し、組織とプロジェクトを作成します。
-
テスト環境での確認
テスト環境の API キーを使い、送信から受信側での署名検証までを確認します。
-
システムへの組み込み
イベントの発生箇所から API を呼び出します。Node.js・Go・PHP の SDK と、MCP に対応した AI エージェントもご利用いただけます。
-
本番運用
本番環境に切り替え、障害の通知先を設定して運用を開始します。
よくあるご質問
署名は Standard Webhooks 形式です。受信側では Node.js・Go・PHP の SDK、または Standard Webhooks の公式ライブラリで署名検証が可能です。ファイアウォールの内側などで受信する場合は、受信側から配信を取得するポーリングもご利用いただけます（使えるプランは製品サイトに掲載）。
既定では、初回を含め最大 8 回、約 28 時間にわたり再送します。回数と間隔は送信先ごとに選べます。失敗が続いた場合は担当者に通知し、5 日間失敗が続いた送信先は自動で停止します。順番を保証する送信先では、先の 1 通が届くか再送を終えるまで、後続の送信は順番待ちとなります。管理画面から手動で再送することも可能です。
Amazon SQS・Amazon EventBridge・Google Cloud Pub/Sub・Azure Service Bus・Kafka（REST API 経由）・RabbitMQ、Amazon S3・Google Cloud Storage・Azure Blob Storage などのストレージ、Slack・Microsoft Teams・Chatwork・Google Chat のチャットに送信できます（使えるプランは製品サイトに掲載）。再送、順番の保証、障害の通知は Webhook と同様にご利用いただけます。キューとストレージへの送信には署名を付け、チャットには署名を付けずに読みやすい形のメッセージを投稿します。
はい。現在お使いの署名の鍵を登録でき、本文の形式も送信先ごとに選べるため、Standard Webhooks の署名を検証している受信側は、実装を変更せずに移行いただけます。本文の書き換え・Webhook 以外の送り先・ポーリングは、互換のパスの API にも対応しています。
関連する記事
Standard Webhooks とは｜Webhook の署名と検証の共通仕様
Standard Webhooks は、Webhook の署名とヘッダーの形式をそろえるための公開仕様です。webhook-id・webhook-timestamp・webhook-signature の 3 つのヘッダー、HMAC-SHA256 による署名の計算、鍵の切り替え、Node.js での署名検証のコードを整理します。
バイブコーディングで作ったアプリを本番運用できる品質にする方法
AIに指示してアプリを作る「バイブコーディング」で動くものはできた。でも本番で使って大丈夫？内製AI開発の典型的な弱点と、本番品質に引き上げるためのチェックポイントを解説します。
Webhook の送信を外部サービスに任せるメリット｜自前で作る場合との比較
Webhook の送信は、再送・署名・配信記録・固定の送信元 IP・顧客向けの設定画面まで含めると、一つの基盤になります。自前で作る場合の作業範囲と、送信を専用の外部サービスに任せる企業の事例、任せる前に確認する点を整理します。