Security
What protects a key, a session, and the network between them
Relay is infrastructure, so the security decisions were taken on day one rather than retrofitted. This page describes the mechanisms rather than the adjectives — everything here is checkable against the API you are about to integrate.
Three credentials, and two of them can never meet
The separation is structural rather than enforced by a check. /v1 resolves its bearer against the API-key store and will never find a session there, so a session cannot publish; a key is not a session, so it cannot administer an organisation. Neither is a rule anybody can forget to apply.
Organisation key
Bearer, long-lived
Issued to an organisation, scoped to one environment, and stored only as a SHA-256 hash — the plaintext is shown once at issuance and cannot be recovered by us or by support. It authorises publishing, reading and signalling for that organisation and nothing else.
Stream ticket
Query parameter, 300 seconds
A browser EventSource cannot set an Authorization header, so your server mints a ticket from your key and hands the browser only that. It lives in a separate store from keys, so it can never authorise a publish, and the worst a leaked URL yields is five minutes of read-only streaming.
Console session
HttpOnly cookie, human
A signed session identifying a PERSON, never an organisation. It is set HttpOnly, so the token never reaches JavaScript; every console read goes browser → our server → Relay, and every mutation is a server action.
There is no password, and that is the stronger position
In any system with a reset link, control of the inbox already grants control of the account. A password is therefore a second thing to steal that grants nothing extra — so sign-in is a one-time code by email, and the optional second factor is a real one.
A second factor at the moment it matters
Enrol TOTP and every key issuance requires a step-up code, not just a live session. Recovery codes are the only escape from a lost authenticator, and they are counted and re-issuable from your account page.
Issuing a key is an owner act, and it is loud
Only an owner can mint a key, only for the organisation in the path, and every other owner is emailed within seconds. Silent issuance is the failure mode that matters — a key you were not told about is a key nobody is looking for.
An append-only audit trail
Keys issued and revoked, members invited, removed and departed, roles changed, settings edited — each recorded with the email address of the person who acted. Rows are written, never edited, and an organisation reads its own.
The last owner cannot leave
An organisation without an owner is an organisation nobody can recover, so the route refuses. The same class of guard covers redirects after sign-in, which are resolved by the URL parser rather than by a prefix comparison.
Sandbox isolation is a one-way boundary, deliberately
Every credential carries its environment from the first key an organisation issues, and an event inherits the environment of the credential that published it. The asymmetry is the design, and it is worth stating precisely.
What the boundary guarantees
A live consumer is served live events only. Nothing published with a sandbox key ever reaches a live subscriber, and a sandbox key cannot confirm, dispute or otherwise touch a live event — that attempt is refused with a distinct status so a misconfigured integration fails loudly rather than silently doing nothing.
What it is not
It is not confidentiality. A sandbox key READS live traffic, on purpose: a sandbox with nothing in it is one nobody can test a filter against, so your integration tests run against the real national feed from the first request. Treat sandbox credentials as production credentials for read access.
The safest data is the data that was never collected
A vehicle position is personal data as soon as it can be linked to someone. Relay’s answer is not to blur positions — imprecision would destroy the value of knowing which lane an obstacle is in — it is that there is no trace to reconstruct.
No trajectories, ever
The API takes isolated point events. There is no field for a trace, so there is no journey to reassemble and nothing to leak.
No vehicle or driver identifier
The contract has no field for one. That is absence rather than pseudonymisation, and absence is the stronger property.
No publisher identity on the wire
Not the organisation, and not a stable pseudonym either — a forever-stable pseudonym is a fleet-coverage map missing only its label. We attribute internally for trust and billing; nobody on the network can.
Reporter tokens are salted on arrival
A confirmation carries a client-chosen reporter token so distinct vehicles can be counted. It is salted with the organisation as it arrives and the raw value is never stored.
The full account, including legal basis and retention, is on the privacy page.
Reporting a vulnerability
Write to us and we will acknowledge within two working days. Tell us what you found and how to reproduce it; we will tell you what we are doing about it and when.
Testing against the sandbox environment is welcome and needs no prior arrangement — mint a sandbox key in the Console and go. Please do not run load or denial-of-service tests against the live environment, and do not access data belonging to another organisation; if you find a way to, that is precisely the report we want.
Certifications, data-processing agreements and contractual service-level commitments are handled per agreement rather than published as blanket claims — raise them in the contract conversation and we will answer in writing.