Harness every screen you already own — one network, any industry.

Built for the reality of a real site with real staff, not a head office in a different country.

Most screen-network solutions rely on a separate device plugged in behind every TV. In practice, on a real site, that's a liability, not a feature: devices get plugged into the wrong port, go missing, get stolen, or just fail — and every failure is a support call to a location that may not have anyone technical on-site. ScreenSync needs none of that. The screen's own browser is the entire client, so there's nothing extra to plug in, lose, or steal in the first place — a design built around this reality, not adapted to it:

• Nothing extra to buy, ship, install, lose, or have stolen — per screen, per location, forever
• No technical setup on-site — if a location's own staff can open a QR code on their phone, they can activate a screen
• Nothing new for anyone to hack — no separate device sitting on your network with its own security gaps to patch or forget about
• Every screen updates the instant a change is made — no manual rollouts, no waiting, no truck rolls to fix a stuck device
• A new screen at a new location can go live in minutes, not weeks of shipping and installing hardware
• No setup fee, no onboarding cost, no devices to buy upfront — start on one location or a hundred, and it costs the same to try either way
• Zero upfront capital cost to deploy — no hardware purchase to approve or depreciate before a single screen goes live
• Turn any screen on or off in seconds, from the dashboard — scale a pilot up or down without buying or shipping anything either way
• Costs stay flat as the network grows — nothing per-screen to multiply across hundreds of locations
• Verified proof of engagement, not just a promise that content played

One dashboard, every screen, always up to date.

Operators spend real money keeping on-screen information accurate and consistent — a hotel's rate board, a rental fleet's availability, a retailer's price ticket, whatever a location needs to show. ScreenSync replaces static signage with a screen the operator already owns, driven from a system they already control:

• Central, real-time control of every screen's content, across every location, from one dashboard
• Content can be typed in by hand, or pushed automatically from the operator's own backend system
• A curated content library for paid advertiser slots — negotiated and scheduled independently of everything else on screen
• A QR code on any slide, linking through to full detail — a spec sheet, a booking page, whatever fits
• No hardware to install — the TV or laptop's own web browser is the entire client

1. A location's TV or laptop opens one ScreenSync URL in its own browser — nothing installed.
2. The screen shows a QR code. Staff scan it once with a phone to claim it for that location.
3. The operator updates content in the dashboard, or their own backend pushes it via a simple API key.
4. Every screen assigned that content updates automatically — typically within one display cycle.
5. Advertiser content and the operator's own content can share the same screen on a schedule they control.

No new hardware. No app to install on the TV. No per-device manual setup beyond the initial QR-code claim.

A hundred identical Samsung TVs at one site look the same to a human. They don't look the same to us.

Make, model and screen size never enter into it. The moment any TV or laptop's browser opens a ScreenSync page for the very first time, our server hands that one browser a long random code of its own — nothing about the hardware is read or fingerprinted, it's simply issued, the same way a raffle ticket is issued rather than printed onto the person holding it. That browser then carries its own code on every single request it ever makes back to us. Two identical TVs sitting side by side get two completely different codes the instant they each load the page for the first time, entirely independently of one another — so from that moment on, we're never telling screens apart by what they are, only by which code showed up with the request.

Scanning the QR code to claim a screen for a location is a separate, later step — it doesn't create the uniqueness, it just labels a code that was already unique the moment the screen first switched on. And because some smart TV browsers wipe their storage on every power cycle, that same code is also written straight into the TV's own address bar, so a screen set to reopen its own URL on startup keeps its identity even through a full reboot.

ScreenSync's device pairing runs on Digitag's core patent — the same mechanism behind eReceipts and our other divisions, just applied to a screen instead of a bag or a bike.

An unclaimed screen has no physical tag the way a bag or a bike would, so its own QR code is the tag: scanning it is what allocates the device to an operator's account in our database and switches on content delivery to it — the same generate-a-tag → scan → assign- ownership → tamper-evident-receipt mechanism protected under South African Patent No. 2022/09555. Under the eReceipts name, this exact mechanism is what issues a digital luggage tag at check-in; here, the "item" being tagged is the screen itself.

Designed for a handful of screens today, and thousands across multiple operators tomorrow.

A growing network's screen count grows fast, whatever the industry — this is built with that in mind from day one, not retrofitted later.

• Each screen identifies itself with its own long random token — no shared credentials between devices
• Every company's screens, content and products are isolated from every other company's
• Per-tenant API keys, rate-limited, for backend-to-backend content pushes
• Screens re-check for updates on an interval designed to stay light even at very high device counts
• Database lookups indexed by company and by screen from the start

Real, verifiable controls — not a checkbox exercise.

Every measure below is live in the product today, not a roadmap item. We'd rather list fewer things and have every one of them be true than pad this section — this matters most for the one integration operators are trusting us with: the content-feed API tied to their own systems.

• API keys are never stored — only a one-way hash, the same principle as a password. A database breach alone can't be used to push fake content.
• An API key is shown in full exactly once, at creation or regeneration, and never again — the same model GitHub, AWS and Stripe use for their own secrets
• Every feed call is logged and visible to that operator in their own dashboard — see exactly what your integration has done, not just trust it blindly
• A strict Content-Security-Policy blocks inline script execution outright — the standard defense against cross-site scripting, not just a header set and forgotten
• All traffic enforced over HTTPS in production (HSTS), with standard hardening headers on every response
• Every dashboard action is protected against cross-site request forgery (CSRF)
• Passwordless login — a one-time emailed link, so there's no password to leak, reuse, or brute-force
• Every database query is parameterized — no string-built SQL, anywhere
• Strict multi-tenant isolation — every lookup is scoped to the requesting company; there is no query path from one operator's session to another's data
• Rate limiting on every sensitive endpoint: login, device pairing, and the content-feed API itself