API-key risk, OAuth limits, consent, token safety, app review, audit trails, and revocation.
No. Agents and other software must use a personal API key or the same scoped OAuth flow as any other app.
A personal API key acts for its owner and has no per-feature scope picker. OAuth is the safer choice when software acts for other users because each user sees the requested access and can remove it without changing their Graph One login.
It acts as its owner on API routes that accept account access. It has no per-feature scope picker.
Treat the key like a password. Do not put it in browser code, a public app, a prompt, a log, or a shared file.
We use a hash to look up the key and encrypt the stored key value. Rotating it stops the old key and gives the user a new one.
No. An app gets only the named scopes and choices in the user's grant.
We reject an OAuth token on any route that has not chosen to accept OAuth. On an enabled route, we check the required scope before the route runs.
Some scopes also let the user limit access to named tables, boards, folders, saved searches, work domains, or connected accounts. Each token keeps a fixed copy of those limits.
The current scope list is below. A user still has to approve the scopes an app requests.
A scope name sets the broad limit. Resource and connected account choices can make it narrower.
Current Graph One app scopes
|
Exact scope
|
Access
|
Extra control
|
|---|---|---|
read:tables |
Read table metadata, columns, and rows. | The user can limit this to selected tables |
write:tables |
Modify rows, columns, and metadata of granted tables; create new tables (newly-created tables are auto-added to the grant). | The user can limit this to selected tables |
read:boards |
Read board metadata, lanes, fields, cards, and comments. | The user can limit this to selected boards |
write:boards |
Modify lanes, fields, cards, labels, comments, and metadata of granted boards; create new boards (newly-created boards are auto-added to the grant). | The user can limit this to selected boards |
read:folders |
Read folder structure for granted folders. Does not cascade to tables inside the folder — apps need read:tables for those. | The user can limit this to selected folders |
write:folders |
Manage granted folders. | The user can limit this to selected folders |
read:search_histories |
Read granted saved searches. | The user can limit this to selected saved searches |
write:search_histories |
Manage granted saved searches. | The user can limit this to selected saved searches |
read:profile |
Read your basic profile information (name, email, avatar). | No extra picker or approval |
read:people |
Read person profiles in your graph. | The user must choose at least one connected account; Graph One must approve this for third-party apps |
read:organisations |
Read organisation profiles in your reach. | The user must choose at least one connected account |
read:team-people |
Read team-scoped people endpoints for the customer-team domains you grant access to. | The user can limit this to selected work domains; Graph One must approve this for third-party apps |
read:team-organisations |
Read team-scoped organisation endpoints for the customer-team domains you grant access to. | The user can limit this to selected work domains; Graph One must approve this for third-party apps |
read:connection-strength |
Read connection-strength data between you and others. | The user must choose at least one connected account; Graph One must approve this for third-party apps |
write:connection-strength |
Override connection-strength values in your graph. | The user must choose at least one connected account; Graph One must approve this for third-party apps |
read:feed |
Read your activity feed. | No extra picker or approval |
read:sync |
Read sync state (which inboxes/calendars are connected and their last-synced timestamps) for the connected accounts you select. | The user must choose at least one connected account |
offline_access |
Issue a long-lived refresh token so the app can keep accessing your data when you are not signed in. | No extra picker or approval |
execute:search |
Run people and organisation search queries. | No extra picker or approval |
execute:semantic-search |
Run AI-powered natural-language search queries (consumes LLM credits from your account). | Graph One must approve this for third-party apps |
read:investors |
Look up investor profiles and portfolio data. | No extra picker or approval |
read:podcasts |
Look up podcast feeds and known-people on episodes. | No extra picker or approval |
write:linkedin.profiles |
Write LinkedIn profile observations into your graph. | Graph One must approve this for third-party apps |
write:linkedin.positions |
Write LinkedIn role/position observations into your graph. | Graph One must approve this for third-party apps |
write:linkedin.educations |
Write LinkedIn education observations into your graph. | Graph One must approve this for third-party apps |
write:linkedin.connections |
Write LinkedIn 1st-degree connection observations into your graph. | Graph One must approve this for third-party apps |
write:linkedin.messages |
Write LinkedIn message (DM) observations into your graph. | Graph One must approve this for third-party apps |
write:linkedin.reachability |
Write LinkedIn 2nd/3rd-degree reachability observations into your graph. | Graph One must approve this for third-party apps |
The user approves the scopes and, where offered, the specific data sources or items the app may use.
An app cannot add a new scope without sending the user through consent again. Existing tokens do not become wider when a grant grows.
Later, the user can remove a scope, change selected resources or connected accounts, ask for consent again, or disconnect the app.
We review higher-risk scopes before a third-party app can ask other users for them.
The scope table marks each scope that needs our approval. Approval lets the app request that scope; it does not certify the app's full security or privacy program.
Before an app can appear in our marketplace, it must publish a description, privacy policy, terms, install link, logo, an approved scope, and a registered return address. The app maker's policy and terms govern what its service does with data it receives.
We require PKCE, store token hashes rather than plain tokens, rotate refresh tokens, and revoke reused tokens.
PKCE with SHA-256 is required for public and confidential apps. We show a plain token to the client only when we issue it and keep its SHA-256 hash.
We revoke tokens affected by the change and record the app or grant event.
Removing a scope or narrowing a data choice revokes tokens that carry the old access. Disconnecting an app revokes its grant and tokens.
Removing a Google, Microsoft, LinkedIn, or X source also removes it from app grants and revokes tokens tied to it. Account deletion revokes the user's app grants and tokens.
App calls also use account rate and credit limits. Token events stay for 365 days; we keep other app and grant audit events for longer.
