Architecture
How a request reaches the calendar that owns the seat
RezRoute is one API endpoint in front of two marketplace backends. This page follows a request from the moment a sales channel makes it to the moment a seat is held, booked or released.
One endpoint: api.rezroute.com
The route
One endpoint, two marketplace backends.
An operator keeps managing departures and seats in the marketplace portal they already use. A sales channel does not talk to that portal directly: it talks to one endpoint, which decides which marketplace owns the product in question and carries the call there.
That is the entire service. The value is in what it refuses to do, which is to keep a copy of your availability.
State of the connection
Routing model
The same four things happen, in the same order, every time.
- 01
The request
A sales channel calls one host over HTTPS. GetYourGuide uses HTTP Basic authentication in both directions and does not accept OAuth or bearer tokens, so the front door is built to that.
- 02
One endpoint
Every channel, every operator and both marketplaces are designed to arrive at the same endpoint, api.rezroute.com. That gives one integration to certify, and one place where a change in behaviour can be reviewed.
- 03
The routing decision
The product identifier carried in the request says which marketplace holds that product. That lookup is the whole decision. No calendar is consulted here, because there is no calendar here.
- 04
The owning backend
The request is forwarded to the marketplace that owns the product, which answers from its own live data. The Greek Local answers for Greece, Cyprus Bucket List answers for Cyprus, and neither answers for the other.
Availability
What happens on an availability call.
01 · Channel
A channel asks about a date range
The channel sends an availability query for one product and a range of dates, authenticated with HTTP Basic.
02 · Endpoint
The identifier is read and the route is chosen
The request is authenticated, the product identifier is read, and the marketplace that owns that product is looked up. Nothing is cached at this layer, so there is nothing here that can be out of date.
03 · Marketplace
The owning marketplace answers from the live calendar
The marketplace reads its own calendar: the departures on those dates, the seats still free, and the dates you have blocked. It is the same calendar a direct customer buys from, so there is no second version to reconcile.
04 · Endpoint
The answer is returned in the shape the channel expects
The response is translated into the channel format and returned as HTTP 200. Under the GetYourGuide specification every response carries that status, and any error is carried inside the JSON payload rather than in the status code.
05 · Endpoint
Changes are pushed rather than waited for
When your calendar changes, the availability update notification that GetYourGuide hosts is called, so the channel refreshes instead of waiting for its next read. Viator reads on a published cadence instead: every 2 hours for the next 2 days, every 1.5 days for 3 to 30 days out, every 3 days at 90 days, every 4.5 days at 180 days, and every 7 days beyond that.
GetYourGuide publishes response time targets for these calls: for a single day, 1 second desired, 3 seconds at the 95th percentile and 6 seconds as the longest acceptable; for 30 days or more, 5, 10 and 15 seconds. It also sets a monthly error ceiling for availability of under 0.01 percent, and treats any call not answered within 15 seconds as unavailable.
Those are the channel targets this service is built against. They are not measurements of it, and this site publishes no latency, uptime or error figure of its own. What is published about reliability.
Reservation
What happens on a reservation hold.
01 · Channel
A traveller reaches checkout
The channel calls the reservation endpoint for a product, a date and a number of travellers. Nothing has been sold yet.
02 · Endpoint
The call is routed, not answered
The product identifier decides the backend, and the call is carried to it unchanged in meaning. This layer never decides whether a seat is free.
03 · Marketplace
The seats leave general availability
The marketplace checks the seats are free and marks them held against a reservation reference, in its own database. From that moment they are offered to nobody: not to the other channel, and not to a direct customer on the marketplace.
04 · Endpoint
A reservation reference goes back to the channel
The reference is what the channel quotes when it later confirms or cancels. The hold carries an expiry from the moment it is created.
05 · Marketplace
If no booking arrives, the hold expires
The seats return to general availability. A released seat is an availability change like any other, so the channel is told about it rather than left to discover it on a later read.
Booking and cancellation
What happens on a booking, and on a cancellation.
A booking
01 · Channel
The channel confirms against the reservation reference
The booking call quotes the reference from the hold and supplies the traveller details.
02 · Marketplace
The hold becomes a booking in one write
The seats already held are converted and a booking record is written. The seats do not return to availability in between, so there is no moment at which another channel could take them.
03 · Marketplace
It lands where your bookings already land
The booking appears in the marketplace portal you already use, in the same list as a direct booking, and reaches you the way your bookings already reach you. There is no second inbox to watch.
A cancellation
01 · Channel
A reservation is cancelled before it becomes a booking
The hold is released immediately instead of waiting out its expiry, and the seats return to availability.
02 · Channel
A confirmed booking is cancelled
The marketplace cancels the booking and returns the seats to availability in the same write, so the seat count cannot drift away from the bookings that justify it.
03 · Endpoint
Both are answered the same way
Reservation cancellation and booking cancellation are two of the six endpoints GetYourGuide requires, and both answer with HTTP 200 and any error inside the payload.
The last seat
Two channels, one seat, and no interval between the check and the write.
The failure this design removes is the cached copy. A connectivity layer that keeps its own copy of your availability has to answer from that copy and reconcile afterwards. In the seconds or minutes before it reconciles, two channels can both be told the last seat is free, and both can sell it.
RezRoute keeps no copy. Every reservation call is carried to the marketplace that owns the product, and inside that marketplace the check and the write are one database transaction: read the remaining seats, decide, write the hold, commit.
So two requests for the last seat meet inside the database rather than inside a synchronisation job. One transaction commits and takes the seat. The other finds no seat and fails, and that failure is returned to the losing channel as an error in the JSON payload with HTTP 200, in the shape the specification requires. The same holds when a channel and a direct customer on the marketplace reach for the same seat at the same moment.
Identifiers
What identifies you, and what identifies a product.
One Supplier ID per operator
GetYourGuide requires one stable Supplier ID for each operator, and stable means it does not change. In this design the Supplier ID identifies you. It does not identify a marketplace, and it does not identify a product.
Because routing is decided on the product identifier, an operator with products in both Greece and Cyprus keeps a single Supplier ID while individual products are routed to different marketplace backends. Listing a new tour, moving one, or connecting a second channel does not change it.
Product identifiers, and where you paste them
We issue an identifier for each product that can be routed. You enter it in your own channel account: in your GetYourGuide supplier account you select RezRoute as the reservation system, and enter the identifier against the matching product.
If you cannot tell which GetYourGuide product corresponds to which of your tours, GetYourGuide undertakes to supply the mapping information to any supplier who asks for it, within two business days. GetYourGuide also gives at least 30 days notice of changes that affect connectivity, which is the window in which a field or an identifier could change.
Scope
What this service is not.
Not a reservation system
There is no RezRoute dashboard, no point of sale, no manifest and no reporting. The screens you work in every day stay where they are.
Not a second calendar
Availability lives in the marketplace portal you already use, and that is the copy every channel is answered from. Nothing is imported, mirrored or synchronised.
Not a marketplace
RezRoute does not list tours, does not price them, does not sell them and does not hold customer money.
Not a website booking widget
This service faces sales channels. It does not put a booking form on your own site, and it does not replace anything you use for direct sales.
Viator adds one further boundary worth stating before you plan around it: Viator supports per-person pricing only. Tiered pricing and per-unit pricing are not supported, so a product priced per boat or per vehicle cannot be represented on that channel as it stands.
Ownership
Who operates this.
Starting
What we need from you to start.
Which marketplace holds your tours
The Greek Local for Greece, or Cyprus Bucket List for Cyprus. That answer is what the routing decision is made on.
Which channels you want, and where you stand with them
Whether you already sell on GetYourGuide or Viator today, and under which account.
A calendar you actually keep
Everything a channel is told comes from it. If it is accurate, there is very little left to do. If it is not, that is the work.
One contact who can act
Somebody who can enter an identifier in your channel account and answer a question about a departure.