Privacy Policy

NORBA TRAVEL OÜ — a private limited company registered in the Estonian Business Register under registry code 17597060, trading as Norba ("we", "us") — is the data controller for the personal data described here. We operate two websites and one API, and this policy covers all three:

• norba.io — the public site and the developer dashboard, where travel businesses get API keys, watch their usage and manage billing.
• booking.norba.io — the traveller-facing booking site, where flights are searched and bought.
• api.norba.io — the NDC aggregation API itself, called by our customers' software.

For anything in this policy — a question, a request to exercise a right, or a vulnerability report — write to hello@norba.io. It reaches a person, not a queue.

When one of our API customers uses Norba inside their own product, THEY decide what to collect from their users and why: for that data we act as their processor, under the contract in our Terms of Service, and their own privacy notice governs. This policy describes what we do as controller — for our own account holders and for travellers who book on booking.norba.io.

Account data. Your email address, your name if you give one, your profile picture URL if you sign in with Google, your chosen language, and the state of your two-factor authentication. Passwords are never stored — only an Argon2id hash, from which the password cannot be recovered.

If you sign in with Google. We ask Google for exactly three scopes — openid, email and profile — and receive your Google account identifier, your email address and whether Google has verified it, your name and your picture. Nothing else, and we never gain access to your Gmail, Drive, Calendar or contacts.

Traveller and booking data (booking.norba.io). To issue a ticket an airline requires the passenger's name, date of birth, nationality, travel-document type and number, and a contact email and phone. We collect exactly that, plus the itinerary and the order record the airline returns. Names, dates of birth, documents and contact details are encrypted at rest with AES-256-GCM under keys held outside the database; the rest of an itinerary — routes, times, prices, status — is stored in the clear so the database can index and total it.

Payment data — what you pay us. We never see or store the card you pay our invoices with. Those details are entered directly into Stripe's own hosted field on our page and go from your browser to Stripe; our servers receive a token and the last four digits, which is all a receipt needs.

Payment data — what an agency pays an airline. A business booking through the API pays the carrier itself, with a card of its own, and that card reaches us inside the booking request: it is held in memory only for as long as the request takes, forwarded to the airline for that one transaction, and never written to the database, a log or a backup. We ask for the fewest fields that will complete it — the security code is optional — and we never take card details by email, chat, a support ticket or the telephone. The traveller's own card never reaches us at all: the traveller pays the agency, on the agency's own checkout.

API usage and request logs. For every call to api.norba.io: the endpoint, the time, the response code, how long it took, the request id, the calling IP address and user agent, and — for the account's own calls — the request and response bodies, so a developer can debug what their integration actually sent. Whole route families are excluded from that body capture: booking, traveller, sign-in and account endpoints never have their bodies stored, which is why neither a card nor a passenger's document can reach these logs. What is captured is redacted as well, key by key, at any depth.

Security events. Sign-ins and failed sign-ins, second-factor changes, API-key creation and revocation, password resets and rate-limit trips, each with the IP address and user agent. You can read your own feed in the dashboard under Settings, and on the booking site under Account → Security; that is why it exists.

Sessions. For each active session: a device name derived from the user agent, the IP it started from, when it started and when it was last used — so you can spot one you do not recognise and end it.

Early-access signups. If you put your address in the waitlist form, it is emailed to our own inbox and is not written to any database.

Service telemetry. Better Stack records page views, timings, errors and a masked replay of sessions so we can find broken and slow pages and investigate abuse. It never runs on the dashboard or the sign-in flow, and in the EEA, the UK and Switzerland it runs only if you accept it: see clause 9 and the Cookie Policy.

We do not ask for special-category data — nothing about health, religion, politics or ethnicity. A special service request you add to a booking (a wheelchair, a particular meal) can imply such data; where it does, we process it solely to pass it to the airline so the service is actually provided, on your explicit consent under Art. 9(2)(a), and we do not use it for anything else.

Under Article 6 of the GDPR, each purpose rests on one of these:

• Performance of a contract, Art. 6(1)(b) — running your account, authenticating you, serving API calls, searching and booking flights, issuing tickets, and invoicing what you used. Without this data there is no service to provide.
• Legitimate interests, Art. 6(1)(f) — security event logging, brute-force lockouts, rate limiting, fraud prevention and keeping the platform available, all of it from our own servers. Our interest is a service that is not abused; the data involved is the minimum that makes an attack visible, and you can object (clause 7).
• Consent, Art. 6(1)(a) — the browser telemetry and masked session replay, wherever the ePrivacy Directive requires it to be asked for. Refusing costs you nothing, and you can withdraw it from the cookie panel at any time.
• Consent, Art. 6(1)(a) — marketing email. Never assumed, never bundled with anything else, and withdrawable at any moment without losing access to anything.
• Legal obligation, Art. 6(1)(c) — invoices and accounting records we are required to keep, and the passenger information airlines and border authorities are required to collect.

We do not sell personal data, we do not share it with data brokers, and we run no advertising. Data reaches the following parties and no others:

