⚡ AI Analyst
A Lovable API key needs a Business or Enterprise plan and an admin role. What it unlocks, what it cannot do, and how to scope it. Verified 11 Oct 2026.
Money Flock
Recommended Contents
Comments
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.
A Lovable API key is a workspace access token that authenticates requests to the Lovable REST API, and creating one requires a Business or Enterprise plan plus an owner or admin role in that workspace. Keys start with lov_, are shown once, and are sent in a Lovable-API-Key header. There is no free tier for the key itself.
That one paragraph answers the question most people are actually asking. The rest of this article is the part that is harder to find: what the key can and cannot reach, the two settings you can never change after you create it, how the per-key spending cap interacts with workspace usage limits, and why several pages ranking for this search still say the API does not exist.
Verified in the browser on 11 October 2026: the Lovable API key documentation, the API reference, the subscription plan tables, the Lovable changelog, and the pricing page read while logged out.
Two completely different things share this name, and the search results for it mix them freely. Before anything else, work out which one you need.
| What you mean | Where it lives | Who issues it | Plan needed |
|---|---|---|---|
| A Lovable API key | Workspace settings, Access tokens | Lovable | Business or Enterprise |
| A key for a service inside your app | Project secrets, or a connector | Stripe, OpenAI, a data provider | Any plan, including Free |
If you are building an app and it needs to call a payment processor, a market data feed or a model provider, you want the second row. That key is a project secret, it never belongs in prompts or front-end code, and Lovable can now recognise a pasted key in chat and offer to set up a connector for it instead, as the 1 September 2026 changelog entry describes. We covered the handling rules for those keys in is Lovable safe for financial data.
The confusion is not academic. The page currently ranking fifth for this search is a security scanner write-up about exposed keys in Lovable apps, which is entirely about the second row: Supabase service role keys and third-party secrets ending up in the front-end bundle. Useful, but it answers a different question from the one in the search box.
One trap that catches people who have both: when you store a Lovable API key as a project secret, do not name it LOVABLE_API_KEY. Lovable creates and manages a secret with that exact name in every project, and names starting with LOVABLE_ are reserved. The docs suggest something like LOV_PUBLIC_API_KEY instead.
Three conditions, all of them hard gates:
Lovable's own plan comparison backs this up in writing. The building, publishing and code table on the subscription plans page carries a row called Lovable API with a dash under Free, a dash under Pro, and Yes under Business and Enterprise.
Here is the part worth knowing before you shop. Read the pricing page on the same day and the Business card lists twelve things: unlimited users, free grants, all Pro features, 100 Business credits, team workspace, role-based access, internal publish, personal projects, SSO, security center, design templates and priority support. The Lovable API is not one of them. The feature is real and it is gated, but the page where you decide to spend money does not mention it. If API access is the reason you are upgrading, the docs table above is the evidence you want, not the pricing card. The plan ladder itself is broken down in Lovable pricing: Free vs Pro vs Business.
Roles matter as much as the plan here, and they are a separate piece of setup. How Lovable team workspaces and roles work covers who gets to be an admin and what that costs you in practice.
This is where expectations tend to be wrong in both directions. The public API manages and deploys projects you already have. It does not build them.
| Resource area | What you can do |
|---|---|
| Projects | List, get, update settings, and delete projects |
| Deployments | Publish or unpublish a project, check deploy status, update publish settings |
| Embed | Generate a one hour URL that embeds a project's built preview on a named HTTPS origin |
| Workspace | List workspaces, read workspace settings, list members and groups |
| Analytics | Read project level and workspace level analytics |
| Security | Poll per-project security scans, read workspace security insights and PII labels |
Two of those reads are Enterprise only: a project's PII labels, which also require sensitive data scanning to be switched on, and the per-project security inventory under workspace insights. Everything else works on Business as well as Enterprise, subject to the key's scopes and each endpoint's own prerequisites. The wider Business and Enterprise split is in Lovable Enterprise vs Business for finance teams.
The embed endpoint deserves a sentence of its own because it is easy to over-read. It gives you a one hour URL for a project's built preview on a specified HTTPS origin. It does not embed the editor and it does not embed the published app, and visitors do not need a Lovable login to view it.
It will not create a project and it will not edit one with AI. The docs are blunt about it: AI project creation and editing live on the Lovable MCP server, not here. If what you want is an AI client that writes code into your projects, you want the other surface, which we walked through in Lovable MCP: Claude Code, Cursor and ChatGPT setup.
A useful consequence of that boundary: because nothing in the current API runs the AI builder, no current endpoint spends AI build credits, and the docs state explicitly that deployment builds through the publish endpoint do not spend them either. There is no separate API pricing on top of the plan.
When you create a key you set a name, scopes, an expiry, an optional monthly credit cap and an optional IP allowlist. Two of those are frozen the moment you click Create.
| Setting | Changeable later? | How |
|---|---|---|
| Key name | No separate edit documented | Create a new key |
| Scopes | No | Create a new key, then revoke the old one |
| Expiry | No | Create a new key, then revoke the old one |
| Credit limit | Yes | Key menu, Edit credit limit: raise, lower or remove |
| IP allowlist | Yes | Key menu, Edit IP allowlist: upload a CSV, or remove every source |
Scopes are set per resource area, and you must grant at least one. Each of the two areas can be None, Read, or Read and write. Projects covers reading and modifying project settings, deleting projects, publishing them, and reading project security scans. Workspace covers listing projects and reading workspace details, members, groups, security insights and analytics. Two presets, Read only and Full access, fill in both areas at once.
Expiry runs 7, 30, 60, 90 or 180 days, 1 year, or Never. Never is offered for long lived service integrations, and the docs still recommend rotating instead. There is a small asymmetry worth planning around: an expired key stays visible in the list so you can see what expired, but a revoked key disappears from the access token list entirely, per the 25 July 2026 changelog entry.
Because scopes and expiry are immutable, the practical rule is the one the docs give: one key per integration. A reporting script and a deploy pipeline should not share a key, or you cannot revoke one without breaking the other.
Every key can carry a monthly credit limit. It caps how many AI build credits requests authenticated with that key can spend in a calendar month, and it resets at 00:00 UTC on the first day of each month, independently of your subscription renewal date. Leave it blank for no limit.
Read that alongside the previous section and a slightly odd picture appears: no endpoint in the current API spends AI build credits, so today the cap guards against nothing. It is a forward-looking control for whatever the API surface becomes, and it costs nothing to set. Set it anyway.
The more useful finding is what the Access tokens page does not tell you. Lovable shipped workspace usage limits and alerts on 7 October 2026, and an access token is one of the scopes it can target on Business and Enterprise. The credit limit you set on the Access tokens page is the same object: a monthly Build limit that blocks. Going through Usage limits and alerts instead gives you three things the key creation form does not:
One asymmetry to plan for: a member who hits a blocking user limit can request an increase that an admin approves or denies. Group and access token limits do not support increase requests. If an automation hits its ceiling at 2am, nobody is clicking approve. Size the cap for the worst honest month, not the average one.
Since 1 October 2026 a key can be restricted to approved addresses. You upload a CSV with one entry per row, either when you create the key or later from its menu. The constraints are specific enough to be worth writing down before you build the file.
| Rule | Value |
|---|---|
| File | CSV, one IP or range per row |
| Size | Up to 3,000 entries and 1 MB |
| Entry format | IPv4 or IPv6 address, or CIDR range such as 203.0.113.0/24 |
| Widest range accepted | /8 for IPv4, /32 for IPv6 |
| Mandatory | At least one IPv4 entry in every list |
| Bad or duplicate rows | Skipped, with a count shown |
| Refused request | 403 ip_restricted |
The mandatory IPv4 entry is the one that catches modern infrastructure: the Lovable API currently answers over IPv4 only, so an IPv6-only allowlist locks you out of your own key. Editing the list is also not a merge. Existing entries appear as one source called Current allowlist, uploading a CSV adds to it, and replacing the list means removing that source first. Remove every source and the key accepts any address again.
If you use the key through the Lovable API connector rather than your own server, the request reaches the API from Lovable's connector gateway, not from your address, so a restricted key needs the gateway IP ranges in the list. On Enterprise, every refused request lands in the workspace audit log as User API key IP rejected, and allowlist changes appear as User API key updated.
Lovable partners with GitHub secret scanning. When GitHub detects a supported Lovable API key, the lov_ prefix being the signal, Lovable revokes it automatically and emails the person who created it along with every workspace owner and admin. The 25 July 2026 changelog adds two details the feature page leaves out: the revoked key stops working right away and disappears from the access token list, and those emails are always sent regardless of your email preferences.
Note the date. Automatic revocation of leaked keys shipped nearly two months before the public API itself, which arrived on 17 September 2026. The protection was already in place the day the API opened.
Everything outside a public GitHub repository is on you. A key pasted into a ticket, a shared document, a chat thread or a screenshot is compromised and nothing will revoke it for you. The other standing rule from the docs is short: never use a Lovable API key in browser code. Server-side scripts and automation tools only.
The base URL is https://api.lovable.dev and endpoints are versioned under /v1. Exactly one header is required.
Lovable-Version is the one to think about. It takes a date in YYYY-MM-DD form. Omit it and your request runs on the oldest supported stable version, which is currently 2026-09-11, the first and so far only generally available version. That default advances when the current default retires, so an unpinned integration will move under you at some point. Pin it.
Every error comes back in the same envelope with type, title, status, request_id, detail, errors and props. Branch on type, which is a stable snake_case token, never on title, whose wording can change. The request_id matches the X-Request-Id response header and is what support will ask for.
| Status and type | What it usually means for you |
|---|---|
| 402 payment_required | Your plan does not include that feature. Check Business vs Enterprise first |
| 403 insufficient_scope | The key is missing a scope. Scopes are immutable, so this is a new key |
| 403 ip_restricted | The caller's address is not on the key's allowlist |
| 404 not_found | Gone, invisible to this key, or outside the endpoint's documented prerequisites |
| 410 retired_version | Your pinned version retired. props.migration_url may point the way |
| 429 rate_limited | Back off. Honour Retry-After when it is present |
Rate limits use a sliding window. Responses carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, and that reset value is an absolute Unix timestamp in seconds, not a delay. Each API key gets its own limit, which is another argument for one key per integration: a chatty reporting job cannot then throttle your deploy pipeline. Because the window slides, remaining capacity recovers gradually rather than all at once.
Two more things that will bite a first integration. List endpoints are cursor paginated with a limit between 1 and 100, defaulting to 50, and you follow pagination.next_cursor until has_more is false. And some reads are eventually consistent, specifically project and member lists, workspace project counts, and project and membership data in security insights, so a successful write does not guarantee the next read reflects it. Retry with backoff rather than treating it as a bug.
If you would rather poke at it before writing code, Lovable put the whole collection on the Postman API Network on 18 September 2026, with saved example responses for every endpoint in the current version.
The API is one of three, and picking the wrong one is the most common mistake in this topic.
| Route | Where it runs | What it does | Credentials |
|---|---|---|---|
| Lovable API | Your own scripts and services | Manage and deploy existing projects, read analytics and security | An API key you store yourself |
| Lovable API connector | An app you built with Lovable | Your app reads and manages a connected workspace | An API key stored by Lovable |
| Lovable MCP server | An AI client such as Claude, Claude Code or Cursor | External AI tools create, edit and manage projects | OAuth, no API key available |
The connector is the one people miss. It is an app and chat connector available on Business and Enterprise, and it lets an internal tool you built with Lovable call the Lovable API from server code. When you add it, the form can create a key for you with Read and write on Projects and Read on Workspace, capped per calendar month. Every request through it is attributed to the person who created the key and is limited to what that person can access. That attribution rule matters for anyone running client work; the broader pattern is in Lovable for agencies: client dashboards.
Worth noting on the Enterprise side: app and chat connectors are available by default on Business, but on Enterprise the setting for who can create connections starts at No one until an admin changes it. A working Business setup will not simply carry over.
For the MCP route, there is no API key option at all. The Lovable MCP server is OAuth 2.1 only, and the FAQ says plainly that API key authentication is not currently available there. Anyone telling you to paste a lov_ key into an MCP client config is describing something that does not exist. Building an MCP server with Lovable covers the third direction, where your published app becomes the connector.
Give a key Read on both areas and nothing else, point a scheduled script at the per-project security scans and workspace security insights, and write the result somewhere your reviewers already look. This is the single clearest use of the API as it stands: the data exists in the product, and nobody is going to open twelve project views every morning. On-demand scans cost nothing, so the export itself is free.
Deployments are an API resource, so a release gate can be code rather than a reminder. A key with Read and write on Projects can check deploy status, and your own wrapper can refuse to call the publish endpoint during the close window. Remember that publishing is asynchronous: a successful POST returns 202 and you poll for status. Retrying a POST is not safe by default, which is exactly the kind of detail a release script has to get right.
One key per integration, each with its own monthly cap, each with its own rate limit, each revocable without touching the others. The cap blocks nothing today, as above, but the structure is what you want in place before the API surface grows. If you are already reporting on run-rate and churn out of a Lovable app, the same discipline applies to the data feeding it: build a SaaS metrics dashboard.
There is no price on the key. There is a price on the plan that lets you create one.
| Plan | Entry monthly price | API key? |
|---|---|---|
| Free | $0 | No |
| Pro | $25 for 100 monthly credits | No |
| Business | $50 for 100 monthly credits | Yes |
| Enterprise | Platform fee plus volume based pricing, no public figure | Yes |
Read logged out on 11 October 2026. The Business ladder runs from 100 credits at $50 a month up to 10,000 credits at $4,300 a month, with the top rungs marked as savings of up to 14 percent, and the monthly to yearly toggle advertises two months free. Pro runs from 100 credits at $25 up to 10,000 at $2,250. Prices move, so check the page rather than this table before you commit. Credit mechanics, rollovers and what an MVP really consumes are in Lovable credits explained.
The honest framing for a finance or operations team: do not buy Business for the API alone. The API as it stands manages and deploys projects and reads security and analytics, which is valuable if you already run several projects in one workspace and worthless if you run one. Buy Business for the team workspace, role-based access, internal publish and SSO, and treat programmatic access as the thing that makes those manageable at scale. If that is where you are heading, the Business plan is the tier that unlocks it.
This is worth stating plainly because it is costing people time. A third-party guide that ranks for this exact search, carrying a last-updated date of September 2026, says that Lovable has no classic public REST API with developer API keys, that a REST developer API with endpoints and static keys still does not exist, and that references to lov_ prefixed API keys come from third-party misinformation.
All three statements are now wrong, and the evidence is on Lovable's own domain:
A second pattern to watch for: several pages cite URLs under lovable.dev/faq/. Those paths now redirect to the documentation FAQ, which is a reasonable signal that the page has not been re-checked since the redirect landed. When a Lovable fact matters, read it on docs.lovable.dev or in the changelog, with the date, and treat everything else as a lead rather than a source. The same habit is why we re-read the pricing page before every article in this series; the full picture is in our Lovable review for 2026.
Open Workspace settings, then Access tokens, and click New API key. Name it, optionally set a monthly credit cap, choose an expiry, grant at least one scope, optionally upload an IP allowlist, then create it and copy the value. The page only works if the workspace is on Business or Enterprise and you are an owner or admin.
You cannot. The secret value is shown once, immediately after creation. The Access tokens page afterwards shows the key's name, who created it, when it was created and last used, its credit usage, scopes, expiry and allowlist, but never the secret. If you lose it, create a new key and revoke the old one.
No. Creating keys requires a Business or Enterprise plan and an owner or admin role. Lovable's own plan comparison shows a dash against Lovable API for both Free and Pro. There is no trial key and no read-only free tier for the REST API.
Yes, since 17 September 2026. It is a versioned REST API at https://api.lovable.dev under /v1, currently at stable version 2026-09-11. It manages and deploys existing projects and reads workspace, analytics and security data. It does not create or edit projects with AI.
Without a key. The free plan includes daily build credits and monthly grants, and you build by chatting in the editor, so nothing about the free experience needs an API key. The key is a management and automation tool for teams running several projects, not a route to the builder. If you want an AI client driving your projects, the MCP server is on all plans including Free and uses OAuth rather than a key.
Not with today's endpoints. The docs state that the public API manages and deploys existing projects and that its current endpoints, including deployment builds through the publish endpoint, do not consume AI build credits. There is no separate API pricing. The per-key monthly cap exists for whatever the API surface becomes later.
A Lovable API key is a Business-and-above workspace token for managing and deploying projects you already have. Scope it narrowly, give every integration its own, set an expiry rather than Never, add the IP allowlist with at least one IPv4 entry, and set a monthly cap even though nothing currently spends against it. Pin the API version. Branch your error handling on the type field. And if a page tells you the API does not exist, check the date on it.
If you are weighing the Business plan for a team that runs more than one project, or you want the setup reviewed before you commit, the Lovable Business plan is the tier that unlocks access tokens, and you can reach TJ through his Lovable Expert directory profile.
TJ Alam is a certified Lovable Expert on the Website Builder track, founder of Digi Flock Enterprises, and the builder behind tjalam.com and cyberdance.in, both built with Lovable. He is listed on the Lovable partner directory. MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.