Skip to content

Realr for developers

Add Sign in with Realr.

One button gives you a real, verified user. No sign-in to build and no ID checks to run. Realr is a full OpenID Connect provider.

Talk to usRead the docs

On this page

What you can build.

  • Sign in with Realr

    Standard OpenID Connect. Your user agrees, and you get a verified person and the checks they have passed.

  • Read what someone has verified

    One GET returns a person's public checks as JSON.

  • Show a verified badge

    One <script> tag renders a live “Verified via Realr” badge on any page.

  • What your app can't do

    The limits, written for your security review.

Sign in with Realr

Add the sign-in button

Point any OpenID Connect library at our discovery URL. The user signs in to Realr, consents to exactly what you asked for, and you get an id_token and an 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. Read the returned verification claims before deciding which features the account can use.
  • One person, 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 what someone has verified

Public data: the same checks a stranger sees on realr.me/{handle}, as JSON. 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 and 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.
  • 404 when the handle doesn’t exist or the profile is private. Cached ~60s.

Website badge

Show a verified badge on your site

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 users to get verified

For a user who isn’t on Realr yet, send them to sign up. They verify once and come back with a profile you can read with 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.

Checks

What each check means, and who pays

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

  • email / phone: a working email or number, confirmed as theirs. It stops spam. It does not prove identity.
  • selfie (“Real person”): a real person was there for the check. Read it as one check, never as a guarantee.
  • government_id: identity, over 18 and country from one reviewed document. The strongest check. The document itself is never shown.
  • verified_photos: photos Realr has checked are really the account holder.
  • gst / company_registration: a registered business.
  • couple_verified: two verified people who confirmed each other.
  • 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: basic identity verification is free for the user. Read the returned claims to determine which checks they have completed. Contact us about integration requirements; signing in does not imply every check is complete.

Limits

What your app can’t do.

The same limits apply to every app that uses Realr.

You can’t match your users with another app’s

Every app gets its own opaque subject ID for the same person. Two services that both use Realr, comparing their full user tables, cannot find a single row in common. Realr is not a correlation key.

You can’t get more than the user agreed to

The consent screen splits what your flow needs from what is optional, and a person can decline the optional half and still connect. Scopes are checked against what Realr approved for your client; a tampered form cannot grant more.

You can’t read an ID, a legal name or a date of birth

Realr returns claims, never the underlying values. “Over 18” is a claim; a date of birth is not on offer at any tier.

Every use is logged

Every consent, token and read is logged by scope name, and never by value: an audit trail holding the email it released would be a second copy of the data it exists to police.

Existing integrations predating pairwise subjects keep the subject they were issued; moving one is a coordinated change, never a silent re-key.

Get started

Tell us about your app.

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