Developers › Apps & OAuth
Developer Reference Scopes & limits What an application can ask for, what decides whether it gets it, and why asking for more than you can have is not an error. A token's scope is the intersection of three independent limits — the client's, the approving person's, and the workspace's — and any of the three can be the one that removed something. Step 3 of the OAuth journey — read it before you write the authorize URL. The most expensive mistake here is assuming a requested scope is a granted one, finding out after launch, and going back to every customer for re-consent. Next: the authorization code flow , then MCP → Hosted server .
The catalogue Scope What it grants Who can approve it leads:read Scored leads, their scores and summaries — without contact details. Anyone who can read leads: admin, procurement, or an agent for their assigned tags. leads:read.contact The same leads including names, phone numbers and email addresses . Admin only. Deliberately stricter than the console — an agent can see a phone number on screen but cannot hand it to a third party. profiles:read Merged customer profiles across leads — without contact details, and with names redacted from free text. Admin or procurement, and the workspace must have the Customer Profiles API grant enabled. profiles:read.contact The same profiles including names, phone numbers and email addresses . Admin only, and the Customer Profiles API grant. Deliberately narrower than leads:read.contact : a profile spans conversations across groups, so an agent scoped to particular tags can never be entitled to the whole of one. workspace:read Which workspace this authorization acts on, and the person's role in it. Any recognised role, including agent — it discloses nothing the approver cannot already see about themselves. workspace:read.contact Your colleagues' work email addresses and phone numbers , the CRM seat id each one maps to, the notification addresses this workspace routes tagged leads to, and — because both describe an individual rather than the organisation — that person's own working hours and CRM time zone . Admin only. This is the scope that lets an application reach the person it decided should take a lead — without it list_crm_agents can name somebody and give you no way to contact them. The tag addresses are frequently a desk or distribution list rather than an individual, which is what makes them survive a staff change. ⚠ Note the split: a DESK's hours and the WORKSPACE's hours are organisational facts and need no scope at all, but a named person's hours and time zone sit behind this one — without it, people[].availability reports WITHHELD_NO_PERMISSION , which says nothing about whether hours exist. tools:write Describe your own tools, so LeadLogiX reads their calls as structured evidence on this workspace's leads — and check where each submission stands. Admin only, and the workspace must have the Tool submissions grant enabled. It writes into a review queue: a submitted tool stays inactive until LeadLogiX approves it, so this grants the right to ask , never the right to change how leads are scored. automations:run Run the automations this workspace has published to applications , and read the results each one declares. Admin only, and the workspace must have the Automation runs grant enabled. ⚠ This is a write, despite reading like a query. An automation can post to a chat channel, call an outside system, send a message on this workspace's behalf, or move a lead into a paid line of business — so approving it means letting an application make the workspace act , not just look. Two things bound it: each automation is published to applications individually and none is published by default, and a published automation hands back only the specific fields it declares — never its logs, and never anything it happened to read along the way. memory:read Read back the notes this application has saved here itself , and search LeadLogiX's own product documentation . Any role, and the workspace must have the Application memory grant enabled. Notes are keyed to three things together — this workspace, this application, and the person who approved this screen — so an application never sees another application's notes, and never a colleague's. That last part is deliberate: two people at the same company may not be entitled to see the same leads, and notes everybody shared would quietly hand one person's data to the other. The documentation half discloses nothing about anybody: it is the same product manual published on the public site, identical for every workspace, and it is searched rather than changed — there is no way for any application to edit what other workspaces read. memory:write Save notes and searchable documents here for later, and delete them again. Any role, and the workspace must have the Application memory grant enabled. ⚠ This is a write — but the only one any role may approve, because what it touches is the application's own saved notes and nothing else. Nothing this workspace knows is disclosed through it. Notes expire on their own ; documents saved so they can be found by meaning do not — a quota is what bounds those, and the workspace can see and delete every one. How much one application may keep for one person is capped. If you run several assistants and they must not read each other's notes, connect them as separate applications : the grouping label a caller passes is for tidiness, not for keeping things apart. files:read List and read back the files this application has saved here itself. Any role, and the workspace must have the Application memory grant enabled. Files are keyed to the same three things notes are — this workspace, this application, and the person who approved this screen — so an application never sees another application's files, and never a colleague's. files:write Save files here, and delete them again. Any role, and the workspace must have the Application memory grant enabled. ⚠ This is a write , and it is deliberately separate from the notes one: agreeing that an application may keep notes for you is not the same as agreeing it may store arbitrary files, and a single checkbox covering both would be asking you to approve something this screen had not described. ⚠ Files do not expire — a quota is the only thing bounding them, so the workspace's own Application storage page is where you see what is being held, and where you can delete it. identity:lookup Whether the person your application is speaking to matches somebody already in this workspace . You send the identifying signals you have — an email address, a phone number, a device fingerprint — and receive pointers to matching conversations. Never a name, an address or a phone number. Admin only, and the workspace must have the Identity Resolution API enabled. ⚠ This is the one permission where personal data travels towards LeadLogiX rather than away from it: approving it means allowing an application to transmit identified people's contact details here, and to learn which of this workspace's customers they are. That is why it is flagged as personal data even though the answer contains none. OIDC scope Grants Notes openid A stable user identifier, sub Makes the token an identity-plane token — two planes email , profile The approving person's own email and name Never workspace data — the claims are on Sign in with LeadLogiX offline_access Not required A refresh token is issued regardless. Ask for the least you need — a .contact scope costs you consent leads:read.contact and profiles:read.contact send real customers' personal details to your systems, and are shown to the approver on their own line, marked, with a warning. Requesting one you do not need costs you approvals. Without it, free text is redacted before it leaves LeadLogiX — not merely stripped of structured fields.
The three ceilings A scope must survive all of them. 1 · The client Registered What this application may ever request. A curated limit set by LeadLogiX, or — for a self-registered client with no limit — whatever it declared, intersected with the public default. 2 · The approver Role A token can never exceed the person who authorized it. An agent approving a request for contact details grants everything else and not that. 3 · The workspace Grant Some data is off unless a LeadLogiX administrator has enabled it for that workspace — profiles:read is the current example. The public default, and why it is small A client nobody has vetted can ask for leads:read and workspace:read . It cannot ask for contact details: that would put a user in front of a consent screen approving personal-data egress to an application registered two seconds earlier. Widening a specific client's ceiling is a deliberate act by a LeadLogiX administrator.
Asking for more than you can have Not an error. The authorization request succeeds, the consent screen shows the scopes it cannot offer as unavailable, and the token comes back without them. This is deliberate — failing the whole request because one scope was out of reach would break sign-in for every workspace that has not enabled an optional feature. So read the granted scope, every time The scope in the token response is the truth. A client that assumes it received what it requested will call an endpoint it has no authority for and read the resulting refusal as an outage. Introspection ( POST /idp/introspect ) tells you the same thing for a token you already hold.
Review is a badge, not a permission LeadLogiX can mark an application reviewed. That changes what every future consent screen tells a user about it — "Reviewed by LeadLogiX" instead of "Not reviewed" — and it changes nothing about what the application may be granted. The two controls are separate on purpose: vouching for who somebody is and deciding what they may read are different judgements, and collapsing them would mean every trust decision silently widened access. If you need a wider ceiling, ask for the limit — not for the badge Contact support@evas.live describing the data your application needs and why. Being marked reviewed will not give it to you. Every application starts unreviewed, and the consent screen says so — “Anyone can register an application with this name.” That warning protects customers from something impersonating you, so nothing you send removes it; review replaces it with a reviewed badge and your logo.
Scopes can shrink under a live token Authority is re-derived on every request, not frozen at issue. If the person who authorized your application is demoted, loses a capability, leaves the workspace, or the workspace turns a feature off, the token keeps working for whatever remains — and refuses what no longer holds. When nothing remains you receive insufficient_scope with error_reason: no_effective_scope . The inverse is also true and less obvious: widening a grant does not reach an existing token. A customer who gains a capability must authorize your application again before it can use it.