予約リクエスト
公開済み地図の訪問者は、地図上のスポットについて事業者にリクエストを送れます。施設の予約、物件の内見、店舗の来店予約、停留所での送迎などです。リクエストは booking.kaleidr.com の Kaleidr Booking にある組織の受信箱に届き、設定すればメールでも届きます。Webhook で自社のシステムにも届けられます。返信は受信箱から行います。
リクエストはあくまで依頼であり、予約の確定ではありません。予約、仮押さえ、支払いは何も発生しません。確定は事業者がメールやいつもの方法で行います。
リクエストを有効にする
- Kaleidr Booking で 設定、一般 を開き、リクエストを受け付ける をオンにします。オフの間は、どの訪問者も組織にリクエストを送れず、リクエストボタンも表示されません。
- Kaleidr Studio でコレクションにリクエストアクションを追加します。コレクションを開き、カードとフィルター、スポットのアクション で リクエスト を追加します。そのラベルが訪問者に表示されるボタンになります。各キットには独自の既定ラベルがあります。
| コレクションの種類 | 既定のラベル | 訪問者が依頼する内容 |
|---|---|---|
| 店舗 | Request an Appointment | 来店予約、受け取り、質問への回答 |
| 物件 | Schedule a Tour | 対面またはビデオでの内見、詳しい情報 |
| 施設 | Reserve | 予約、質問への回答 |
| 停留所 | Request Pickup | 送迎、事前注文、お知らせ |
- コレクションを表示する地図を公開します。その地図のスポットのカード、スポットのレイアウト、Ask Kaleidr の回答に出てくるスポットにボタンが表示されます。
- リクエストアクションはコレクシ ョンごとに 1 つです。 追加すると、コレクションのすべてのスポットでリクエストが有効になります。新しい施設コレクションは Reserve、新しい停留所コレクションは Request Pickup から始まります。
- 車両とカスタムのコレクション はリクエストを受け付けません。
- チャットのスポット。 Studio の地図の リクエスト 設定にある すべての場所でリクエストを受け付ける をオンにすると、ホテル近くのレストランなど、Kaleidr AI が回答で挙げたスポットについても訪問者がリクエストを送れます。既定ではオフです。このリクエストはスポットを名前と住所で示します。地図上の位置が含まれるのは、Kaleidr 独自の住所データでその住所が見つかった場合だけです。
- Kaleidr AI はフォームに記入できますが、送信はしません。「7 時に 4 人で席を予約して」と頼まれると、Ask Kaleidr パネルは訪問者の発言をもとにフォームを用意し、確認して送信 を表示します。訪問者が内容を確認し、自分の情報を加えて送信します。Kaleidr AI が訪問者の名前、メールアドレス、電話番号を見ることはありません。
フォーム
訪問者には地図の上にフォームが表示されます。コレクションのキットのフィールド、名前、メールアドレス、任意の電話番号、メッセージ、同意の一文です。リクエストを送信 は、必須 フィールドが入力され、同意のチェックボックスにチェックが入るまで無効のままです。送信後、訪問者には リクエストを送信しました と、K-7XQ2MD のような参照番号が表示されます。フォームそのものについてはリクエストフォームを参照してください。
Kaleidr Booking の 設定、リクエストフォーム にはキットごとのタブがあります。フィールドごとに表示するか、必須にするか、ラベルを選べ、独自の質問を 5 つまで追加できます。横のプレビューで、訪問者に表示されるとおりのフォームを確認できます。
| キット | 標準フィールド |
|---|---|
| 店舗 | リクエストの用件、日付、時間帯、品目 |
| 物件 | リクエストの用件、対面またはビデオでの内見、最大 3 つの候補日、時間帯、資金計画 |
| 施設 | リクエストの用件、日付、時刻、人数（1〜50）、泊数（1〜60） |
| 停留所 | リクエストの用件、乗車地、目的地、日付、時刻、人数（1〜20）、品目 |
乗車地と目的地 は訪問者が入力するテキストです。ライブのレイアウトでは、リクエストアクションで訪問者に選ばせる設定にした停留所コレクションの場合、住所検索または地図のタップで見つけた 2 つの地点が加わります。これは訪問者が事業者に対応してほしいと選んだ地点です。
ボット対策。 Kaleidr にサインインしていない訪問者は、リクエストを送信する前に短い本人確認を通ります。
受信箱
Kaleidr Booking の リクエスト は、新規、承諾済み、完了、お断り の列があるボードです。カードをドラッグするか、カードの 移動先 メニューで状態を変えます。スパムを表示 でスパムにしたリクエストが表示されます。地図、スポット、キット、日付で絞り込み、参照番号、名前、メールアドレス、スポットで検索できます。
リクエストを開くと、訪問者の情報と回答、同意の内容、地図上のスポット、リクエストの履歴が表示されます。ここからできる操作は次のとおりです。
| 操作 | 内容 |
|---|---|
| 承諾、お断り、完了にする、スパムにする、再開 | 状態を変えます。新規のリクエストは承諾、お断り、スパムにでき、承諾済みは完了またはお断りにでき、お断りやスパムは再開できます。完了は最終状態です。 |
| 返信 | 返信をメールで訪問者に送ります。訪問者からの返事はご自身のメールアドレスに届きます。 |
| メモを追加 | チーム内だけのメモです。送信されることはありません。 |
| 担当者 | リクエストを組織のメンバーに割り当てます。 |
| リクエストした人のデータを消去 | 組織内のそのメールアドレスからのリクエストをすべて削除し ます。保存期間と消去を参照してください。 |
誰が何をできるか は組織のロールに従います。オーナー、管理者、メンバー、閲覧者はリクエストを読めます。オーナー、管理者、メンバーは変更、返信、割り当てができます。オーナーと管理者は設定、フォーム、Webhook、通知を管理し、リクエストの削除と消去、CSV でのエクスポートができます。
メール。 設定、通知 の 新しいリクエストをメールで通知 をオンにすると、リクエストが届いたときに チーム で通知をオンにしたメンバーにメールが送られます。メールにはスポットとリクエストの種類、リクエストへのリンクが含まれ、訪問者の情報は含まれません。受付確認を送信 は、参照番号付きの控えを訪問者にメールで送ります。
テストリクエスト。 Studio から自分で送ったリクエストには テスト の印が付き、プランの上限には数えられません。
同意
フォームの同意の一文は次のとおりです。「事業者名 がリクエストへの回答のためにこれらの情報を使用することに同意します。Kaleidr は 事業者名 に代わってこれらを処理します。」事業者名 には、設定、一般 の 事業者名、なければ組織の名前が入ります。プライバシーポリシーのリンク に自社ポリシー の https:// アドレスを設定すると、この一文からリンクされます。チェックボックスは最初はオフで、チェックがないリクエストは拒否されます。各リクエストには、訪問者が同意した一文のバージョンと同意した日時が保存されます。
保存期間と消去
- リクエストの保存期間 を過ぎて動きのないリクエストは削除されます。変更しなければ 365 日で、30〜730 日に設定できます。スパムにしたリクエストは 30 日後に削除されます。
- リクエストした人のデータを消去 は、組織内の 1 つのメールアドレスからのリクエストすべてを、それらについて送ったメールと一緒に削除します。本人からデータの削除を求められたときに使います。
- リクエストを削除 すると、そのリクエストについて送ったメールも一緒に削除されます。
- 本人が Kaleidr アカウントを削除すると、 その人のリクエストはすべての組織で削除されます。
- 組織が削除されると、 その組織のリクエストも削除されます。
Webhook
Webhook は、リクエストのイベントが起きるたびに指定のアドレスへ送るので、予約システム、CRM、スプレッドシートの自動化などで処理できます。Kaleidr Booking の 設定、Webhook で追加します。Webhook は Pro と Enterprise で利用できます。
- アドレスはポート 443 の
httpsである必要があり、 名前が解決されるすべてのアドレスが公開アドレスでなければなりません。ほかのポートやプライベートアドレスは、保存時と毎回の配信時に拒否されます。 - シークレットは Webhook を追加したときに 1 回だけ表示されます。 シークレットを更新 で新しいシークレットを発行でき、切り替えのために古いシークレットも 24 時間は署名に使われ続けます。
- テストを送信 で
webhook.testイベントを送ります。
| イベント | 送信されるとき |
|---|---|
request.created | 訪問者がリクエストを送信したとき。 |
request.status_changed | リクエストの状態が変わったとき。data.from_status に変更前の状態が入ります。 |
request.replied | 誰かが訪問者に返信したとき。data.reply に { body, created_at } が入ります。 |
webhook.test | テストを送信 を選んだとき。 |
配信はそれぞれ、JSON 本文と次のヘッダーを持つ POST です。
| ヘッダー | 値 |
|---|---|
Kaleidr-Signature | t=<unix seconds>,v1=<hex HMAC-SHA256(secret, "<t>.<raw body>")> |
Kaleidr-Event-Id | イベントの ID。再試行でも同じです。重複を無 視するために使います。 |
Kaleidr-Event-Type | 上の表のイベント。 |
Kaleidr-Delivery-Attempt | 1〜7。 |
{
"id": "8a1c2b9e-0000-4000-8000-000000000001",
"type": "request.created",
"api_version": "2026-10-22",
"created_at": "2026-10-22T15:04:05Z",
"org_id": "…",
"data": {
"request": {
"id": "…",
"ref": "K-7XQ2MD",
"kit": "venues",
"status": "new",
"place": { "name": "Sample Venue", "line": "…", "lat": 40.7411, "lng": -73.9897 },
"requester": { "name": "…", "email": "…", "phone": null, "locale": "en", "signed_in": false },
"fields": { "kind": "reservation", "date": "2026-10-30", "time": "19:00", "party_size": 4 },
"message": "…"
}
}
}
チャットのスポットについてのリクエストで、その住所が Kaleidr 独自の住所データで見つからなかった場合、place.lat と place.lng は null になります。
署名を検証する
解析する前に生の本文を検証し、5 分より古いタイムスタンプは拒否してください。シークレットの更新中は、ヘッダーに古いシークレットで署名した 2 つ目の v1= が入ります。どちらでも受け入れてください。
import hashlib, hmac, time
def verify(header: str, secret: str, body: bytes, tolerance: int = 300) -> bool:
parts = [p.split("=", 1) for p in header.split(",")]
t = next((v for k, v in parts if k == "t"), "")
if not t.isdigit() or abs(time.time() - int(t)) > tolerance:
return False
expected = hmac.new(secret.encode(), f"{t}.".encode() + body, hashlib.sha256).hexdigest()
return any(k == "v1" and hmac.compare_digest(v, expected) for k, v in parts)
次のベクターでコードをテストしてください。
| 入力 | 値 |
|---|---|
| シークレット | whsec_MfKQ9r8GKYqrTwjUPD8ILPZIo2LaLaSw |
t | 1761091200 |
| 本文 | {"id":"8a1c2b9e-0000-4000-8000-000000000001","type":"webhook.test"} |
v1 | 3e55a2f93ac990282b95fd9140f8290ffaddc5d41969831e4234b164d613bd72 |
配信と再試行
- 10 秒以内に 2xx のいずれかのステータスで応答してください。 リダイレクトはたどりません。
- 少なくとも 1 回。 失敗した配信は 1 分、5 分、30 分、2 時間、6 時間、24 時間後に再試行され、約 32 時間で 7 回試みます。同じイベントが 2 回届くことがあるため、受信済みの
Kaleidr-Event-Idは無視してください。 - 本文は送信時点のリクエストなので、 再試行には最新の状態が入ります。その間に消去されたリクエストは送られません。
- すべての試行が失敗した配信が 10 回続くと、Webhook はオフになります。 オンに戻すとカウントがリセットされます。
- 各 Webhook の 配信履歴 には、過去 30 日間の試行がステータス、応答コード、所要時間とともに、本文なしで表示されます。再送 で失敗した配信を送り直せます。
上限
| 上限 | Free | Pro | Enterprise |
|---|---|---|---|
| 月あたりのリクエスト数 | 50 | 1,000 | 契約で設定 |
| Webhook | なし | 5 | 契約で設定 |
1 か月は組織の請求期間です。テストリクエストは数えられません。上限に達すると次の期間まで新しいリクエストは拒否され、フォームにはスポットの電話番号やリンクがあればそれが代わりに表示されます。