Access Concepts & Portal Terms

Lexabit's API and its Portal deliberately use different words for the same things. The API names mechanisms (sponsored, delegated, "App", "Connector"); the Portal names outcomes in plain language, because the person reading it is a lawyer or an office manager, not an integrator.

That is a good split, but it leaves you with a translation problem: your integration reads a JSON field, and your user reads a sentence — and support conversations happen in the user's words, not yours. This page is the bridge. It explains the underlying model, then maps every concept to the exact term your user sees.

Internal names never change

Nothing here renames anything in the API. sponsored, delegated, App, Connector and the rest are stable and will keep appearing in payloads exactly as documented. Only the user-facing words differ — this page tells you which is which.

The underlying model

The objects

Five object types carry all platform access. Four of them come from the OAuth flow:

Connector  ──(user consents)──▶  Connection  +  App  ──(token mint)──▶  Token
"the doorway"                    "the record"  "the actor"              "the credential"
holds no access                  grants nothing  holds the roles         bound to one App
                                 by itself       on one entity

• A Connector is your product's OAuth client registration — branding, redirect URIs, credentials. It is a doorway, not an identity: it never authenticates against the platform and holds no access of its own.
• A Connection is the durable record that a specific user authorized your Connector on a specific entity. It is the audit and revocation ledger — it grants nothing by itself, and it survives revocation as history.
• An App is the machine actor that authorization mints. It holds the granted roles on exactly one entity. This is what your token acts as.
• A Token is bound to one App. Isolation is structural, not conventional: one token, one App, one entity.

The fifth is the odd one out — a personal access token is minted on the user, not on an App, and therefore has full identity parity with that user. See Personal Access Tokens.

For the complete flow, see Connectors & OAuth.

Two independent axes

The two fields that most often confuse integrators, sponsored and delegated, answer completely different questions. They are orthogonal: any combination is meaningful, and neither implies the other.

Field	Question it answers	If true
sponsored	Whose is it? — ownership and lifecycle	The connection belongs to the member who created it, and ends automatically when that member's own access to the entity ends
delegated	What can it see? — visibility	The App sees what the consenting user sees, within the consented scope

Neither field affects what the App may do. Actions are governed only by the App's own granted roles, on every combination — see Permissions for the layered model these plug into.

The mapping

Every row carries its own anchor, so you can link a colleague straight to one term — row 3 is /docs/concepts/access-vocabulary/#row-connected-tool, and so on for each row- id below. The terms that come up most often also have their own notes further down.

#	Internal / API name	Portal term (EN)	Portal term (NO)	Developer definition	Portal phrasing to quote to a user
1	Connector (the doorway) and the connection-born App it produces at consent. No API field names the pair as a unit — read app.name / app.logoUrl on a connection, or connector.name on the grouped view.	(no generic noun)	(same)	The OAuth doorway and the single-entity machine actor it produces. Neither is ever surfaced as an object in the Portal — only the partner's own product identity is.	n/a — render app.name / connector.name directly; never a category word like "App".
2	Connection, API field sponsored: false (or absent)	Integration	Integrasjon	An entity-owned installation. Revocation is gated on the apps.manage permission against the connection's own entity (never the app's), and the installation survives the grantor leaving.	Row/heading: "Installed for {scope}." · Section heading: "Integrations"
3	Connection, API field sponsored: true	Connected tool	Tilkoblet verktøy	Owned by the sponsoring member; auto-revokes in full when the sponsor's own access to the entity lapses — a scheduled sweep plus a same-request fast path that rejects use immediately. Orthogonal to delegation.	Row: "Stops automatically if you leave {scope}." · Section headings: "Connected by you" (profile), "Member-connected tools" (Access Management)
4	Delegation record, API field delegated: boolean on a connection	(no noun — a standardized sentence instead)	(same)	A visibility-only lend — the visibility layer of the access model — with zero action authority; never mixed into permission resolution. Independently withdrawable via DELETE /oauth/v1/consents/{id}/delegation, and it dies automatically if the delegating user's own access dies.	"Sees Lexabit as you do" (EN) / "Ser Lexabit slik du gjør" (NO) — one canonical phrase, reused verbatim in consent, every row, the detail drawer, and the post-consent confirmation.
5	revocation_reason (recorded server-side on every revocation; not exposed on the connection payload)	(not surfaced in copy yet)	(same)	Distinguishes why a connection ended — sponsor lapsed, self-revoked, administrator-revoked, and so on.	None yet — revoked-row copy deliberately avoids asserting a reason it does not have.
6	ApiApp where connectorId == null (self-created via apps/v1)	Application (within "Developer access")	Applikasjon	A self-service machine identity: own keys, own roles, suspend/reactivate/destroy lifecycle. Unlike row 1, the user consciously created and named this object.	Section heading: "Developer access"
7	PersonalAccessToken, kind='pat'	Personal access token	Personlig tilgangstoken	A token minted on the user record — full identity parity, and not scoped to one entity, unlike an App.	Already user-facing wording; quote it as-is.
8	Consent submission field sponsored: false, echoed on management surfaces in the past tense	Installed for {org}	Installert for {org}	The tense-shifted echo of the consent screen's own "Install it for {scope}" — the same words carried through, deliberately.	The same string, used directly as row and drawer copy.
9	Consent submission field sponsored: true, echoed on management surfaces in the past tense	Connected by you	Tilkoblet av deg	Echoes consent's "Connect it for myself in {scope}."	The same string; reused verbatim as the profile section title.
10	granted_by_name / granted_by_email (grantedBy on the wire), revoked_by_name / revoked_by_email	Authorized by {name}	Autorisert av {name}	Audit snapshots, never control — they persist past the acting user's own erasure on organization-scope rows.	Already user-facing wording; quote it as-is.

