Developers › Apps & OAuth
Developer Reference Sign in with LeadLogiX The identity half of the authorization server. Ask for openid, exchange the code, and call UserInfo to learn who signed in, which workspace they belong to and what they may do there — enough to create an account in your own product without asking them to type anything.
Add it in four steps Identity only. Shorter than the full OAuth journey. Register a client Register a client . Dynamic registration, with your callback in redirect_uris . No approval step. Send them to authorize with the right scopes openid gets you an identity. Add workspace:read if you want to know which workspace they belong to and their role in it — and almost every product does. Send no resource : openid is what makes this an identity-plane token — two planes . Read the claims, not the name sub is the stable user identifier. Map roles with the table below, and check name_verified before trusting a workspace name for anything that matters. Decide what happens on first sign-in Link to an existing account or provision a new one — the last section covers both, including the trap of matching on an unverified email. You can stop here Nothing on this path needs a workspace grant, and none of it reads customer data — you can skip most of Scopes & limits . The runnable client is A complete authorization ; what to build around it is Build on LeadLogiX identity . Want their leads too? That is a second, data-plane authorization and MCP → Hosted server .
Claims Released at UserInfo, per granted scope. Scope Claims Notes openid sub , workspace , role , role_rank The last three additionally require workspace:read to have been granted — see below. email email , email_verified email_verified is omitted if we could not check it. Absent is not false. profile name , given_name , family_name , updated_at Standard OIDC profile claims about the person, not their membership. Declaring a claim is not releasing it workspace , role and role_rank are declared under openid because that is the only place UserInfo will look — it filters to OIDC scopes before resolving claims. They are released only when workspace:read was actually granted and the authorization is still live. Ask for both.
Mapping LeadLogiX roles onto yours role role_rank What it means admin 50 Runs the workspace: billing, members, integrations, configuration. procurement 10 Buys leads and works the clearing pool. agent 10 Works assigned leads. Sees a subset, scoped by tag. Treat the vocabulary as open — map anything you do not recognise to your lowest tier These are the roles a workspace assigns. A token can carry a value that is not among them, and the safe response is always the same: grant your least privileged tier and carry on, rather than guessing from role_rank or failing the sign-in. Never treat an unrecognised role as an administrator because its rank is high. Rank is an ordering, not a hierarchy procurement and agent are both rank 10 and neither manages the other. A role_rank >= 10 test admits both — which is fine when that is what you meant, and a silent privilege grant when you meant "procurement". Compare role when the distinction matters.
Linking to an account you already have Key on sub, not on email sub is stable and belongs to LeadLogiX. An email address can be changed by its owner, and reassigned by an administrator. Require email_verified === true before linking by email If you must match an existing account by email, the claim must be present AND true. Treating an absent claim as false is safe; treating it as true is an account-takeover path. Re-check membership rather than caching it Role and workspace change. Call UserInfo again — or the MCP get_workspace tool, which re-derives on every call — rather than storing a role at signup and trusting it a year later. Identify a workspace by workspace.id , never by its name — typed by whoever registered it and unchecked unless name_verified is true. Provisioning, sessions and staying current: Build on LeadLogiX identity .
Choosing which LeadLogiX account gets connected One browser can hold two LeadLogiX identities. Ask, before you store a subject. LeadLogiX keeps one sign-in session per browser for 14 days . An authorization request that needs no interaction completes against whichever account that session holds — no screen, no chooser. That is ordinary single sign-on, and for a plain sign-in button it is what you want. It stops being what you want the moment you store the subject A person who holds two LeadLogiX accounts in one browser — anybody testing an integration, and any consultant who belongs to two workspaces — gets whichever one is live. If your product then binds that sub to one of your own user records, the wrong identity can be attached permanently, with no error on either side : a subject you have never seen looks exactly like a first connection. Only the person can tell, and only if you ask them. Send prompt=select_account on the authorization request. The consent screen then names the account that is about to be connected and offers Use a different account , which signs them out and returns them to the same pending request. prompt What LeadLogiX does select_account Always shows the screen, names the account being connected, and offers to sign out and come back as somebody else. Use this before you store a subject against one of your users. login The same screen, framed as “confirm it is you”. Use it when you want the person re-checked rather than offered a choice. consent Always shows the screen, even for an application this person already approved. none Never shows a screen. Answers login_required , interaction_required or consent_required at your redirect URI instead of prompting. Must be sent on its own. Read the supported list, do not probe for it The authorization-server metadata publishes prompt_values_supported . Any value outside it is refused with invalid_request and unsupported prompt value requested , delivered to your redirect URI — which is easy to mistake for a problem with the rest of your request. A forced consent supersedes the last one — and revokes its tokens select_account and consent show the screen every time, and approving creates a new authorization that replaces the previous one. Any access or refresh token issued under the old one stops working: the next call answers 401 with error_reason: grant_missing , and a refresh answers invalid_grant . For an interactive sign-in that is harmless — you have just been given a newer token. It is not harmless if the same client_id also holds a long-lived token doing background work: asking a person to confirm their identity would cut that off. Use a separate client for the flow that asks, or send no prompt on the flow that must not be interrupted. ⚠ And the supersede stands even if your own flow then fails. Once the person approves, the new authorization exists — whatever your application does next. If you take the code and your own account-linking step rejects it (because that identity is already attached to a different user of yours, say), the previous authorization is still gone. The visible outcome is a link that failed and a background token that stopped working, with nothing in between to connect them. An account switch adds a hop to the redirect chain When somebody approves as a different account from the one the browser session holds, LeadLogiX ends the first sign-in before completing the authorization. A browser follows that automatically. A server-side harness that stops at the first non-redirect response will see it as a dead end — follow it, and the code arrives at your redirect URI as usual.