Reliability
Service levels this connection is built to meet.
GetYourGuide and Viator each publish the response times, error ceilings and availability a connectivity partner is expected to hold. This page lists those numbers, and describes the design decisions taken to meet them.
Targets and design decisions, not measurements. Last updated 24 October 2026.
Read this first
GetYourGuide
The targets set by the Supplier API specification.
RezRoute is built to the GetYourGuide Supplier API specification. GetYourGuide certified this connection on 20 October 2026 after its Supplier API live test, and the first supplier was connected through self-mapping on 21 October 2026. The figures below are the ones that specification sets. They are reproduced here so a reviewer can see that the service was designed against them rather than adjusted to them afterwards.
The availability commitment is 99.8 percent per calendar month. A call that is not answered within 15 seconds counts as unavailable, which means a slow answer and no answer are treated as the same failure.
| Call | Desired | 95th percentile | Longest acceptable |
|---|---|---|---|
| Availability, one day | 1 | 3 | 6 |
| Availability, thirty days or more | 5 | 10 | 15 |
| Reservation | 1 | 3 | 10 |
| Booking | 2 | 4 | 10 |
| Reservation cancellation | 1 | 2 | 4 |
| Booking cancellation | 1 | 4 | 6 |
| Call | Monthly error ceiling |
|---|---|
| Availability | Under 0.01 percent |
| Reservation | Under 1 percent |
| Booking | Under 0.5 percent |
| Booking cancellation | Under 0.5 percent |
Obligations that sit alongside the numbers
- A named technical contact who answers within 24 hours, or the next business day.
- Mapping information supplied to any supplier who asks for it, within two business days.
- At least 30 days notice of any change that affects connectivity.
Notice of changes affecting connectivity is published on the changelog on the day it is given.
Viator
The targets set by the Connectivity Quality Program.
Viator development has not started. Viator requires that a reservation system already has registered operators using it, with a published minimum of five active engaged operators, before development may commence. The targets below are recorded now because they shape decisions taken today, not because anything is running against them.
Viator sets 99.8 percent uptime for critical synchronous APIs and 99.5 percent for asynchronous APIs.
| Call | Monthly error ceiling |
|---|---|
| Availability check | Under 1.5 percent |
| Reserve | Under 1.5 percent |
| Booking | Under 0.75 percent |
Architecture
The decisions that serve those numbers.
- 01
No cached copy of availability
A channel asking whether a seat is free is answered from the calendar that holds the seat. There is no copy in this service to fall behind, and therefore no reconciliation window in which two channels can both be told that the last seat is free. A cache would make the response time targets easier to hit and the answers less true, which is the wrong trade for the one number that matters.
- 02
The seat check happens inside the marketplace transaction
A booking is written in the same database transaction that verifies the seat is still available, inside the marketplace that owns the product. Two requests for the same last seat are resolved by that database: one succeeds, the other is refused. This service does not arbitrate, so there is no place in it for a race to occur.
- 03
Timeouts derived per endpoint, not one global timeout
A thirty day availability query has a longest acceptable time of 15 seconds, while a reservation cancellation has 4. A single global timeout would be either too patient to protect the short call or too aggressive for the long one, so each call carries a timeout derived from its own budget. Each timeout sits inside the budget rather than at it, because a call that is not answered within 15 seconds counts against availability.
A request for a product owned by The Greek Local and a request for a product owned by Cyprus Bucket List are each answered by the marketplace that owns the product.
Incidents
Severity, response targets and escalation.
Severity levels
- S1, critical
- A channel cannot read availability, or cannot complete bookings, for one or both marketplaces. Sales stop. A call that is not answered counts here, because an unanswered call is a failed sale.
- S2, major
- A function is degraded or failing intermittently. For example bookings succeed but cancellations do not, or responses arrive within the transport timeout but outside the longest acceptable time in the tables above.
- S3, moderate
- An issue that does not stop sales. For example a mapping correction, a malformed optional field, or a discrepancy in a figure that is reported rather than transacted.
Response targets
| Severity | Acknowledge | Recover |
|---|---|---|
| S1, critical | 2 | 5 |
| S2, major | 3 | 14 |
| S3, moderate | 5 | 90 |
Escalation path
Report it to connectivity@rezroute.com. Include the channel, the product identifier and the time, because a routing fault is usually specific to one marketplace and one product. Support is by e-mail, and no telephone support line or out-of-hours line is published.
Incidents that turn out to sit on the channel side are reported by that channel through its own channels, and this service does not restate them as its own.
Incidents affecting connectivity will be recorded on the status page with start time, end time, effect and cause.
Ownership