A booking link gives a guest a page where they can complete a hotel booking. A confirmed reservation requires a successful booking outcome. Creating a link, opening the page, or submitting details must not cause an AI assistant to report that the hotel has confirmed the room.
In Stayker's current AI workflow, the assistant finds hotels, retrieves current room offers, and returns a secure booking page. The guest completes that page. The integration then needs verified reservation status before it can report success. See the full booking workflow and current 1Stay docs.
Preserve the different states
The following is a product-design model, not a list of API status strings. Map your interface to the actual documented service results. Only report an intermediate state when your application has evidence for it.
| State | What it establishes | Appropriate guest message |
|---|---|---|
| Booking page created | A secure handoff is available | "Your booking page is ready." |
| Guest opened the page | The guest reached the page, if observed | "Complete the booking on that page." |
| Booking submitted | A request was submitted, if observed | "The booking is being processed." |
| Reservation confirmed | The booking result establishes success | "Your reservation is confirmed," with the verified reference |
| Booking failed | A definite failure was returned | Explain the returned failure and the documented next step |
| Outcome uncertain | The application cannot yet establish success or failure | "I'm checking the booking status before trying again." |
Do not infer page-open or submission events from a link being displayed. If your integration cannot observe those steps, keep the state at handoff until a later verified result is available.
Why the distinction matters
A guest who hears "booked" may stop looking for a room, plan travel, or arrive expecting a reservation. Your interface therefore needs a success condition based on the reservation result, not on whether a tool call returned HTTP 200 or a URL.
Keep the hotel's confirmation reference distinct from internal request IDs and booking-page references. Display the type of reference the service actually returned. An internal identifier can help recovery without proving the hotel has confirmed the stay.
The same distinction helps measure your product. Count booking handoffs and confirmed bookings separately. A link-created event is useful evidence of interest, but it is not a completed booking or booking revenue.
Keep sensitive collection on the secure page
The guest supplies identity and payment details on the booking page. The assistant should not ask for card numbers or security codes in chat, copy them into tool arguments, or repeat them in a response.
Use the selected current offer to create the handoff. Price and recorded cancellation terms belong together. If the offer expires or materially changes, follow the quote freshness workflow and obtain renewed acceptance before proceeding.
Recover safely from uncertainty
A timeout does not always mean a request failed. The service may have completed the booking while its response was lost. Starting another booking immediately can produce a duplicate reservation.
Preserve the documented booking reference or recovery context and check the existing result through the supported status or verified lookup path. If it is confirmed, report that result. If it definitively failed, follow the documented retry path. If it remains uncertain, explain that status and use the approved support path. Do not silently turn uncertainty into success or failure.
Reservation lookup has its own identity checks. Follow the documented verification factors before revealing an existing booking; knowing a guest's name alone is not sufficient authorization.
Cancellation has the same handoff boundary
Stayker's current cancellation tool returns recorded terms and a first-party review link. The tool call itself does not cancel the reservation. The guest must review the terms and explicitly confirm on that page. Verify the resulting status before saying cancellation is complete.
Amending a reservation is a separate capability. Current guest-service guidance sends amendments through the hotel's verified management path or front desk. Do not promise that a cancellation link can change dates, guests, or rooms.
Verify the guest journey
Test successful completion, an abandoned page, a definite failure, and an uncertain outcome. Verify your product's messages against the actual returned state at each step. A sandbox can prove application handling; it does not establish delivery of a real reservation to a hotel.
Use Stayker Build and the 1Stay developer documentation to choose the supported integration. The MCP vs REST guide explains the interface choice; this outcome boundary applies to both.