Open Service Booking Protocol
OSBP authorizes the booking, not the payment.
OSBP is a small, open protocol that lets an AI agent book a service only after the user has approved a scoped authorization, a BookingMandate. The agent can search, compare, and prepare. It can only book inside the mandate.
The gap
Section titled “The gap”A service booking is not a purchase. It is a provider-bound timeslot: one named person’s time, at one place, for one duration, under one cancellation policy, that cannot be double-sold. The new agentic commerce protocols move money and place orders; they do not currently define a general mandate-bounded model for provider-bound service appointments. The platforms and adapters that do book provider time are single-platform channels, not a neutral protocol that any mandate-aware agent and any booking platform can share. OSBP fills that gap: the open layer for the provider-bound timeslot.
Open booking is not new. OpenActive showed it for activities and FHIR for clinics. OSBP brings that tradition to AI agents, and adds the one thing autonomous booking needs that they did not: a user-approved mandate.
The mandate
Section titled “The mandate”A BookingMandate states who authorized what: which service, with whom, in what time and price range, and for how long. Every booking must fall inside it. If the agent is unsure, it asks. Put plainly: if an agent cannot show you the provider, the service, the place, the time, the price ceiling, and the policy, it cannot book. The merchant platform stays the system of record. OSBP rides the Model Context Protocol for transport; it does not replace it.
Payment authority is a separate layer. Protocols like AP2 are converging there. OSBP is designed to compose with them: a BookingMandate is a sibling to a payment mandate, one scopes the appointment, the other scopes the charge. When a booking needs payment, OSBP will hand off rather than handle the card itself.
The objection
Section titled “The objection”Why not just write your own connector? If you are one platform with one agent partner, you should. The case for a protocol is everything a connector leaves out: server-side mandate enforcement, fail-closed payment gates, idempotency, and audit evidence of what was authorized and what actually happened. Those are the parts that stop an agent from acting outside its authority, and almost nobody builds them twice. A connector integrates one platform with one agent. A protocol makes the authority boundary reusable across mandate-aware agents and OSBP platforms, and gives the next adapter a spec to implement instead of a partnership document to negotiate.
And why now, when agents book almost nothing today: protocols precede behavior. The payment protocols are being negotiated before agent purchasing is mainstream, because the alternative is a closed platform setting the standard once the behavior arrives. Booking is the first high-frequency agent task after buying, and mandate-bounded provider appointments still have no general open agent model. The time to define it is before it is contested.
The proof
Section titled “The proof”This is not a proposal on paper. The public reference backend runs the whole booking loop without accounts or secrets, and the Openings adapter has completed a live booking flow under a BookingMandate through an OSBP-enabled booking platform.
The invitation
Section titled “The invitation”OSBP is small on purpose. A small, precise specification is easy to implement, for a developer and for the AI agent that writes the adapter. OSBP composes existing web standards, including RFC 3339, ISO 4217, E.164, and IANA time zone names, rather than inventing new ones. v0.1.0 ships eight tools and a single booking action, booking.create; change and cancel are on the roadmap, not in this release. Implement OSBP for your booking platform. Pressure-test the mandate. Help shape the change, cancellation, and payment-composition surfaces before they harden.
Spec · Repository · Reference demo · Discuss
By Andy Volk, co-author of Media RSS (2004). Version 0.1.0, June 15, 2026.
Code under Apache 2.0; this text under CC BY 4.0. Protocols and platforms named here are illustrative, not endorsements.