confirm_booking
STEP 5, the committing call — turns a hold into a booking. payload = { hold_id } (from hold_slot). Your envelope signature IS the buyer signature on the resulting booking, so this is a non-repudiable act: do not call it speculatively. SIDE EFFECTS: returns { ok, status, booking_id, payment_status } with status "BOOKED", or { ok, status, booking_id, approval_id } with status "PENDING_APPROVAL" (no payment_status on that branch) when the BUYER's own policy requires a human for booking.confirm (it is the buyer policy that decides, not the shop). Sandbox covers the MONEY here, not only the goods: no payment processor is connected, so nothing on this hub moves funds and no card or account of yours is ever touched. Of the 5 payment states it publishes, exactly 1 can ever reach you — funds simulated as escrowed — and the other 4 never ride this field, 3 of them being vocabulary in the enum rather than behaviour today, so no settlement follows this call. Those names are deliberately NOT repeated here: they name states of the payment, and this description is where you read your own booking status, which is exactly where a foreign state literal gets misread. https://hub.videtion.com/spec §5 tables all 5 and says, for each, whether shipped code can produce it. What IS real is the record: the payment row and its booking are written to this hub’s database and outlive the call. Agents that register here are provisioned at full autonomy, so every confirm that SUCCEEDS ends at BOOKED: the PENDING_APPROVAL branch above is not merely unlikely for you, it is UNREACHABLE from self-registration, and approve_pending has no caller you can become (its own description carries the full reason). That is a claim about the approval branch only — a confirm can still fail, see ERRORS below. Requires the booking.confirm capability. ERRORS: over your daily booking cap this answers 429 "reservations_per_day exceeded" — YOUR counter, cleared at midnight UTC, so wait rather than retry, and do not take a fresh hold in the meantime (a hold is not capped, so you would just park a real slot for 15 minutes and still not confirm it). Every other refusal from the policy gate is a 403 that no retry and no re-read of the offer list can clear. Sandbox: bookings are against demo inventory and bind nobody in the real world.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | Single-use random string, 1..256 chars (32 hex recommended). A nonce this agent has used before is rejected as a replay (401). | |
| payload | Yes | Covered by the signature. | |
| agent_id | Yes | The agent_id returned by register_agent. Call that tool first; it is the only one needing no credentials. | |
| signature | Yes | Hex-encoded ed25519 signature over the RFC 8785 (JCS) canonical JSON of exactly {payload, agent_id, nonce, timestamp} — the whole envelope minus this field. Sign with the private key matching the public_key you registered. Worked example, and where it actually is: https://hub.videtion.com/quickstart.mjs — 6941 bytes, zero dependencies, Node 20+, which mints an ed25519 key, canonicalises exactly these four fields and signs them, so you can diff your bytes against a call this hub accepts. https://hub.videtion.com/spec states the same rule in prose and field tables and publishes no signature to copy: it is the reference, not the example. | |
| timestamp | Yes | Epoch MILLISECONDS (Date.now()), not seconds. Must be within +/-60 s of server time, else 401 stale timestamp. |