Authentication

The initial API and MCP pilot uses OAuth authorization code with PKCE for both individual and business Pro accounts. Fisk hosts sign-in and consent. Your application receives a short-lived token for the Fisk research resource.

Prerequisites

• An active Fisk Pro account.
• A pre-registered and enabled OAuth client.
• An exact, registered callback URL.
• The client ID issued by Fisk after registration.

Clients are registered manually with their exact callback URLs. Open dynamic client registration is disabled; entering the server URL in an arbitrary MCP client does not register or enable it. Ordinary Fisk login tokens and OpenID Connect ID tokens are not API access tokens.

Connection URLs

Setting	Value
API base URL	https://api.fisk.co.tz
MCP server URL	https://api.fisk.co.tz/mcp
OAuth resource URI	https://api.fisk.co.tz
Protected-resource metadata	https://api.fisk.co.tz/.well-known/oauth-protected-resource
MCP resource metadata	https://api.fisk.co.tz/.well-known/oauth-protected-resource/mcp
Scope	openid

Authorization flow

1. Read the protected-resource metadata. MCP clients can also use the metadata URL ending in /mcp above.
2. Read its authorization_servers metadata and discover the provider’s authorization and token endpoints.
3. Generate a fresh PKCE verifier, its S256 challenge and a random state. Bind them to the browser session that starts the connection.
4. Request the authorization-code flow with your client ID, registered callback URL, openid scope and resource=https://api.fisk.co.tz.
5. The user signs in on Fisk and approves read-only access.
6. Validate returned state, then exchange the authorization code with the original PKCE verifier. Include the same resource URI.
7. Send the issued access token in an Authorization: Bearer header.

Use your client’s standard OAuth implementation where possible. The resource URI represents the whole API and is shared by REST and MCP; it is not just the /mcp path.

GET /v1/companies?query=KCB&limit=5 HTTP/1.1
Host: api.fisk.co.tz
Authorization: Bearer <access-token>
Accept: application/json

Token handling

Access tokens last at most one hour. Refresh handling is delegated to the authorization provider. Store refresh tokens securely on your backend, rotate stored tokens when the provider supplies a replacement, and serialize concurrent refreshes for the same grant.

Do not send tokens in query parameters, browser analytics, application logs or support messages. Do not forward a Fisk token to third-party services.

Consent and revocation

Users can review their connections in Fisk → Settings → Connected apps. Revoking a connection invalidates its data access at the gateway, including already-issued access tokens.

An expired token can be refreshed through the provider. A revoked connection requires new consent. A disabled client, inactive account or account that no longer has Pro access cannot continue to query using an older token.

Browser integrations

Browser origins must be approved by Fisk. A successful server-side request does not imply that arbitrary browser origins are allowed.

For a brokerage or trading app, connect your designated Pro account from your backend and enforce your own customer authorization. Agree the permitted use and distribution of data with Fisk before serving it to customers.

Business integrations

Businesses initially use the same Pro account OAuth flow, consent controls and shared account quotas as other API and MCP users. The integration token belongs to the designated connected account; do not ask customers to share passwords or expose that token in a browser or mobile app.

There are no organization API keys or client-credentials grants in this release. If your application needs greater capacity or a different access model, discuss it with Fisk before planning a production launch.