Agent runbook
Give an authorized agent one progressive runbook
This is a copyable operating prompt for an AI agent that can browse and write code. This page is guidance, not a credential or a grant of authority. The workspace owner remains responsible for account changes, secret handling, and transaction approval.
Progressive checkpoints
1. Live setup and booking
Follow the complete flow from registration to a real reservation and booking management.
2. Make your Search call
Run the cURL, JavaScript, or Python example with your server-side key.
Optional Sandbox testing
Use a separate Test key for no-payment smoke checks or a simulated booking.
Limits, commission, and Enterprise
Standard is self-serve. Higher limits and custom commercial terms are optional.
Copy this prompt
Read https://www.brek.com/agent-commerce.md and follow its links.
With my workspace-owner authorization, register or sign in, accept the current approved terms, and create a Live application and key using trusted server-side secret handoff. If safe handoff is unavailable, stop for me to store the key.
Follow Search → Hotel Offers → Quote → Hosted checkout → Confirm → Retrieve and manage booking. Preserve my destination, dates, guests, and opaque API identifiers. Show the current total and cancellation terms, then stop for my explicit approval before payment or booking. Payment authorization is not hotel confirmation.
Deliver the private View / Manage My Booking link after confirmation. Cancel only when I ask: show a fresh cancellation preview and stop for separate approval. Never automatically cancel a real reservation or blindly repeat a write; recover using GET on the original resource.
Test is optional. Use a separate Test key only when I request sandbox testing. Test payment automation must first prove environment=test and payment.livemode=false; never use it in Live.
Keep credentials, raw card data, signed checkout URLs, payment secrets, and cancellation approval tokens out of model context, logs, screenshots, and public client code.Mandatory guardrails
- Keep API keys in trusted server-side secret storage; never expose them to a model, browser bundle, log, screenshot, analytics event, URL, or support ticket.
- Search requires explicit latitude and longitude. Brek Hotel API v1 does not geocode place names, so callers must use a trusted geocoder and must never let a model guess coordinates.
- Raw card data, Stripe client secrets, signed hosted-checkout URLs, and cancellation approval tokens stay outside model context and pass only through trusted payment or server code.
- Obtain fresh traveler approval of the current Quote before Confirm and fresh human approval of a current cancellation preview before Cancel.
- After an indeterminate Confirm or a submitted Cancel, recover with GET on the original resource only; never create a replacement transaction or blindly repeat the write.
- Treat partner economics, rev share, commission, raw supplier net cost, and booking P&L as private server data and never place them in a traveler-facing response or model prompt used to speak to the traveler. The returned Brek-bookable offer is different: its documented payNow, payAtProperty, and travelerTotal are displayable. Build traveler output from an explicit allowlist.
No hidden agent-only transaction protocol
AI agents and conventional server applications use the same Brek Hotel REST API and OpenAPI contract. Agent Commerce is the partner program and console area; it is not a second protocol.