Rows 2, 3 and 6 each also carry the Access Management section heading they head up — "Integrations", "Member-connected tools", "Developer access" — folded into the row for their own concept, since a section heading has no API anchor of its own.

Norwegian terms

The Norwegian column is the Portal's own shipped wording, included so you can support Norwegian-speaking users in their own words. This page itself is published in English only.

Term notes

Four of these come up in nearly every integration conversation, and each has a way of going wrong that the table alone does not warn you about.

Delegation

Delegation lends sight, never authority. An older generation of our docs and UI called it "acting on your behalf" — that wording is retired, because it described an authority the mechanism never grants. A delegated App with viewer roles sees everything the user sees and can still change nothing. If you find yourself explaining delegation with the word "acts", you are describing something Lexabit does not do.

The practical consequence: do not size your integration's capabilities by what the user can do. Size them by the roles you requested, and use delegation only to widen what you can read.

Connected tools and integrations

Both are connections; the difference is who owns it, and ownership decides how it dies. An Integration (sponsored: false) belongs to the organization and outlives the person who authorized it. A Connected tool (sponsored: true) belongs to that person and ends automatically when their own access to the entity ends.

The trap is the second case: your integration can lose access with no revocation event, no webhook, and no user action — because someone changed jobs. Handle a suddenly-invalid token as a normal lifecycle event, not an error state.

Connectors and apps

Your users never encounter either word. They see your product's name and your logo, and nothing else — so a support instruction like "go and remove the App" will not match anything on their screen. Tell them to look for your product's name under Connected by you (their own) or ask an administrator to check Integrations or Member-connected tools (the organization's).

Personal access tokens

The one term that is identical on both sides, so you can safely use it in support conversations. What matters here is not the vocabulary but the boundary: a PAT is the user, with no way for them to constrain it. Asking a user to paste one into a service you host is asking for their whole identity. Use delegated access instead.

From a field to a sentence

The Portal never shows sponsored or delegated as labels. It composes one plain-language summary line per connection instead, from the terms above. For a connection the signed-in user authorized themself, the four combinations read:

sponsored	delegated	What the user reads (EN)	What the user reads (NO)
false	false	Installed for {scope}.	Installert for {scope}.
false	true	Sees Lexabit as you do.	Ser Lexabit slik du gjør.
true	false	Stops automatically if you leave {scope}.	Stopper automatisk hvis du forlater {scope}.
true	true	Sees Lexabit as you do · Stops automatically if you leave {scope}.	Ser Lexabit slik du gjør · Stopper automatisk hvis du forlater {scope}.

Administrators reviewing a colleague's connections see the same sentences with the member's name in place of "you". Revoked connections switch to the past tense and restate ownership, because once a connection is dead, what kind of thing it was becomes the more useful historical fact.

This is the practical payoff of the mapping: when a user asks "why can this tool see my client list?", the answer is already written — it is the sentence on their own screen, and it corresponds exactly to delegated: true.

What the consent screen asks

The user does not choose sponsored and delegated as two separate questions. The consent screen presents one required three-way choice, and your two booleans are derived from it:

The user chooses	sponsored	delegated
For everyone at {scope} — an integration the organization relies on	false	false
My own tool — with its own view (only the access listed on the screen)	true	false
My own tool — seeing my view (everything they can see in the scope, including what colleagues and clients shared with them personally)	true	true

The third option appears only when your Connector requested delegation. Nothing is preselected: the user must actively choose before the approve button becomes available, and the choice itself is the act of consent.

Organization install plus delegation is not offered

The combination sponsored: false + delegated: true — an organization-owned installation that also carries one person's view — remains legal in the API, but the consent screen does not offer it. If a user picks delegated access, the resulting connection is theirs, not the organization's, and it ends when their own access ends. Do not build a flow that depends on reaching that combination through the standard authorization flow.

Whichever option the user picks, no option changes what your integration can do. Actions stay bounded by the roles they granted; the only variable is how much it can see.

The scope parameter

scope on GET /oauth/v1/authorize is a space-delimited list of three kinds of token:

Token kind	Example	Notes
Role keys	viewer	The roles your App receives, capped by what the consenting user can themself grant
Capability keys	e.g. companies.search (illustrative — not a fixed list)	Only capabilities currently exposed for consent are accepted; the exposed set is operator-managed and can change
The literal delegate	delegate	Requests delegated access; only accepted if your Connector is enabled for delegate mode

So scope=viewer delegate requests the viewer role plus delegated access.

Unrecognized or no-longer-exposed tokens are dropped silently

A token that is not a recognized role key, a currently-exposed capability key, or delegate is discarded without an error — this applies equally to a typo and to a role or capability that Lexabit has since stopped exposing for consent. The user then sees a consent screen missing that grant, and your integration gets a connection narrower than you designed — indistinguishable from the user declining something.

delegate is the one exception that fails loudly: requesting it from a Connector without delegate mode returns error=invalid_scope rather than downgrading quietly. A request whose scope tokens resolve to nothing at all also fails loudly the same way, rather than proceeding with an empty grant.

Verify what you actually received after the token exchange rather than assuming your requested scope was granted in full. The discovery document at /.well-known/oauth-authorization-server is the live source of truth for the valid role scopes, published in scopes_supported (cached for up to an hour — see Discovery); consentable capability keys are not published machine-readably yet, so confirm them with Lexabit when you register. See Policy changes for what happens when the exposed set changes under you.

Where to go next

• Connectors & OAuth — the full authorization flow.
• Delegated Access — the visibility axis in depth.
• Personal Access Tokens — the "is you" credential, and when not to use it.
• Connecting an MCP — the same flow for AI assistants.
• Permissions — the layered access model all of this plugs into.