The four capabilities that matter
Section titled “The four capabilities that matter”| Capability | What it means | Why products stall without it |
|---|---|---|
| Live rates and availability | Current prices and what is actually bookable, per date range | Cached rates fail at confirmation and erode trust |
| Booking creation | Create a real reservation the hotel receives | Without it you are a referral link, not a product |
| Payment | Take money as part of the booking | A handoff to another site is where conversion dies |
| Confirmation and webhooks | Tell guest, hotel and your system what happened | Support load and reconciliation gaps otherwise |
Most “hotel APIs” a developer finds cover the first and sometimes the second. The transaction is the hard part, and it is the part that decides whether you have a product.
Whose supply are you integrating?
Section titled “Whose supply are you integrating?”This question shapes everything downstream. Supply resold through a chain arrives with a markup inside the rate, staler availability, and no route back to the hotel for a booking question. Supply that comes from the hotel directly carries the hotel’s own rate, live availability, and a hotel that knows the booking exists.
For anything where the traveler will compare against the hotel’s own website — which is most things — hotel-controlled supply avoids the awkward moment when your price is worse.
Who is the merchant of record
Section titled “Who is the merchant of record”If you build hotel booking yourself, becoming the merchant of record means taking on payment liability, chargebacks, refunds, tax handling and often a travel-agency licence in each market.
On Wink the hotel stays merchant of record and payment is collected for the hotel, so an integrator does not inherit that surface. Merchant-of-record arrangements are available on API integrations where a partner genuinely needs to take payment itself, and that route carries its own licensing requirements.
Three levels of integration
Section titled “Three levels of integration”- Web components. Drop a bookable search, room list or checkout into an existing page. No backend work; least control over layout.
- REST API. Full control over search, rates, booking creation and confirmation, authenticated with OAuth2. Use it when the booking flow is part of your product’s own experience.
- MCP server. The same capabilities exposed for AI agents, so an assistant can search, price and complete a booking rather than hand the user off to a website.
The three are not exclusive — a product commonly uses components for a marketing surface and the API for its core flow.
What to build first
Section titled “What to build first”- Search and price for one city and one date range. Get real rates flowing before designing anything.
- Create one test booking end to end, including payment and confirmation.
- Subscribe to
booking.createand the cancellation events before you build any UI on top. - Decide your attribution model early — source context needs to travel with the booking, or your reporting is guesswork later.
- Handle the failure cases: availability lost between quote and book, payment declined, partial refunds.
Pricing a developer should know
Section titled “Pricing a developer should know”The Consumer and Booking Engine APIs are free. The Partner API includes a free monthly allowance of 10,000 hotel-nights, then bills per unit. Confirmed bookings carry the hotel’s 1.5% platform fee plus card processing at cost, and a 10% default commission applies when your product drove the booking — which is how an integrator earns rather than pays.
Common mistakes
Section titled “Common mistakes”- Building on cached rates. They look fine in development and fail in production.
- Leaving payment to a redirect. Every handoff loses bookings.
- Ignoring webhooks until launch. Reconciliation becomes a manual job.
- Becoming merchant of record without needing to. It is a licensing and liability decision, not just a technical one.
- Not passing source context. Attribution cannot be reconstructed afterwards.