approve_pending
STEP 5b, SELLER-SIDE, only when confirm_booking answered PENDING_APPROVAL. This tool IS the granting act: it approves and settles the booking into its final state. payload = { approval_id } (from the confirm_booking response). Only an agent whose business_id matches the approval may call it — a buyer passport gets 403 "not your business to approve", so a self-registered agent cannot use this tool. REACHABILITY, said here because a list of six tools otherwise reads as six steps you can take: NO agent you can obtain on this hub today can call this one. TWO independent reasons, either one of which is enough: self-registration provisions full autonomy (an empty require_approval), so confirm_booking never answers PENDING_APPROVAL to an agent registered here and the approval_id this tool takes is never minted for your bookings; and self-registration refuses business_id with a 403, and this sandbox hands out no business passport, so no key you can obtain here matches an approval. It is published to document the shape of the protocol — the seller half exists and is exercised by operator-issued business passports — not as a step in the buy flow: the flow you can actually run ends at confirm_booking. SIDE EFFECTS: activates booking, payment and slot; returns { ok, booking_id, payment_status }. 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. Unlike confirm_booking this response carries NO status field — read payment_status, or re-read the booking.
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. |