Skip to content
realr

Realr · Developers

Add Sign in with Realr.

One button and you get a real, verified user — no auth to build, no KYC to run. Realr is a full OpenID Connect provider, so your users sign in once and carry their verification everywhere.

Sign in with Realr

Standard OIDC. Your user consents, you get a proven identity + their verification status.

Read trust status

One GET returns a person's public verification claims + trust level as JSON.

Embed a badge

Drop one <script> tag to render a live 'Verified via Realr' badge on any page.

Sign in with Realr

OpenID Connect, out of the box

We're a standard OIDC provider — point any OpenID Connect library at our discovery URL and you're done. The user signs in to Realr, consents to exactly what you asked for, and you get an id_token + access token.

Discovery
https://www.realr.me/.well-known/openid-configuration
Authorization request
GET https://www.realr.me/oauth/authorize
  ?client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.com/auth/realr/callback
  &response_type=code
  &scope=openid profile email trust
  &state=...&nonce=...
  • Default scopes: openid profile email trust — a stable account id, name/handle/photo, email, and verification status. That’s a proven, verified user on day one.
  • One human, one account — dedupe on sub. The sub claim is a stable, unique id for the Realr account — the same person returns the same sub on every sign-in. Store it with a unique constraint and, on sign-in, look the user up by sub and log into the existing account instead of creating a new one. (Like “Sign in with Google”, we guarantee a stable id; enforcing one-account-per-id is the app’s job.) This is what keeps “Verified via Realr” meaning one real person.
  • The user is always in control. The consent screen lists exactly what you’ll see; anything sensitive is opt-in and off by default.
  • Endpoints: /oauth/authorize · /api/oauth/token · /api/oauth/userinfo · /oauth/jwks (RS256).

Trust Status API

Read a profile's verified status

Public data — the same claims a stranger sees on realr.me/{handle}, in machine-readable form. No API key. CORS-open, so you can call it from a browser or your backend.

Request
GET https://www.realr.me/api/v1/trust/vintagevault
Response · 200
{
  "handle": "vintagevault",
  "displayName": "Vintage Vault",
  "accountType": "business",
  "profileUrl": "https://www.realr.me/vintagevault",
  "verified": true,
  "trust": { "level": "established", "label": "Established reputation" },
  "verifications": [
    { "type": "email",         "label": "Email verified",         "since": "2024-09-10T00:00:00Z" },
    { "type": "government_id", "label": "Government ID verified", "since": "2024-09-12T00:00:00Z" }
  ],
  "badges": ["identity_verified", "verified_human"],
  "legalNameVerified": true,
  "memberSince": "2024-09-10",
  "version": "1"
}
  • Claims only. Verification badges + a sentence-form trust level — never a numeric score, never raw ID numbers, dates of birth, or the legal-name value.
  • Privacy carries through. Anything a user keeps private on their profile is absent here too.
  • 404when the handle doesn’t exist or the profile is private. Cached ~60s.

Embed

Drop a live trust badge on any page

One script tag renders a self-contained badge in a sandboxed iframe. No build step, no analytics, no callbacks.

HTML
<script
  src="https://www.realr.me/widget.js"
  data-handle="vintagevault"
  data-variant="reputation"
  data-theme="light"
  async
></script>

Variants: minimal (the verified pill), reputation (adds a trust line), dynamic (profile card with level). Themes: light / dark.

Verify via Realr

Send unverified users to get verified

For a user who isn't on Realr yet, link them into onboarding. They verify once and come back with a profile you can read via the API above.

Link
https://www.realr.me/signup?ref=cuepop

Add ?ref=your-platform for attribution. Once they finish, poll the Trust Status API (or, soon, subscribe to a webhook) to reflect their new status.

Verification claims

What each claim means — and who pays

The trust scope returns realr_verifications (the checks a user has passed) and realr_trust_level. Here's what each asserts, so you can require the level your use case needs.

  • email / phone — a reachable contact (OTP). Anti-spam, not identity.
  • selfie (“real person”) — a live human, liveness-checked. Kills bots and AI fakes.
  • government_id — identity + age (18+) + location, reviewer-matched to the live face. The strongest anchor; the document itself is never exposed.
  • verified_photos — photos matched to the live face. Anti-catfish.
  • gst / company_registration — a registered business.
  • couple_verified — a mutually verified pair.

Requiring a level: read realr_trust_level / realr_verifications and gate on your side — e.g. only let ID-verified users transact. (A built-in “require this verification” step-up is on the roadmap.)

Who pays: identity verification is a one-time paid step for the user, and it’s portable — they verify once and carry it to every platform, so you get a verified user without running (or paying for) KYC per check. If you’d rather remove that friction, you can sponsoryour users’ verification (you cover the fee) — talk to us to enable it.

Get started

Ready to integrate?

We onboard partners directly — tell us your app and redirect URLs and we’ll issue your client credentials. The trust-status API and the embed widget need nothing but a handle and work today.

Talk to us about integrating
Verify a Realr