Security
What this service receives, forwards and keeps.
RezRoute carries availability and booking traffic between a sales channel and the marketplace that owns the product. This page describes the data in that path, where it is held, how it is authenticated, and which certifications are not held.
Last updated 24 October 2026
Data flow
Three questions, answered in order.
- Received
- Calls from a sales channel, over HTTPS, authenticated with HTTP Basic. An availability call carries a product identifier, a date range and the party composition. A reservation or booking call additionally carries the traveller details that channel requires, and that channel's own booking reference.
- Forwarded
- The same request, expressed as a call to the one marketplace backend that owns the product. Nothing is sent to the other marketplace, and nothing is sent to any third party. The answer travels back the way it came.
- Retained
- No calendar, no availability copy, and no booking record. This service holds no database of what it carried. Request logs are the only thing kept, and they are described below.
The exact traveller fields each channel sends are fixed by that channel, not by this service. This page describes the categories rather than guessing at the fields.
Storage
Where the little that is kept is kept.
Because no availability or booking record is retained, the storage question is short: what hosts this website, and who answers the calls.
- This website is hosted on Vercel. It is static: no operator data and no traveller data reaches it.
- The marketplace backends that answer the calls hold the calendars and the bookings. Each marketplace is responsible for its own data, under its own terms with the operator.
- Every provider this service relies on is named, with the personal data that reaches it, on the sub-processors page. The terms that govern them are in the data processing terms.
In transit
Encryption, and why HTTP Basic is the authentication.
Every inbound and outbound connection uses HTTPS. Plain HTTP is not served.
Authentication in both directions is HTTP Basic. That is not a preference. The GetYourGuide Supplier API specification requires HTTP Basic in both directions and does not accept OAuth or bearer tokens, so a connectivity partner implements what the channel accepts. Basic carries a reusable credential on every request, which is why the controls around the credential do the work that a short-lived token would otherwise do.
- Credentials are held as environment secrets in the hosting platform secret store. They are not in the repository, and not in any file committed to version control.
- Credentials are redacted before a log entry is written, so a request log cannot leak the credential that produced it.
- A separate credential is used for each channel and for each direction, so that rotating or revoking one does not disturb the others.
- Credentials are rotated on a fixed schedule, and immediately on any suspicion of exposure.
- HTTP Basic is only acceptable over an encrypted transport, so plain HTTP is not served at all.
Access control
What this service can reach.
Neither marketplace grants this service more access than the routing calls require. It does not read operator records it was not asked about, and it has no administrative access to either marketplace.
Logging
What a request log contains, and what it is for.
| Field | Logged | Notes |
|---|---|---|
| Timestamp | Yes | When the call arrived and how long it took |
| Channel and endpoint | Yes | Which channel called, and which call it made |
| Product identifier | Yes | Which product was asked about, and therefore which marketplace answered |
| Outcome | Yes | Success, refusal or failure, and the error carried in the payload if there was one |
| Authorization header | No | Redacted before the entry is written. Channel credentials are never logged |
| Traveller personal data | No | Names, contact details and any free text a traveller supplies are not written to request logs |
Logs exist to answer two questions and no others: whether a call was answered correctly, and which marketplace answered it. They are not used to build a picture of an operator, a product or a traveller, and they are never shared with the other marketplace. What the data may and may not be used for is set out on the data use page.
Certifications
What is held, and what is not.
Two certifications are held, both from OCTO and both conformance certifications of the OCTO booking API rather than security audits: Supplier Certification and Reseller Certification, each issued on 2026-09-07 with a public verification page. They are set out on the certification page.
Neither GetYourGuide nor Viator requires a security certification, a public status page, or connectivity partner insurance. This section exists anyway, because the honest way to answer a certification question is to answer it before it is asked.
Not held
- SOC 2, Type I and Type II
- Not held. No audit is in progress and none is scheduled. If that changes, the report and its scope will be named here rather than described in the abstract.
- ISO/IEC 27001
- Not held, and no certification work is under way.
- PCI DSS
- No claim is made. No cardholder data reaches this service, so the standard does not apply to the routing path. Payment for a channel booking is taken by the channel.
- Insurance
- No statement is made here about professional indemnity or cyber cover. Neither channel requires a connectivity partner to carry insurance.
Responsible disclosure
How to report something you have found.
The full policy, including scope, the safe harbour for good faith research and what is explicitly out of scope, is on the vulnerability disclosure page. This section is the summary.
Report a suspected vulnerability to connectivity@rezroute.com and say that the report is a security matter, and it will be routed without being discussed in a wider thread.
What we ask of you
- Do not test against production in a way that degrades service for an operator, and do not run automated scanning that generates booking or reservation traffic.
- Do not access, modify or retain data belonging to an operator, a traveller or a marketplace. Enough to demonstrate the issue is enough.
- Tell us before you publish, so that we can reply first.
What we commit to
- A reply from a person rather than an autoresponder. No acknowledgement time is promised, because there is no rota yet to honour one.
- An assessment of severity using the same levels published on the reliability page, and a plain answer about what we intend to do.
- Credit in the changelog entry when the fix ships, if you want it.
There is no paid bug bounty and no promised response time. Saying so is fairer than leaving a researcher to assume there is either.
Ownership