Client ID
Each project gets its own client identifier.
Meld® IDOne account
For project teams
This page shows the technical contract separately from the user-facing portal: client_id, redirect_uri, secret, IP allowlist, and OAuth flow.
Each project gets its own client identifier.
Secrets can be rotated from the admin area.
Callback URLs are registered ahead of time and matched exactly.
Server-to-server requests can be limited to known addresses.
01
Every project gets its own rules and does not disturb the others.
The project gets a client_id, while the user keeps one identity.
Allowed redirect_uri values are set ahead of time and are not guessed.
The client secret is stored separately and can be reissued.
The integration can be limited to specific IP addresses.
02
Each project asks only for the scopes it needs, and Meld® ID returns only the claims the user approved.
Confirms identity and is needed for the basic login flow.
Returns the confirmed email and its verification status.
Broad profile scope. It covers profile.basic, profile.contact, profile.address, and profile.billing.
First name, last name, display name, birth date, and language.
Phone number for contact and verification.
Home or delivery address without payment data.
Billing name, company, and tax details. No cards are transferred.
03
First authorization, then code, then token exchange, then the project’s local session.
The user opens Meld® ID and approves the project login.
After consent, Meld® ID issues an authorization code for the registered redirect_uri.
The project exchanges the code for an access token and receives userinfo.
04
We check redirects, secrets, and IP allowlists without guesswork.
The match must be exact, with no arbitrary variations.
The server verifies the secret separately from the browser login.
The admin area shows who goes where and where the chain breaks.