Going live · Okia docs

Work through this checklist before switching real traffic to Okia. Until domain verification passes, your site runs in test mode: 25 users max, a visible banner on the hosted sheet, and no phone scope.

Checklist

1. Verify your domain

Site → Setup → Domain verification: the domain from your redirect URI is already filled in, with its token. Wrong domain? Change it there (pasting the full address is fine — only the host is kept).
Add the DNS TXT record at _okia.<domain> shown in the dashboard, or serve /.well-known/okia-verify.txt with the given token. The WordPress plugin (1.1+) serves that file for you; the JS snippet verifies nothing.
Walk away: Okia keeps checking for 48 hours and the site flips to live by itself — or click "Check now" in Site → Setup to see it happen.
Keep the record/file in place — verification is re-checked weekly; removing it drops you back to test mode.

The hosted sheet shows users your verified domain name. That's an anti-phishing feature — it only works if verification stays green.

2. Lock down origins and redirect URIs

Register every production redirect URI exactly — scheme, host, port, path. No wildcards, no trailing-slash slack.
Register every origin that opens the login popup in allowed origins (exact https://host[:port]).
Remove localhost / staging entries from the production site config (keep a separate site for dev).
Confirm your token exchange runs server-side with the client secret, or PKCE-only if you registered a public client.

3. Test on real devices

Emulators don't exercise real platform authenticators. Before launch:

Real iPhone (Safari): enroll with WhatsApp code → create passkey → Face ID returning login.
Real Android (Chrome): same pass with fingerprint.
WhatsApp code fallback on a device without the passkey (borrowed-laptop scenario).
Popup blocked on desktop → confirm the automatic redirect fallback completes the login.

4. Branding

Upload your logo and set your accent color in Site → Branding; check the live sheet preview in both light and dark.
Heed the contrast guard — an accent failing 4.5:1 text contrast gets flagged; fix it rather than shipping unreadable buttons.
Confirm the sheet header shows the site name your users expect ("Sign in to {Site}").

5. Webhooks

Endpoint is HTTPS, publicly reachable, and answers 2xx in under 10 seconds.
Signature verification implemented and negative-tested: a tampered body and a stale timestamp (>300s) must both be rejected. See webhooks.
Send a ping from the dashboard and confirm it in your logs and in the deliveries view.
Duplicate delivery of the same evt_… id is a no-op on your side.
Someone actually receives token.reuse_detected (alerting, not just storage) — it means a code or refresh token was replayed.
You know where to look when an endpoint starts failing: Site → Webhooks shows the failure and when it started, and an endpoint failing for three days is switched off.

6. Failure paths

Your OAuth callback handles error responses (user cancelled, access denied) with a sane page, not a stack trace.
Your error pages show a support contact so a stuck user can reach a human — login failures are lockouts, not inconveniences.
Org contact email in Settings is a monitored address. It receives every ops alert: a webhook switched off after three failing days, a weekly domain check that failed, a site demoted to test mode, a test site nearing its 25-user cap, and a sign-in still using a rotated client secret. The two that break sign-ins — demotion and webhook disablement — also go to every owner's WhatsApp, so keep at least one owner on a number someone actually reads. One alert per site and kind per day, at most ten per organisation per day.

7. Final sanity

amr checked before sensitive actions if you rely on step-up (see concepts).
Token verification checks iss, aud, exp, and token_use (api-reference).
Client secret stored in a secret manager, not in the repo. Rotation gives a 24h overlap — rehearse it once.