---
title: "Lovable integrations: the complete map | Lovable Field Guide"
url: https://prerenderlovable.com/blog/lovable-integrations
description: "Lovable integrations come in six connection types, and picking the wrong one is why wiring fails. What each type does, what exists, and how secrets flow."
lang: en
---

Skip to content

# Lovable integrations: the complete map

Lovable integrations come in six connection types, and picking the wrong one is why wiring fails. What each type does, what exists, and how secrets flow.

Published September 11, 2026 16 min read

Lovable has six kinds of integration, and its documentation organizes them by **connection type** rather than by category like “payments” or “CRM”. Which one you need depends on who owns the credential and whether the capability has to run in your published app or only in the Lovable chat. Most integration problems are category errors: you connected the thing, the chat could use it, and then your published app could not, or you assumed a toggle existed where Lovable actually writes server code that calls an API with a key you stored.

Below is what each type is, who owns the credential, where the capability actually runs, and then a survey of what is available in each (data, auth, email, payments, code, and the MCP layer) with the traps that produce most of the questions.

## The six connection types, in one table

| Type | Credential owner | Works in chat | Works in your published app | Typical job |
| --- | --- | --- | --- | --- |
| App + chat connector | You (one shared account) | Yes | Yes | Send transactional email from your app and from chat. Resend is one. |
| Chat connector (MCP server) | You, personally | Yes | **No** | Give the agent context or tools while you build |
| App user connector | Each end user of your app | Not documented | Yes | “Connect your account” flows inside your product |
| Custom connector | Workspace admin | Depends on how it is exposed | Yes | Wrap an internal or niche REST API for the whole workspace |
| Custom MCP server | You | Yes | No | Bring your own build-time tooling |
| Any API, no connector | You (stored backend secret) | Not documented | Yes | Anything without a connector. Stripe effectively works this way. |

Lovable’s integrations doc defines these types by credential ownership; as of September 2026 it does not state whether the agent can exercise app user connectors or direct API calls in chat, which is why those two cells say “not documented” rather than “no”.

Read the third and fourth columns before anything else. The difference between “works in chat” and “works in your published app” is where almost all of the confusion lives, and it is not a limitation anyone hits until the thing is deployed and quietly does nothing for real users.

Lovable points to `lovable.dev/dashboard?connectors` for the live catalog, and the doc index in `llms.txt` lists on the order of ninety connectors spanning data, AI, comms, CRM, devops, commerce, accounting, mapping, social, productivity, payments and security. The catalog moves, so treat any list in a blog post, including this one, as a description of how it works, and check the live catalog for what’s available.

## App + chat connectors: one shared account, two places it runs

An app + chat connector is a single set of credentials that both the Lovable agent (during development) and your published app (at runtime) can use. You supply the API key once; it is stored as a backend secret and reused everywhere.

Resend is the canonical example, and it is worth reading its documented limits closely because they generalize. It is one shared Resend account across every linked project. It calls the Resend API to send HTML or plain-text transactional email with multiple recipients, cc/bcc/reply-to, attachments and tracking tags, and it can query your sending domains and email status. You give it a key prefixed `re_`, either sending-access only (dispatch, optionally scoped to one domain) or full access.

What it explicitly cannot do:

- **Verify a domain.** Resend delivers to your app’s users only from a domain you have verified in Resend, and the connector cannot do DNS or verification. You do that in Resend first.
- **Receive webhooks through Lovable.** Delivery, bounce and complaint events do not flow back through the connector.
- **Authenticate per user.** There is no per-end-user Resend identity; it is one account.

