Going live

Moving from test keys to real people. Work through this once and the switch itself is a configuration change.

Before you switch

1 · Your integration survives the unhappy paths

Test verifications are free, so exercise every branch before real users find them:

• A user who abandons the flow and never returns.
• A user who denies consent.
• A duplicate callback — the same code delivered twice.
• A state mismatch. Your code must reject it.
• A 503 from the provider. Your users should see “try again shortly”, not “verification failed”.
• A 429. Your retry should back off with jitter.

2 · Claims are read defensively

Never assume a claim is present — consent and entitlements both vary. Confirm your code degrades gracefully rather than throwing on a missing key. See Claims & identity keys.

3 · The identity key is stored and indexed

It is your handle on this person for as long as they have an account. Store it against your user record and index it — that index is what makes duplicate detection and returning-user recognition possible later.

4 · Nothing sensitive reaches your logs

Grep your own code before you ship. None of these belong in a log line, at any level:

# API keys
grep -rn "sk_live\|sk_test\|EMNET_API_KEY" src/ --include=*.java

# Whole response objects, which contain claims
grep -rn "log.*VerifiedIdentity\|log.*identity\b" src/ --include=*.java

# Exception bodies from the SDK
grep -rn "e.body()\|getBody()" src/ --include=*.java

5 · Secrets come from a secret manager

Live keys must not be in source control, a container image, or a config file baked at build time. Load from the environment or a secret manager, and fail fast at startup if the key is missing — a service that starts without its key will fail every verification instead.

String apiKey = System.getenv("EMNET_API_KEY");
if (apiKey == null || apiKey.isBlank()) {
    throw new IllegalStateException("EMNET_API_KEY is not set — refusing to start");
}

6 · Redirect URLs are registered for production

Your live redirect URL must be registered on your account and served over HTTPS. Register it before you switch keys, or the first live verification will fail at the redirect.

Making the switch

1. Request a live secret key by writing to sales@emnetid.com.
2. Store it in your production secret manager.
3. Deploy with the new key — behind a feature flag if you can, so rollback is instant.
4. Verify one real person, ideally someone on your team.
5. Confirm the identity key, claims and assurance level all landed in your database.
6. Roll out to real traffic.

After you are live

• Alert on 401 and 403. Both mean your integration is misconfigured. A revoked or wrong-environment key can otherwise fail every verification for hours before anyone notices.
• Watch your completion rate. A sudden drop is usually a redirect or callback problem, not a user-behaviour change.
• Track 503s separately. They are upstream availability, not your bug — but you want to know.
• Rotate keys on a schedule and whenever someone with access leaves. Request the new key, deploy it, then have the old one revoked — both keys work during the overlap.
• Watch the changelog. Additive changes are safe by design; anything breaking is announced in advance.

Data protection

You are the controller of the personal data you receive. That means keeping only the claims you genuinely use, deleting them when you delete the user, and being able to tell a person what you hold about them. Emnet minimises what it sends you precisely so this obligation stays small.

Accounts entitled to expanded claims need a signed data-processing agreement first. If your use case needs more than the standard set, start that conversation before you build against it: sales@emnetid.com.

Launch checklist

[ ] Unhappy paths tested: abandon, deny, duplicate callback, state mismatch, 503, 429
[ ] state is compared and cleared on every callback
[ ] Claims read defensively — no assumption that a claim exists
[ ] identityKey stored and indexed on the user record
[ ] No API key, claim or identifier reachable from any log line
[ ] Live key loaded from a secret manager; startup fails if absent
[ ] Production redirect URL registered and served over HTTPS
[ ] Alerting on 401 / 403 from the Emnet API
[ ] Staging remains on test keys
[ ] Support runbook: who to contact, what to include, what never to send

Questions before you flip the switch? support@emnetid.com — we would rather review your integration than debug it after launch.