How does Ergoport work?

Ergoport is a pure play transmission layer — not an age verification provider. We do not verify identity. A third-party verification provider (currently iDenfy) performs the actual identity and age check.

Ergoport receives only the verified output — a boolean confirmation — and stores it as a portable, user-owned credential with the user's explicit consent. When a user visits a platform that has integrated Ergoport, they choose to share their verified status. Ergoport transmits a signal to the platform. The platform receives verified true or false. No identity data passes through the platform.

Ergoport deliberately stores the minimum possible. We never receive or retain the underlying identity documents, face images, date of birth, or any personal data used in the verification process. That data stays with iDenfy.

What we store: a verified status flag, an encrypted device-bound credential, and a SHA-256 lookup hash of the user's email (never the raw email). A breach of Ergoport's servers reveals no usable identity data.

One script tag and a postMessage listener. Most platforms are integrated in under an afternoon. There are no backend changes required for the basic integration — the widget handles the entire flow on our side.

If you want to pass data-email-hashfor identity-linked flows, you'll need to generate a SHA-256 hash of your user's normalised email on your backend. That's typically a few lines of code.

HEAA (Highly Effective Age Assurance) is required for platforms hosting primary priority content under the UK Online Safety Act — adult content, and AI companion platforms with explicit modes. HEAA verification is app-only. Users enter a TOTP code from the Ergoport app. No mweb path is offered.

Standard (Non-HEAA)is for platforms with a duty of care obligation that doesn't reach the HEAA bar — social media, gaming, AI companions without explicit modes, and similar. Three verification paths are available: Ergoport app, ergoport.com/verify, or email OTP.

Your platform type is set at onboarding and tied to your API key. The widget reads it automatically — you cannot change it at runtime.

The anon flow is triggered when you don't pass data-email-hash. No identity is claimed. The user simply proves they are a real human on a real device — a deterministic human presence signal.

Use it for: bot detection, CAPTCHA replacement, pre-login age gates where you don't yet know the user's email, and any scenario where you need a human presence signal without identity verification.

The anon flow returns human_verified: true with a 1-hour expires_at token. The user enters a session code via app or mweb. HEAA platforms can also use the anon flow — app only in that case.

Ergoport requires a standardised lookup hash: SHA256(lowercase(trim(email))). You must normalise the email — lowercase and trim whitespace — before hashing.

Never send the raw email address. Ergoport never stores raw emails and does not accept them as input. The SHA-256 hash is the only email-derived data we accept from platforms.

For returning users, pass both data-email-hash and data-consent-ts (the Unix timestamp from their original consent event). The widget detects this and renders a re-verification flow.

Ergoport issues a session token with an expires_at timestamp on returning user and anon flows. Your platform enforces expiry — Ergoport does not fire an expiry event. When you determine the token has expired, re-surface the widget with the same parameters.

HEAA platforms: you decide your re-verification cadence based on your compliance position. Ergoport provides the expires_at timestamp but does not enforce it on your behalf.

Yes — each widget instantiation generates a unique session ID. Multiple simultaneous sessions across different platforms are fully supported by design. There is no collision between concurrent sessions.

If you pass data-session-id in the anon flow, Ergoport echoes it back in the postMessage so you can correlate the verification against your own session record. This identifier is never stored against any user.

No. Ergoport deliberately does not collect, store, or process biometric identifiers. The device binding in our credential model uses a cryptographic token tied to the registered device — not biometric data.

This means Ergoport sits outside the scope of Illinois BIPA, Texas CUBI, and Washington MHMDA biometric privacy laws. It also means a breach of our servers cannot expose biometric data because we never had it.

Blast erasure. When a user deletes their credential, Ergoport broadcasts deletion instructions to every platform that has a confirmed consent record for that user. The platform receives a deletion event and must remove any stored reference to that user's Ergoport signal.

Cryptographically, when the user's credential is deleted, their per-platform consent tokens become dead — they are derived from a salt that no longer exists. Even without a deletion event, the tokens are useless.