That first bullet is the source of the most common email symptom in Lovable apps: you test with the shared `onboarding@resend.dev` address, mail reaches only the Resend account owner, and you conclude sending works. It does, for exactly one recipient. The Resend setup walkthrough (https://prerenderlovable.com/blog/lovable-resend-email-setup) covers the domain verification and `from`-address change in full, and why Lovable contact forms silently do nothing (https://prerenderlovable.com/blog/lovable-contact-form) covers the case where the send never fires at all.

## Chat connectors are MCP servers, and they stop at the editor

A chat connector is an MCP server wired into your Lovable chat, such as Encited’s SEO MCP (https://encited.com/seo-mcp) for Search Console and audit data while you build. It is personal to you and it is build-time context only. It can let the agent read your design system, query a service, or pull documentation while it writes code. It does not become a capability of the app you ship.

This distinction is worth stating flatly because the failure is silent and late: you connect a service as a chat connector, the agent demonstrates it working inside the editor, you publish, and production has no such connection. If the capability must run for end users, you need an app connector, an app user connector, a custom connector, or generated server code calling the API directly.

Custom MCP servers are the same category with your own server instead of a catalog entry: useful when you have internal tooling the agent should be able to call while building. The Lovable MCP servers post (https://prerenderlovable.com/blog/lovable-mcp-servers) goes into what is worth connecting and what just burns context, and driving Lovable from Claude Code or Codex (https://prerenderlovable.com/blog/lovable-with-claude-code-and-codex) covers the inverse direction, where Lovable is the thing being called.

## App user connectors: the credential belongs to your user

App user connectors invert ownership. Instead of you supplying one key for the whole app, each end user of your published app connects their own account to the third-party service. This is the model you want for any “connect your calendar”, “connect your CRM”, “import from your drive” feature: anything where the data being touched belongs to the person using your product, not to you.

Two consequences follow. Your app needs a place in its UI for the connection state, because a user who has not connected yet is a real state you have to design for. And your backend logic has to handle the per-user token rather than a single environment secret, which means the code shape is genuinely different from an app connector integration. Decide which of the two you need before you prompt, because retrofitting from one to the other means rewriting the data access layer.

## Custom connectors: an admin wraps an API once

If the service you want has no catalog entry, a workspace admin can define a custom connector that wraps its REST API and makes it available to projects across the workspace. This is the governance-friendly middle ground between “there is a connector” and “every project hand-rolls its own fetch calls with its own copy of the key.”

Reach for it when more than one project in the workspace needs the same internal API, when you want the credential managed centrally rather than pasted per project, or when you need the wrapping to be consistent so that generated code does not invent three different shapes for the same endpoint.

## Any API, no connector: the path Stripe actually takes

The sixth option is no connector at all. Lovable generates server-side code that calls an API using a key you have stored as a backend secret. Most people’s mental model of “native integration” breaks here, and Stripe is the example that matters.

### Stripe is set up through prompts

Lovable’s Stripe documentation is explicit: Lovable builds your payment flow with edge functions: small pieces of backend code that call Stripe using your stored key. You submit the key through a dedicated form, and it is stored as the backend secret `STRIPE_SECRET_KEY`, never in app code and never in chat. On Cloud projects it appears in the Secrets section with a Lovable badge; on projects connected to your own Supabase it syncs to edge function secrets in your Supabase dashboard.

What Lovable will build for you, per its docs: checkout functions and buy buttons, subscription checkout and status checks, customer portal integration, product and price creation in Stripe with your approval, and subscription matching by user email.

The detail that surprises people:

```
// Shape of what Lovable generates on a Supabase/Deno edge function
// (the pre-13 May 2026 path). The key is read from the backend secret.
import Stripe from 'stripe'

const stripe = new Stripe(Deno.env.get('STRIPE_SECRET_KEY')!)

// Webhooks are OFF by default. The generated app polls Stripe for status
// instead of receiving events, so no signing secret is needed unless you opt in.
export async function isPaid(sessionId: string) {
  const session = await stripe.checkout.sessions.retrieve(sessionId)
  return session.payment_status === 'paid'
}
```

`Deno.env` exists only in that edge-function runtime. On the TanStack Start stack the same logic lives inside a `createServerFn` handler running on Cloudflare Workers, and the key arrives as a Workers binding on the request rather than through `Deno.env.get`, which is undefined there.

Webhooks are optional. If you want them, Lovable writes the function but you configure the event destination and the signing secret in Stripe yourself. Test versus live mode is decided purely by key prefix: `sk_test_` or `rk_test_` gives you the sandbox. The in-Lovable payments view is read-only, and the customer portal does not work inside the preview panel, so test it on the published URL.

### Built-in payments is a different product

Separately from bring-your-own-Stripe, Lovable has a built-in payments feature where Lovable handles account creation, connection and technical setup, recommending Paddle or Stripe. Paddle acts as merchant of record (handling tax, compliance and invoicing) at 5.0% + 50c per transaction, with microtransactions under $10 charged at a flat 10%. Stripe offers optional merchant-of-record service via Managed Payments. Lovable documents that using either through Lovable costs the same as going direct.

The constraints are what decide it for most people: built-in payments requires a paid plan (bring-your-own-Stripe works on Free), it is digital products only, one payment provider per project, and projects with payments **cannot be remixed or forked**. You cannot run built-in payments and your own Stripe account at the same time. The Stripe on Lovable post (https://prerenderlovable.com/blog/lovable-stripe-payments) works through both paths end to end.

## Data and auth: Cloud or your own Supabase, and you choose once

Lovable Cloud is the built-in backend bundled with hosting: database, authentication, storage, realtime and edge functions with no infrastructure setup. It is built on Supabase’s open-source foundation, and it is enabled by default for your workspace. What it is not is a Supabase account. There is no Supabase dashboard login and no Supabase org or project of your own behind it; you manage everything in the Lovable editor under More -> Cloud: database viewer with tables, records, security policies and backups, SQL editor, users and auth, storage buckets, secrets, scheduled jobs, edge functions, logs and usage analytics.

Connecting your own Supabase instead is a two-level flow. A workspace owner or admin links a Supabase **organization** to the Lovable workspace, which makes it available to everyone; then anyone with edit access connects a specific Lovable **project** to a Supabase project inside that org. Individual team members do not each need a Supabase account once the org is linked. Lovable writes the SQL migrations for you (it shows you the SQL and asks for approval before running it) and the migration files are saved into your project code.

The part to internalize before you start building:

That makes the backend an effectively one-way decision at project creation. Cloud buys you no separate billing or account, in-editor database and user management, managed backups and scaling, and auth configured through chat. Your own Supabase buys you ownership, the full Supabase dashboard, direct infrastructure control, access to Supabase’s REST API for external integrations, and no per-project cost to Lovable. Cloud versus your own Supabase (https://prerenderlovable.com/blog/lovable-cloud-vs-supabase) makes the call properly, and the Cloud-to-Supabase runbook (https://prerenderlovable.com/blog/lovable-cloud-to-supabase) is the escape route if you already picked and regret it.

### Auth is Supabase Auth. Clerk is not in the catalog.

Lovable’s documented authentication is Supabase Auth, via Cloud or your own project, with dedicated doc pages for email auth, phone auth, Google, Apple, Microsoft, SAML SSO for your app, and reusing Lovable workspace identity inside your app.

Clerk is not a documented Lovable integration. As of September 2026, `docs.lovable.dev/integrations/clerk` returns 404 and Clerk does not appear in the connector catalog. What exists is third-party: a video tutorial page and Clerk’s own blog. You can wire it through the any-API path, but you are on the generic road with no first-party support, and you should price that in rather than assume parity with Supabase Auth.

## Code: Git sync and the GitHub API connector are not the same feature

These two get conflated constantly, and Lovable’s own GitHub API doc opens by disambiguating them.

**Git sync** moves your project’s source code. It supports GitHub, GitLab and Bitbucket Cloud: most writing about Lovable only mentions GitHub. Sync is genuinely two-way: changes in Lovable go to the repository, and changes pushed to the active branch flow back into Lovable, though only one branch at a time. The action in the UI is **Connect**, not “Export to GitHub”; no such button exists.

Its limits are sharp and worth memorizing:

1. **Import does not exist.** You cannot connect a Lovable project to an existing repository. Connecting always creates a new one, private by default.
2. **Transferring the repo to another owner or organization breaks sync** and needs a support ticket to re-attach. Renaming the repo is safe: Lovable detects it. Renaming your GitHub username or org breaks the connection entirely.
3. **Disconnect is effectively one-way.** Reconnecting creates a _new_ repository with the current project state rather than re-linking the original, orphaning your old repo and its history.
4. **Pushing commits does not deploy.** Publishing is a separate snapshot action; the live site does not change until you republish.
5. Files over 100 MB fail (GitHub’s own limit) and files over 10 MB cannot be edited inside Lovable. Commits are authored by a bot account and co-attributed to whoever triggered the sync.

The GitHub app requests Contents (write), Metadata (read), Pull requests (write), Workflows (write) and Administration (write). That last one is what allows repo creation, and it is the scope a security reviewer will ask about.

Meanwhile, **the GitHub API connector** does something else entirely: it calls GitHub’s REST API from your deployed app’s server code at runtime: listing and reading repos, branches and file contents, creating and updating issues and pull requests, reading commits, releases and workflow runs. It is for building internal engineering tools: triage boards, PR dashboards, release trackers. It has nothing to do with your own project’s code.

If you want the code itself, see Git sync in practice (https://prerenderlovable.com/blog/lovable-github-sync) and downloading your Lovable code (https://prerenderlovable.com/blog/download-lovable-code).

## Search and SEO connectors

Two are worth knowing about. There is a Google Search Console connector allowing verification and sitemap submission directly from chat. Check the sitemap Lovable generates before you submit it: it can include URLs that don’t exist (https://encited.com/blog/how-to-generate-sitemap-on-lovable). And Lovable ships a Semrush integration for live keyword research, competitor analysis and SEO strategy guidance with no separate Semrush account: documented as free **only through September 15, 2026**. As of September 2026 that date has effectively passed, so check the current terms before planning around it.

Neither changes what crawlers receive from your app, which is a rendering question rather than an integration one. The Lovable SEO guide (https://prerenderlovable.com/blog/lovable-seo) and how Lovable’s pre-rendering actually behaves (https://prerenderlovable.com/blog/lovable-prerendering) cover that separately.

## Secrets: where they live and what happens to them

Every integration that is not a per-user OAuth flow ends up as a stored secret. Two independent things decide what you see: your **backend** determines where the secret is stored, and your **stack** determines how server code reads it. A project has a separate answer from each table.

Where it is stored, by backend:

| Backend | Where the secret lives |
| --- | --- |
| Lovable Cloud | Cloud Secrets section in the editor, provider-managed entries carrying a Lovable badge |
| Your own Supabase | Synced to edge function secrets in your Supabase dashboard |

How server code reads it, by stack:

| Stack | How the secret reaches your code |
| --- | --- |
| React + Vite (pre-13 May 2026) | Stored in Supabase and read by separately deployed edge functions |
| TanStack Start (13 May 2026 onward) | Injected at request time as Cloudflare Workers bindings rather than baked into the bundle |

Three rules follow from this:

- **Secrets never belong in app code or chat.** Lovable’s own flow for Stripe uses a dedicated submission form precisely so the key never passes through the conversation. Treat any integration the same way.
- **Anything prefixed for the client is public.** On the Vite stack, environment variables must be prefixed to reach the browser, and anything that reaches the browser is readable by anyone. A service key that ends up client-side is compromised the moment you publish.
- **Secrets are write-only from your side.** You cannot read them back out, which means a migration involves regenerating each secret at its provider and installing it again at the destination. Missing one fails silently until the specific code path runs.

## Integrations have a running cost, denominated in credits

Lovable uses one unified credit pool covering three different kinds of usage: **build** (messages you send to plan and generate), **cloud** (database, network, storage, compute and realtime in your _deployed_ app), and **AI gateway** (your deployed app calling AI models at runtime). Hosting itself does not cap visitors, requests or bandwidth, but the runtime your integrations consume is billed from the same pool as your AI coding.

This has a specific implication for integration design. Lovable’s docs say Cloud usage (database, network, storage, compute and realtime in your deployed app) draws from the same pool as your AI coding, but they do not publish a per-operation rate. So the safe design rule is structural rather than numeric: a scheduled job that runs whether or not there is work to do bills continuously, while an event-driven webhook bills only when it fires. When you have the choice between polling and a webhook, that asymmetry is a real argument for the webhook even when polling is simpler to generate. Cutting Lovable credit burn (https://prerenderlovable.com/blog/save-lovable-credits) covers the build side of the same pool.

## What breaks when you leave Lovable hosting

This one cuts across every integration above, so it’s worth covering here. Connectors are a platform feature. Export your code and deploy it on Vercel, Cloudflare Pages, Netlify or your own box and you take the _calls_ with you, but not the plumbing: stored secrets do not travel, webhook endpoints still point at the old backend, OAuth redirect URIs still name the old origin, scheduled jobs keep running where they were, and Lovable’s built-in pre-rendering for verified crawlers stops.

That last one is the easiest to miss and the most expensive. On the React + Vite stack, pre-rendering is a hosting feature: crawlers get the empty SPA shell the moment you deploy somewhere else. On the TanStack Start stack you keep SSR, but the cached HTML still omits anything your components fetch from Supabase or Lovable Cloud after hydration. Test against a page with dynamically loaded content (CMS posts, product pages, directory listings: anything that isn’t written into the page’s source code) rather than the homepage:

```
curl -sS https://yourdomain.com/products | grep -c 'product-card'
# Compare against what you count in the browser. A gap is the whole problem.
```

These failures are quiet and often go unnoticed for days, so schedule the audit rather than waiting for the symptom. How Lovable’s pre-rendering actually behaves (https://prerenderlovable.com/blog/lovable-prerendering) covers what you have to replace and how.

## What to do next

1. **Write down, for each integration you plan, which of the six types it is.** If the answer is “chat connector” and the feature has to work for end users, you have already found a bug that does not exist yet.
2. **Settle the backend question before you build anything.** Cloud or your own Supabase is a one-way door; there is no migration in either direction.
3. **Check which stack your project is on** by looking at `package.json`, in the Lovable code editor, or in your synced repo or downloaded ZIP, all of which need a paid plan. Run `grep -E '"(@tanstack/react-start|@tanstack/react-router|react-router-dom)"' package.json`; `@tanstack/react-start` means the new stack. It determines how server code is deployed and how it reads your secrets.
4. **Inventory your secrets now,** while you can still remember which provider issued which key.
5. **For each integration, ask whether it polls.** Convert what you can to events before the runtime bill teaches you the same lesson.

Found something wrong or out of date? Lovable changes fast and we'd rather fix a guide than let it rot.

Disclosure: the team behind this guide also builds Encited, mentioned above.

## Frequently asked questions

How many types of integration does Lovable have?

Six, and Lovable's integrations documentation organizes them by connection type rather than by category. They are app + chat connectors, chat connectors (MCP servers), app user connectors, custom connectors, custom MCP servers, and direct any-API integration with no connector at all. Which one you need depends on who owns the credential and whether the capability has to work in your published app or only in the Lovable chat.

Is Stripe a one-click Lovable integration?

No. Lovable's Stripe documentation describes it as prompt-driven: Lovable builds your payment flow with edge functions that call Stripe using a key you store as the backend secret STRIPE_SECRET_KEY. There is no toggle. Separately, Lovable has a built-in payments product using Paddle or Stripe, which is a different thing, requires a paid plan, and cannot be used at the same time as your own Stripe account.

Does Lovable support Clerk for authentication?

Not as a documented integration. As of September 2026 docs.lovable.dev/integrations/clerk returns 404 and Clerk does not appear in Lovable's connector catalog. Lovable's documented auth is Supabase Auth, either through Lovable Cloud or your own Supabase project. You would have to wire Clerk through the generic any-API path, with no first-party support.

What is the difference between GitHub Git sync and the GitHub API connector?

Git sync exports and two-way syncs your Lovable project's source code to a repository. The GitHub API connector is unrelated: it calls GitHub's REST API from your deployed app's server code at runtime, so you can build issue triage boards, PR dashboards and release trackers. Lovable's own GitHub API doc points readers to Git sync if what they actually wanted was code export.

Can a Lovable chat connector be used by my published app?

No. Chat connectors are MCP servers, and Lovable documents them as personal and build-time only: they give the agent context while you are building. If the capability has to run for your end users in production, you need an app connector, an app user connector, a custom connector, or a direct API call from generated server code.

Where does Lovable store an integration's API key?

As a backend secret, never in app code or chat. On Lovable Cloud projects it appears in the Cloud Secrets section; on projects connected to your own Supabase it syncs to edge function secrets in your Supabase dashboard. On the newer TanStack Start stack, secrets are injected at request time as Cloudflare Workers bindings rather than baked into the bundle.

Read next

## Keep going

- ### Lovable Stripe integration vs built-in payments: https://prerenderlovable.com/blog/lovable-stripe-payments
  Lovable Stripe is set up through prompts, and it's a different thing from Lovable's built-in payments. How to choose, plus the webhook code you own.
- ### Setting up Resend in a Lovable app: https://prerenderlovable.com/blog/lovable-resend-email-setup
  The Lovable Resend setup that actually ships: what the shared connector can't do, the DNS you verify first, and the deliverability work nobody documents.
- ### Lovable MCP and chat connectors, explained: https://prerenderlovable.com/blog/lovable-mcp-servers
  Lovable MCP servers are chat connectors: personal, build-time only, and they do not run in your published app. The six connector types, and what's worth wiring.
- ### Adding a contact form to a Lovable app: https://prerenderlovable.com/blog/lovable-contact-form
  A Lovable contact form needs an endpoint to POST to. Compare an edge function plus Resend, a hosted form backend, and a keyless HTML endpoint.

## Structured data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://prerenderlovable.com/#website",
      "url": "https://prerenderlovable.com",
      "name": "The Lovable Field Guide",
      "description": "A working journal on Lovable SEO: getting apps built with Lovable indexed, ranked and cited, plus the migration and integration work that comes with it.",
      "publisher": {
        "@id": "https://prerenderlovable.com/#organization"
      },
      "inLanguage": "en"
    },
    {
      "@type": "Organization",
      "@id": "https://prerenderlovable.com/#organization",
      "name": "The Lovable Field Guide",
      "url": "https://prerenderlovable.com"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://prerenderlovable.com/blog/lovable-integrations#article",
      "headline": "Lovable integrations: the complete map",
      "description": "Lovable integrations come in six connection types, and picking the wrong one is why wiring fails. What each type does, what exists, and how secrets flow.",
      "datePublished": "2026-09-11T00:00:00.000Z",
      "dateModified": "2026-09-11T00:00:00.000Z",
      "inLanguage": "en",
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://prerenderlovable.com/blog/lovable-integrations"
      },
      "author": {
        "@type": "Organization",
        "name": "The Lovable Field Guide",
        "url": "https://prerenderlovable.com"
      },
      "publisher": {
        "@id": "https://prerenderlovable.com/#organization"
      },
      "keywords": "lovable integrations, lovable connectors, lovable app connectors vs chat connectors, lovable integration list, lovable custom connector",
      "articleSection": "Integrations"
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://prerenderlovable.com/blog/lovable-integrations#breadcrumbs",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Home",
          "item": "https://prerenderlovable.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Integrations",
          "item": "https://prerenderlovable.com/integrations"
        },
        {
          "@type": "ListItem",
          "position": 3,
          "name": "Lovable integrations: the complete map",
          "item": "https://prerenderlovable.com/blog/lovable-integrations"
        }
      ]
    },
    {
      "@type": "FAQPage",
      "@id": "https://prerenderlovable.com/blog/lovable-integrations#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "How many types of integration does Lovable have?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Six, and Lovable's integrations documentation organizes them by connection type rather than by category. They are app + chat connectors, chat connectors (MCP servers), app user connectors, custom connectors, custom MCP servers, and direct any-API integration with no connector at all. Which one you need depends on who owns the credential and whether the capability has to work in your published app or only in the Lovable chat."
          }
        },
        {
          "@type": "Question",
          "name": "Is Stripe a one-click Lovable integration?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "No. Lovable's Stripe documentation describes it as prompt-driven: Lovable builds your payment flow with edge functions that call Stripe using a key you store as the backend secret STRIPE_SECRET_KEY. There is no toggle. Separately, Lovable has a built-in payments product using Paddle or Stripe, which is a different thing, requires a paid plan, and cannot be used at the same time as your own Stripe account."
          }
        },
        {
          "@type": "Question",
          "name": "Does Lovable support Clerk for authentication?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Not as a documented integration. As of September 2026 docs.lovable.dev/integrations/clerk returns 404 and Clerk does not appear in Lovable's connector catalog. Lovable's documented auth is Supabase Auth, either through Lovable Cloud or your own Supabase project. You would have to wire Clerk through the generic any-API path, with no first-party support."
          }
        },
        {
          "@type": "Question",
          "name": "What is the difference between GitHub Git sync and the GitHub API connector?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Git sync exports and two-way syncs your Lovable project's source code to a repository. The GitHub API connector is unrelated: it calls GitHub's REST API from your deployed app's server code at runtime, so you can build issue triage boards, PR dashboards and release trackers. Lovable's own GitHub API doc points readers to Git sync if what they actually wanted was code export."
          }
        },
        {
          "@type": "Question",
          "name": "Can a Lovable chat connector be used by my published app?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "No. Chat connectors are MCP servers, and Lovable documents them as personal and build-time only: they give the agent context while you are building. If the capability has to run for your end users in production, you need an app connector, an app user connector, a custom connector, or a direct API call from generated server code."
          }
        },
        {
          "@type": "Question",
          "name": "Where does Lovable store an integration's API key?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "As a backend secret, never in app code or chat. On Lovable Cloud projects it appears in the Cloud Secrets section; on projects connected to your own Supabase it syncs to edge function secrets in your Supabase dashboard. On the newer TanStack Start stack, secrets are injected at request time as Cloudflare Workers bindings rather than baked into the bundle."
          }
        }
      ]
    }
  ]
}
```