What we access, what we store, and where it lives

Read-only API access to your signage CMS. Nothing else. The credentials you issue should have no write permission at all — if your CMS can scope them, scope them, and we will tell you the minimum needed.

From that connection Nodark reads:

• The player or screen list, and each screen's identifier
• Last check-in time and online/offline state
• Site or venue name and address, so a screen can be located
• Player and device metadata where the CMS exposes it

Nodark does not read, download, copy or store your media assets, playlists, schedules, campaign data, booking data or revenue data. It does not need them. It does not push anything back into your CMS.

Separately, you supply venue contact details — a name and a mobile number per site — because outreach cannot happen without them. You control that list.

• Screen records: identifier, venue, address, opening hours, current state
• Incident history: when a screen went dark, what was done, when it came back
• Contact log: every SMS sent and received, and every call, with transcripts and outcome
• Site knowledge recorded against a venue, for example where the media player sits
• Callout records and their approval status
• User accounts for the people on your side who log in

Contact names and mobile numbers are personal data. They are held because they are needed to contact the venue, and for no other purpose. Call transcripts may contain whatever the contact said, so they are treated as personal data too.

We do not sell data. We do not use your data to train any model. Your data is not pooled with any other operator’s.

Hosted in the European Union.

The database, storage and application layer run on managed EU infrastructure.

Named sub-processors, so there are no surprises:

Supabase

database, authentication and application backend (EU region)

Vercel

application hosting

Twilio

SMS delivery and voice calls

ElevenLabs

voice synthesis for the AI call

Google

the language model behind message drafting and call diagnosis, and the Places API used to seed venue opening hours

The current sub-processor list is given in writing before you sign, and you are notified before it changes. If a specific one is a problem for you, tell us at the start — some can be swapped, some cannot.

• Your team, through role-based accounts. You decide who gets one.
• A display-only role exists for office wallboards. It can see screen status and nothing sensitive.
• Us. Support access is limited to the people who run the service, and it is used to run the service — investigating an incident, fixing a fault, checking a call went as it should.

Every automated action is logged with a timestamp and an actor. So is every manual override. You can see who approved a callout, who cancelled one, and when.

No other operator can see your estate. No client of yours can see another client’s screens.

• Screen and incident records are kept while your account is live, because they are the history you use to spot recurring faults.
• Call and SMS transcripts are kept for the duration of the contract, so an incident is auditable after the fact.
• You can request deletion of any individual record, any venue, or any contact at any time.
• On termination: API access is revoked immediately, and all data is exported to you and deleted within 30 days. You get the export first. You confirm it, then we delete.
• A shorter retention period can be agreed if your policy requires it. Ask before you sign, not after.

• A data processing agreement is available and will be signed before any credentials are exchanged. You are the controller, we are the processor.
• The sub-processor list above forms part of it.
• Personal data stays in the EU. If any sub-processor changes that, you are told before it happens.
• Support with a data subject request — access, correction, erasure — is included. Venue contacts occasionally ask, and we will help you answer them.