Skip to main content
A provider is trusted application code selected by the final segment of a connection path. Request bodies cannot choose a provider implementation or upload deployment credentials.

Use a trusted provider

Start with a built-in provider when Hookfish already supports the service. The provider owns credential acquisition and refresh. Your trusted application accesses the current credential and passes it to the service’s SDK.

Configure GitHub

Register GitHub with the OAuth application credentials from your deployment environment:
Provider IDs must be non-reserved lower-camel JavaScript identifiers up to 128 characters. Slashes, hyphens, dots, and reserved words such as class are not allowed. Register this callback URL in the GitHub OAuth application:
Set OAUTH_REDIRECT_BASE_URL to the public broker origin in production. Other fixed OAuth providers use the same callback pattern with their provider ID as the final segment.

Make a GitHub request with Octokit

Install the Hookfish SDK in the trusted application that uses the connection:
Pass the GitHub connection path, then request the connected user with the authenticated Octokit client returned by Hookfish:
The first access throws authorization_required when the connection needs consent. Open its authorizeUrl, complete GitHub authorization, and repeat the request. Hookfish keeps the provider token in trusted server code and injects it into Octokit. The same initializer is available as hookfish.provider.github({ connection }).

Authentication and provider inputs

GET /connections/providers describes credential acquisition and provider inputs. The authentication value is either oauth or secret. Each input field declares how Hookfish uses it:
  • identity adds a segment to the connection path.
  • configuration supplies immutable, non-secret connection configuration.
  • scopes requests provider scopes.
GitHub, Linear, and Notion use OAuth and expose optional scopes without connection-specific configuration. The generic mcp provider uses OAuth and requires a resource name and URL, with optional scopes. The generic secret provider requires a credential name and a supplied value. The mcp provider stores its URL as immutable connection configuration. Requested and granted provider scopes are tracked separately and can change only through the authorization lifecycle. Continue with remote MCP servers for the MCP client flow.

Implement a custom provider

Implement OAuthProvider from @hookfish/provider when Hookfish does not include the service. The provider owns the upstream protocol details. Hookfish owns state, storage, encryption, resource authorization, and connection lifecycle.

Required operations

Every OAuth provider must create an authorization request and exchange the returned code.
Keep client authentication, request encoding, response validation, PKCE generation, and error translation inside the provider package.

Optional capabilities

Implement refreshToken when the provider issues refresh tokens. Implement revokeToken when it exposes a revocation API. Hookfish reports these capabilities in provider discovery and invokes them at the appropriate point in the connection lifecycle. Implement isConfigured when provider availability depends on deployment credentials. Register the instance under a trusted provider ID in hookfish.config.ts. OAuthProviderTemplate is reserved for trusted implementations such as mcp that need connection-owned configuration. A lazy ProviderSource remains available for large application-owned catalogs.
Validate every upstream JSON response before returning it. Throw ProviderConfigurationError for invalid local configuration and ProviderRequestError for upstream failures.