Who can create connectors
Creating connectors requires the workspace admin or owner role, and is available on all plans. Connectors you create are scoped to a single workspace: they appear in that workspace’s connector catalog and are not visible to other workspaces. Once created, workspace members connect to your connector the same way they connect to any other app + chat connector.How to create a connector
You define the entire connector in a single form with three sections, Details, Authentication, and Agent knowledge, opened from the + button in the connector catalog:Open the create form
Describe your connector
- Display name: the name users see in the catalog. Use the name of the API the connector reaches (for example,
Acme Projects API). The connector’s internal ID is derived from this name and can’t be changed later. - Short description: a one-line summary (for example,
Project management boards). - Description: a longer explanation of what the connector does.
- Logo (optional): select Upload logo to add the logo users see in the catalog.
- Category: where the connector appears in the catalog (Productivity, Sales, Marketing, E-commerce, Support, Messaging, Development, Payments, or Other).
- Documentation URL (optional): a link to the API’s documentation.
Choose an authentication method
Set the API base URL and test request
- API base URL: where requests are sent. Must be an
https://URL. - Under Test request, a Method and Path: an endpoint Lovable calls to verify credentials when a user connects (for example,
GET /v1/me). The path must start with/.
Add knowledge (optional)
Create the connector
Authentication methods
Pick the method that matches how your API expects credentials:Setting up OAuth 2.0
For APIs that use OAuth 2.0, configure:- Authorization URL and Token URL: your provider’s OAuth endpoints (both must be
https://). - Scopes (optional): one per line, or separated by spaces or commas.
- Scope separator (optional): leave blank for the default (space). Some providers require a comma.
- Use PKCE: enable if your provider supports or requires PKCE (Proof Key for Code Exchange), an extension that adds an extra verification step to the authorization flow.
Writing connector knowledge files
Connector knowledge files are how Lovable learns to use your API. Without them, Lovable only knows your base URL and authentication method, so it has to guess endpoint paths, parameter names, and response formats. A good knowledge file removes the need to guess, so treat it as documentation written for Lovable rather than for humans. They are separate from workspace and project knowledge: connector knowledge is part of the connector definition and only covers how to call its API. Each knowledge file has three parts:- Name: a short identifier (for example,
Acme Projects API basics). - Description: a one-line summary of what the file covers, so Lovable picks the right file for the task (for example,
Endpoints and request formats for reading and writing Acme Projects boards and tasks.). - Content: the actual instructions, in Markdown, including the endpoints, examples, and caveats.
What to include
Follow the same structure Lovable uses for its built-in connectors:- A one-line summary of what the API does and what it’s for.
- Key endpoints: method, path, and what each does. Use paths relative to your API base URL (for example,
GET /v1/tasks). Lovable routes requests and attaches credentials automatically, so don’t hardcode full URLs or authentication headers. - Request examples for the most common operations, as code blocks. Show the exact request body, required parameters, and query options.
- Response formats: mention wrappers and field names Lovable should expect (for example, “responses are wrapped in a top-level
datafield”). - A notes section for details that commonly cause integration errors: pagination parameters, rate limits, API versioning in paths, async operations, and date or ID formats.
What to leave out
Some content does not belong in knowledge files:- Credentials or secrets: never put tokens, keys, or client secrets in knowledge content. Authentication is configured separately and injected automatically.
- Authentication boilerplate: Lovable doesn’t need instructions for attaching credentials. The connector handles it.
- Marketing copy: promotional language does not help Lovable call the API. Keep knowledge files technical and factual.
Example
A knowledge file for the fictionalAcme Projects API, a project management API:
Using your connector
After creation, your connector behaves like any other app + chat connector:- Users open Connectors, find your connector in the catalog, and select Add connection.
- They enter the credential values you defined (an API key, username and password, or OAuth Client ID and secret). For OAuth connectors, a popup runs the authorization flow with your provider.
- Under Who can use this connection, they choose who can use it: only themselves (the default), specific people, or the entire workspace. See Who can use connections and clients.
- Lovable verifies the credentials by calling the test request you configured.
- Once connected, the connection can be linked to projects, and Lovable can build apps that call your API, guided by any knowledge files you added.
Managing connectors
Workspace admins and owners manage the connectors created in their workspace from Connectors → Admin settings → App + chat connectors, under Custom connectors. The admin settings area is available on Business and Enterprise plans:- Availability: control who can create connections (No one, Editors & admins, or Admins), the same way as for any other connector. A newly created connector starts at Admins. Free and Pro plans have no picker: any workspace member with the editor role or higher can create connections. See Manage connectors in your workspace for the defaults on each plan.
- Edit: update the connector’s details, endpoint, knowledge, and authentication configuration. Some authentication changes are restricted because existing connections store credentials in their current structure: a connector can’t switch between OAuth 2.0 and credential-based authentication, and existing credential field keys are locked. You can still switch between the single-credential methods (bearer token, custom header, or query parameter), or move any credential-based method to Advanced.
- Delete: remove the connector definition from the workspace.
Security
Custom connectors follow the same security model as built-in connectors, described in Integration security:- Credential values are entered only when a connection is created, and are stored encrypted by Lovable. They are injected into requests server-side by the connector gateway, and never appear in chat or in project code. Members with access to a connection can view its configuration, where secret values appear masked.
- Workspace-shared connections can be used by other members of the workspace, so only share connections whose data you’re comfortable making available to your team.
FAQ
Do workspace members need their own account with the API?
Do workspace members need their own account with the API?
Can I change the authentication method after creating a connector?
Can I change the authentication method after creating a connector?
What happens when I delete a custom connector?
What happens when I delete a custom connector?
Who can see the credential values users enter?
Who can see the credential values users enter?