Skip to content
Gateway Stream

Getting Started

Introduction

The Gateway Stream client API puts several hotel sources behind one set of endpoints, one vocabulary and one API key.

A hotel booking normally means integrating each supplier separately: their hotel codes, their rate structures, their error vocabulary, their cancellation rules. The Gateway Stream API does that work once. You search, you book, you cancel — and the shape of what comes back is the same whichever source actually held the room.

What the API Gives You

  • One search across every source. A single POST /search covers every source your account may sell, and returns whatever answered inside your timeout. A source that is slow is reported in the response (meta.complete) rather than failing the call.
  • Places you can pick. Destinations lists the countries and cities a search can be run in, and a search takes a city and country straight from it.
  • One canonical shape. Rates, rooms, prices, boards, cancellation policies and bookings all use the same field names regardless of origin. Errors from the hotel's own systems are translated before they reach you.
  • A complete booking record. A booking comes back with the hotel, each room with its guests, and the rate it was sold at — and a hotel page is one call: its rooms, their pictures and their rates together.
  • Rate keys instead of supplier tokens. Search hands you an opaque rateKey; booking redeems it. You never hold a hotel system's own session token.
  • Server-side pricing. Markup is applied before the price reaches you, so the sell figure on a rate is the figure to show and the figure to book at.

Where the Hotels Come From

Behind the API are several sources of hotel inventory — hotels contracted directly, direct-to-hotel networks and wholesale gateways. Which of them your key may sell is set on your account.

You never see, choose or depend on which one holds a room. A hotel, a rate and a booking carry no source, and neither do error messages: that is what lets Gateway Stream change what stands behind the API without changing anything you have built.

How a Call Is Shaped

Every request carries an x-api-key header, and that key alone decides whether the call runs against sandbox or live data. Requests and responses are JSON. Errors always arrive as { error: { code, message, requestId } }.

The client API is seven endpoints:

GET /properties/:id is part of the properties page. Administration — switching sources on and off, markup rules, issuing API keys — is a separate, operator-only API and is not documented here.

Not in This Version

Worth knowing before you design around them:

  • Reading a booking back from the hotel's own reservation system. GET /bookings/:id serves Gateway Stream's own record of the reservation.
  • Matching the same hotel across sources — it appears once per source.
  • Room pictures on search results: they come with the single-property call instead.
  • Payment collection. payment records who took the guest's money; the API does not take card details and never will.

Where to Go Next

If you have a key, go straight to the Quickstart. If you are deciding whether this API fits, the booking flow overview is the shortest route to understanding what an integration looks like end to end.