MakeのWebhookを自社サイトにつなぐ方法｜保存・通知・再送の設計

サイト側で受付を確定してから送る

フォームはまず自社サイトのサーバーで検証し、受付IDと送信待ち状態を保存します。その後、サーバーからMakeへイベントを送ります。Makeの応答が遅れたときにも受付そのものを失わないためです。ブラウザーには自社サイトの受付結果を返し、Makeの内部URLやAPIキーを渡しません。

event_idと項目の契約を決める

架空のJSON例はevent_id「TEST-WH001」、event_type「inquiry.created」、occurred_at「2026-10-29T09:00:00Z」、schema_version「1」、category「setup」です。本文は必要最小限にします。同じ出来事の再送は同じevent_idを使い、送信のたびに新しいIDを作らないでください。入力値の型、長さ、必須項目、許可する種類を両側で決めます。

Custom webhookと認証を設定する

MakeでWebhooksのCustom webhookを作成し、API Key authenticationを設定します。サーバーからのHTTPSリクエストにx-make-apikeyヘッダーでキーを付けます。URLとキーはサーバーの秘密設定へ保存し、公開リポジトリ、画面、ログ、ブラウザー用の環境変数へ出しません。キーを交換できる担当者と手順も決めてください。

明示的なデータ構造で受信を検証する

Advanced settingsのData structureで型と必須項目を定義します。サンプルを送ってマッピング項目を検出するだけでは、受信検証が有効になるとは限りません。定義済み構造に加え、event_typeやschema_versionの許可値をFilterで確認します。ブラウザー由来のcategoryを、そのまま保存先や通知先の識別子へ割り当てないでください。

event_idをキーに保存してから通知する

保存先にはevent_idを一意キーにできる台帳を選び、received、notified、failedなどの段階を持たせます。高頻度や複数経路から届く構成では、データベースの一意制約などで同時到着を扱います。表を検索して未登録なら追加するだけでは競合を防げません。通知先は固定し、成功したメッセージIDをevent_idへ対応させます。

200 Acceptedを処理完了と混同しない

Webhookの既定応答はキューへの受付を表す場合があり、保存や通知の完了証明にはなりません。Webhook responseを後段へ置く場合も、タイムアウトや応答後の失敗を考慮します。サイト側の送信記録とMake側の業務完了記録を分け、必要なら認証された状態照会や完了通知で突き合わせる設計にしてください。

再送と順序の規則を実装する

サイト側は送信待ちを保存し、一時的な失敗や429などは上限付きの待機を挟んで再送します。400でも本文がQueue is fullならキューの混雑であり、入力検証エラーとは区別します。入力不備は修正せず繰り返しません。即時Webhookは既定で並行処理されるため、順序が必要ならProcess data in orderを検討します。ただし、この設定だけで他経路を含む重複防止や一回限りの完了は保証されません。

本番前は四種類の受付結果を照合する

有効な一件、認証なし、必須項目不足、同じevent_idの再送を試します。応答だけでなく、保存件数、通知数、各段階の記録を確認してください。通知成功後の状態更新失敗も用意し、再送で二重通知されないかを調べます。テスト用URLやキーを本文・配布物へ含めず、確認後に本番の監視・保管期間・復旧担当を決めます。

• 一意キーと部分成功の扱い
• 履歴から安全に復旧する
• コードを使わないフォーム通知の例