OAuth reference

This reference covers OAuth permissions, shared data, token handling, and client implementation. MCP uses Streamable HTTP to carry requests; OAuth controls how a client obtains permission to make them.

How OAuth requests are authorized

1. You approve a connection. Sign in to DataFast and select websites and permissions. DataFast saves that approval against your account and the OAuth client.
2. The client receives a token. The token identifies that saved connection. It does not contain your password or give the client your existing API keys.
3. MCP verifies each request. DataFast checks the token's expiry, its intended MCP endpoint, whether the connection is still active, the requested permission, and your current membership of the approved websites.
4. The existing API handler checks access too. The MCP tool calls the same handler used by the corresponding REST endpoint, with the identity and permissions verified by DataFast. The handler still enforces its authorization, validation, rate limits, and applicable plan restrictions before returning data.

For example, a connection approved to read Website A cannot fetch Website B by changing a website ID, or write to Website A without write permission and a suitable current role. Removing your membership of Website A also removes that connection's access to it.

DataFast does not exchange OAuth tokens for a master API key. The verified identity is passed inside the server for that request. OAuth tokens cannot authenticate directly to the public REST API or sign in to the dashboard.

Manage a connection

Only selected websites are included. Websites added elsewhere are not shared automatically. If you approve website creation, a website created through that connection is added to its approval. Account-only permissions can be approved without selecting a website; that does not grant access to existing websites. Your active API access, website membership, team role, and each feature's plan restrictions still apply. For example, Starter social mention limits and owner-only Bot traffic controls also apply through OAuth.

Permissions and shared data

The realtime widget groups visitors by coordinates rounded to 0.1 degrees and country. It excludes visitor IDs, paths, conversion predictions, names, and profiles. Geographic accuracy depends on the location data available to DataFast.

Custom goal parameters, chart notes, recorded paths, and alert recipients can contain information your site or team deliberately recorded. Grant access only to applications you trust to receive it. Team tools include member names, emails and roles, and require the explicit team scope.

OAuth offers the same DataFast tools as API-token MCP, including account profiles, website creation, API keys, account tokens, and Bot traffic credentials. Each has an explicit permission; there is no wildcard. Sensitive permissions are unchecked by default, and existing connections must obtain fresh consent to add them. Account-wide Bot traffic usage requires approval for every currently owned website.

API keys and account tokens created through OAuth cannot exceed the approved websites and permissions. They remain bound to the original connection: expiration, revocation, account access loss, or loss of website membership disables their access. Account-token listing and deletion exclude tokens outside the approved scope. Website API-key changes and Bot traffic credentials require the current owner role. Bot traffic ingestion tokens only authorize event submission; they do not read analytics and remain valid until rotated or deleted in Bot traffic settings.

Writes and retries

Reuse the same key and identical arguments to retry a write. Completed results are retained for 24 hours within that specific OAuth connection. Changed arguments are rejected. If an attempt's outcome is unknown, DataFast will not execute it again automatically; inspect the website before deliberately issuing a new operation. Revoked or removed website access is checked before a cached result can be returned. Newly issued secrets are returned only on the first successful call and are never saved for replay; a retry reports that the credential has already been issued. Store the first response securely. Child credentials cannot replay their parent connection's results.

OAuth client implementation

These are Bearer tokens, so possession of a valid token permits its approved access. Binding a token to a client and resource does not bind it to one device or prove which application is presenting it. Store tokens securely and revoke the connection if a token is exposed.

Access tokens, refresh tokens, authorization codes, and client secrets are stored as hashes. Codes expire after two minutes and are consumed once. Reusing a consumed code or rotated refresh token revokes the connection. Consent requests expire after ten minutes and are bound to the browser and the signed-in account. Consent pages contain no analytics or third-party scripts.

OAuth tool reference

New tools are excluded until explicitly assigned a permission. The following tools are available, subject to your consent and current website access.