App and API security

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.

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.

• Access tokens expire after one hour.
• Refresh tokens expire after 180 days without use.
• Authorization codes expire after 10 minutes.
• Tokens and codes use 256 bits of random input.
• Reusing a rotated refresh token revokes its whole token family.

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.