Legal
Privacy notice
How RezRoute handles personal data: what we decide about and answer for as a controller, what we merely carry between a sales channel and a marketplace as a processor, and who is accountable for which part.
Last updated 24 October 2026 · Draft, pending legal review
1. How this notice is written, and the two roles it describes
RezRoute is a single API front door. A sales channel calls it, and it routes that call to whichever of two marketplaces owns the product being asked about: The Greek Local in Greece, or Cyprus Bucket List in Cyprus. It keeps no copy of availability, it holds no customer money, and it creates no booking record of its own.
This notice is written to Articles 12 to 14 of the General Data Protection Regulation (EU) 2016/679, which set out what a controller has to tell people about the personal data it handles. The part of it that describes traveller data is written to Article 28, which governs what a processor may do with personal data belonging to somebody else.
That split is the spine of this document, and it is the thing most often got wrong by a service in this position. RezRoute is both of the following at once.
- A controller, in the sense of Article 4(7), of operator and staff contact details, correspondence, billing records if a charge is ever introduced, and the technical records the router keeps about its own calls. We decide why that data is held and what happens to it, so we answer for it.
- A processor, in the sense of Article 4(8), of traveller personal data that passes through the router in the course of a booking. We decide nothing about that data. It is carried on the instructions of the marketplace that owns the product, and it is used for no purpose of our own.
Read every section below with that distinction in mind. Where a section applies to only one of the two roles, it says so. Sections 4 and 5 are the two halves: the register of what we decide about, then the separate account of what we merely carry.
This notice does not cover what a sales channel does with personal data it holds for its own purposes, and it does not cover what an operator or a marketplace does with a booking once it arrives. Those parties publish their own notices.
2. Who is responsible
The entity behind RezRoute also operates the two marketplaces it routes for. That relationship is disclosed rather than managed quietly, and the data use page sets out what follows from it.
| Item | Detail |
|---|---|
| Entity | DEMCYN LTD |
| Company registration | HE 491561 |
| Registered office | Vavyla 3, Block A, Flat/Office 204, Pera Chorio Nisou, 2572 Nicosia, Cyprus |
| Country of establishment | Republic of Cyprus |
| Data protection law | The GDPR (EU) 2016/679, as applied in Republic of Cyprus by Law 125(I)/2018 |
| Privacy enquiries | connectivity@rezroute.com |
| Data Protection Officer | None appointed. Section 3 says why. |
Establishment and supervisory authority
DemCyn Ltd is the controller. It is established in Cyprus, and the Office of the Commissioner for Personal Data Protection is the supervisory authority for this service. Section 12 gives its contact details and says how to complain.
3. Data Protection Officer, and why there is none
No Data Protection Officer is appointed.
Article 37(1) requires one in three cases. None of them applies to this service, in either of the roles described in section 1.
- We are not a public authority or body, so Article 37(1)(a) does not apply.
- Our core activities do not consist of processing operations that require regular and systematic monitoring of individuals on a large scale, so Article 37(1)(b) does not apply. The service routes calls about products. It does not observe people, and it builds no profile of anybody, traveller or operator.
- Our core activities do not consist of processing on a large scale of the special categories of data in Article 9, or of data relating to criminal convictions and offences in Article 10, so Article 37(1)(c) does not apply.
Article 37 binds processors as well as controllers, and the assessment above was made in both capacities rather than only as a controller.
One qualification belongs here rather than buried. A channel booking payload can carry free text: a note, a special requirement, a question for the operator. Free text of that kind can contain health, mobility or dietary information, which is special category data under Article 9. That is incidental to routing a call, it is not a core activity, and it is not processed at scale, so it does not change the conclusion above. It does change how such a field has to be handled, which is section 5.
Data protection questions are answered by the company directly, at the address in section 2.
Cyprus is inside the EEA, so no representative under Article 27 is required.
4. What we process as controller, and why
This section is the controller half of the notice. Every purpose for which we decide to process personal data is in the table below. If a purpose is not in the table, we are not doing it.
Two rows describe the router: request logging, and rate limiting with the detection of misuse.
| Purpose | Data | Legal basis |
|---|---|---|
| Answering an enquiry you send us by email | Your name, your email address, the business you write on behalf of, and whatever you put in the message and the thread that follows it | Article 6(1)(b), steps taken at your request before entering into a contract, where the enquiry is about connecting. For any other enquiry, Article 6(1)(f), our legitimate interest in answering people who write to us |
| Keeping the contact record for an operator connection | Name, role, business email address and telephone number of the named commercial and technical contacts, the operator business details, product and option identifiers, and the supplier identifier a channel issues | Article 6(1)(b) where the individual is the operator and a party to the agreement. Where the individual is a member of operator staff and not a party, Article 6(1)(f), our legitimate interest in having a named person to reach about a connection that person runs |
| Correspondence about a connection, and the record of what was agreed | Support messages, incident notes, and the notice emails sent about changes to the service or to the sub-processor list | Article 6(1)(b), performance of the agreement, and Article 6(1)(f), our legitimate interest in being able to show what we told an operator and when |
| Billing, if a charge for connectivity is ever introduced | Operator business and billing details, invoices, and payment records | Article 6(1)(b), performance of the agreement, and Article 6(1)(c), the statutory duty to keep accounting records |
| Request logging by the router, so that a failed call can be explained and the error ceilings a channel imposes can be met | For each call: the time, which channel called, which endpoint, the product and option identifier, the response status, how long the call took, and error detail where a call failed. The log is designed to hold no traveller personal data beyond what the booking call itself carries | Article 6(1)(f), our legitimate interest in keeping the connection working and in being able to answer an operator whose booking failed. Where a log line unavoidably contains traveller data, that data is handled under section 5 and not on this basis |
| Rate limiting, and detecting misuse of a connection or of credentials | The calling identity, call counts and timestamps, and the source address a call came from | Article 6(1)(f), our legitimate interest in protecting the service and the operators on it |
| Serving this website and defending it against abuse | The request records the hosting provider keeps in order to serve a page, which include the source address of the visit | Article 6(1)(f), our legitimate interest in serving the site and keeping it available |
Where the basis is legitimate interests under Article 6(1)(f), we have considered whether our interest is overridden by the interests and rights of the people concerned. In each case the processing is limited to business contact data or to technical records about calls, it is what somebody running a connection would expect, and it can be objected to at any time under Article 21.
Connectivity is free, so the billing row is not running
Connectivity is free on both marketplaces. There is no fee anywhere, nothing is deducted from a booking, and no money passes through the service. A charge may be introduced later, with notice, and the billing row describes what would then be processed. Nothing is processed under it today.
The website sets no cookies and tracks nothing
rezroute.com is a static site. It sets no cookies of any kind, runs no analytics, embeds no advertising or social media tags, and carries no tracking. There is no consent banner, because there is nothing to consent to. There is no login, no signup form and no operator dashboard, so there is no account and no visitor profile of any sort.
You can read every page here without giving us anything. The only way to hand us personal data through this site is to write to one of the addresses printed on it, which is the first row of the table above.
That absence is a fact about how the site is built rather than a promise about how it will always be built. If any of it changes, this notice changes first and the date at the top of the page moves. The hosting provider still keeps request records in order to serve pages and to defend the site, which is the last row of the table.
5. Traveller data carried through the router, where we are a processor
This section is the processor half of the notice, and it is written in more detail than the rest because it is the part people most often assume wrongly.
What happens, in order
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. Viator is planned. The flow below is what the service does for a booking.
A traveller buys a tour on GetYourGuide or Viator. The channel sends a reservation call and then a booking call to the connectivity endpoint at api.rezroute.com. That call carries personal data about the traveller. The router reads enough of it to decide which marketplace owns the product, passes it to that marketplace, and the marketplace writes the booking into its own database in the same transaction that checks the seat is still free. The operator sees the booking in the marketplace portal it already uses.
Whose instructions govern it
The marketplace that owns the product decides why and how traveller data in a booking is handled. RezRoute carries the call on its instructions and on no other basis. In the language of Article 28, the marketplace is the controller and RezRoute is the processor. The written terms are on the data processing terms page.
What passes through
- Identity and contact details supplied by the channel: the name of the lead traveller, an email address and a telephone number.
- Booking details: the product and option, the departure date and time, the number of travellers and their categories, the language requested, and the booking reference the channel uses.
- Free text the channel passes as a note, a special requirement or a question for the operator. A field of that kind can contain health, mobility or dietary information, which is special category data under Article 9 and is treated as sensitive wherever it appears.
What is never done with it
- It is never used for any purpose of our own. RezRoute does not market to travellers, does not profile them, and does not build audiences out of booking data.
- It is never combined across operators. No pooled view, no benchmarks, no demand reports assembled out of what passes through. The same commitment is on the data use page, written so that it can be broken and therefore checked.
- It is never retained beyond what carrying the call requires. There is no separate RezRoute booking store. The booking record is created and kept in the marketplace, under the retention rules of that marketplace, and it is not duplicated here.
- It is never used to inform a commercial decision on either marketplace.
What we owe the controller
Article 28(3) sets the obligations, and the data processing terms restate them in full: process only on documented instructions, keep the people who handle it under a duty of confidence, apply the security measures Article 32 requires, engage a sub-processor only on the agreed conditions, help the controller answer a rights request, help it meet Articles 32 to 36, delete or return the data at the end, and make available the information needed to show all of that. Under Article 33(2) we notify the controller without undue delay after becoming aware of a personal data breach.
6. Who else sees the data
We do not sell personal data, and we do not share it for the advertising of anybody else. The parties below either receive data as the destination of a call, or handle it on our behalf under contract and on our instructions.
| Who | What they do |
|---|---|
| The marketplace that owns the product: The Greek Local or Cyprus Bucket List | Receives the routed call and writes the booking into its own database. This is the destination of a booking rather than an onward disclosure for a separate purpose. Each marketplace is a separate system, and the service routes to it. |
| The sales channel that made the sale, GetYourGuide or Viator | Holds traveller data for its own purposes, as its own controller, under its own privacy notice. A booking payload comes from the channel in the first place, so data reaches it because the traveller bought from it. |
| The operator delivering the tour | Receives the booking in the marketplace portal it already uses, and decides for itself how it runs the tour. |
| Vercel Inc. | Hosts and delivers this website. The provider is a United States company. No operator data and no traveller data reaches this website. |
The maintained version of this list, including how a change to it is notified, is the sub-processors page.
We will also disclose personal data where we are legally required to, for example to a tax authority, a court, or a regulator acting within its powers.
7. Transfers outside the EEA
Cyprus, where the company is established, is inside the EEA, so a transfer under Chapter V of the GDPR means personal data going outside it. This website is hosted by Vercel Inc., a company established in the United States, so a transfer mechanism is needed for the request records described in section 4.
Data reaches a sales channel because the traveller bought from it, not because we passed it on, and the channel handles it under its own privacy notice.
8. Security, and what happens if it fails
The full account of storage, access and transport is on the security page, and the contractual version is in the data processing terms. The measures that bear directly on personal data are these.
- Transport. Everything is served over HTTPS, and plain HTTP is not served at all.
- Credentials. Authentication with the channels is HTTP Basic in both directions, because that is what they require and neither accepts OAuth or bearer tokens. Basic carries a reusable credential on every request and has no expiry of its own, so the controls around it carry the weight: encrypted transport, restricted storage, and rotation.
- Exposure. The service holds no copy of availability, creates no separate booking store, and has no operator dashboard and no login. There is therefore no second database of traveller records to lose and no account to take over. That is a consequence of the architecture rather than a control we added, which is why it is stated as a fact rather than offered as a reassurance.
- Payments. No payment card data reaches this service. RezRoute takes no payment from travellers and holds no money.
This service holds no security certification. It has had no SOC 2 audit and it is not certified to ISO 27001, and nothing on this site should be read as claiming otherwise.
If there is a breach
No system is perfectly secure. Where a personal data breach affects data we control, we will notify the competent supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of the people concerned, as Article 33(1) requires. Where the breach is likely to result in a high risk to those rights, we will tell the people affected directly, as Article 34 requires.
Where a breach affects traveller data we merely carry, Article 33(2) applies instead: we notify the marketplace that instructed us, without undue delay, and it decides what has to be reported.
The supervisory authority that would be notified is the Office of the Commissioner for Personal Data Protection, named in section 12.
If you believe you have found a security problem, the vulnerability disclosure page says how to tell us.
9. Your rights
You have the rights below over your personal data. Exercising them is free, unless a request is manifestly unfounded or excessive under Article 12(5), and we will answer within one month. Article 12(3) allows that to be extended by two further months for a complex request, in which case we will tell you why inside the first month.
- Access: a copy of the personal data we hold about you and confirmation of how it is used (Article 15).
- Rectification: correction of anything inaccurate and completion of anything incomplete (Article 16).
- Erasure: deletion where we no longer need the data, where you withdraw the consent that was its only basis, or where you successfully object (Article 17). This does not override records we are legally required to keep.
- Restriction: a pause on processing while an accuracy question or an objection is resolved (Article 18).
- Portability: the data you gave us, in a structured, commonly used and machine readable format, where the basis is consent or contract and the processing is automated (Article 20).
- Objection: to any processing based on legitimate interests, on grounds relating to your particular situation (Article 21). The rows in section 4 that rely on Article 6(1)(f) are the ones this bites on.
- Withdrawal of consent: at any time, without affecting anything done before you withdrew it (Article 7(3)). No processing described in this notice currently relies on consent, because the site sets no cookies and runs no analytics.
How to exercise them
Write to connectivity@rezroute.com. We may ask you to confirm your identity first, as Article 12(6) allows, so that we do not disclose your data to somebody else.
If your request concerns a booking, it is usually quicker to ask the party that holds the record: the sales channel that took the sale, or the marketplace and the operator that delivered the tour. Where a request reaches us about data we merely carried, we have no authority to act on it ourselves. We pass it to the controller responsible, as Article 28(3)(e) requires, and we tell you that we have done so.
10. Automated decision making
We do not carry out automated decision making or profiling that produces legal effects concerning you, or that similarly significantly affects you, within the meaning of Article 22.
One decision in the service is automated, and it is worth naming so that the answer above is not taken as evasive. The router decides which marketplace a call belongs to. That decision is made about a product, not about a person: it reads which system owns the product being asked about, and nothing about the traveller enters into it. No score is calculated about anybody, no price is set for anybody, and no booking is accepted or refused on the strength of who a traveller is.
11. Children
This website is aimed at tour operators and at sales channel partnership teams. It is not directed at children, it offers no service to a child, and Article 8 does not arise, because nothing here is offered to a child on the basis of consent.
Travellers on a tour can be children, and the composition of a party reaches the router in a booking call because the channel sends it. Nothing is decided about that data here, it is carried to the marketplace like the rest of the booking, and RezRoute never contacts a traveller of any age.
If you believe a child has sent us personal data directly, write to us and we will delete it.
12. Complaining
If you are unhappy with how your data has been handled, please tell us first, at connectivity@rezroute.com. We would rather fix it. That is a request, not a condition: Article 77 gives you the right to complain to a supervisory authority whether or not you have raised it with us, and Articles 78 and 79 give you a judicial remedy against the authority or against us.
The supervisory authority for this service is the authority of its country of establishment, Republic of Cyprus.
| Item | Detail |
|---|---|
| Authority | Office of the Commissioner for Personal Data Protection (Γραφείο Επιτρόπου Προστασίας Δεδομένων Προσωπικού Χαρακτήρα) |
| Address | Iasonos 1, 1082 Nicosia, Cyprus (P.O. Box 23378, 1682 Nicosia) |
| Telephone | +357 22 818 456 |
| commissioner@dataprotection.gov.cy | |
| Website | dataprotection.gov.cy |
13. Changes to this notice
When this notice changes, the date at the top of the page changes with it. The date is the record: if the date has not moved, the notice has not changed.
Where a change materially affects how personal data is used, we will make it obvious rather than relying on you to notice, and connected operators are emailed at the named contact rather than left to re-read the page. The same applies to a change in the sub-processor list, which is notified in the way the sub-processors page describes.
This version of the notice is dated 24 October 2026.
Ownership