Integrate a provider

A provider adapter publishes an AI provider to Bricoop so every connected application can reach its models. The adapter declares how to authenticate, which models and services the provider exposes, and which capabilities each model supports. Once published, every supported application can use the provider without per-application glue.

The adapter boundary

A provider adapter is auths[] (how to sign in), models[] and services[] (what the provider serves), and the capabilities each model supports. Bricoop normalizes incoming application requests to this boundary, routes them to the provider, and normalizes the response back to a shape every application expects. The adapter never sees application-specific logic and never stores application config; it only translates between the provider’s API and Bricoop’s protocol.

Before you start

Confirm you have a stable id for the provider, the full set of authentication methods the provider supports (such as api_key, oauth, or device_code), and the list of models and services the provider exposes. You also need the capabilities each model supports so Bricoop can negotiate them with applications. See the provider authentication page for how each method maps to an auths[] entry.

Publish

Author the provider manifest as a stable YAML file with metadata describing the provider, then submit it to bricoop-releases following the registry contribution guide. The repository’s validation runs before the PR can merge, so fix every reported issue before requesting review. On merge, a release manifest is published and Bricoop Desktop picks it up; users can then connect the provider and route it to any supported application.