No — and this is structural, not a policy promise. Each platform receives a signal derived using a per-platform HMAC salt. The same user produces a different identifier on Platform A versus Platform B. Cross-platform tracking is cryptographically impossible, even under simultaneous breach of both platforms and Ergoport's servers.

Platforms cannot see which other platforms a user has verified on. Ergoport cannot link user activity across platforms either — the salts are generated such that even we cannot perform the correlation.

We are pursuing a legal opinion from Lewis Silkin LLP (London) specifically on this question. Ofcom's HEAA standard is technology-neutral — it requires the age verification method to be technically accurate, robust, reliable, and fair. It does not mandate a specific approved provider list.

Our architecture uses iDenfy for document verification and liveness detection, and transmits the verified result as a portable credential. The specific question we are seeking an opinion on is whether Ergoport's transmission layer role constitutes an age verification provider under the OSA or sits in a different category.

Ergoport's architecture satisfies AGCOM's double anonymity model by design. Resolution 96/25/CONS requires: (1) the verification provider cannot see which platform is requesting the check; and (2) the platform cannot see any personal data — only a boolean.

Our HMAC per-platform salt model ensures iDenfy cannot identify the destination platform, and platforms receive only verified: true/false. We are currently pursuing AGCOM certification and ROC registration with Italian counsel (Portolano Cavallo).

We are pursuing a legal opinion from US counsel on Texas HB 1181 and 23 mirror state laws. Texas requires “reasonable age verification measures” — a technology-neutral standard with no approved provider list.

Our no-retention architecture directly addresses the Texas HB 1181 retention penalty clause: we never retain identifying information used for verification. The underlying verification is performed by iDenfy. Ergoport transmits the result. US counsel's opinion is expected in Q3 2026.

We are actively pursuing IEEE 2089.1 certification from the Age Check Certification Scheme (ACCS) — the international standard for age assurance intermediaries. This certification is recognised across UK, Italy, EU, US, and Australia.

Post-certification, we will pursue UK DIATF 1.0 (DVS register listing) which unlocks GOV.UK Wallet integration, and we will submit our AGCOM Declaration of Conformity for Italy using the same audit report.

No. That is the entire point of Ergoport. You verify once. Your credential is stored on your device. Every time you visit a new platform that has integrated Ergoport, you tap to share your verified status — no document scan, no new account, no starting over.

Think of it as your age credential living in your pocket. You show it when you need to. You decide who you show it to. You can revoke it at any time.

Yes, at any time. Deleting your credential triggers blast erasure — Ergoport sends deletion instructions to every platform you have ported to. Your verified status is removed from all integrated platforms simultaneously.

After deletion, your credential no longer exists anywhere. If you want to use Ergoport again, you start fresh with a new verification.

Only a boolean signal: verified true or false, whether a real human completed the check, and whether the Ergoport app was used. That is all.

The platform never sees your name, date of birth, document number, face image, or any personal information. Ergoport never sends identity data to platforms. The architecture makes it structurally impossible — not just a policy promise.

Verification for users you refer to our network is free — Ergoport subsidises the verification cost on your behalf. You pay only when users from the Ergoport network (referred by other integrated platforms) visit your platform.

Early adopter pricing is available for the first platforms to integrate. Contact us to discuss terms. We are currently onboarding a limited number of early integration partners.

Yes — Ergoport is designed to coexist with other age verification solutions, not replace them. Think of it like payment rails: you might have Stripe and PayPal running simultaneously. Each captures different users.

Ergoport specifically brings users who are already verified on other integrated platforms — zero friction for them, no new verification required. Your existing Yoti or other provider continues to handle new users who aren't on the Ergoport network yet.

Yes — and smaller, founder-led platforms are often our best early partners. You get the same compliance coverage as large platforms with one afternoon of integration work and no upfront cost.

As the Ergoport network grows, your users gain access to a growing pool of pre-verified users from other integrated platforms. The network value compounds over time — early integrators benefit most.