Apply for API credentials through the ID.me developer portal at developers.id.me; you will receive a client_id and client_secret scoped to one or more verification policies (e.g., identity, military, student).
Redirect the user to the ID.me authorization endpoint with response_type=code, the relevant scope (openid and the policy-specific scope), redirect_uri, and state.
After the user completes identity or community verification on ID.me, receive the authorization code at your redirect_uri and exchange it at the token endpoint for an access token and id_token.
Call the userinfo endpoint with the access token to retrieve verified attributes; the payload includes verified status and the group or community affiliation (e.g., military, veteran) depending on the requested policy.
Validate the id_token signature using the ID.me JWKS endpoint, verify iss and aud, and confirm the sub is stable across sessions for the same user.
Handle the case where verification is incomplete or the user denies consent by inspecting the error parameter returned to your redirect_uri and surfacing an actionable message.
Known gotchas
ID.me operates separate endpoints for identity verification (IAL2-equivalent) and community affiliation (military, first responder, student); requesting the wrong scope returns a verified claim without the group attribute your policy requires.
ID.me enforces a production approval process; credentials obtained in the sandbox environment do not work in production and require a separate production application review.
The verified claim in the userinfo response is a boolean but does not encode the assurance level achieved; integrations that need to distinguish IAL1 from IAL2 must inspect additional policy-specific attributes or use the dedicated trust framework metadata.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp