Lovable API Key: Where to Add It and How to Keep It Safe

In Lovable, your API key goes in Secrets: open More → Settings → Secrets in the project toolbar, or use the Add secret form Lovable shows in the project chat. Backend code reads it from there, so the key never reaches the browser. Don't paste it into a chat message, and don't put it in frontend code.

Short answer

• Your own key (GPT, Claude, Resend): Secrets, or the form a connector shows you.
• Lovable's own keys: LOVABLE_API_KEY is generated for you; a workspace key (lov_…) needs Business or Enterprise.
• GPT, Claude or DeepSeek with your key: ask Lovable for a backend function, because the built-in AI connector can't use your key.
• If it leaks: revoke it at the provider first, then replace the secret.

Which Lovable API key do you need?

"Lovable API key" can mean four different things.

The workspace key goes only to the Lovable API, in the Lovable-API-Key header, and its value is shown once (API key docs, checked November 2, 2026). It manages and deploys your projects; it does not call AI models or build apps (Lovable API), and it is not the project LOVABLE_API_KEY (AI docs).

Everything below is about the first row: your own key.

Where to add an API key in Lovable

1. Lovable asks. When a feature needs a key it opens the Add secret form in the project chat. Enter the value there, not as a chat message: the form saves it straight to the project's secrets and keeps it out of chat history (Lovable's custom API docs, checked November 2, 2026).
2. You add it. Open More → Settings → Secrets in the project toolbar, click Add secret, and enter one or more name and value pairs (Secrets docs).

Lovable's August 26, 2026 changelog calls the path More → Cloud → Secrets, so look there if your menu differs (changelog).

Rules that catch people out:

• Write-only: you can replace or delete a value, never read it back.
• VITE_ names are rejected; they are build-time values the browser can see and belong in .env.
• SUPABASE_ and LOVABLE_ names are reserved and filled in for you.
• Secrets belong to one project. After a remix you re-enter yours, because only Lovable-generated keys are recreated.

On your own Supabase project the backend view has a Manage secrets button that opens the Supabase dashboard, where the store is Edge Function Secrets (Supabase secrets, checked November 2, 2026). Two Lovable projects sharing one Supabase project overwrite each other's secrets, LOVABLE_API_KEY included (Supabase integration).

Where do Resend, Stripe and Google Maps keys go?

Not every key goes straight into Secrets: these services have connector forms (Stripe, Resend, custom APIs, checked November 2, 2026).

Google Maps is the exception to the rule. Its browser key is public by design and reaches your frontend as VITE_LOVABLE_CONNECTOR_GOOGLE_MAPS_BROWSER_KEY, and its website restriction is what stops other sites reusing it (Google Maps, checked November 2, 2026). The server key stays private. Connector credentials are stored encrypted, and nobody can read them back, not even Lovable (integration security).

How to connect GPT, Claude or DeepSeek with your own key

First, check whether you need a key: the built-in AI connector needs none. Lovable generates a LOVABLE_API_KEY per project and runs GPT-6 Astra by default, with Claude chat models only in newer TanStack Start apps created from May 13, 2026 (AI docs, AI chat, checked November 2, 2026).

That connector can't use your key: it always runs through Lovable and bills workspace credits. Lovable's docs, as we read them on November 2, 2026, don't mention DeepSeek. For your own key, ask Lovable to call the provider from a backend function with the key in Secrets.

There is no create-function button: describe the function in the project chat and Lovable writes and deploys it (Edge functions). Newer TanStack Start apps (created from May 13, 2026, or June 22, 2026 on Enterprise) get a server function; older React + Vite apps get an Edge Function, which is code that runs on the server.

Our code uses OmniaKey's OpenAI-compatible API, because one key reaches GPT-6.1 Terra, Claude Sonnet 5.5 and DeepSeek.

1. Create a key at your provider. For OmniaKey: sign up at omniakey.com, then Dashboard → tokens (Quick start).

2. Paste this prompt into the project chat:

   text

   Add an AI chat feature that uses my own API key, not the built-in AI connector.
   Create a backend function named "chat". It reads OMNIAKEY_API_KEY from Secrets and calls
   POST https://api.omniakey.com/v1/chat/completions with the model and messages the frontend sends.
   Only allow these models: gpt-6.1-terra, claude-sonnet-5-5, deepseek-flash.
   Require a signed-in user. Never put the key in frontend code.
   Ask me for the key with the Add secret form.
   

3. Enter the key in the Add secret form, named OMNIAKEY_API_KEY.

We haven't run that prompt in Lovable, because we don't have a Lovable account, and the Lovable steps here come from its docs. The function should end up like this, which is the copy we ran on our own machine.

// supabase/functions/chat/index.ts
// The browser sends { model, messages }; this function adds the API key on the server.
const corsHeaders = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Headers": "authorization, x-client-info, apikey, content-type",
};

const ALLOWED_MODELS = ["gpt-6.1-terra", "claude-sonnet-5-5", "deepseek-flash"];

function json(body: unknown, status = 200) {
  return new Response(JSON.stringify(body), {
    status,
    headers: { ...corsHeaders, "Content-Type": "application/json" },
  });
}

Deno.serve(async (req) => {
  if (req.method === "OPTIONS") {
    return new Response("ok", { headers: corsHeaders });
  }

  const apiKey = Deno.env.get("OMNIAKEY_API_KEY");
  if (!apiKey) {
    return json({ error: "OMNIAKEY_API_KEY is not set" }, 500);
  }

  const { model, messages } = await req.json();
  if (!ALLOWED_MODELS.includes(model)) {
    return json({ error: `model must be one of: ${ALLOWED_MODELS.join(", ")}` }, 400);
  }

  const upstream = await fetch("https://api.omniakey.com/v1/chat/completions", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ model, messages, max_tokens: 800 }),
  });

  const data = await upstream.json();
  if (!upstream.ok) {
    return json({ error: data.error?.message ?? "upstream error" }, upstream.status);
  }
  return json({ reply: data.choices[0].message.content, model: data.model, usage: data.usage });
});

Our test copy leaves out the sign-in check so we could call it from a script; the prompt above asks Lovable to add it, because Lovable's security best practices say authentication decisions happen on the server (best practices).

From the browser, the call looks like this (supabase-js):

const { data, error } = await supabase.functions.invoke("chat", {
  body: { model: "deepseek-flash", messages: [{ role: "user", content: "Say hello in five words." }] },
});

With another provider, change the URL and model IDs to the ones in its docs. An OmniaKey key also works for a custom API key in Cline and custom models in Factory Droid.

What happened when we ran it

We ran the function on our own machine, not in Lovable, with Deno 2.9.8 on November 2, 2026, and called it like a browser, with an Origin header and a CORS preflight.

One call per model, so each time is one sample; deepseek-flash answered as deepseek-v4-1-flash-261017.

Why you only see "non-2xx status code"

On an error, supabase.functions.invoke gives you only Edge Function returned a non-2xx status code, and data is null. The function's real message is in await error.context.json():

if (error) {
  const details = await error.context.json();
  console.error(details.error);
}

• 401: the key is wrong. Ours read Invalid token (request id: …).
• 500 with OMNIAKEY_API_KEY is not set: the secret is missing, or named differently.
• 400: the model is not on your list.

How to check whether your key is exposed

A key in frontend code is visible to users and should be treated as compromised (best practices, checked November 2, 2026).

• Quick security scan runs by itself on every publish.
• Deep security scan does not; start it from the project Security view (Security view).
• Look for the group Leaked secrets & credentials.
• Either scan is free; only bulk fixes draw on the 10 free fixes and then credits (security scans).

By hand: in Chrome, open your published app's developer tools, press Command+Option+F on a Mac or Control+Shift+F on Windows and Linux, and search loaded files for the first few characters of your key. Look for any VITE_ value holding a private key, since those are built for the browser (DevTools search). A clean search covers only the files that page loaded, so run the scan too.

Hiding the key does not stop strangers calling your function: anyone can call a function with no sign-in check, and every call spends your key. Lovable's docs say to enforce sign-in on the server; our allowlist and max_tokens: 800 limit each call; and OmniaKey's docs recommend a separate key per environment with a spending cap (OmniaKey's API docs).

What to do if a key was exposed

1. Revoke it at the service that issued it and create a new one there; Lovable's docs list a Rotate action only for its own key (Secrets docs).
2. Replace the value in Secrets, the connector form, or Supabase. On Supabase the function reads the new secret straight away with no redeploy (Supabase secrets). Lovable's docs don't say whether its built-in backend, Cloud, does the same, so call the function once to confirm.
3. Move the key out of frontend code or .env, then run the Deep security scan again.
4. Check the provider's usage page for calls you did not make.

Lovable's own keys work differently. LOVABLE_API_KEY has a Rotate action, for editors and above, that issues a new key and updates the Edge Function environment. A workspace key (lov_…) that GitHub secret scanning reports is revoked automatically; anywhere else, revoke it yourself (API key docs).

What it costs

Lovable's bill and your provider's bill are separate: with your own key the provider bills the model usage, and your app only uses Cloud to run the function (AI docs, Cloud, checked November 2, 2026).

The built-in AI connector bills workspace credits instead: Free, Pro and Business get a 4-credit monthly AI grant, running out returns 402, and going over the rate limit returns 429. The Free plan also gives 5 build credits a day, up to 30 a month, plus 20 Cloud credits (pricing); Lovable's plans table lists 100 credits at $25 a month on Pro (subscription plans, checked November 2, 2026).

For OmniaKey, see the current rates on the GPT-6.1 Terra, Claude Sonnet 5.5 and DeepSeek pages.

Frequently asked questions

Where do I find my Lovable API key?

It depends which key you mean. LOVABLE_API_KEY is generated per project and sits in that project's Secrets, where you can rotate it but never read it. A workspace key comes from Workspace settings → API keys & OAuth → Workspace access tokens, shown once.

Is there a free Lovable API key?

The closest thing is LOVABLE_API_KEY: the built-in AI connector generates it for each project, and Free, Pro and Business workspaces get a 4-credit monthly AI grant to use it. A workspace key needs a Business or Enterprise plan.

Can I use my own OpenAI key with Lovable AI?

Not with the built-in AI connector, which always runs through Lovable and bills workspace credits. For your own key, ask Lovable for a backend function that calls the provider directly, with the key in Secrets.

Should my API key go in Secrets or .env?

Secrets, when the key is private and read by backend code. .env is for VITE_ values, which are built into the app and visible in the browser.

Why won't Lovable connect to GPT, Claude or DeepSeek?

Read the function's message first; it names the problem:

• 500 with OMNIAKEY_API_KEY is not set: the secret is missing, or saved under a different name.
• 401: the key is wrong or revoked.
• 400: the model ID is not on your allowlist.
• 404: the base URL is wrong; ours ends at /v1/chat/completions, and most setup errors come from a wrong protocol suffix (OmniaKey's error docs).

In the browser you see only Edge Function returned a non-2xx status code, so log error.context as shown above to see which one it is.

Sources checked

• Lovable Secrets docs, checked November 2, 2026
• Lovable API keys, checked November 2, 2026
• Lovable API, checked November 2, 2026
• Lovable MCP server, checked November 2, 2026
• Build with URL, checked November 2, 2026
• Lovable AI features, checked November 2, 2026
• Lovable AI chat, checked November 2, 2026
• Lovable Edge functions, checked November 2, 2026
• Lovable Cloud, checked November 2, 2026
• Custom APIs and connectors, checked November 2, 2026
• Stripe integration, checked November 2, 2026
• Resend integration, checked November 2, 2026
• Google Maps integration, checked November 2, 2026
• Integration security, checked November 2, 2026
• Supabase integration, checked November 2, 2026
• Lovable security, checked November 2, 2026
• Lovable Security view, checked November 2, 2026
• Lovable security best practices, checked November 2, 2026
• Lovable subscription plans, checked November 2, 2026
• Lovable changelog, checked November 2, 2026
• Lovable pricing, checked November 2, 2026
• Supabase Edge Function secrets, checked November 2, 2026
• Supabase functions.invoke, checked November 2, 2026
• Chrome DevTools search, checked November 2, 2026

OmniaKey's own documentation, checked November 2, 2026: Quick start, OpenAI-compatible API, authentication and errors.