クロノックWebhookで予約後の作業を自動化する方法
クロノックWebhookを使うと、予約作成・キャンセル・日時変更をきっかけにCRM更新、チーム通知、自社システム連携などの予約後ワークフローを自動化できます。
日程調整は、予約が入ったところで終わりではありません。
予約が作成されたあとに、CRMへ活動履歴を残す、Slackへ通知する、フォローアップタスクを作る、オンボーディングを開始する、自社の管理画面へ予定情報を同期する。こうした作業が続くことはよくあります。
もしその作業が、誰かがクロノックを確認して手で転記する運用になっていると、抜け漏れが起きやすくなります。
クロノックのOutbound Webhookを使うと、予約の作成・キャンセル・日時変更をきっかけに、指定したHTTPSエンドポイントへ署名付きのJSONリクエストを送れます。
つまり、日程調整を単独の作業で終わらせず、その後の業務フローを始めるトリガーとして使えるようになります。
クロノックWebhookでできること
Webhookは、クロノックから指定URLへ自動で送られるHTTPリクエストです。
初期バージョンでは、予約ライフサイクルに関するイベントを扱います。
| イベント | 送信タイミング | 自動化の例 |
|---|---|---|
booking.created |
新しい予約が確定したとき | CRMへ活動履歴を追加する、営業チームへ通知する、オンボーディングタスクを作る |
booking.canceled |
予約がキャンセルされたとき | タスクを閉じる、担当者へ通知する、社内レコードを更新する |
booking.rescheduled |
カレンダー連携経由で予約時間が変わったとき | 後続システムの予定を更新する、チームへ変更を知らせる、リマインダーを更新する |
Webhookエンドポイントはクロノックのワークスペース単位で管理されます。ワークスペースのownerまたはadminは、エンドポイントの作成、受け取るイベントの選択、テスト送信、配信履歴の確認ができます。
日程調整後の作業を減らせる
日程調整ツールは、実際の業務プロセスとつながっていることが多いです。
営業チームなら、デモ予約が入ったら商談の活動履歴を更新したいかもしれません。採用チームなら、面接予約が確定したらコーディネーターに知らせたいかもしれません。カスタマーサクセスなら、キックオフ面談がキャンセルされたときに次のタスクを止めたいかもしれません。
Webhookがない場合、こうした作業は次のどれかになりがちです。
- 誰かが忘れずに行う手作業
- 定期的に変更を確認するバッチ処理
- 特定サービス専用の個別連携
Webhookはもっと汎用的な入口です。クロノックは予約に関する変更が起きたタイミングでイベントを送り、受け取った側のシステムが次の処理を決めます。
受け取り先は、自社API、サーバーレス関数、Webhookトリガーを持つ自動化ツール、社内ワークフローシステムなどにできます。
自動化しやすいワークフロー
クロノックWebhookは、予約情報を別システムへすばやく渡したい場面で役立ちます。
| ワークフロー | Webhookでできること |
|---|---|
| CRM更新 | リード、取引先、商談、会社レコードへ予約情報を紐づける |
| チーム通知 | 重要な予約、キャンセル、日時変更をSlackなどへ通知する |
| 採用オペレーション | 面接予約が入ったタイミングでコーディネーターへ知らせる |
| 顧客オンボーディング | 初回面談の予約をきっかけにキックオフ準備を始める |
| 社内ダッシュボード | 予約イベントをデータパイプラインや業務DBへ送る |
| 独自リマインダー | 自社システム側でリマインダーや準備タスクを作る |
ポイントは、連携先を1つに固定しないことです。
自社システムがある場合は直接受け取れます。ノーコードで組みたい場合は、Webhookトリガーを受け取れる自動化プラットフォームを経由して、普段使っているツールにつなげられます。
送信されるデータ
クロノックWebhookのペイロードはJSONです。
予約ライフサイクルのペイロードには、イベントID、イベント種別、APIバージョン、作成日時、予約データが含まれます。
{
"id": "evt_7Z4A2rXh2B4V8nYcH9pQmN",
"type": "booking.created",
"api_version": "2026-07-06",
"created_at": "2026-07-06T03:04:05.000Z",
"data": {
"booking": {
"id": "7Z4A2rXh2B4V8nYcH9pQmN",
"status": "confirmed",
"start_time": "2026-07-07T01:00:00.000Z",
"end_time": "2026-07-07T01:30:00.000Z",
"timezone": "Asia/Tokyo",
"slot": {
"id": "2dK8eV6hKp9mQr4ZyT1xAb",
"title": "Product Demo"
},
"meeting_tool": "google_meet",
"meeting_url": "https://meet.google.com/example"
}
}
}
予約日時が変更された場合は、変更前の開始・終了時刻も含まれます。これにより、受け取り側のシステムでは「新しい予定」として扱うのではなく、既存レコードの時間を更新しやすくなります。
初期設定では、参加者名やメールアドレスなどの詳細情報は含めません。必要なエンドポイントだけ、ownerまたはadminが参加者詳細を有効にできます。
多くの自動化では、予約ID、日時、予約枠、会議URLがあれば十分です。個人情報を標準で送らない設計にしておくことで、意図しない情報共有を減らせます。
配信履歴で動作を確認できる
Webhook連携は、送られたかどうかを確認できることが重要です。
クロノックではWebhook配信を記録し、成功、失敗、リトライ待ちの状態を確認できます。新しいワークフローを作るとき、クロノックが期待したリクエストを送ったか、受け取り側がどう応答したかを追いやすくなります。
また、実際の予約を発生させる前にテスト送信できます。エンドポイントを作成し、テストイベントを送り、受け取り側で検証してから本番のワークフローへ進められます。
手動テストでは予約データではなくエンドポイント情報を含むendpoint.verificationイベントを送ります。このイベントは、エンドポイントで選択した予約イベントにかかわらず送信されます。
配信に失敗した場合、クロノックはバックオフしながらリトライします。受け取り側の一時的な障害が、そのまま予約イベントの取りこぼしになることを避けやすくなります。
クロノックは、非同期配信を始める前に、完成した予約イベントのペイロードを対応する予約ライフサイクル操作と同じトランザクションで永続化します。配信処理はexactly-onceではなくat-least-onceのため、タイムアウトなどで配信結果を確定できない場合、同じリクエストが複数回届くことがあります。受け取り側は冪等に実装し、Chronock-Webhook-Idでリトライを重複排除してください。
Webhookエンドポイントの設定方法
Webhookを管理するには、ワークスペースのownerまたはadmin権限が必要です。
基本的な流れは次のとおりです。
- クロノックでワークスペースの連携設定を開く
- HTTPSのURLを指定してWebhookエンドポイントを作成する
- 受け取りたい予約イベントを選ぶ
- 作成時に表示されるエンドポイントsecretを保存する
- 受け取り側でクロノック署名を検証する
- テストWebhookを送信し、配信履歴を確認する
エンドポイントsecretは作成時に一度だけ表示されます。受け取り側のサービスや自動化ツールに保存し、Webhook署名の検証に使ってください。
クロノックから届いたWebhookか検証する
クロノックはWebhookリクエストにHMAC-SHA256署名を付けます。
受け取り側では、ペイロードを信頼する前に署名を検証してください。クロノックは次のようなヘッダーを送ります。
| ヘッダー | 用途 |
|---|---|
Chronock-Webhook-Id |
配信ID |
Chronock-Webhook-Event-Id |
WebhookイベントID |
Chronock-Webhook-Event-Type |
booking.createdなどのイベント種別 |
Chronock-Webhook-Timestamp |
リプレイ対策に使うタイムスタンプ |
Chronock-Webhook-Signature |
HMAC署名 |
本番運用では、署名を検証し、古すぎるタイムスタンプのリクエストを拒否するのが安全です。これにより、クロノック以外からのリクエストや、後から再送された古いリクエストを受け入れるリスクを下げられます。
また、WebhookエンドポイントのURLはHTTPS必須です。クロノック側でもエンドポイントURLを検証し、SSRFリスクを下げる設計にしています。
Webhookでまだできないこと
Webhookは柔軟な連携口ですが、すべての外部連携を含むわけではありません。
初期実装には、次のものは含まれていません。
- 他サービスからクロノックへ送るInbound Webhook
- Zapier REST Hooksのsubscribe / unsubscribe API
- n8nコミュニティノード
- MakeやYoomのマーケットプレイス掲載
- 予約枠単位、部屋単位の細かなフィルター
- 参加者詳細の標準送信
まずは、予約イベントの永続化を軸に、Webhookエンドポイント管理、署名付き配信、エンドポイント配信の回数上限付きリトライ、テスト送信、配信履歴という中核を整える方針です。
個別のマーケットプレイス連携は、この基盤の上に追加できます。
まずは1つの自動化から始める
Webhookは、最初からすべてを自動化しようとしないほうが運用しやすいです。
まずは、予約情報の転記漏れや通知漏れが起きると困るワークフローを1つ選びます。
- デモ予約が入ったら営業チャンネルへ通知する
- 予約が作成されたらCRMにメモを残す
- 予約がキャンセルされたら社内タスクを閉じる
- キックオフ面談の日時変更を顧客オンボーディングレコードへ反映する
1つ目のワークフローが安定したら、次の自動化を追加していくのが現実的です。
予約を業務フローのトリガーにする
クロノックは、GoogleカレンダーやMicrosoft Outlookカレンダーと連携して空き時間を見つけ、予約を受け付けるためのツールです。Webhookは、その価値を予約後の業務にも広げます。
予約確定を日程調整の終点として扱うのではなく、次の作業の起点にできます。必要な人に知らせ、必要なレコードを更新し、後続システムと同期する。
日程調整の変更を業務フロー全体につなげたいなら、クロノックWebhookは実用的な入口になります。