• Airlines and their NDC distribution platforms — to search for and book the flight you asked for. A carrier receives the passenger details it needs to issue the ticket and becomes a controller of that booking in its own right, under its own privacy notice and its conditions of carriage. This is unavoidable: a ticket cannot exist without the airline holding the passenger's name and document.
• Render Services, Inc. — hosting for the API, both websites and the database. Our instances run in Render's Frankfurt region, so the data rests in the EU.
• Resend — delivery of transactional email (verification, password reset, security alerts, booking confirmations). It sees the recipient address and the message.
• Stripe Payments Europe, Ltd. — card payments and stored payment methods. Stripe is the controller of the card data it collects, under its own policy.
• Better Stack (BetterStack s.r.o.) — server logs, uptime monitoring, and the service telemetry and masked session replay described in the Cookie Policy.
• Google Ireland Ltd. — only if you choose "Sign in with Google", and only for that sign-in.
• Professional advisers, and authorities where we are legally compelled — in which case we tell you unless the law forbids it.

Every provider above is bound by a data-processing agreement that limits them to acting on our instructions, except the airlines and Stripe, which are independent controllers for the parts described.

Our servers and database are in the EU (Frankfurt). Some providers are established outside the EEA or have parent companies that are:

• Render is a US company; the personal data itself stays in its Frankfurt region, and the transfer of any administrative access is covered by the European Commission's Standard Contractual Clauses.
• Stripe contracts through its Irish entity, with onward transfers to the US under Standard Contractual Clauses.
• Better Stack is established in the Czech Republic — inside the EEA.
• Google, for sign-in only, under Standard Contractual Clauses and the EU–US Data Privacy Framework.
• Airlines are worldwide by nature. Where you book a flight to or through a country outside the EEA, the passenger data necessarily reaches carriers and authorities there; that transfer is necessary for the performance of the contract you asked us to make, under Art. 49(1)(b).

The windows we apply:

• Account data — while your account exists. Delete the account and the personal fields are cleared; the rows that invoices and tickets reference are retained in anonymised form, because an invoice cannot be un-issued.
• Bookings and orders — kept for as long as the ticket can still be flown, changed, refunded or disputed, and thereafter for the period accounting and tax law requires (six years in Spain).
• API request logs and security events — kept while they are useful for a billing dispute, a bug or a security investigation, and no longer than 24 months.
• Search records — short-lived by design; they carry routes and counts, never a passenger identity.
• The public booking demo — deleted automatically after 30 days. It never stores a full document number (a masked last four at most) or a full date of birth (the year only).
• Your cookie choice — six months, then we ask again.

In fairness, one caveat: only the demo purge above runs on a timer today. The other windows are applied on review rather than by an automatic job, so a row may briefly outlive its window. If you ask us to delete your data sooner, we do it — see the next clause.

You can ask us to: give you a copy of your data (Art. 15); correct it (Art. 16); delete it (Art. 17); restrict what we do with it (Art. 18); hand it over in a portable format (Art. 20); or stop processing based on legitimate interests (Art. 21). Where processing rests on consent, you can withdraw it at any time, with no effect on what was lawful before you did.

Write to hello@norba.io. We reply within one month, and we do not charge for it. We may ask you to confirm you control the account's email address — not as an obstacle, but because handing an account's data to whoever asks is itself a breach.

Much of this needs no request at all: the dashboard and the booking site let you edit your profile, list and revoke your active sessions, see your own security events, and delete your saved traveller profiles yourself.

If you think we have got this wrong, you can complain to a supervisory authority. Because we are established in Estonia, our lead authority is the Estonian Data Protection Inspectorate — Andmekaitse Inspektsioon, www.aki.ee. You may equally complain to the authority where you live: in Spain that is the Agencia Española de Protección de Datos (www.aepd.es). We would rather you told us first — hello@norba.io — but that is your choice, not a precondition.

Concretely, and only what is actually in place:

• Passwords hashed with Argon2id. Passenger names, dates of birth, travel documents and contact details encrypted field-by-field with AES-256-GCM, under keys the database does not hold.
• Optional two-factor authentication (TOTP) with single-use recovery codes.
• Sessions scoped to one surface: a booking-site session is refused on the developer API and vice versa, so a token taken from one product cannot be spent in the other.
• Row-level security in the database, so one agency's rows are unreachable from another's connection even if a query forgets to filter.
• TLS everywhere; a strict Content-Security-Policy on both sites, so injected script does not run; API keys stored hashed, revealable only after re-entering your password, and never during a support session.
• The card you pay us with never touches our servers. A card an agency sends to pay an airline is held only for the life of that request, forwarded to the carrier, and never stored.

No system is perfect. If a breach is likely to put you at risk we notify the supervisory authority within 72 hours and tell you directly, as Art. 33 and 34 require.

Every cookie, local-storage and session-storage item either site sets is listed — by name, purpose, provider and lifetime — in the Cookie Policy. Only one group is optional; it is off until you switch it on, and refusing it costs you nothing.

We make no automated decision that produces a legal effect for you or similarly significantly affects you, within the meaning of Art. 22. Two things are automated and worth naming anyway: a temporary lockout after repeated failed sign-ins, and rate limits on the API and the auth endpoints. Both are reversible, neither profiles you, and a human will lift either on request.

Our accounts are not for children: you must be 16 or older, or of the age of digital consent in your country, to create one. A child can of course be a passenger on a booking an adult makes, in which case the adult provides their details and is responsible for doing so. If you believe a child has created an account, tell us at hello@norba.io and we will remove it.

We update this policy when what we do changes — not the other way round. Material changes are emailed to account holders and posted here at least 14 days before they take effect, and a change that adds a purpose relying on consent means we ask again rather than reading your old answer as covering it.

The controller of everything described here is NORBA TRAVEL OÜ, registry code 17597060, Estonian Business Register.

One address for all of it — privacy enquiries, rights requests, security reports and everything else: hello@norba.io. We are a small team and we read it.