これまで、投稿が出たかどうかを知るには、こちらから尋ねる必要がありました。API を呼び、ステータスを確認し、しばらくしてまた呼ぶ。これでも動きますが、要はポーリングです。頻繁に呼べばリクエストを無駄にし、間隔を空ければ気づくのが遅れます。Webhook はこれを逆にします。sona.to に URL を渡しておけば、何かが起きた瞬間に sona.to の側から連絡が来ます。すべてのプランで利用できます。
購読できるイベントは 4 つで、反応する価値のある結果を網羅しています。投稿の公開、投稿の失敗、サイト監査の完了、サイト監査の失敗です。どれを受け取るかは Webhook ごとに選べるので、Slack への通知は失敗だけを聞き、レポート用の処理はすべてを受け取る、といった使い分けができます。ペイロードのフィールド名は REST API が返すものと同じなので、GET リクエストで既に解析している処理はそのまま動きます。
設定は 1 分で済みます。ダッシュボードの API ページを開き、利用中のツールが発行した URL を貼り付け、必要なイベントにチェックを入れて保存します。署名用のシークレットはそのとき一度だけ表示されます。二度と表示されないので、その場でコピーしてください。
そのシークレットが、リクエストが本物だと判断する手段になります。すべての配信には署名ヘッダーが付き、タイムスタンプと、そのタイムスタンプおよびリクエスト本文からあなたのシークレットで計算した HMAC SHA-256 が含まれます。自分の側で同じ計算をし、定数時間で比較する関数で照合してください。タイムスタンプも署名対象に含まれるため、傍受されたリクエストを後から再送されることはありません。数分より古いものを拒否すれば十分です。
配信は最初の失敗であきらめません。エンドポイントが停止していたりエラーを返したりした場合、リクエストは 60 秒後、次に 5 分後、次に 30 分後に再試行されます。各試行はステータスコードと所要時間とともに記録されるため、調子の悪いエンドポイントは推測ではなく調査できる対象になります。失敗が続くエンドポイントは自動的に停止され、直したあとに再開できます。
向け先として真っ先に挙がるのは自動化プラットフォームです。Zapier、Make、n8n はいずれも貼り付け用の Webhook URL を発行し、イベントは次の処理につなげられる JSON で届きます。チャンネルへのメッセージ、表計算への 1 行、タスク管理へのチケットなどです。自社サーバーでもまったく同じで、あいだにプラットフォームは要りません。
sona.to が受け付ける宛先についての注意です。宛先は https で、公開アドレスである必要があります。プライベートネットワークに解決される URL は、保存時にも配信時にも拒否され、リダイレクトは追いません。受信側をローカルネットワークで自前運用している場合は、公開ホスト名かトンネルの後ろに置いてください。
Webhook は、REST API と MCP サーバーに続く、ダッシュボードの外から sona.to を動かす 3 つ目の方法です。API は尋ねるため、MCP は AI アシスタントから尋ねられるため、Webhook は知らせを受けるためのものです。署名検証の例を含む詳細は API ドキュメントにあります。