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.
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 }).
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.