How they fit together
Auth models
Each integration declares one auth model. The catalog lists the model per integration.
Each integration’s setup guide names the exact environment variables, where to create the credentials, and how to get a test or sandbox account. Set them per environment as described in Connect an integration; locally they come from the project’s
.env file (see Configuration).
Managed and bring-your-own OAuth apps
For user-authorized OAuth integrations, Veryfront can host a managed OAuth app so a project connects without creating provider credentials. Credentials resolve in a fixed order: credentials stored on the project integration first, then<NAME>_CLIENT_ID and <NAME>_CLIENT_SECRET project environment variables, then the managed app. Your own OAuth app always wins over the managed one.
Bring your own OAuth app when you need provider verification under your name, custom consent branding, or scopes the managed app does not request. If Connect fails without project credentials, no managed app is configured for that provider yet; create your own OAuth app from the integration’s setup guide.
Availability
Integrations are either available by default or experimental. Default integrations appear in every project. Experimental integrations are hidden until the project setsVERYFRONT_EXPERIMENTAL_INTEGRATIONS to all or to a comma-separated list of integration names.
Tools and write access
Integration tools are the actions agents call: list invoices, send a message, create a record. Tools that change external state are marked as write tools. Read tools are safe to call when verifying a new connection. Connect only the services a project needs. Review connected accounts when project ownership or permissions change.Related
- Integration catalog: Every integration with auth model and tool count.
- Connect an integration: Steps to connect a project to a service.