# AGENTS Source: https://docs.lovable.dev/AGENTS # Documentation agent instructions Lovable is a full-stack app development platform that lets users build web applications through natural language prompts. These instructions define how the Mintlify AI agent should create and update documentation across docs.lovable.dev. Follow them consistently unless explicitly instructed otherwise. ## Accuracy and safety * Do not invent or assume product behavior, limits, pricing, plan availability, or UI elements. * Always specify which plans features are available on (Free, Pro, Business, Enterprise, or "all plans"). * Distinguish between workspace credits (for building) and Cloud/AI balance (for deployed apps). * If information is not clearly documented or provided, do not guess. * Prefer omitting details over adding uncertain or speculative content. * When necessary, ask for clarification instead of making assumptions or filling gaps. * Clearly call out irreversible actions, limitations, and unknowns when applicable. ## Required information flow (core rule) When creating or updating documentation pages, follow this narrative order: 1. **What**: Explain what the feature, connector, or concept is. * Keep this to 1–2 short paragraphs. 2. **Why**: Explain why it matters. * Focus on value, outcomes, and when to use (or not to use) it. 3. **Who**: Explain who it’s for. * Use concrete use cases, example apps, scenarios, or tables. 4. **How**: Explain how it works or how to use it. * Include setup steps, configuration, requirements (accounts, credentials), billing and usage notes, limitations, and irreversible actions. * For **conceptual or reference content**, “How” may describe how the concept works at a high level rather than step-by-step instructions. 5. **FAQ**: Add frequently asked questions to improve clarity, AI assistant retrieval, and search ranking. ## Required section order (default) Use this heading order exactly unless the content clearly does not apply. Always adjust the section titles as it best makes sense: * Intro (describe what it is) * Describe why & when to use it * Common use cases & example apps (describe who would use it and how) * Prerequisites (list external or internal requirements, for example external accounts, workspace roles and permissions, pricing plan requirements) * Setup / configuration (describe how to set up, connect, configure, document the steps and any configurations specifics) * Limitations (list limitations if any) * FAQ (optional, but preferred for SEO, always leave out on specific Connector pages) * Troubleshooting (optional) ## What to include (content checklist) * Add **prerequisites** when users need API keys, accounts, environment setup, or dependencies. * Add **FAQ** to help search engines and the Mintlify AI assistant understand and rank content. * Add **troubleshooting sections** for common issues seen in support tickets. * Clearly call out **billing ownership**, **usage consumption**, and **irreversible actions** when applicable. ## FAQ * Include **3–6 FAQ** on most pages (depending on page size). * Write FAQ as **natural-language questions** users would actually ask. * Prioritize questions about: * Billing and ownership (Lovable vs external provider) * Account, credentials, or API key requirements * Limits, quotas, or rate limits * Deletion, revocation, or irreversible actions * Common misconceptions or failure cases * Keep answers concise, factual, and skimmable. * Avoid marketing language; optimize for clarity and retrieval accuracy. ## Writing principles (global) * Keep intros scannable and short. * Prefer outcomes over features in the “Why” section. * Use concrete, realistic examples in “Who” and “How”. * Make all steps unambiguous, including exact UI paths when relevant. ## SEO and accessibility * Use descriptive, keyword-rich headings aligned with what users search for. * Ensure frontmatter `title` and `description` are clear, specific, and user-focused. * Add a `keywords` array in frontmatter when it improves discoverability (use relevant, specific terms users would search for; avoid keyword stuffing). * Prefer action-oriented page titles. Titles can be longer and more descriptive when helpful. * If the page title is long, add `sidebarTitle` with a shorter version for navigation. * Use specific, actionable link text (avoid “click here”). * Maintain a logical heading hierarchy (don’t skip levels). * Add descriptive alt text for all images and diagrams. * Structure content for scannability using short paragraphs, lists, and clear section breaks. ## Mintlify components (when to use them) Use Mintlify components intentionally to improve clarity and readability. Do not overuse components. ### Callouts * Use `` for helpful context that supports the main content. * Use `` for best practices or expert guidance. * Use `` for destructive actions, irreversible steps, security concerns, or critical limitations. * Use `` to confirm success or provide verification steps. ### Steps * Use `` and `` for multi-step procedures, especially setup and configuration. * Prefer steps when actions must be completed in order. * Include a verification step or success indicator when possible. ### Tabs * Use `` for platform-specific instructions or mutually exclusive alternatives. * Do not use tabs for sequential steps. ### Accordions * Use `` for troubleshooting, FAQs, edge cases, or advanced configuration. * Keep core flows visible; hide deep detail behind accordions. ### Code groups * Use `` when showing the same example in multiple languages. * Use a single code block when only one language is relevant. ## Audience and tone * Write primarily for a **non-technical audience**. * Don’t oversimplify, but explain non-obvious concepts. * Use **active voice** and **second person** (“you”). * Focus on clarity, correctness, and usefulness over marketing language. ## Style and formatting * **Never use em dashes**. * **Active voice**: Prefer active voice to make it clear who performs the action. * Correct: “Delete the project.” * Incorrect: “The project is deleted.” * Exception: Use passive voice when emphasizing the state or outcome. * Example: “The project is saved.” * **Present tense**: * Use present tense for general behavior. * Correct: “Click Save to update settings.” * Use future tense only for future consequences. * Correct: “Your changes will be lost.” * **Sentence case**: * Use sentence case for all headings. * Capitalize only the first word, proper nouns, and acronyms. * Correct: “Project settings” * Incorrect: “Project Settings” * **Serial (Oxford) comma**: * Always include a comma before the final “and” or “or.” * Example: “Edit, share, and delete projects.” * **Dates**: * Use *month day, year* (e.g., *July 31, 2025*). * Don’t use ordinal numbers (1st, 2nd, 3rd). * **UI references**: * Bold UI elements: **Settings**, **Delete project**. * Use inline code for values, fields, or identifiers: `project_id`. * Use exact UI paths with → separators: **Settings → Privacy & security → Default project visibility** ## Prompt examples * Put all prompt examples in **plain-text code blocks**. * Use `text wrap` to preserve readability. Example: ```text wrap theme={null} Integrate the OpenWeatherMap API. Base URL: https://api.openweathermap.org/data/2.5. Auth: API key passed as a query parameter appid. I need an endpoint to fetch the current weather: GET /weather?q={city}&units=metric&appid={API_KEY}. Docs: https://openweathermap.org/current ``` # Lovable changelog Source: https://docs.lovable.dev/changelog Lovable changelog and product updates. Stay up to date with new features, improvements, and bug fixes shipped in Lovable. ### Reuse your workspace identity in the apps you build Apps you build for your team can now [recognize the signed-in Lovable user automatically](/features/lovable-workspace-identity-reuse), with no login page and no second sign-in. Whoever is signed in to Lovable, through workspace SSO, Google, or email, is recognized by the app, so internal tools, admin dashboards, and workspace-only apps do not need to build their own login. Your app can read the current user's name, email, and Lovable user ID directly. This is available on the Business and Enterprise plans for newer projects on the TanStack Start stack, and it is rolling out gradually, so it may not be available for every workspace yet. It does not require workspace SSO to be configured. Workspace admins and owners control it from **Workspace settings → Privacy & security → App login methods**. To use it in a project, ask Lovable to reuse the signed-in user instead of adding a login page. ### Connect your app to Apollo.io You can now connect your Lovable app to [Apollo.io](/integrations/apollo) to search its B2B database of people and companies, enrich contact and organization data, and manage contacts, accounts, and deals. It fits prospecting dashboards, lead-enrichment forms, and internal sales tools built on live Apollo data. Add it from **Connectors**, or ask Lovable in a project to connect it. ### Choose which Wiz policies run during security scans If you use the [Wiz connector](/integrations/wiz) for security scanning, you can now choose which Wiz CI/CD policies run during a scan. Workspace admins and owners set a comma-separated list of policy names in the connector's **Advanced settings → CI/CD scan policies**. Leave it blank to keep running your Wiz tenant's default policies, as before. If a policy name is unknown, the scan now surfaces a visible **Wiz scan failed** finding in the project's **Security** view. ### Let AI assistants use your published app Your published app can now be used by AI assistants such as ChatGPT and Claude, not just by people in a browser. With [agent integrations](/features/agent-integrations), Lovable turns your app's functionality into actions an assistant can call. If you built a booking app, for example, your users can connect it to their assistant and ask it to look up availability and book a time, and the assistant uses your app to do it. Enable it from **More → Agent integrations** in the editor by selecting **Enable agent integrations**, or ask Lovable to add agent integrations to your app. Lovable proposes the actions, you choose who can call them, and you get an MCP link that your users add to their AI assistant. Only publicly published apps are supported for now. ### Automatically delete abandoned projects Enterprise workspaces can now [clean up abandoned projects automatically](/features/privacy-and-security-settings#abandoned-projects), published and unpublished alike. Workspace admins and owners configure it under **Settings → Security → Privacy & security → Abandoned projects**: choose when a project counts as abandoned and how long after that it is deleted. Auto-delete is off by default. A project stays active while someone works on it in the editor, visitors use the published app, or its backend functions run; just opening or previewing it does not count. Before a project is deleted, its owner and members with edit access receive warning emails and see an in-project banner 5 days and 1 day ahead. Editing the project, sending it a message, or selecting **Keep it** cancels the deletion. Lovable keeps a deleted project for 60 days, and support can bring it back within that window. ### GPT-5.6 and Gemini text-to-speech models for your app's AI features Your app's [AI features](/integrations/ai) can now use OpenAI's GPT-5.6 preview models for chat and text: * **GPT-5.6 Sol** for the hardest reasoning and coding tasks * **GPT-5.6 Terra** for everyday work at lower cost * **GPT-5.6 Luna** for fast, high-volume tasks For voice features, Google's Gemini text-to-speech models are also available: * **Gemini 2.5 Flash TTS** for cost-effective speech * **Gemini 2.5 Pro TTS** for higher-fidelity voices * **Gemini 2.5 Flash Lite Preview TTS** for lightweight speech tasks, in preview * **Gemini 3.1 Flash TTS Preview** for the newest Gemini voices, in preview Ask Lovable to use any of these models in your app. Usage is billed per token, and you do not need your own OpenAI or Google API keys. ### Email alerts for sign-ins from a new device and country When someone signs in to your Lovable account from both a device and a country that have not been seen on your account before, you now receive a [sign-in alert email](/introduction/lovable-account-settings#sign-in-alerts). The email shows the country, the browser and operating system, the time, and the sign-in method that was used. If the sign-in was you, no action is needed. If you do not recognize it, follow the instructions in the email to reset your password and secure your account. These emails are always sent, regardless of your email preferences. ### Password reset is unavailable for accounts without a password If your account signs in only through Google, GitHub, Apple, or SSO, selecting **Forgot password?** no longer sends a password-reset email. You see a **Password reset unavailable** message instead. Sign in with the provider you used to create your account, and manage your password through that provider. See [Reset your password](/introduction/create-an-account#reset-your-password). ### See images, videos, and files the agent works with in chat When the agent generates or refers to files, chat now shows them as thumbnails instead of a list of file paths. Ask something like "show me my images" and you get a gallery of clickable tiles right in the conversation. Images and videos appear as visual previews, and other file types like PDFs, documents, and audio appear as labeled tiles. Click a tile to open it: files stored in your project open in the [**Files** panel](/features/projects/editor#project-toolbar), and freshly generated images open in a preview. This works for files in the Files tab, images the agent just generated, and assets in your project's code. ### Emails and confirmations for workspace role and membership changes You now get email notifications when [membership changes](/features/people#manage-existing-members) in your workspace. When someone is made an admin or owner, the workspace's other admins and owners receive an email that names the person, their new role, and who made the change. When someone is removed from a workspace, that person receives an email. When you invite or promote someone to admin or owner, Lovable shows what the role includes: admins can manage workspace members, billing, integrations, and settings, and owners have full control of the workspace, including billing and managing other owners. Promoting an existing member to admin or owner also asks you to confirm first. ### The Lovable badge returns on your next publish after a downgrade Hiding the **Edit with Lovable** badge on your published site is a paid feature, available on the Pro, Business, and Enterprise plans. If your workspace moves to a plan that doesn't include it, the badge now comes back the next time you publish that project. Sites that are already live stay as they are until you republish them. ### Clearer visitor analytics toggle in project settings The analytics control in **Project settings → Publishing** is now labeled **Visitor analytics**, replacing the older **Disable analytics** toggle. Turn it on to collect visitor analytics for your published app, and turn it off to stop collecting. Your existing setting carries over, so nothing changes for your project. ### Let your app's users connect their own accounts [App user connectors](/integrations/app-user-connectors) let each person who uses your published app connect their own third-party account, so your app acts on their behalf, with their own permissions and only their data. This is different from a standard app connector, where you connect one account once and every visitor shares it. Use it when your app is multi-tenant by nature: a signed-in user should see their own inbox, their own calendar, or their own CRM records. Supported providers include Google, Microsoft, Slack, Salesforce, HubSpot, Linear, Databricks, and Snowflake. As the builder, you configure a client once for your workspace, then each user signs in with their own account the first time they use it. Setting up a client follows the same access rules as other app connectors. ### Mapbox connector You can now connect your app to [Mapbox](/integrations/mapbox) to embed interactive maps with Mapbox GL JS, geocode addresses, and calculate routes and directions. Add it from **Connectors**, or ask Lovable in a project to connect it. Mapbox uses your own Mapbox access tokens, so Mapbox usage is billed to your Mapbox account. ### Connect KLIPY in one click, no API key The [KLIPY GIF connector](/integrations/klipy) now offers a **Managed by Lovable** authentication option: connect in one click, with no KLIPY account or API key. Lovable provisions and manages a workspace-level key for you. Under **Authentication**, select **Managed by Lovable**. You can create one managed KLIPY connection per workspace, and it is shared with the whole workspace by default. To limit who can use it, select **Restrict to specific people** under **Who can use this connection**. The **Bring Your Own Key** option remains available if you want to manage your own KLIPY account, content, and usage limits. ### Redesigned settings All workspace and project settings pages now use a consistent layout, with section cards, compact rows, and a refreshed sidebar with new icons. As part of the redesign, two sidebar sections were renamed: **Members & access** is now **Access**, and **Security & compliance** is now **Security**. Everything stays under **Settings**. [Groups](/features/groups) also open in a dedicated detail page now instead of expanding inline: select a group in **Settings → Groups** to search its member list, add or remove members, change group roles, or delete the group. Existing links to a specific group forward to the new page. ### Functions usage is now labeled Compute The [Cloud usage](/introduction/credits-and-usage#cloud-costs) category that was labeled **Functions** is now labeled **Compute**, which better reflects that it covers both the edge functions and the workers running your app. Find it under **Settings → Plans & credit usage → Usage details**. This is a labeling change only, so what counts toward the category has not changed. ### Collapse and expand the code file tree In the [Code view](/features/code-mode), you can now collapse or expand all folders in the file tree at once with new controls next to the search box, which makes it easier to get an overview of a large project. ### Sign in to Lovable from your identity provider's portal Members of Business and Enterprise workspaces that use [SAML single sign-on](/features/business/sso) can now sign in by clicking the Lovable tile in their identity provider's app portal, such as Okta or Microsoft Entra, instead of starting at lovable.dev. Workspace admins and owners turn this on in the SAML provider setup under **Settings → Members & access → Identity**. The setup wizard now shows a dedicated IdP-initiated ACS URL to add to your identity provider, along with its requirements. Group restrictions are enforced the same way as standard SSO sign-in. IdP-initiated sign-in works only while your workspace is the only one that has verified your email domain, and it turns off automatically if another workspace verifies the same domain. The SAML response must be signed and scoped to the SP Entity ID. ### See project status in your browser tab The browser tab for a project now shows a status badge on its icon, so you can tell what Lovable is doing without switching back to it. The badge appears while Lovable is building, changes when Lovable needs you to approve an action, and clears when the work is done. ### App connectors: dbt Semantic Layer and ClickHouse [dbt Semantic Layer](/integrations/dbt-semantic-layer) lets apps query governed metrics from your dbt Cloud Semantic Layer, sliced by dimension and time grain, without writing warehouse SQL. Use it for internal dashboards, customer-facing analytics, and AI features that answer with the metric definitions your data team already maintains in dbt. The connector is read-only. [ClickHouse](/integrations/clickhouse) lets apps run SQL queries against a self-hosted or ClickHouse Cloud database over its HTTP interface. Use it for analytics dashboards, log and event explorers, and other apps built on top of your OLAP data. Add it from **Connectors**, or ask Lovable in a project to connect it. ### Connect BigQuery with your Google account You can now link the [BigQuery connector](/integrations/bigquery) by signing in with Google, without setting up Workload Identity Federation. Select **Connect with Google**, enter the Google Cloud project ID that queries should run in, and approve access. Queries run as your own Google account, and BigQuery usage is billed to your Google Cloud project. The **Bring Your Own Key** option remains available for connecting with a service account through Workload Identity Federation, which suits teams that do not want the connection tied to one person's Google account. ### Approve connector actions before they run When Lovable wants to use one of your [app connectors](/integrations/introduction) to make a change, such as sending a message or updating a record, it now pauses and [asks for your approval](/integrations/introduction#approving-connector-actions-in-chat) first. The approval card describes what Lovable wants to do and shows the request details. Read-only requests keep running without prompts. Select **Allow once** to approve a single action, **Always allow** to let future actions for that connection run without asking, or **Skip** to move on without running the action. The **Always allow** preference applies to you and that connection, and you can change it later from the connection's settings. ### Enterprise member profiles are now private by default Public Lovable profiles of Enterprise workspace members are now hidden by default. People outside the workspace can no longer open a member's public profile page, and public project pages no longer show the member's name and avatar as the publisher. Members of the same workspace still see each other's profiles. Workspace admins and owners can make member profiles public again with the [Public member profiles](/features/privacy-and-security-settings#public-member-profiles) setting in **Settings → Security & compliance → Privacy & security**. ### Workspace invitations expire after 30 days Unaccepted [workspace invitations](/features/people#invite-by-email) now expire 30 days after they are sent. An expired invitation disappears from the People tab and can no longer be used to join the workspace on any path, including the invitation email, invite links, domain auto-join, and SSO sign-in. Invitation emails now state the expiry date. To bring someone in after their invitation expires, invite them again: a new invitation starts a fresh 30-day window. This also applies to invitations that were already pending, so any invitation sent more than 30 days ago has expired. ### Improved image gallery in the Files tab The [Files tab's](/features/generate-files#manage-generated-files) grid view now shows images at their real proportions instead of cropping them to uniform squares, so a project's images are easier to scan. Each file also gets quick actions: hover an image and select **Reference** to add it as a reference in chat, or open the file actions menu to reference the file, download it, copy an image to your clipboard, or delete it. Deleting a file cannot be undone. ### Search your settings You can now filter settings from a search box in the [settings sidebar](/features/workspace-admin-settings). Start typing in **Search settings** at the top of the sidebar to narrow the list to matching sections in both workspace settings and [project settings](/features/projects/settings). Search matches setting names and common synonyms, so typing `env` surfaces build secrets and `sso` surfaces identity settings. If nothing matches, you see **No matching settings**. ### Reference a connector in chat You can now reference an [app connector](/integrations/introduction) directly in a chat message. Type `@` in the chat input and pick an app connector from the list to insert it as a reference while you describe what you want to build. The picker shows popular app connectors by default and filters as you type. ### Pause a Lovable Cloud project You can now manually [pause a project's Lovable Cloud backend](/integrations/cloud#pause-cloud) so it stops using compute credits while you are not working on it. Open **Cloud tab → Overview → Advanced settings**, select **Pause**, and confirm the action. While paused, the project's database, authentication, storage, and edge functions are unavailable, so the live app stops working until you resume. Your data is preserved and pausing is fully reversible: select **Wake up** to bring the backend back online. Storage still counts toward usage while a project is paused. ### Resize your Cloud instance from chat You can now ask Lovable in chat to [resize your project's Lovable Cloud compute instance](/integrations/cloud#ask-lovable-to-resize-your-instance), instead of opening Advanced settings yourself. Describe the problem, such as a backend that is slow under load, and Lovable offers a size picker (Tiny through Large) with your current size preselected. Resizing changes the compute instance, its CPU and memory, not your database storage. A larger instance handles more traffic and heavier database work and increases your ongoing Cloud usage, and a smaller instance reduces it. Resizing takes a few minutes, during which the backend is briefly unavailable. Available on Pro, Business, and Enterprise plans, for Lovable Cloud projects, and requires permission to edit the project. ### Configure SSO Just-in-Time provisioning from settings Workspace owners and admins on Enterprise plans can now turn [SSO Just-in-Time (JIT) provisioning](/features/workspace-identity#sso-sign-in) on or off themselves. Open **Settings → Members & access → Identity**, find **User provisioning**, and use the **SSO Just-in-Time provisioning** toggle under **SSO sign-in**. When it is on, people who sign in through your SSO provider for the first time are added to your workspace automatically, with the role you set on the provider. On Business plans, SSO sign-in provisioning turns on automatically once an SSO provider is configured, and its status is shown as read-only. ### Workspace insights now on Business plans Workspace admins and owners on Business plans can now use [Workspace insights](/features/workspace-insights) to review and govern every project in the workspace from one place, which was previously available only on Enterprise. Open it from **Settings → Security & compliance → Security center → Workspace insights**. You get the full project inventory with search, filters, and sorting, along with summary cards, CSV export, and the option to run a security scan. Detecting and scanning for personal identifiable information (PII) remains available only on Enterprise plans. ### Images Lovable generates are labeled as AI-generated Images that Lovable's AI generates or edits for your project now include standard provenance metadata (IPTC) that marks them as AI-generated. This covers images from the agent's image generation and editing, social preview images, and image variants created in the visual editor. Platforms and tools that read this metadata, such as Google and some social networks, can then label the images as AI-generated. This applies to newly generated images and does not change how images are generated or what they cost. Images your app generates through its own AI features are not affected. ### Nano Banana 2 Lite image model for AI features in your app [Lovable AI gateway](/integrations/ai) now supports Nano Banana 2 Lite, Google's `gemini-3.1-flash-lite-image` model, for AI features inside your app. Use it as a faster, lower-cost option for image generation and editing workflows, such as drafts, thumbnails, visual variants, and editing tools. ### Restrict workspace access by SSO group Workspace owners and admins on Business and Enterprise plans can now map IdP groups to workspace roles for their [SSO provider](/features/business/sso). Open the provider from **Settings → Identity**, then use the **Groups** tab to map IdP groups to viewer, editor, or admin roles. When someone signs in through SSO, Lovable assigns the mapped role if their IdP group matches. Everyone else gets the default JIT role. Turn on **Group restriction** to limit access to mapped groups only. Anyone without a matching IdP group is blocked from signing in, so map every group that needs access before turning it on. ### Sign in with SSO using your company domain or provider ID Business and Enterprise users can now start [SSO sign-in](/features/business/sso) with a company domain or provider ID, instead of needing the workspace URL name. On the SSO login page, enter your company domain, such as `acme.com`, or your provider ID, such as `saml.okta-acme`. Lovable finds the matching SSO provider, and if more than one provider matches, you can choose which one to use. ### App connector: GitHub API [GitHub API](/integrations/github-api) lets the apps you build read repositories, track issues and pull requests, follow releases and workflow runs, and build automations around your engineering work. Use it for issue triage boards, PR status hubs, release trackers, repository health dashboards, contributor activity feeds, and internal tools powered by GitHub. Add it from Connectors, or ask Lovable in a project to connect it. This is separate from [GitHub Git sync](/integrations/github). Use the GitHub API connector when your app needs to work with GitHub data. Use GitHub Git sync when you want to export or sync your Lovable project’s code to a GitHub repository. ### Find in page, clipboard, and location in the desktop app The [Lovable desktop app](/integrations/desktop-app) now supports more browser behavior in app previews. Use **Cmd+F** on macOS or **Ctrl+F** on Windows to find text on the current page, then move through matches with **Cmd/Ctrl+G** and **Cmd/Ctrl+Shift+G**. Apps you preview can also copy to your clipboard, read from your clipboard after you allow access, and request your location. Lovable asks the first time an app tries to read your clipboard or use your location, with permissions scoped to that app. ### Search from the dashboard project tabs The [dashboard’s project tabs bar](/introduction/project-search-and-find#search-from-the-dashboard-project-tabs) now has a **Search** entry. Select it and the tabs turn into a search box that filters across all your project lists at once, so you do not have to switch tabs to find a project. Type to filter by a project’s name or owner, and select **X** or press **Escape** to close the search box. ### The last owner cannot leave a shared folder The only owner of a personal folder that is shared with others can no longer leave it. The **Leave folder** action is disabled with a note explaining why, so the folder is never left without an owner. ### Reorder folders shared with you You can now reorder personal folders that are shared with you by dragging them in the sidebar, alongside your own folders. Reordering only changes a shared folder's position at the same level, it does not move it into or out of another folder. ### Lovable Desktop app is now on Windows The [Lovable desktop app](/integrations/desktop-app) is now available on Windows, alongside macOS. The desktop app includes the full web experience along with support for local MCP servers, multi-project tabs, and keyboard shortcuts. ### Recover access when an SSO provider is removed Members can now recover access from the login page if their workspace’s SSO provider is removed, without contacting an admin. On Business and Enterprise workspaces, the login page now detects when a member’s only sign-in method was deleted. If the workspace has a new SSO provider, they can sign in with it to reconnect their account. If no replacement provider is available, Lovable emails them a link to set a password instead. ### Export or remove Lovable Cloud data If your app uses [Lovable Cloud](/integrations/cloud), you can now export your database and remove Lovable Cloud from a project, both from **Cloud tab → Overview → Advanced settings**. Available on all plans. * [**Export project data**](/integrations/cloud#export-lovable-cloud-data): download your database as an SQL dump. Select **Export data** to start the export, and Lovable emails you a download link when it is ready. Exports are limited to 5 GB, one per project every 24 hours. Storage files are downloaded separately from the **Storage** tab. * [**Remove Lovable Cloud**](/integrations/cloud#remove-lovable-cloud): permanently delete the project's Cloud-managed database, storage, authentication, and functions when you no longer need them. This cannot be undone, so export your data and download any storage files first. ### Workspace admins and owners can transfer projects again Workspace admins and owners on Enterprise plans can once again transfer projects to another workspace from the project menu, even when [Editor project transfers](/features/privacy-and-security-settings#editor-project-transfers) is disabled. This fixes a bug where that setting could incorrectly block admins and owners from transferring projects. Editors still need **Editor project transfers** turned on to transfer projects they own. The disabled **Transfer** button now also explains what is blocking the action. ### Queued messages no longer overlap Queued messages now stay aligned when you remove or reorder items while Lovable is working. This fixes a bug where deleting a message from the queue could leave the remaining messages visually overlapping. ### Connectors page in projects Every project now has a [**Connectors**](/integrations/introduction) page where you can see the services connected to it in one place. Open it from **More → Connectors** in the project toolbar. It shows app connectors under **App connections**, and the MCP servers your project can access under **Chat connectors**. To browse the full catalog, select **All connectors**. You still manage each connection from its own connector page. ### App connector: WordPress (self-hosted) [WordPress (self-hosted)](/integrations/wordpress) lets apps work with content from WordPress sites you host yourself, separate from the WordPress.com connector for sites hosted on WordPress.com. Use it to build blogs, marketing sites, help centers, editorial dashboards, content workflows, and headless CMS experiences that pull from your WordPress posts, pages, custom post types, media, categories, tags, and user profiles. Add it from **Connectors**, or ask Lovable in a project to connect it. ### Restrict who can download project code Enterprise workspaces can now control who can download project source code from Lovable. Workspace admins and owners can open **Settings → Security & compliance → Privacy & security** and disable [Code downloads](/features/privacy-and-security-settings#code-downloads). When code downloads are disabled, only workspace admins and owners can download a project’s source code as a zip file. Other members see the download option disabled. This only controls zip downloads from Lovable. It does not affect access to connected GitHub or GitLab repositories, or the ability to view code in the editor. ### Project monitoring (Beta) [Project monitoring](/features/project-monitoring) is now in beta on Pro, Business, and Enterprise workspaces. Turn it on for a project to have Lovable check your app on a schedule, review your code, and look at recent visitor errors. When Lovable finds an important issue, project editors see the finding above chat, and the project owner gets an email for important or time-sensitive findings. Monitoring is opt-in per project, and any project editor can turn it on from [**Project settings**](/features/projects/settings#project-monitoring), choose a daily or weekly schedule, and set a minimum number of project edits before a check runs. Run history in project settings shows previous checks, results, and credit usage. ### Faster AI responses in your app with OpenAI priority processing You can now ask Lovable to make AI features in your app respond faster. When you ask for lower latency, Lovable can use [priority processing](/integrations/ai#faster-responses-with-priority-processing) for supported OpenAI chat models through the Lovable AI Gateway. Use it when speed matters, such as chat features, assistants, copilots, and other interactive AI experiences. ### Set a default hosting region for new projects Workspace admins and owners on Business and Enterprise plans can now set a [default hosting region](/features/privacy-and-security-settings#default-hosting-region) for new Lovable Cloud projects. Set it from **Settings → Security & compliance → Privacy & security → Default hosting region**, and choose **Americas**, **Europe**, or **Asia Pacific**. When a default region is set, every new Cloud project in the workspace uses that region, and members cannot choose a different one when creating a project. The setting only applies to new projects. Existing projects keep the region they were created in, and are not migrated. Setting a default hosting region requires new projects to use a micro database instance or higher, which may use more credits. ### App connector: X [X](/integrations/x) (formerly Twitter) lets apps look up users, search recent public posts, and read public post details. Use it for social dashboards, profile lookups, keyword monitoring, social proof widgets, event hashtag trackers, influencer directories, and brand mention boards. The connector is read-only, so apps can fetch public X data but cannot post, like, follow, or send DMs. Add it from **Connectors**, or ask Lovable in a project to connect it. ### Fewer taps to attach images on mobile On the [Lovable mobile app](/integrations/lovable-mobile-app), attaching an image to a message now takes fewer taps. Tapping the add button opens your device's photo, camera, and file picker directly, instead of going through an extra menu first. ### App connectors: KLIPY and Logo.dev [KLIPY](/integrations/klipy) lets apps search and embed GIFs, stickers, and short clips, generate AI emojis on demand, and add trending media pickers. Use it for chat, social, commenting, reactions, meme feeds, and custom emoji tools. [Logo.dev](/integrations/logo-dev) lets apps display company logos by domain, stock ticker, or crypto symbol. Use it for dashboards, directories, marketplaces, CRM views, profile cards, and company search experiences. Add it from **Connectors**, or ask Lovable in a project to connect it. ### Comments in shared app previews People with a preview link can now leave comments directly on the app preview, even without a Lovable account. Guest comments are on by default for [shared preview links](/features/share-project#share-preview-links), and you can turn them off from the **Share** dialog. Guests can click **Comment** in the [preview toolbar](/features/preview-toolbar), click anywhere on the preview to pin feedback, and follow the conversation in the comments panel alongside the preview. ### Paste an API key in chat and Lovable saves it as a secret You can now paste an API key or token into chat and Lovable will save it as a project secret automatically. When Lovable detects a key, it replaces the value with a labeled tag, such as `OPENAI_API_KEY`, before you send the message. The real value stays out of the message and chat history, while the agent can still use the secret by name when helping you build. ### 8-hour session option for enforced SSO Workspace admins and owners on Business and Enterprise plans can now set enforced SSO sessions to expire after 8 hours. The new option sits alongside the existing 24-hour, 48-hour, and 7-day durations. Members who [sign in with SSO](/features/business/sso) are asked to re-authenticate after the selected period. Set it from **Enforce SSO** in your workspace identity settings. ### Search the template and design system pickers When you start a project from a template or attach a design system, the picker now has a search box. Type to filter the list by name instead of scrolling, and clear the search to see everything again. ### Let Lovable debug and improve your app's AI features Lovable can now use your app's [AI activity](/integrations/ai#monitor-ai-usage-and-activity) to help debug failing requests, improve prompts, and reduce cost and latency. When you ask for help, Lovable can see request summaries from the **Cloud → AI** tab, including status, model, token usage, cost, and duration. To let Lovable inspect the full request and response, turn on **AI app context** in [project settings](/features/projects/settings#publishing). ### Detach a design system from a project Enterprise workspaces can now detach a [design system](/features/design-systems) from a project. Open the project's design system settings, then select **Remove**. The design system's files stay in your project under `src/design-system` as regular code you can edit, but the project stops receiving updates from the design system. Detaching is permanent: to reconnect, you attach the design system again from scratch. ### Keep collaborators when you transfer a project to another workspace You can now choose whether to keep project collaborators when moving a project to another workspace. The **Transfer to workspace** dialog now includes a **Transfer project collaborators** checkbox. Leave it off to remove direct collaborators and pending invites from the project during the move. Turn it on to bring them along, as long as the destination workspace settings allow their role and you have permission to grant it. ### Manage scheduled jobs in Lovable Cloud If your app uses Lovable Cloud, you can now manage scheduled jobs from the new [Jobs](/integrations/cloud#jobs) tab in your project's Cloud panel. Use it to see every scheduled job, its status, schedule, last run time, and run history. You can also enable or disable jobs without leaving the page. Creating jobs, changing schedules, and deleting jobs still happens in SQL or by asking Lovable. The *Jobs* view gives you a clearer way to understand what is running in the background, how often each job runs, and which jobs may be driving credit usage. ### App connector: Calendly [Calendly](/integrations/calendly) lets your apps build booking and scheduling flows using Calendly account data. Apps can read the connected user and organization profile, list event types and scheduled events, fetch invitee details, create single-use scheduling links, and cancel scheduled events on behalf of the connected user. Add it from *Connectors → App connectors*, or ask Lovable in a project to connect it. ### Lovable MCP updates The [Lovable MCP server](/integrations/lovable-mcp-server) is now listed in the Azure API Center directory, making it easier for enterprise teams to discover and connect Lovable from Microsoft tools like Copilot Studio and Azure AI Foundry. ### Cleaner preview error messages Preview error messages now have a cleaner, more consistent design and behavior, making them easier to understand and act on when something goes wrong. ### Workspace insights for Enterprise governance Workspace admins and owners on Enterprise plans can now use [Workspace insights](/features/workspace-insights) to review and govern every project in the workspace from one place. Open it from *Settings → Security & compliance → Security center → Workspace insights*. Workspace insights brings together security findings, PII findings, ownership, lifecycle, cost, publish status, and activity across projects, then gives each project a review priority of *High*, *Medium*, *Low*, or *Not scanned* so the projects that need attention rise to the top. ### Restrict external collaborators without enforcing SSO Workspace admins and owners on Business and Enterprise plans can now limit how much access [external project collaborators](/features/privacy-and-security-settings#external-project-collaborators) can have, without enforcing SSO. Previously, this control was only available for workspaces with SSO enforcement turned on. Open *Settings → Privacy & security* and set *External project collaborators* to the highest project role someone outside the workspace can have: *Allow all*, *Allow editors and viewers*, *Allow viewers*, or *None allowed*. ### Set up Okta SSO and SCIM from the Okta app catalog Lovable is now a verified app in the Okta Integration Network. Workspace admins and owners can search for Lovable in their Okta app catalog and set up [single sign-on](/features/business/sso) and [SCIM provisioning](/features/business/scim) through a guided, pre-built flow, instead of copying metadata, ACS URLs, and SCIM endpoints by hand. ### A more compact Show toolbar button When you hide the [preview toolbar](/features/preview-toolbar), the control to bring it back is now an icon-only button instead of a labeled one, freeing up horizontal space in the project toolbar. You can find it at the top of the preview, next to *Share* and *Publish*. ### Better standard image generation while building Lovable now uses GPT Image 2 for standard-quality image generation when creating image assets for your app, with better results for text, fine details, and polished visuals. ### Browser testing is more integrated [Browser testing](/features/browser-testing) now runs more directly as part of Lovable’s regular app-building flow, making it easier to test changes against your live preview before confirming they work. ### Lovable MCP updates The [Lovable Model Context Protocol (MCP) server](/integrations/lovable-mcp-server) now connects natively to Cursor and is listed in the GitHub MCP directory, making it easier to build from Cursor, Visual Studio Code, and other supported tools. ### Aikido penetration testing is now available on all plans [Aikido penetration testing](/integrations/aikido) is now available on all Lovable plans. Use Aikido to run AI-powered penetration testing, identify exploitable vulnerabilities through dynamic testing, sync findings into your project’s Security view, and generate downloadable reports for security reviews, compliance workflows, and stakeholder communication. ### Verified-domain teammates now join projects with the right workspace role On Business and Enterprise workspaces with verified-email JIT provisioning enabled, project invites now add verified-domain teammates with the workspace’s default provisioning role and no longer treat them as external collaborators. Existing verified-domain collaborators are updated the next time they are invited to a project. ### Filter audit logs by restricted projects Enterprise workspace admins and owners can now use the *Resources* filter in *Settings → Audit logs* to find any project in the workspace, including restricted projects they are not a member of. The picker also shows each project’s owner, making it easier to review activity across the whole workspace. ### TanStack Start is now the default for Enterprise apps New Enterprise apps now use TanStack Start with server-side rendering by default, matching the default stack used for other new Lovable apps. ### One credit balance and clearer usage insights Lovable now uses one credit balance for building your app, hosting and running it with Lovable Cloud, and AI features your deployed app uses. Go to *Settings → Plans & credit usage* to see your balance, manage one-time top-ups and auto top-up, review included grants, and understand where credits are spent. Build credits continue to work as before. Cloud and AI usage now use credits instead of separate dollar balances, and any remaining Cloud or AI balance was converted into credits at your plan’s credit rate. Cloud and AI costs have not changed. The old Cloud and AI balance tab, Cloud and AI specific top-ups, and dollar-based auto top-up have been replaced by credit-based controls in *Plans & credit usage*. Use the credit balance view to see your credit types, expiry dates, and recent credit activity. Open *Usage details* to see *Build credits* and *Run credits* by time range, project, person, and group, depending on your plan and role. Build credits show credits spent planning, generating, editing, and updating apps. Run credits show Lovable Cloud and Lovable AI gateway usage together, including Cloud usage by Database, Network, Storage, Functions, and Realtime, and Lovable AI Gateway usage by the top three models using credits. Learn more in [Credits and usage](/introduction/credits-and-usage). ### Ask Lovable about your workspace’s credit usage You can now ask Lovable about your workspace’s [credit usage](/introduction/credits-and-usage) directly in chat. Ask a question about credits, spend, or cost, and Lovable looks up your usage using the same numbers shown in *Settings → Plans & credit usage*. Try prompts like *How many credits did this workspace use this month?*, *How many credits have I used?*, *Which project used the most Run credits?*, *Which Lovable AI Gateway model is using the most credits?*, or *Which Lovable Cloud category is driving usage?* Usage answers follow the same visibility rules as *Usage details*, so Lovable only shows the usage data your role is allowed to see. ### Add voice to your app with text-to-speech and speech-to-text [Lovable AI gateway](/integrations/ai) can now turn text into spoken audio and transcribe audio into text, so you can build voice features into your apps without a separate voice provider or API key. Describe what you want, and Lovable wires up the backend and picks the right model. Use [text-to-speech](/integrations/ai#text-to-speech-models) to read articles aloud, narrate AI-generated stories, or build a voice assistant that talks back. Use [speech-to-text](/integrations/ai#speech-to-text-models) to add dictation, transcribe voice notes, or turn a meeting recording into notes and action items. You can combine both to build two-way voice experiences like assistants and translators. ### Inspect your app's AI activity Every project now has an [AI activity dashboard](/integrations/ai#monitor-ai-usage-and-activity) under *Cloud → AI* that shows what your app's built-in AI features cost and how they are performing. Use it to track spend, spot failed requests, and inspect individual AI calls. Each request shows its status, the model used, the input and output tokens, the credits it cost, and how long it took. Turn on *Capture request details* to store the redacted request and response for each call, so you can open one and see exactly what was sent and returned. Secrets are removed before storage, and captured details are kept for 90 days. AI activity is available on all plans. Free workspaces can view the last 24 hours; paid plans can view the last 90 days. ### Publish and install private npm packages Enterprise workspaces can now host a [private npm registry](/features/private-registry) inside Lovable. You can publish internal packages, like a shared design system or utility library, without making them public, and install them in any project in your workspace. Workspace owners and admins set it up from *Settings → Build & deploy → Private registry* by selecting *Provision registry* and creating a service account key. Any workspace editor can then view the published packages. ### Require the workspace editor role to edit projects Enterprise workspace admins and owners can now require that only members with the workspace editor role or higher can edit projects. Turn on [*Require workspace editor role*](/features/privacy-and-security-settings#require-workspace-editor-role) in *Settings → Privacy & security*. When it is on, workspace viewers and external collaborators can still view projects but cannot edit them, even if they own a project or were given editor access to it directly, through a folder, or through a group. The setting is off by default. ### Change nameservers for a domain bought through Lovable If you bought a domain through Lovable, you can now [point it at your own custom nameservers](/features/custom-domain#change-nameservers-for-a-domain-bought-through-lovable), for example Cloudflare, instead of letting Lovable manage its DNS. Workspace admins and owners can change nameservers from *Workspace settings → Workspace domains* by selecting *Configure* next to a domain and editing the *Nameservers* section. Select *Reset to Lovable* to hand DNS back to Lovable. When you switch to custom nameservers, Lovable stops managing the domain's DNS, so any connected site and its email stay offline until you recreate the records at your provider. ### Clearer personal folder access management On Business and Enterprise plans, managing who can access a [personal folder](/introduction/project-folders#personal-folders) is now clearer. The option to share a folder is labeled *Manage access*, and new tooltips explain how folder access works, including how the projects inside a folder inherit access and which roles you can grant. ### LinkedIn skills If your projects qualify you for a [LinkedIn skill](/introduction/lovable-account-settings#linkedin-skills-beta) based on how you use Lovable, you can now show it on your LinkedIn profile from *Settings → Your account*. Your skill appears on LinkedIn under *Connected apps*, in the Lovable app's details, describing what you build. You can show one skill at a time. You can disconnect at any time to remove it. This replaces the previous *Vibe coding level*, which LinkedIn no longer supports. ### Choose your interface language You can now choose the language Lovable uses in *Settings → Your account → Language*. Your choice is saved to your [account](/introduction/lovable-account-settings) and applied automatically when you sign in on any device. Lovable is currently available in 11 languages: English, French, German, Spanish, Portuguese (Brazil), Italian, Hindi, Indonesian, Japanese, Korean, and Thai. Not every part of Lovable is translated yet. ### App connector: Lightspeed [Lightspeed](/integrations/lightspeed) lets your apps work with Lightspeed Retail (X-Series) store data, including products, inventory, outlets, registers, customers, and sales. Add it from *Connectors → App connectors*, or ask Lovable in a project to connect it. Use it for retail dashboards, inventory tools, and store reporting. ### Build in Lovable from Claude The [Lovable MCP server](/integrations/lovable-mcp-server) now connects natively to Claude, so you can build, ship, and manage Lovable projects without leaving Claude's products. ### A refreshed color palette Lovable's interface now uses a new color system for a cleaner, more consistent look and improved readability. ### App connectors: Chargebee, GatewayAPI, Lexware, Pipedrive, PrestaShop, Sevdesk, Wave, Wix, WooCommerce, Zoho Books, and Zoho CRM Eleven new app connectors let your apps work with more CRM, accounting, e-commerce, billing, and messaging services. Add them from *Connectors → App connectors*, or ask Lovable in a project to connect one. * [Chargebee](/integrations/chargebee) lets apps manage customers, subscriptions, invoices, checkout, and billing workflows. * [GatewayAPI](/integrations/gatewayapi) lets apps send SMS and RCS messages, track delivery, and handle inbound messages. * [Lexware](/integrations/lexware) lets apps work with contacts, invoices, quotations, vouchers, and accounting data. * [Pipedrive](/integrations/pipedrive) lets apps manage deals, people, organizations, activities, leads, and pipelines. * [PrestaShop](/integrations/prestashop) lets apps read and manage catalog, order, customer, and inventory data. * [Sevdesk](/integrations/sevdesk) lets apps manage contacts, invoices, orders, vouchers, and bookkeeping workflows. * [Wave](/integrations/wave) lets apps manage customers, products, invoices, estimates, vendors, and accounting data. * [Wix](/integrations/wix) lets apps work with Wix sites, e-commerce, bookings, CRM, CMS, and business resources. * [WooCommerce](/integrations/woocommerce) lets apps manage products, orders, customers, coupons, and store data. * [Zoho Books](/integrations/zoho-books) lets apps manage customers, invoices, bills, expenses, projects, and accounting records. * [Zoho CRM](/integrations/zoho-crm) lets apps read, search, create, and update leads, contacts, accounts, and deals. ### Cleaner preview links Preview links are now shorter and easier to share. When you copy a link from [Share preview](/features/share-project#share-preview-links), Lovable gives you a short `lovable.dev/preview/…` link instead of a long URL with the access token in it. Preview links are public, view-only links that anyone can open without logging in. Links are valid for 7 days, so you can share work in progress with clients, teammates, social posts, or bug reports without giving access to the project or publishing the app. ### Reference web pages in a "Build with URL" link [Build with URL](/integrations/build-with-url) links can now reference public web pages, not just images. Add an `html=` URL and Lovable uses the page as a reference for layout, content, and styling, so you can recreate or iterate on an existing page from a single link. Create links manually or with the [Link Generator](https://lovable.dev/links). Each link supports up to 10 references total, combining images and web pages. Referenced pages must be publicly reachable. ### See when you have unpublished changes The **Publish** button in the editor now shows a small dot when your project has changes that are newer than the live version. It gives you a quick visual cue that there is something new to [publish](/features/publish), without opening the publish dialog. The dot clears once you publish. It stays hidden when there is nothing new to publish, and when you do not have permission to publish. ### App connectors: AWS Athena and Replicate Two new app connectors let your apps query data in Amazon S3 with SQL and run open-source AI models for image, video, audio, and text generation. Workspace admins and owners can configure them from *Connectors → App connectors.* [AWS Athena](/integrations/aws-athena) lets apps browse databases and table schemas, run SQL queries against data in Amazon S3, and fetch results without moving your data. Use it for dashboards, reports, internal tools, data explorers, and analytics workflows. [Replicate](/integrations/replicate) lets apps run thousands of open-source AI models, including models for image generation, video generation, audio, transcription, upscaling, background removal, and text generation. Use it for creative tools, media workflows, AI-powered editing, transcription, model playgrounds, and apps powered by your own fine-tuned models. ### Clearer inbox notifications Your [inbox](/introduction/dashboard-overview#inbox-tab) is now easier to scan. Each notification now shows an icon for its type, such as comments, collaboration, usage alerts, billing, and email, and notifications from another person show that person's avatar. The action button is now specific to the notification: a comment shows *View comment* and a billing notification shows *View credits*. The unread dot has also moved to the edge of each icon, so it no longer interrupts the notification text. ### Preview toolbar The new [preview toolbar](/features/preview-toolbar) replaces Visual edits with a faster way to edit your app directly from the preview. Instead of opening a separate editing panel, pick a mode on the toolbar and point at what you want to change: * **Select elements** to click one or more parts of your app, attach them to chat as context, and describe the change you want. * **Edit text inline** to fix copy directly on the page, without writing a prompt. * **Draw annotation** to sketch on the preview and send the drawing with your message. * **Add a comment** to pin feedback to a specific element, so you and your collaborators can discuss changes in context. The toolbar appears as soon as the preview loads, docked at the bottom center. You can drag it anywhere, minimize it to an edge tab, hide it, bring it back from the project toolbar options, and choose Auto, Light, or Dark theme. You can also queue up your next change while Lovable is still working on the previous one, so small edits feel faster and more continuous. ### User insights for workspace members Workspace admins and owners can now click a member in *Settings → People* to open a [User insights](/features/people#user-insights) profile. The profile shows the member’s identity and role, credit usage over the last 7 and 30 days, projects they created, and projects they collaborate on, including pending project invitations. Project lists can be sorted by latest edit or highest usage. On Enterprise workspaces with audit logs, User insights also includes an Activity tab with the member’s recent workspace actions. ### Reference exact lines of code in chat You can now point Lovable at an exact line of code instead of referencing a whole file. Hover over a line number in the [code editor](/features/code-mode) and click the **+** chip to add a reference like `Button.tsx:42` to chat. Drag the chip to reference a range of lines, or use **Cmd/Ctrl+Shift+L** to insert a reference for the line or selection at your cursor. Line references appear as pills in your message. Click a pill in the chat input or in a sent message to jump the code editor back to that exact line. ### Find and fix database performance problems Lovable can now [investigate the slowest database queries](/integrations/cloud#find-and-fix-database-performance-problems) in your app’s backend. When you tell Lovable that your app or database feels slow, it can read PostgreSQL query statistics and rank the heaviest queries by total execution time, including call counts and timing data. Lovable can then inspect query plans and add targeted indexes where they help and help fix real bottlenecks before you consider upgrading compute. ### Workspace view-only sharing Business and Enterprise workspaces can now share a project with everyone in the workspace as read-only. From the [Share](/features/share-project) dialog, choose your workspace as the audience, then set the permission to *Can view*. Workspace members can open and reference the project without being able to edit it, which makes it easier to share examples, hand off context, or showcase work without risking accidental changes. ### Publish from chat The agent can now [publish your app](/features/publish) for you while respecting all publish-related workspace settings and permissions. Ask Lovable to publish, deploy, ship, or go live, and the agent will check your publish settings, confirm required page information, run the same security checks used by the publish flow, and schedule the deploy. You can also ask for a specific Lovable subdomain, such as `my-todos.lovable.app`. Lovable asks for approval before publishing unless you have set the tool to auto-approve. For related settings, such as changing visibility, connecting a custom domain, or unpublishing, it points you to the right place in the UI. ### SVG previews in chat SVG attachments now render correctly when opened from the full-screen attachment viewer. Previously, SVG files could appear blank or broken. ### Transfer a domain to Lovable Workspace admins and owners on paid plans can now [transfer domains](/features/transfer-domain) from another registrar into Lovable, so renewals, DNS records, registration details, and connected projects can all live in one place. Start from *Workspace settings → Workspace domains → Transfer in*. Lovable checks whether the domain is eligible, guides you through the required transfer details, and lets you choose which detected DNS records to carry over. Transfers from another registrar usually take 5 to 7 days. Your domain keeps working through your current provider while the transfer is in progress. Once the transfer completes, Lovable becomes the registrar, applies the DNS records you selected, and reconnects existing Lovable projects that were already using subdomains of the transferred domain. ### Markdown preview in the code editor Markdown files now have a preview toggle in the [code editor](/features/code-mode). Open a `.md` or `.markdown` file, then click the eye icon in the code editor toolbar to switch between the raw source and a rendered preview. This makes it easier to read READMEs, docs, and other Markdown files as formatted text without leaving the code editor. The preview supports common Markdown formatting, including tables, task lists, links, and code blocks. ### Toggle WHOIS privacy after purchase [WHOIS privacy](/features/custom-domain) is enabled by default when you register a domain through Lovable, for TLDs that support it. You can now disable or re-enable it after purchase. Go to *Workspace settings → Workspace domains*, click *Configure* next to the domain, open the three dots menu in the upper right corner, and toggle *WHOIS privacy*. ### Buy a domain without connecting it to a project You can now [purchase a domain](/features/custom-domain#buy-without-connecting-to-a-project) through *Workspace settings → Workspace domains* and leave the project connection step empty. The domain is registered to your workspace and can be connected to any project later from workspace or project domain settings. ### Transfer a domain out to another registrar You can now [transfer domains](/features/custom-domain) registered through Lovable to another registrar. From *Workspace settings → Workspace domains*, click *Configure* next to the domain, open the three dots menu in the upper right corner, and select *Transfer out*. Turn off the transfer lock, then reveal the EPP authorization code to provide to your new registrar. Lovable tracks the transfer status and automatically disconnects the domain from any connected projects when the transfer completes. New domains are locked for 60 days from registration, as required by ICANN; the exact unlock date is shown in the dialog. ### Lovable MCP server now available on all plans The [Lovable MCP server](/integrations/lovable-mcp-server) at `mcp.lovable.dev` is now available on all plans, including Free. Connect any supported AI client (ChatGPT, Claude, Claude Code, Cursor, or VS Code) to create, edit, deploy, and manage Lovable projects through natural language. Free and Pro workspaces have third-party MCP client access on by default. On Business and Enterprise workspaces, admins and owners can configure it in *Settings → Privacy & security → Third-party MCP clients*: it is enabled by default on Business and disabled by default on Enterprise. ### Configure who can create app connector connections On Free and Pro plans, any workspace member with the editor role or higher can create [app connector](/integrations/introduction#who-can-create-connections) connections. On Business and Enterprise plans, workspace admins and owners can now choose one of three states for each connector from *Connectors → Admin settings → App connectors*: * *Disabled*: the connector is unavailable and no one in the workspace can create new connections. (Enterprise plan default) * *Enabled for admins only*: the connector is available but only workspace admins can create new connections. (Business plan default) * *Enabled for editors and admins*: the connector is available and any workspace member with the editor role or higher can create new connections. ### Connector sidebar The [connectors](/integrations/introduction) page now has a sidebar for faster navigation and discovery. Connectors are grouped under categories, making it easier to browse by type. *Admin settings* have moved to the bottom of the sidebar, where they open a panel for managing app connector and chat connector access across the workspace. ### Smarter PWA support When you ask Lovable to make your app installable, work offline, or send push notifications, it now picks the right setup for the request instead of applying the full PWA stack every time. ### Move projects to folders from chat You can now ask Lovable to list your [folders](/introduction/project-folders) or move a project into a personal or shared folder directly from chat. Try prompts like “show my folders” or “move this project to my Marketing folder.” Lovable finds the right folder, handles visibility changes between personal and shared folders, and files the project for you, so you can stay organized without leaving the editor. ### Cleaner project collaborator icons When a project has more active collaborators than fit cleanly in the top bar, the extras now collapse behind a single avatar. Click it to see the rest. ### Security scan profiles Lovable now has two built-in security scan profiles: [Basic scan and Deep scan](/features/security). Basic scan checks row-level security (RLS) policies, database schema and access control, and dependency vulnerabilities. It runs automatically when you open the publish dialog, and you can also run it manually from the project *Security view*. Deep scan adds a broader agentic code review for access control issues, unprotected backend endpoints, exposed secrets, unsafe input handling, insecure storage settings, and project-specific issues from security memory. You can run it manually from the project *Security view*, workspace *Security center*, or publish dialog after Basic scan passes. When publishing, Lovable shows Basic scan findings in the [publish dialog](/features/publish) with a warning to review and fix them in the *Security view*. If Basic scan passes, you can optionally run a Deep scan before publishing. ### Automatic fixes for Basic scan findings Lovable can now [automatically fix eligible critical finding](/features/security#let-lovable-automatically-fix-eligible-findings)s from Basic scan during regular agent work. When auto-fix is enabled, Lovable uses the latest error-level Basic scan findings as context in chat, then attempts to fix safe issues like row-level security (RLS) misconfigurations and database access patterns. Auto-fix does not apply to Deep scan findings. Configure workspace defaults from *Workspace settings → Privacy & security → Security automation → Auto-fix security issues*, or manage it per project from *Project settings → Auto-fix security issues*. ### Scheduled security scans (Enterprise) Workspace admins and owners on Enterprise plans can now [schedule Deep security scans](/features/security-center#schedule-security-scans-enterprise-only) to run automatically across selected projects from the workspace *Security center*. Each workspace can have one weekly or monthly schedule for published projects or all projects. You can also trigger the scheduled scan manually and view the last run status from the schedule settings. Scheduled scans consume 1 credit per included project each time they run. ### App connector: Salesforce The new [Salesforce](/integrations/salesforce) app connector lets your apps query and update CRM records from your Salesforce org, including Accounts, Contacts, Leads, Cases, Opportunities, and more. Workspace admins and owners can configure it from *Connectors → App connectors*, with support for production, Developer Edition, and sandbox organizations. Use it to build support case dashboards, account health trackers, lead pipeline views, contact directories, sales activity reports, and other internal tools that work with live Salesforce data. ### Improvements and bug fixes * **App login methods moved to *Privacy & security***. Workspace admins and owners on Business and Enterprise plans can manage the policy for blocking app sign-in providers from *Settings → Privacy & security → [App login methods](/features/privacy-and-security-settings#app-login-methods)*. Functionality is unchanged. * **SCIM badge in *Settings → People*.** Members provisioned through SCIM now show a small SCIM badge next to their name. Enterprise admins can quickly tell which seats are managed by their identity provider and which were invited manually, making access reviews and support escalations easier. * **Session-based SSO login**. Fixed a gap where users in single sign-on (SSO) enforced workspaces could still sign in with email and password, bypassing the identity provider. SSO sessions are now validated on every request, so deprovisioned users lose access immediately. ### More consistent project action buttons Comment, share, and publish buttons now use matching styles, with refined avatars and a more polished layout. ### App connectors: Algolia, LinkedIn, and Microsoft SharePoint Three new app connectors let your apps work directly with advanced search, LinkedIn posting workflows, and Microsoft SharePoint content. Workspace admins and owners can configure them from *Connectors → App connectors*. [Algolia](/integrations/algolia) lets apps add fast, typo-tolerant search, faceted filtering, indexing, ranking, recommendations, and search analytics. Use it for product search, marketplace listings, documentation search, directories, location finders, and search analytics dashboards. [LinkedIn](/integrations/linkedin) lets apps read basic profile details, read the connected member’s primary email address, and publish posts on their behalf. Use it for post schedulers, personal brand dashboards, event registration, sales workflows, and content publishing tools. [Microsoft SharePoint](/integrations/microsoft) lets apps build with SharePoint sites, lists, and document libraries. Use it to build apps that browse team resources, work with shared documents, read and write list items, and connect workflows to existing Microsoft 365 content. ### Improvements and bug fixes * **Asset storage.** Images, videos, and other large files used in your apps are now stored outside the project itself. This keeps projects smaller, faster, and easier to work with, especially when using GitHub. * **History panel with bookmarks.** The history panel now has separate tabs for history and bookmarks, making it easier to find past work and saved items. History also loads more reliably and better matches what you see in chat. ### Subagents [Subagents](/features/subagents) help Lovable investigate complex tasks faster by splitting research, code exploration, and review into focused parallel work. Available to all users. When a request needs more context, Lovable can start temporary, read-only subagents to inspect your project, look up documentation, review work against your prompt, and return findings to the main agent. Subagents cannot edit, create, or delete files, and all project changes still come from the main Lovable agent. Lovable decides when to use subagents automatically. For larger investigations, you can mention subagents in your prompt to encourage Lovable to split the work. ### New OpenAI image models for AI features in your app Lovable’s [built-in AI connector](/integrations/ai) now supports two OpenAI image models for AI features inside your app: * GPT Image 2 (`openai/gpt-image-2`) * GPT Image 1 Mini (`openai/gpt-image-1-mini`) Use them to build image generation and editing workflows, such as product mockups, marketing visuals, thumbnails, drafts, and creative assets, directly inside your projects without managing provider API keys. ### Sensitive data scanning Enterprise workspaces can now enable [sensitive data scanning](/features/sensitive-data-scanning) to detect personally identifiable information (PII) across projects. Workspace admins and owners can turn on *Sensitive data scanning* from *Settings → Privacy & security*, configure *Chat send protection* for new messages and attached files, and enable *Block publishing with PII* to prevent projects with unresolved PII findings from being published. Anyone with project edit access can run on-demand scans from the project’s *Sensitive data* tab to check chat history, Lovable Cloud Database, and Lovable Cloud Storage. They can also review all findings, mark false positives, redact detected segments in chat messages, or delete files that contain PII. ### Faster app previews across regions We improved the infrastructure that serves customer apps, reducing latency for live previews across regions. Apps should now load faster and perform more consistently, especially for users farther from Europe. ### Delete a workspace Workspace owners can now [delete a workspace](/introduction/delete-workspace) directly from *Settings → Workspace*. Deleted workspaces enter a 60-day grace period where Lovable support can restore them. Members lose access immediately, and any active subscription is scheduled to cancel at the end of the current billing period. After the grace period, Lovable permanently deletes the workspace and its associated content. Workspace deletion is available to workspace owners on Free, Pro, and Business plans. Enterprise customers should contact their Lovable account team to delete a workspace. ### Project toolbar navigation improvements The project toolbar now has a more polished view switcher, clearer active states, improved keyboard navigation, and a simplified *More* menu for project views like Analytics, Cloud, Security, and other sections. ### Removed * **Project view pins.** Project views can no longer be customized with pins. The toolbar now uses a fixed layout to keep navigation consistent. ### Custom MCP servers available on all plans [Custom MCP servers](/integrations/mcp-servers#custom-mcp-servers) are now available on all plans, no paid plan required. Connect custom MCPs from *Connectors → Chat connectors*. ### Group members now show only active and pending users [Group](/features/groups) page and CSV exports now exclude deactivated users, include only active and pending members, and mark pending members with an `invited` badge. ### Lovable Cloud database health check Troubleshoot database issues faster with an on-demand [database health check](/integrations/cloud#database-health-check) for your Lovable Cloud database, directly from chat. Ask Lovable to run a health check, and it returns a summary of your database’s current status, including connections, memory, disk usage, uptime, and more. Use it to understand whether slow queries or timeouts are caused by query performance, runaway connections, memory pressure, low disk space, or compute limits. Try prompting: `Run a health check on my Cloud database.` ### Auto-compress large images on upload Lovable now automatically compresses large images during upload when they exceed the size limit, helping them fit into your request while preserving quality. When compression is applied, Lovable shows an info tag so you can see what changed. If an image would need too much compression and quality would noticeably degrade, Lovable still rejects the upload with a clear message. ### Branded app URLs Business and Enterprise workspaces can now publish apps under a shared [branded URL](/features/branded-workspace-urls) pattern instead of the default `your-app.lovable.app`. Workspace admins and owners configure a single workspace subdomain from *Workspace settings → Branded app URLs*. When enabled, every app in the workspace follows this format: `https://{app-name}.{workspace-subdomain}.lovable.app` Newly published apps use the branded URL once the subdomain is active. Apps published before enabling the feature keep their existing URLs until they are republished. Custom domains still take precedence when configured. ### App connectors: Google Maps Platform, Semrush, and TikTok Three new app connectors let your apps work directly with maps, search engine optimization (SEO) data, and TikTok creator data. Workspace admins and owners can configure them from *Connectors → App connectors*. [Google Maps Platform](/integrations/google-maps) supports geocoding, routes, places, embedded maps, address validation, weather, air quality, and other Google Maps Platform application programming interfaces (APIs). Choose *Managed by Lovable* for the fastest setup, or provide your own credentials when you need more control. [Semrush](/integrations/semrush) lets apps read keyword research, domain analytics, backlinks, paid search data, projects, and position tracking from a connected Semrush account. Use it for SEO dashboards, keyword tools, competitor tracking, backlink monitoring, and client-facing reports. [TikTok](/integrations/tiktok) lets apps read profile information, follower counts, like counts, video statistics, and published video metadata from a connected TikTok account. The connector is read-only and does not support publishing content to TikTok. ### Gemini 3.5 Flash for AI features in your app Lovable’s [built-in AI connector](/integrations/ai) now supports `google/gemini-3.5-flash` for AI features in your app. This efficient Gemini model provides fast coding, reasoning, and agentic workflows, so you can build more responsive AI-powered features directly inside your projects. ### Improvements and bug fixes * **Mobile sidebar search searches across all sections.** [Mobile app](/integrations/lovable-mobile-app) sidebar search now searches *Starred*, *Created by me*, *Shared with me*, and your workspace at the same time, with duplicate results removed and grouped under labeled sections. * **Transparent backgrounds in image editing.** Image editing now preserves transparency when you remove a background or edit an image that already has a transparent background. * **New comments panel.** The [project comments](/features/project-comments) sidebar now stays hidden when it is not in use, and comment pins only appear while you are in comment mode. * **Chat response tips.** Chat now shows brief contextual tips while the agent is processing a response, highlighting useful Lovable features. * **Settings sidebar reorganized.** Settings are now grouped under Account, Project, and Workspace, with [workspace settings](/features/workspace-admin-settings) divided into *Members & access*, *Customization*, *Build & deploy*, and *Security & compliance*. * **Lovable templates and workspace templates.** The dashboard now separates *Lovable templates* from [*Workspace templates*](/features/business/design-templates). Lovable templates are the curated templates provided by Lovable, while workspace templates are templates owned by your workspace. * **Static egress IPs for app connectors.** Outbound traffic from Lovable’s app connector gateway now uses a stable IP range, so partners and enterprise customers can allowlist Lovable connector traffic more easily. * **Plans, skills, and files on the activity card.** Plans, skills, and files now render inline on the agent activity card in chat using a single, consistent card pattern. * **Tooltips dismiss reliably.** Tooltips now dismiss correctly when you move the cursor away. ### SEO and AI search 2026-may-18-seo-reviewl Lovable now includes a dedicated [SEO and AI search](/features/seo-aeo) tab under *Services → SEO & AI search*. The new tab brings together: * **SEO and AI search review.** Run on-demand audits for sitemap, `robots.txt`, metadata, semantic HTML, content structure, alt text, canonical tags, indexing, accessibility, mobile usability, and performance. * **Speed and Lighthouse checks.** Performance, accessibility, mobile usability, and indexing checks from the previous standalone *Speed* tab now live directly inside the SEO and AI search review. * **Google Search Console (GSC) setup.** If the [Google Search Console connector](/integrations/google-search-console) is enabled in your workspace, the SEO and AI search review can detect missing GSC setup and guide you through connecting GSC, verifying your site, and submitting your sitemap directly from chat. * **Semrush-powered SEO research.** Use *Research SEO with Lovable* to research keywords, competitors, backlinks, rankings, and SEO strategy using live Semrush data. * **Custom domains.** Buy or connect a custom domain and build your search presence on a domain you control. Lovable surfaces clear recommendations and can apply most fixes in one click. Semrush-powered SEO research has no additional cost through August 15, 2026, and does not require a Semrush account. ### Design guidance 2026-may-18-design-guidance [Design guidance](/features/design-guidance) helps you shape the visual direction of your project before Lovable starts building. Available to all users. For visually open-ended prompts, Lovable can generate three lightweight **design directions** so you can compare different layouts, typography, colors, spacing, and overall visual tone before choosing one. Pick a direction, refine it, or ask for another set before Lovable starts building the full app. Lovable can also ask guided **design questions** when your prompt would benefit from clearer visual preferences. Choose typography, color palette, and layout direction, and Lovable turns your choices into a design brief for the build. Design guidance also works on existing projects. Ask for variations of a hero section, navbar, pricing card, footer, or another component to explore alternatives without restarting the project. ### Chat with Lovable in Telegram 2026-may-18-lovable-telegram-bot You can now [chat with Lovable directly from Telegram](/tips-tricks/lovable-telegram-bot). Message the Lovable bot to build new apps, update existing projects, fix bugs, make UI changes, publish projects, review edit history, query your project database with read-only SQL, and view analytics for published projects. You can also search code across workspace projects, copy assets between projects, and compare patterns across codebases. Connect from [**Devices and apps**](https://lovable.dev/settings/apps) (*Settings → Devices & apps*). Available on Free and Pro plans. This is for chatting with Lovable inside Telegram, not for adding Telegram messaging to your app. ### Lovable MCP server (research preview) The [Lovable Model Context Protocol (MCP) server](/integrations/lovable-mcp-server) is now available in research preview for Pro and Business plans at `https://mcp.lovable.dev`, letting external AI clients connect to Lovable and manage projects through natural language. Use Claude Desktop, Claude Code, Cursor, or other MCP-compatible tools to create projects, send messages to the Lovable agent, inspect files and diffs, enable Lovable Cloud, run SQL, query analytics, or deploy apps without leaving your AI client. ### Lovable mobile app The [Lovable mobile app](https://lovable.dev/blog/mobile-app) is now available globally on iOS and Android. Build and iterate on projects from your phone, send messages to the agent, review updates, and check analytics while away from your computer. ### Workspace skills You can now create reusable [skills](/features/skills) that teach Lovable how to handle recurring tasks across your workspace. A skill is a named markdown playbook with instructions for a specific workflow, such as a launch checklist, changelog draft, accessibility review, SEO audit, support reply, or quality assurance pass. Workspace admins and owners can create skills from chat, import a public GitHub repository with a `SKILL.md`, or upload a ZIP with a `SKILL.md`. Lovable can apply skills automatically when a request matches the skill description, or you can invoke one manually from the slash menu in chat. Skills are available to every project in the workspace by default, and workspace admins and owners can disable *Automatic use* for a skill so Lovable will not apply it on its own, while still letting workspace members invoke it manually. ### Wiz security scanning [Wiz security scanning](/integrations/wiz) is now available in Lovable. Wiz adds software composition analysis (SCA) for dependency vulnerabilities and static application security testing (SAST) for risky source-code patterns, hardcoded secrets, unsafe API usage, and other code-security issues. Wiz findings appear directly in the project *Security view* alongside Lovable's other scanners. Workspace admins and owners can connect Wiz from *Connectors → App connectors → Wiz*. Only one Wiz connection can be added per workspace. ### Improved GitHub integration Lovable's [GitHub integration](/integrations/github) now supports more hosting setups, clearer connection management, and better recovery when sync breaks. The update includes: * **GitHub Enterprise Cloud with data residency.** Enterprise teams can now connect Lovable to `*.ghe.com` instances. * **GitHub Enterprise Server.** Enterprise teams can now connect Lovable to self-hosted GitHub Enterprise Server by creating their own copy of the Lovable GitHub app. * **GitHub connection recovery.** Lovable now shows *Reconnect* prompts when it detects sync failures caused by suspended app installations, missing repository access, changed permissions, removed workspace connections, or app installation issues. * **Cleaner editor navigation.** The GitHub button has moved out of the editor top navigation. You can still access project GitHub settings from *Project settings → Git → GitHub* or the `+` (plus) menu in the chat input. ### App connectors: Airtable, Attention, Brevo, Google Search Console, Granola, Mailgun, Notion, Storyblok Your apps can now integrate with more services for content, communications, search visibility, customer conversations, and team workflows. These connectors expand what you can build in Lovable by letting your apps interact directly with external tools and data sources. Workspace admins and owners can configure app connectors in *Connectors → App connectors*. * [Airtable](/integrations/airtable) lets your apps use Airtable bases as a flexible backend for records, lists, dashboards, and operational workflows. Your apps can read, create, update, and delete records with filtering, sorting, and pagination. * [Attention](/integrations/attention) lets your apps work with customer conversation data, including transcripts, scorecards, conversation insights, and team data. This makes it easier to build sales dashboards, call review tools, workflow automations, and AI summaries powered by customer calls. * [Brevo](/integrations/brevo) lets your apps send transactional and marketing emails, manage contacts and lists, and trigger communication workflows through your Brevo account. Use it for onboarding sequences, newsletters, internal alerts, customer outreach, and multi-channel messaging where supported by your Brevo account. * [Google Search Console](/integrations/google-search-console) lets your apps verify domains, submit and manage sitemaps, inspect URLs, read search analytics, and build SEO dashboards or reporting tools. Lovable can also use the connector in chat to answer SEO questions using live Search Console data. * [Granola](/integrations/granola) lets your apps access AI-generated meeting notes, summaries, transcripts, decisions, and action items. Use it to build internal tools that search meeting context, retrieve decisions, generate follow-ups, or surface insights from past conversations. * [Mailgun](/integrations/mailgun) lets your apps send transactional email through your existing Mailgun account and verified sending domains. Use it for receipts, account lifecycle emails, form-to-email workflows, scheduled reports, alerts, and deliverability dashboards. * [Notion](/integrations/notion) lets your apps read and write pages, query databases, create pages, append blocks, and update database rows. Use it to build apps backed by Notion content, such as help centers, project dashboards, lead capture flows, blogs, status pages, and changelogs. * [Storyblok](/integrations/storyblok) lets your apps fetch editor-managed content from a headless content management system and visual page builder. Use it to build marketing sites, blogs, documentation, product directories, localized sites, and preview experiences powered by Storyblok stories, components, assets, and SEO metadata. ### Chat connectors: HeyGen HeyGen is now available as a prebuilt [chat connector](/integrations/mcp-servers). Connect HeyGen so the Lovable agent can use avatars, voices, and video generation tools while building. Use it to create apps and workflows for AI avatar videos, voiceovers, personalized onboarding, and media-rich demos without leaving Lovable. Configure it in *Connectors → Chat connectors*. ### Lovable AI models for app features New models and embedding support are now available in [Lovable AI](/integrations/ai) for AI features inside your apps. * **GPT 5.5 family.** `gpt-5.5` and `gpt-5.5-pro` are now available with context windows up to 1.05 million tokens and tiered pricing above 272,000 tokens. The Pro variant is suited for the most demanding reasoning tasks. * **GPT 5.4 family.** `gpt-5.4`, `gpt-5.4-mini`, `gpt-5.4-nano`, and `gpt-5.4-pro` are now available with context windows up to 1.05 million tokens and tiered pricing above 272,000 tokens. * **Gemini 3.1 Flash Lite Preview.** The fastest and lowest-cost Gemini 3 option, designed for simple, high-throughput tasks with limited reasoning depth * [Embedding models](/integrations/ai#embedding-models). You can now generate text embeddings through Lovable AI to build semantic search, RAG pipelines, FAQ bots, and knowledge bases. Four models are available: * `google/gemini-embedding-001` * `openai/text-embedding-3-small` * `openai/text-embedding-3-large` * `google/gemini-embedding-2-preview` Describe what you want to build and Lovable sets up the full implementation. Lovable AI requires no provider API keys. Usage is billed based on the underlying model. ### TanStack Start is now the default for new apps New Lovable apps created from May 13, 2026 use TanStack Start with server-side rendering by default, except on Enterprise plans. This gives new apps crawlable HTML from the first request, improves search engine optimization (SEO), and provides a stronger foundation for server-side functionality. Older React + Vite apps use **on-request pre-rendering** for verified search and AI crawlers, such as Google, Bing, social preview bots, and AI engines like ChatGPT, Perplexity, Claude, and Gemini. Pre-rendering runs at request time, so dynamically loaded content is included in what crawlers receive. ### Database backup restoration You can now [restore a Lovable Cloud project database](/integrations/cloud#database) to any of its recent daily backups from *Cloud → Database → Backups*, without contacting support. Lovable rolls the database back (schema and data), and brings the project back online in a few minutes. Useful for accidental changes, broken migrations, or data issues. Restores are permanent and discard data changed after the chosen backup, so ask Lovable to test your app afterwards. ### Domain management updates [Custom domain](/features/custom-domain) setup and management is now clearer, more centralized, and easier to recover when something goes wrong. * **Buy domains from workspace settings.** You can now buy domains directly from *Workspace settings → Workspace domains*. Domains bought through Lovable belong to your workspace, not a single project, so admins and owners can manage them centrally and connect them to projects as needed. * **Move domains between workspaces.** Lovable-purchased domains can now be moved between workspaces, making it easier to reorganize projects, transfer ownership, or hand off domains between teams. The destination workspace must be on a Pro plan or above, and you must be an admin or owner of the destination workspace. * **Stalled SSL provisioning recovery.** If custom domain setup stalls during SSL certificate provisioning, a *Stalled* status and a *Retry* button now appear after 10 minutes. Click Retry to restart without removing and re-adding the domain. ### Draw on images You can now draw directly on uploaded images before sending them to the agent. Highlight the exact area, element, or detail you want Lovable to focus on. The annotated image is sent with your message, giving the agent clearer visual context without needing a long written explanation. ### Build and Plan mode switch The chat input now has a clearer dropdown for switching between [Build](/features/agent-mode) and [Plan](/features/plan-mode) modes. Build and Plan behavior is unchanged: Build makes changes directly, while Plan lets you discuss architecture, requirements, or design before anything is written. When Plan mode is active, the send button turns blue, and you can still switch modes with `⌥P`. ### Security memory Each project now has a dedicated [security memory document](/features/security-view#improve-scan-accuracy-with-security-memory) that the security scanner reads before each scan. Use it to describe your app’s access control model, business logic rules, and risks you have already reviewed and accepted, so future scans can stay focused on new or unresolved issues instead of re-flagging the same findings. The scanner can also update the memory when a risk is accepted during a scan, adding a short note for future runs. You can view and edit the document from the [Security view](/features/security-view) by clicking *Edit security memory*. Security memory replaces the previous *Add context* field that stored scan context in project *Knowledge*. ### Admin and security updates New visibility and management tools help workspace admins and owners on Business or Enterprise plans audit authentication, manage groups, and troubleshoot identity provisioning at scale. * [**Security center** auth provider filter](/features/security-center) (Business and Enterprise)
Filter projects in *Security center → Code analysis* by active sign-in method: Google, Apple, email, phone, and SAML SSO. This makes it faster to audit which projects fall outside workspace authentication policy. * [Group exports ](/features/groups#export-group-membership)(Business and Enterprise)
Download group membership as a CSV file from *Settings → Groups*. Exports include workspace name and ID, group name and ID, user name and ID, email, date added, and who added them. * [Server-side group member search](/features/groups)
Searching within a workspace group is now faster and more reliable, returning matching members directly regardless of group size. * [SCIM provisioning errors ](/features/business/scim)(Enterprise)
View SCIM provisioning failures in *Settings → Identity*. Previously, errors like domain blocks failed silently, leaving you unaware that users were not provisioned. * **Privacy and security settings layout**
The *Privacy & security* tab in workspace settings is now organized into five cards: Access & membership, Publishing, Sharing, MCP servers, and Data protection. The settings themselves have not changed. ### Improvements and bug fixes * **GPT-Image-2 for premium image generation.** When generating images at premium quality, Lovable now uses GPT-Image-2. Lovable continues to select quality level automatically, with better results for images that require legible text or precise visual detail. * **[Profile visibility](/introduction/lovable-account-settings#profile-settings).** You can now choose whether your Lovable profile is public or private. Public profiles are visible to everyone at `lovable.dev/@`. Private profiles are visible only to you, workspace owners, and workspace admins. On Enterprise plans, profiles are private by default. On all other plans, profiles are public by default. * **Remix progress tracking.** The remix dialog now shows a live step-by-step progress checklist, making long remixes easier to follow. * **Automatic device previews.** Lovable can now switch the preview device automatically based on what you are building, such as mobile or tablet layouts. * [Cross-project reference picker](/features/cross-project-referencing)**.** Project `@` mentions now show the full project name, description, preview image, and more project details, using the same layout as the command palette. Clicking the preview image opens the referenced project in a new tab, making it easier to choose the right project when names are similar or vague. * **Referral sharing.** Referral sharing now includes a QR code for your invite link, making it easier to move the link from desktop to phone or share it in person. * **Project creation feedback.** When you create a project from the dashboard, the send button now turns into a loading indicator immediately after submit. Project creation can take more than ten seconds, and the form previously gave no feedback while the project was being created. * **Feature suggestions persist.** Feature suggestions now stay visible when you refresh a project or come back to it later. Previously, they only appeared right after a new message arrived. ### Removed * **Speed tab.** The standalone Speed tab has been removed. Speed and Lighthouse checks for performance, accessibility, mobile usability, and indexing now live inside the [SEO and AI search review](/features/seo-aeo) under *Services → SEO & AI search*. The SEO and AI search review replaces the previous Speed dashboard. * **GitHub button in editor top navigation.** The [GitHub](/integrations/github) button has been removed from the editor top navigation. You can still access project GitHub settings from *Project settings → Git → GitHub* or the `+` (plus) menu in the chat input. ### Add payments to your app 2026-apr-23-lovable-payments [Lovable payments](/features/payments) lets you add subscriptions and one-time payments to any app using the built-in Paddle or Stripe integrations. Lovable handles the setup and infrastructure, including account creation, webhooks, and subscription data, so you can focus on building your product. Set up a working test checkout in minutes, create products and pricing, and go live the same day. Lovable payments supports SaaS, subscriptions, one-time purchases, memberships, and digital products. Stripe can also be used for physical products, but inventory and logistics need to be handled separately. Available on paid plans. ### Lovable desktop app [Lovable desktop](/integrations/desktop-app) is now available as a native app for macOS, with Windows support coming soon. It includes the full web experience along with support for local MCP servers, multi-project tabs, and keyboard shortcuts. Local MCP support lets Lovable connect directly to tools running on your machine, such as Figma Desktop and Paper, so it can read design files and use that context while building your app. ### Opus 4.7 Lovable now incorporates Claude Opus 4.7, improving code quality, instruction following, and performance across complex, multi-step tasks. For more information, see [**Opus 4.7 in Lovable announcement**](https://lovable.dev/blog/opus-4-7-now-in-lovable). ### Chat history search Lovable can now search and reference the full history of your project. It can retrieve specific past messages, run keyword searches across the full conversation, and answer semantic questions like "*what design style did I ask you to use?*". This helps it recover the exact context it needs before taking the next step. ### Group-based access and granular publishing [Groups](/features/groups) let you organize workspace members and control access across projects, folders, and published apps. Supports SCIM sync from identity providers. Available on Business and Enterprise plans. * Workspace admins and owners can organize users by team or role in *Settings → Groups* to manage access across projects and folders. * Restrict access to your published apps by sharing them with specific groups or individuals instead of the entire workspace. ### Connector updates [Connectors](/integrations/introduction) are now easier to discover, manage, and control across your workspace. * **Dedicated connectors experience**
Connectors now open in a dedicated interface from the dashboard instead of being nested inside settings. * **App connectors and Chat connectors**
Connector categories have been renamed to make it clearer what powers your apps versus what provides context in the chat. * **Manage private projects in connections**
Workspace admins can now see private projects linked to an app connector directly from the connections table. * **Connection access controls**
Restrict connections to specific users or the entire workspace. Only users with access can link the connection and access projects that use it, while others are blocked. Workspace admins and owners always retain access. Applies during development only; published apps are not affected. ### Productivity app connectors: Google Workspace, Microsoft 365 Your apps can now integrate with major workplace tools across Google Workspace and Microsoft 365. These connectors let your apps read, write, and automate workflows across email, files, documents, spreadsheets, calendars, and presentations. Connections operate on the data of the connected account. * [Google Workspace](/integrations/google-workspace) includes Gmail, Drive, Docs, Sheets, Slides, and Calendar. * [Microsoft 365](/integrations/microsoft) includes Outlook, Teams, OneDrive, Word, Excel, PowerPoint, and OneNote. ### Data app connectors: BigQuery, Databricks, Snowflake Your apps can now connect to more data warehouse platforms, making it easier to build dashboards, internal tools, analytics features, and data workflows directly on top of the data your team already trusts. * [BigQuery](/integrations/bigquery) lets your apps run SQL, explore datasets and schemas, and build analytics features. * [Databricks](/integrations/databricks) lets your apps query data with SQL, manage clusters and jobs, read and write to Unity Catalog, and access workspace resources. * [Snowflake](/integrations/snowflake) lets your apps run SQL, work with warehouses, databases, and schemas, and build internal tools and dashboards backed by Snowflake data. ### Business app connectors: Asana, Ashby, HubSpot Your apps can now integrate with business systems for task management, recruiting, and CRM workflows. * [Asana](/integrations/asana) lets your apps read and create tasks for project automation and planning. * [Ashby](/integrations/ashby) brings hiring data into your apps for recruiting workflows and candidate management. * [HubSpot](/integrations/hubspot) supports CRM workflows like lead dashboards, sales tools, onboarding flows, and support assistants. ### Email and workflow app connectors: Inngest, Resend Your apps can now integrate with tools for background workflows and email delivery. * [Inngest](/integrations/inngest) lets your apps run durable workflows, scheduled jobs, and event-driven background tasks through your own Inngest account. * [Resend](/integrations/resend) lets your apps send transactional and marketing emails through your own Resend account. ### Knowledge and content app connectors: Fireflies, Gemini Enterprise, WordPress Your apps can now integrate with external knowledge sources, including meeting data, enterprise search, and content management systems. * [Fireflies](/integrations/fireflies) lets your apps access meeting transcripts, summaries, action items, and conversation insights. * [Gemini Enterprise](/integrations/gemini-enterprise) lets your apps build grounded search and Q\&A experiences on top of your existing enterprise data, with citations and access controls. * [WordPress](/integrations/wordpress-com) lets your apps fetch posts, pages, and media from *WordPress.com* to power dynamic, content-driven experiences. Workspace admins and owners can configure app connectors in *Connectors → App connectors*. ### Chat connectors: Sentry MCP **Sentry MCP** is now available as a [chat connector](/integrations/mcp-servers). This lets Lovable read and investigate errors directly from your Sentry account so you can debug issues faster without switching tools. You can configure chat connectors in *Connectors → Chat connectors*. ### Security updates New controls and visibility tools help workspace admins and owners on Business or Enterprise plans enforce stronger security and manage identity at scale. * [Auth policy](/features/security-center) (Business and Enterprise)
Control which sign-in methods are allowed across every project in your workspace. Configure this in *Settings → Security center → Auth policy*. * [Export secrets as CSV ](/features/security-center)(Business and Enterprise)
Export all or selected secrets for auditing and rotation workflows from *Settings → Security center.* * [Audit logs improvements](/features/audit-logs) (Enterprise)
Improved search, filtering, grouped events, expanded event coverage, and human-readable context to make it easier to investigate activity in *Settings → Audit logs.* * [**SCIM activity overview**](/features/business/scim) (Enterprise)
A dedicated view of identity sync health, failed events, and per-sync timelines for SCIM provisioning in *Settings → Identity*. ### Workspace provisioning Bulk-provision all users from a verified email domain into your workspace in a single action. Select a domain, preview users, assign a default role, and provision your organization at once. Available on Enterprise plans in *Settings → Identity*. ### SAML 2.0 single sign-on for your apps You can now add SAML 2.0 SSO to Lovable Cloud apps from *Lovable Cloud → Users → Auth,* or ask the agent to “Add SAML SSO to my app.” Lovable collects your identity provider metadata and email domains, then configures authentication automatically. Works with Okta, Azure AD / Entra ID, OneLogin, and other SAML 2.0 providers. ### Dashboard organization and navigation * [Sort projects by popularity](/introduction/project-search-and-find)
You can now sort your projects by visitor count across different time windows (24 hours, 7 days, or 30 days). Project cards show traffic for published projects, and apps with traffic spikes get a visual indicator that links directly to analytics. A new *Most visitors today* tab highlights your top-performing published projects. * [Persistent dashboard filters](/introduction/project-search-and-find)
Dashboard filter, sort, and search preferences now persist in the URL, so you can navigate, refresh, or share focused views without losing your place. * [Folder collaborators](/introduction/project-folders)
You can now add individuals and groups as collaborators on folders, with admin, edit, and view roles. This lets you manage access to all projects in a folder at once instead of updating projects individually. ### Improvements and bug fixes * [Code execution on Enterprise plans.](/features/generate-files) On Enterprise plans, Lovable can now analyze data, generate files, and run code directly in chat without modifying your project. * **Auto-generated SEO descriptions.** Lovable now generates an SEO-friendly project description during publishing, used for search results and link previews. * **Custom domain setup.** Users on paid plans can now choose whether to automatically set up the `www.` subdomain when connecting a custom domain. * **Cloud Storage management.** You can now delete buckets and folders directly from *Lovable Cloud → Storage*. * **Supabase alerts.** Lovable Cloud resource exhaustion alerts now run hourly instead of daily, so you are notified of issues sooner. * **Shopify connections.** Shopify connections are now per-user. Each collaborator connects their own account via OAuth, with permissions based on their Shopify role. Tokens refresh automatically and prompt reconnection when expired. * [Rich folders in the command palette](/introduction/project-search-and-find). You can now browse folders and the projects inside them directly from the command palette, making it faster to navigate your workspace without leaving the keyboard. * **Command palette connectors.** Opening connectors from the command palette now keeps you inside your project instead of redirecting you away. * **Instant UI updates.** Changes to projects, folders, and members now appear instantly in the UI. * **Live preview updates.** The live preview now refreshes once per agent update instead of multiple times, reducing flicker and incomplete states while code is being written. * **Fullscreen chat persistence.** Fullscreen chat state now persists on reload and exits automatically when new edits run. ### Removed * **Public project visibility.** Public project visibility has been removed. All public projects have been updated to *workspace* visibility, and access is controlled through [project access](/features/project-visibility) settings. To let others copy and remix your project, go to *Project settings* and turn on *Enable public remixing*. * **Labs tab.** The *Labs* tab has been removed from settings. GitHub branch switching is now enabled by default. ### Generate files and analyze data 2026 Apr 1 Code Exec Lovable can now run code and [generate downloadable files](/features/generate-files) directly inside the conversation. Analyze uploaded files, transform data, create charts, and generate outputs like PDFs, Excel spreadsheets, PowerPoint presentations, and more, all without leaving the chat. Generated files stay in the conversation, can be refined in follow-up prompts, and never modify your project's source code. Available on Free, Pro, and Business plans. ### App emails 2026 Apr 1 App Emails You can now [send custom transactional app emails](/features/custom-emails) from your own domain, extending Lovable's email system beyond authentication flows. Send order confirmations, receipts, shipping updates, security notices, and other user-triggered emails with branded templates, automatic unsubscribe handling, and built-in suppression lists. Lovable handles domain verification, email authentication, and delivery infrastructure for you, so no external email provider is required. Available on paid plans for Lovable Cloud projects. ### App connectors: Aikido, GitLab, and AWS S3 Your apps can now integrate with more services for data, security, and developer workflows. These integrations expand what you can build in Lovable by allowing your apps to interact directly with external platforms. [Aikido](/integrations/aikido) brings AI-powered penetration testing to Lovable, helping you identify real exploitable vulnerabilities through dynamic testing. Findings can be synced directly into your project's *Security view*, and Aikido generates downloadable, shareable reports for security reviews, compliance workflows, and stakeholder communication. [GitLab](/integrations/gitlab) enables two-way sync between Lovable and your repositories for code backup, collaboration, and deployment. It supports both GitLab.com and GitLab Self-Managed, so teams can keep code entirely within their own infrastructure while syncing changes between Lovable and the default branch. [AWS S3](/integrations/aws-s3) lets you build apps that read and write files directly in Amazon Simple Storage Service (Amazon S3). You can browse bucket contents, download files through signed URLs, and upload new objects when write access is enabled, making it easy to work with datasets, exports, uploads, and other file-based workflows. Workspace admins and owners can configure app connectors in *Connectors → App connectors*. ### Chat connectors: Hex, Confidence, and PostHog Three new MCP servers are available as [chat connectors](/integrations/mcp-servers). This allows Lovable to interact directly with external services and use their data as context while building apps. **Hex** connects Lovable to your Hex workspace so you can query notebooks, explore data, and use results directly while building apps and workflows. **Confidence** connects Lovable to your feature flags and experiments so you can evaluate flags, access experiment results, and incorporate experimentation logic into your applications. **PostHog** connects Lovable to your product analytics so you can query user behavior data, run analyses, and build features informed by real usage insights. You can configure chat connectors in *Connectors → Chat connectors*. ### AI-powered visual edits Visual edits are now fully AI-powered and work across your entire app, including dynamic content from databases and APIs. You can select and update any UI element visually, without writing code, even while the agent is running. The feature is now free to use within daily limits, making it easier for designers, marketers, and product teams to iterate quickly alongside developers. ### Project comments You can now collaborate directly inside Lovable by leaving [comments and annotations](/features/project-comments) on elements in your project preview. Anyone with access to the project can join the discussion, and you can send a thread straight to the agent either by tagging **@Lovable** or using **Send to chat**. This creates a tight feedback loop between review and implementation without leaving the editor. ### Redesigned domain purchasing [Buying and connecting custom domains](/features/custom-domain#buy-a-domain-through-lovable) is now a faster, smoother, and fully in-app experience. Search for a domain, check out through Stripe, and Lovable automatically handles registration, DNS, SSL, and setup for both the root domain and `www` version. Domains are managed at the workspace level and can be connected to projects as needed, making it much easier to launch on a branded URL. Available on paid plans. ### Security updates Several new workspace-level controls and visibility tools help you enforce stronger security standards and identify risks earlier. * [Security center updates](/features/security-center)
Workspace admins and owners on Business and Enterprise plans can now access a *Secrets overview* tab in *Settings → Security center*, where all project secrets are aggregated in one place. You can sort or filter by age, type, and security warnings to identify outdated or exposed credentials and take action to secure your workspace.

You can also trigger security scans directly from the *Security center* overview, with a centralized view of scan history and coverage across projects. This makes it easy to identify unscanned or risky projects and ensure consistent security coverage. * **Audit log export**
Workspace admins and owners on Enterprise plans can now export [audit logs](/features/audit-logs) as JSONL files for external analysis, reporting, and compliance workflows. * **Publishing controls**
Two new controls in *Settings → Privacy & security* allow workspace admins and owners to prevent apps from being published or updated if critical vulnerabilities are detected or if a basic security scan has not been completed, helping ensure insecure applications are never deployed. The settings are: * *Block publishing with critical findings* * *Require basic security scan before first publish* ### Browser performance tools Lovable can now diagnose and troubleshoot performance issues in your applications. The agent can profile Core Web Vitals, resource loading, memory usage, DOM complexity, and long tasks. It can also record CPU profiles and identify the exact functions responsible for slowdowns, making it much easier to debug and optimize performance. ### Image tools Lovable can now zoom into and crop specific regions of uploaded images directly in chat. This makes it easier to inspect details, reference UI elements, and guide the agent with more precise visual context. ### Command palette The command palette (`Cmd + K`) has been redesigned to make navigation and actions faster from the keyboard. You can search across projects, tools, and settings, switch workspaces, trigger actions, and access Lovable Cloud features without leaving your keyboard. ### CDN and reverse proxy support (reintroduced) Users on paid plans can once again connect custom domains that route traffic through [your own CDN or reverse proxy](/features/custom-domain#advanced-use-a-cdn-or-reverse-proxy), such as Cloudflare, CloudFront, or Fastly. This capability has been reintroduced with a simpler and more reliable setup. When connecting a domain, expand the *Advanced* section and enable *Domain uses Cloudflare or a similar proxy* to switch to a CNAME-based configuration. You add a single CNAME record pointing to your Lovable project, and Lovable handles SSL provisioning when the record is live. You are responsible for configuring and maintaining your CDN or proxy. Lovable does not configure or manage proxy setups. ### Workspace onboarding and discovery These updates, available on Business plans and above, make it easier for users to find, join, and get access to the right workspaces during onboarding. * **Automatic workspace joining for verified emails (Domain JIT)**
Previously, just-in-time (JIT) provisioning was available through SSO only. Now, new users signing up with a verified company email can be automatically placed into the correct workspaces with the appropriate permissions. This removes the need for manual invites and speeds up onboarding. Workspace admins and owners can enable this feature and set the default role for newly joined users in *Settings → Identity → User provisioning*. * **Workspace discovery**
Users can now discover and request access to existing workspaces within their organization during onboarding. Workspace admins and owners can control visibility and manage this setting in *Settings → Privacy & security*. ### Improvements and bug fixes * The dashboard now loads significantly faster by using server-side search with pagination instead of fetching all projects at once. This reduces both network requests and payload size. * Search on the dashboard *All projects* page now includes folders alongside projects, and folders are now visible in mobile search results. This makes it easier to locate content across devices. * You can now choose the workspace and folder when remixing a project, giving you more control over where new projects are created. * Fixed an issue where chat drafts could be lost on page refresh. Drafts are now reliably restored before any components initialize. * Fixed an issue where users invited to SSO-enforced workspaces could hit an error page when signing up with a password. Users are now automatically redirected to the correct login flow. ### Removed * **Test and Live environments (Beta)**
As of March 24, 2026, Test and Live environments are no longer available for new Lovable Cloud projects. Existing projects will continue to have access, but the feature cannot be re-enabled once disabled. We are iterating on this feature based on beta feedback and plan to bring it back in an improved form. ### App connectors: Twitch, Twilio, Linear, Telegram, and Contentful 2026 Mar 16 App connectors Your apps can now integrate with more services for communication, content, and developer workflows. These integrations expand what you can build in Lovable by allowing your apps to interact directly with external platforms. [Twitch](/integrations/twitch) lets your app access Twitch API so you can build overlays, dashboards, moderation tools, and community apps that respond to activity on a channel. [Twilio](/integrations/twilio) lets your app reach users through messaging and voice. With Twilio, your app can send SMS notifications, manage phone-based workflows, support WhatsApp messaging, and build features that communicate with users outside the app interface. [Linear](/integrations/linear) lets your app interact with issues, projects, teams, cycles, and comments in your Linear workspace so you can automate workflows, build dashboards that track progress, and connect engineering tasks directly to your application. [Telegram](/integrations/telegram) lets your app communicate with users through chats, groups, and channels using the Telegram Bot API. Telegram bots act as a conversational interface for your app so users can receive updates, request information, or trigger workflows directly from chat. [Contentful](/integrations/contentful) lets your Lovable app fetch published content from your Contentful space through the Content Delivery API. This allows you to build dynamic pages, product catalogs, blogs, and documentation powered directly by your CMS content. Workspace admins and owners can connect these services in *Connectors → App connectors*, and they will be available to all members across all projects in your workspace. ### Chat connectors: Polar and Sanity 2026 Mar 16 Mcp Two new MCP servers are available as [chat connectors](/integrations/mcp-servers). This allows Lovable to interact directly with external services and use their data as context while building apps. **Polar** connects Lovable to your Polar billing setup so your apps can incorporate real subscription and billing context. Lovable can access your products, customers, subscriptions, and pricing so it can scaffold SaaS apps, checkout flows, and subscription management features. **Sanity** connects Lovable to your Sanity CMS so the agent can access your documents, schemas, and structured content while building apps. Lovable can read your content model and generate apps, landing pages, and interfaces aligned with your CMS structure. You can configure chat connectors in *Connectors → Chat connectors*. ### Authentication emails You can now send [authentication emails](/features/custom-emails) from your own domain instead of the default Lovable Cloud sender. This improves deliverability, protects your domain reputation, and keeps the login experience consistent with your brand. Lovable automatically manages domain verification and authentication (DNS, SPF, DKIM, and DMARC) so no external email provider setup is required. You can configure your sending domain, customize branding and templates, and manage authentication emails such as signup confirmations, password resets, magic links, invitations, email change confirmations, and reauthentication messages. Available on paid plans for Lovable Cloud projects. ### Workspace knowledge You can now define shared rules and conventions once and apply them automatically across every project in your workspace. [Workspace knowledge](/features/knowledge) is designed for instructions that should stay consistent across projects, such as coding standards, architecture patterns, preferred libraries, or brand voice guidelines. This helps teams avoid repeating the same instructions in every project and ensures new projects follow the same conventions automatically. Workspace admins and owners can manage workspace knowledge from *Settings → Knowledge* or *Project settings → Knowledge*. ### Audit logs Workspace [audit logs](/features/audit-logs) are now available on Enterprise plans. Audit logs provide a searchable history of activity across your workspace so you can review changes, monitor access, and investigate unexpected behavior. Workspace admins and owners can filter logs by action, member, or time range to review events such as workspace membership changes, project activity, authentication events, integration changes, and workspace configuration updates. Each entry shows who performed the action, when it occurred, what changed, and which resource was affected. You can expand entries to view detailed metadata associated with the event. Audit logs are available in *Settings → Workspace → Audit logs*. ### Bulk management of workspace members Workspace admins and owners can now [manage multiple members](/features/people#invite-members) at once. Enable *Select mode* on the People page to change roles, set credit limits, remove users, or revoke invitations for several members simultaneously. This significantly reduces administrative overhead for larger workspaces. ### Workspace invite links Editors and above can now invite people to your workspace using a [shareable link](/features/people#invite-by-link) instead of entering email addresses individually. Invite links are available on Free, Pro, and Business plans. Invite links are role-based and expire after 5 days. Only one active invite link per role can exist at a time, and creating a new link automatically replaces the previous one. Workspace admins and owners can regenerate or delete links at any time from *Settings → People*, or disable them entirely from *Settings → Privacy & security → Invite links*. ### Nano Banana 2 (Gemini 3.1 Flash Image) support [Lovable AI](/integrations/ai) now supports Nano Banana 2, Google's Gemini 3.1 Flash Image model. This specialized model provides fast, high-quality image generation and editing so you can build richer visual features directly inside your projects. ### Lovable Cloud updates Lovable Cloud now provides better visibility and smoother workflows. * [Per-project Cloud usage breakdown](/integrations/cloud#usage) now appears in the *Usage* tab in the Cloud section. You can see a percentage breakdown of how each project consumes Cloud resources and how that contributes to your overall Cloud balance. * [Cloud tools now auto-approve by default](/integrations/cloud#configuring-lovable-cloud-tools), which reduces interruptions while building. You can switch back to manual approval in settings if you prefer to review tool actions before they run. ### Better dashboard organization and navigation These updates improve how you organize and navigate projects across the dashboard. * Recently viewed projects now load significantly faster across the dashboard, sidebar, and search. * A new *Last viewed* sort option helps you quickly return to the projects you accessed most recently. * The *Created by me* filter in the dashboard sidebar gives you immediate access to projects you authored. * Folder search now includes projects inside nested subfolders. * You can now create a folder directly from the *Move to folder* dialog if the folder does not already exist. * The *cmd+K* search modal now displays folder results more clearly, which improves keyboard navigation across projects and folders. ### Project management updates These updates improve how you manage projects across workspaces. * You can now choose the destination workspace when remixing a project. * You can now name a project during the remix flow instead of renaming it afterward. * You can now transfer projects directly from the project card dropdown menu on the dashboard. * Project cards now include a share dropdown so you can copy project links or published app URLs directly from the dashboard. * On Enterprise plans, workspace admins and owners can allows workspace editors to transfer projects they own to their personal workspaces. This ensures students and team members in enterprise cohorts can retain access to their private projects when a course or program ends. Find it in *Settings → Privacy & security → Allow editors to transfer projects.* ### Image generation updates * Lovable now generates higher-quality images with intricate details, accurate in-image text, and realistic app UI mockups. The agent automatically selects the most suitable image generation model for each request. * You can now generate images with transparent backgrounds directly from the chat so generated assets blend seamlessly into your designs. ### Improvements and bug fixes * All newly created projects now open in fullscreen mode automatically. This provides a more focused workspace from the start and ensures a consistent project creation experience. * Lovable now loads code more efficiently. Lovable loads the file tree first and fetches file contents on demand, which significantly improves performance for larger projects. * The code editor sidebar now combines filename search and content search into a single experience so one query shows both matching file names and files containing matching code. * Shopify onboarding now requires fewer steps and automatically detects your country during setup. * SSO-only login is now enforced on Enterprise plans, which prevents sign-in through other authentication methods. * Commits pushed by Lovable now include your GitHub identity as a co-author, which improves traceability and audit history within repositories. * The *Plan mode* toggle now appears as an icon button in the prompt box This aligns it with other project controls. ### Removed * *Themes* have been removed from the *Design* view due to low usage and performance issues. ### Cross-project referencing Example of referencing a project within the Lovable prompt box Lovable can now access and reuse implementations from other projects in your workspace using [cross-project referencing](/features/cross-project-referencing). You can explicitly reference a project using `@` mentions in chat, or simply ask Lovable to use an existing project when relevant. Lovable reads the file structure, source code, and relevant chat history to understand how something was built, then recreates or adapts it in your current project. Referenced projects remain unchanged. Projects can opt out in *Project settings → Cross-project sharing*, and workspace admins can disable the feature under *Settings → Privacy & security*. ### Slack available as an app connector Slack logo on Lovable background [Slack](/integrations/slack) brings messaging and notifications to your apps. Send channel updates, post structured alerts, and read messages directly from your projects. Perfect for deployment alerts, internal updates, support notifications, or keeping teams informed in real time. Workspace admins and owners can connect Slack in *Connectors → App connectors*, and it will be available across all projects in your workspace. You can choose a shared bot for team-wide use or a personal token for individual use, with granular permission control. ### Granola MCP available as a chat connector You can now [connect Lovable to your Granola account](/integrations/mcp-servers) to give the agent context from your meeting notes and conversations, helping it generate apps and features that reflect decisions and discussions captured in Granola. ### Amplitude MCP available as a chat connector You can now [connect Lovable to your Amplitude account](/integrations/mcp-servers) to give the agent access to product analytics data, helping you build apps and features informed by real usage insights and metrics. ### Opus 4.6 Lovable's Agent now incorporates Claude Opus 4.6 at no additional cost. For more information, see [Opus 4.6 in Lovable announcement](https://lovable.dev/blog/opus-4-6-now-in-lovable). ### Lovable Cloud updates Several improvements have been made across [Lovable Cloud](/integrations/cloud). * [Cloud region selection](/integrations/cloud#region-selection)
You can now choose where your Cloud project is hosted: Americas, Europe, or Asia Pacific. If you set a preferred default region in Cloud connector settings, Lovable uses that region automatically. Otherwise, Lovable selects the region closest to your current location. Choosing a nearby region improves latency and overall backend performance. After Cloud is enabled, you cannot change the selected region, and you cannot move existing projects between regions. * **Non-code deployments**
Non-code changes such as adding a secret, configuring a storage bucket, or updating environment settings now deploy directly to your Live environment without requiring a code change. This ensures environment updates are applied reliably across [Test and Live environments](/features/environments) without needing a placeholder commit. * **Reduced Cloud edge function errors**
Cloud reliability has been improved by significantly reducing agent errors related to backend edge function requests. This reduces unexpected failures and improves overall stability for Cloud projects. * **Email rate limits**
You can now configure the number of emails that can be sent per hour from your project. Adjusting this limit helps control delivery pacing and manage Cloud usage. ### SCIM provisioning Workspace admins and owners on Enterprise plans can now provision and deprovision users automatically from an identity provider using [SCIM provisioning.](/features/business/scim) Identity provider groups can be mapped to Lovable roles such as viewer, editor, and admin so new users receive appropriate permissions automatically. ### Guided publishing flow [Publishing](/features/publish) now uses a guided multi-step flow. Set your website address, configure access permissions, add a title and description, upload a favicon and social image, review security, then publish. Favicons are now automatically cropped and converted to the correct sizes and `.ico` format. ### Folder visibility controls You can now set folder visibility to: * Workspace visibility: All workspace members can see and add projects to the folder. * Private visibility: Only you can see and add projects to the folder. You can only configure visibility on the top-level folder. Nested folders inherit the visibility of their parent folder. Projects inside a folder inherit that folder’s visibility and their visibility can no longer be set independently. When moving a project, an access preview shows who will gain or lose access, and you can remove redundant collaborators during the move. Projects that were already inside folders have not been migrated to the new behavior. They retain their current visibility until you manually update them to match the folder. ### Admin controls for app connectors Workspace admins and owners on Business and Enterprise plans can now enable or disable specific [app connectors](/integrations/introduction#app-connectors-add-capabilities-to-your-published-app) at the workspace level. Lovable Cloud cannot be disabled. This gives teams control over which third-party services are available across the workspace. ### External collaborator visibility Lovable now clearly indicates when someone is outside your organization, both when inviting them and when viewing access in the "Share" dialog and other relevant areas. This helps teams maintain governance and awareness when working with external users. ### Project ownership transfer You can now transfer ownership of a project to another workspace member directly from "Project settings". This ensures project administration remains seamless if the original owner leaves the workspace or if ownership needs to shift within your organization. A confirmation dialog clearly indicates if your access will change as a result of the transfer. ### Improvements * The [Plan mode](/features/plan-mode) editor now uses a rendered rich-text view that combines read and edit modes into a single experience. * File edits now persist when stopping the agent, so you can resume work without losing changes. Stopping a request immediately halts further processing and token usage. * Slide generation has been improved through enhanced knowledge file handling, producing better slideshow results from a single prompt. * Project search has been improved with faster full-text search, better substring matching and relevance scoring, and improved stability without unexpected reloads or disappearing results. * Users without any workspace memberships now see a dialog to create a new free workspace or find existing ones to join, ensuring they can continue using Lovable even after losing access to a workspace. * Invitations to workspaces and projects are now accepted automatically by default. You can change this behavior in *Settings → Your account*. ### Removed * Drag and drop reordering of pinned tools in the project navigation bar has been removed due to low usage and cross-browser performance issues. Tools can still be reordered by pinning them in the preferred order. * The custom domain proxying option has been removed from custom domain settings. Running an app behind a CDN or reverse proxy such as Cloudflare, CloudFront, or Fastly must now be [configured directly with your DNS or proxy provider](/features/custom-domain#advanced-use-a-cdn-or-reverse-proxy). ### Plan mode Chat mode is now [Plan Mode](/features/plan-mode). Plan mode helps you review and shape Lovable's approach before implementation begins. * Review and approve a detailed plan before any code is written * Edit and refine plans in a dedicated view before approving * Approved plans are saved to `.lovable/plan.md`, so context persists across messages This improves reliability on complex requests and reduces rework during implementation. ### Prompt queue (with repeatable items) The [prompt queue](/features/agent-mode#prompt-queue) lets Lovable process one prompt at a time. While Lovable is working, you can continue sending prompts and they will be added to a visible queue above the chat input. * Pause and resume the entire queue as needed * Reorder, edit, copy, or remove individual queued prompts * Repeat a queued prompt a specified number of times (up to 50) This makes it easier to batch work, collaborate without waiting, and automate repetitive workflows. ### Browser testing [Browser testing](/features/browser-testing) lets Lovable interact with your app in a real browser running in a virtual environment, so it can test your app like a real user. * Navigate pages and test user flows end-to-end * Capture screenshots of the app * Click UI elements and fill out forms * Read console logs and inspect network requests * Observe real behavior when debugging or verifying changes ### Test and Live environments (Beta) As of **March 24, 2026**, this feature is no longer available for new Cloud projects. Existing Cloud projects that already use this feature will continue to have access. Lovable Cloud projects now support separate Test and Live environments with isolated databases. **Free during Beta**. You must publish at least once to create a Live database before enabling Test. * **Test** is your workspace for building and experimenting * **Live** is the production environment serving real users and is read-only for Lovable When you publish, code and database structure are pushed to Live. Test data stays in Test. Live data never gets overwritten. ### Seamless Google and Apple authentication Lovable now makes it easy to add [Google](/features/google-auth) and Apple sign-in to your Lovable Cloud project. * Ask Lovable to add Google or Apple sign-in and it generates the full authentication flow for you * Remove signup friction with OAuth-based authentication * No password handling or manual authentication setup required ### LinkedIn vibe coding level (Beta) This feature is no longer supported. LinkedIn has sunset the ability to display the older vibe coding status levels, and the feature has been replaced by [Skills](/introduction/lovable-account-settings#linkedin-skills-beta). You can now view your Lovable vibe coding level from L1 to L5 and add it to your LinkedIn profile. * Find your level in *Settings → Your account → Vibe coding level* * Connect Lovable to your LinkedIn account to add it * Appears publicly on LinkedIn under **Licenses & certifications** and updates automatically as your level changes ### Custom MCP servers on all paid plans [Custom MCP servers](/integrations/mcp-servers#custom-mcp-servers) are now available on all paid plans, not just Business and Enterprise. Find it in **Connectors** → **Chat connectors** → **New MCP server** ### New agent and chat UI The agent and chat interface has been refreshed to be cleaner and easier to navigate. * Condensed cards that group tool calls and actions * A details view showing the full timeline of actions Lovable has taken, including tool calls and file changes * Cleaner chat for quick scanning ### New user profiles User profiles have been redesigned to be more expressive and customizable. Profiles are available at `lovable.dev/@yourusername` and lay the groundwork for future community and publishing features. * Set a username and add a custom profile banner image * Teams can claim a workspace username * Bio, location, and link fields let you share more about yourself and your work ### Disconnect Shopify stores You can now [disconnect a Shopify store](/integrations/shopify#disconnect-a-shopify-store) from a project. Disconnect via the Shopify menu, project settings, or by asking the agent. This allows you to: * Remix the project (projects with a connected Shopify store cannot be remixed) * Connect a different store or create a new one without creating a new project ### Custom domain proxying When connecting a custom domain, you can now enable [Allow traffic through a CDN or proxy](/features/custom-domain#advanced-use-a-cdn-or-reverse-proxy) to run your Lovable app behind your own CDN or reverse proxy, such as Cloudflare, CloudFront, or Fastly. ### Default design templates (Business and Enterprise) Set a default [design template](/features/business/design-templates) for your workspace so new projects start with consistent design and structure. * Workspace templates can now be marked as default in *Settings → Templates* * New projects automatically use the default template, with the option to override ### Improvements * Extended processing time per request for the Lovable agent, up to 15 minutes, supporting longer browser sessions and more complex tasks * Reorder folders in the dashboard sidebar via drag and drop, with support for nesting up to 3 levels * Drag to select multiple projects for bulk actions on the dashboard, inside folders, and in starred projects * Right-click on projects and folders in the dashboard to open their dropdown menus * A new banner encouraging email and password users to enable [two-factor authentication](/introduction/two-factor-authentication-2-fa) for better account security * Icon loading optimizations to reduce bundle size and improve initial UI load times * [Project visibility](/features/project-visibility) renamed from "Personal" to "Restricted" ### Build credit top-ups You can now purchase credit top-ups when you run out of build credits, without changing your subscription. Top-ups are billed as a one-time payment and added instantly to your workspace. Find it in *Settings → Plans & credit usage*. * Available on Pro and Business plans * Purchased in 50-credit increments * Valid for 12 months from your most recent top-up purchase ### GPT-5.2 and Gemini 3 Flash support [Lovable AI](/integrations/ai) now supports GPT-5.2 and Gemini 3 Flash, giving you access to the latest models for building and iterating faster. Enable Lovable Cloud and AI to use these models. **Gemini 3 Flash is now the default model**. ### Two-factor authentication (2FA) [Two-factor authentication (2FA)](https://docs.lovable.dev/introduction/faq#how-do-i-enable-two-factor-authentication-2fa) adds an extra layer of security to your Lovable account using an authenticator app (recommended) or SMS. This is a form of multi-factor authentication (MFA) that helps you protect your Lovable account. Find it in *Settings → Account → Your account*. ### Lovable bonuses Earn credits by completing simple actions: * **Daily bonus**: Send 25 messages to earn 5 credits (available to all users) * **One-time bonuses**: Add a custom domain or invite a collaborator to earn 5 credits (available to newly registered users from Jan 15, 2026) ### Smarter agent capabilities The Lovable agent continues to get more capable and helpful: * Generates videos when prompted * Suggests publishing at the right moment and opens the publish menu * Cleans up unused edge functions to keep projects tidy * Tests authenticated edge functions while you’re logged in, improving reliability for features that require authentication * Responds faster by selecting relevant information more efficiently during generation * Understands TypeScript projects more deeply, with IDE-level code intelligence for types, references, and relationships ### Smoother publishing experience Publishing your app is now smoother and clearer: * You can generate logos, favicons, and Open Graph images by prompting the agent, making it easier to customize your app before publishing. These assets are then used automatically during publishing. * Publishing failures are now visible, with a built-in "Try to fix" action to help you recover. * Links and redirects for published apps are more reliable, with better awareness of deployed app URLs. ### Better dashboard organization and navigation * New "Recent" projects section in the sidebar * Nested folders for better organization * Drag-and-drop support for projects and folders * Redesigned workspace selector, with better default ordering, the ability to reorder workspaces, improved visibility, and faster loading ### Security center (v0.1) A new security center gives admins a workspace-wide overview of security findings across projects, including code analysis statuses (errors, warnings, scan state) and dependency vulnerabilities with severity levels and affected projects. Find it in *Settings → Workspace → Security center*. ### Redesigned "People" page The "People" page has been updated with clearer separation between invitations and collaborators, improved searching and filtering, and more reliable sorting. ### Improvements * **Dependency vulnerability scanning is now available**, with issues in project dependencies reported as security findings you can review and fix like other security issues, and surfaced to workspace admins in the new "Security center". * **Lovable now offers a more native mobile experience across the app**, with sheets replacing popovers for menus, navigation, and sharing. "Inbox" and "What’s new" now live inside the top-right avatar menu. * **Custom domain setup guidance has been improved**, prompting users to add both `www` and non-`www` variants to avoid common configuration issues. * **Payment issues are now surfaced inside the app**, making it easier to spot and resolve failed or overdue payments. * **You’ll now receive reminders when rollover credits are about to expire**, helping you avoid losing unused credits. * **Chat now provides more natural next-step suggestions**, helping you understand what to do after your first message. * **Plan cards in chat mode have been standardized**, with a single "Implement plan" action to streamline the flow. * **Vitest is now included in the React template**, enabling the agent to write and run tests without additional setup. * **Speech-to-text has been upgraded** to use the new ElevenLabs transcription model Scribe V2, improving accuracy, language detection, and transcription quality for voice input in Lovable chat and apps using ElevenLabs. * **Project and workspace settings pages have been redesigned**, replacing modals with dedicated pages while keeping the same settings and options. ### Connectors: ElevenLabs, Perplexity, and Firecrawl Ai Connectors Your apps can now speak out loud, do research, and pull live data from anywhere on the web. These powerful integrations expand what you can build in Lovable. [ElevenLabs](/integrations/eleven-labs) brings voice and sound to your apps. Generate natural-sounding speech in dozens of languages, create character voices for storytelling apps, or add audio briefings to any project. [Perplexity](/integrations/perplexity) adds AI-powered research to your apps. Your app can now search the web, synthesize information, and deliver answers backed by verifiable sources. Perfect for building sales prep tools, competitor trackers, or fact-checking apps. [Firecrawl](/integrations/firecrawl) transforms websites into structured data. Build job boards that aggregate from multiple sources, price trackers that monitor competitors, or tools that keep website data up to date automatically. Free for Lovable users through April 2026 when choosing managed credentials. Workspace admins can connect these services in *Connectors → App connectors*, and they'll be available to all members across all projects in your workspace. [Learn more about connectors](/integrations/introduction). ### Lovable ChatGPT app Lovable Chatgpt App Plan your ideas in ChatGPT, then build them instantly in Lovable. The new Lovable ChatGPT app lets you turn conversations into working apps without leaving your chat. Simply tag @Lovable in any ChatGPT conversation to start building, then jump into Lovable to continue editing, iterating, and shipping your project. [Learn more about Lovable ChatGPT app](https://lovable.dev/chatgpt-app). ### Lovable gift cards Give the gift of building. Lovable gift cards are now available, making it easy to gift Lovable to friends, teammates, or clients, and just in time for the holidays. Find them in *Settings → Plans & credits usage*. ### Tasks The agent now creates visible tasks while working, giving you more control and transparency over what's happening. This makes it easier to follow progress and guide longer or more complex builds. It's a step toward longer-running agents and more sophisticated planning. ### Mention code files in chat Reference specific files directly in chat by typing `@` or clicking the reference button in the code editor. This makes targeted edits and discussions about specific files faster and clearer. ### Project credit usage (new projects only) Project settings now show the total credits used for each project, giving you better visibility into actual usage. Project credit totals are only available for new projects. ### Verified domain workspace discovery Business and enterprise users can now discover and request to join workspaces based on verified email domains, making it easier to find and collaborate with the right team. ### Public preview link controls Enterprise plans now have the option to disable public preview link creation for workspace members, giving admins more control over how projects are shared externally. You can find this setting in *Settings → Privacy & security.* ### Simplified SAML SSO setup Business and enterprise plans can now configure SSO more easily by importing SAML configuration directly from a metadata URL, automatically populating all required fields instead of manually entering each value. [Learn more about SSO.](/features/business/sso) ### Bug fixes and improvements * Fixed issue where links in chat didn't always open in new tabs. * Updated the [publish](/features/publish) modal to better explain what happens when you publish an app, clarifying that publishing does **not** expose your source code or make the app automatically remixable. ### **A more Lovable dashboard** Screenshot of the redesigned Lovable dashboard showing project organization with folders, filters, and grid view We launched a completely redesigned dashboard with major improvements to navigation and project organization. * Star your go-to projects for quick access * Stay organized with folders * Find projects faster with new filters and global search * Discover apps from the community * Switch between grid and list views * Select new dashboard themes (User settings → Appearance) * Use bulk actions: delete, move, remove from folders, transfer between workspaces ### **Chat before you build** Interface showing the new Chat mode option for starting projects with a conversation before generating code You can now start any new project in **Chat mode**. Instead of immediately generating an app from your first prompt, you have the option to have a conversation with Lovable to refine your ideas before any code is written. [Learn more about starting from chat mode](https://lovable.dev/blog/chat-mode-and-questions). ### **Opus 4.5 as a core model** We upgraded Lovable’s Agent to incorporate **Claude Opus 4.5** for core parts, bringing major improvements to planning, design quality, and accuracy. This results in smoother development loops, 20% fewer errors, and better overall project success. Available automatically to all users at no additional cost. [Learn more about Opus 4.5 in Lovable](https://lovable.dev/blog/claude-opus-4-5-in-chat). ### **New custom domain actions** New actions are now available to help troubleshoot domain configuration issues. * **Check status**: Use to check the latest status and verify the DNS records. Appears when the domain status is **Verifying** or **Unable to verify**. Check that your `A` and `TXT` records are added correctly at your DNS provider, especially the full TXT value. * **Recover**: Use to review displayed DNS records and update them at your DNS provider to reconnect your domain. Appears when domain status is **Offline**. * **Reconnect**: Use to connect the domain again. Appears when domain status is **Removed**. [Learn more about custom domains](https://docs.lovable.dev/features/custom-domain). ### **Cloud instance upgrade alerts** You now receive alerts when approaching your Lovable Cloud resource limits. This lets you upgrade your instance in a timely manner to ensure fast and reliable performance. The upgrade alert in Cloud → Advanced settings also includes a detailed breakdown of usage (disk space, disk IO, CPU). [Learn more about Cloud instance upgrade options.](https://docs.lovable.dev/integrations/cloud#advanced-settings-upgrade-instance) ### **Connectors hub (formerly Integrations)** The Integrations page is now called **Connectors**, and the information has been reorganized to clearly distinguish between: * **App connectors**: Add functionality to your apps. Configured once by admins, available to everyone in your workspace. For example, Lovable Cloud, Stripe, Shopify. * **Chat connectors**: Connect your personal tool accounts to provide context while building. Only you can access your connections. For example, Notion, Linear, Miro. [Learn more about connectors](https://docs.lovable.dev/integrations/introduction). ### **Miro MCP available as a chat connector** You can now connect Lovable to your Miro account to give the Agent context from your boards and diagrams and generate apps that reflect what you mapped. [Learn more about Miro MCP](https://docs.lovable.dev/integrations/mcp-servers). ### **Support for unauthenticated MCP servers** Business and Enterprise plans can now add custom MCP servers that don’t require authentication. [Learn more about custom MCP servers](https://docs.lovable.dev/integrations/mcp-servers). ### **Manage tool permissions for chat connectors** You now get a clearer overview of tools for each chat connector and can set how the Agent is allowed to use them by default: always allow, ask each time, or never allow. ### **Control who can publish externally** On Enterprise plans, admins can now restrict external publishing to: * Admins & owners * Owners only This improves security and supports governance for organizations handling sensitive data. [Learn more about publishing](https://docs.lovable.dev/features/publish). ### **Chat suggestions on mobile** Context-aware prompts now appear in chat on mobile, helping you build faster with fewer taps. ### **Bug fixes and improvements** * Lovable’s generated designs are now more creative and polished. * Lovable is now better at understanding and using your imported packages, leading to fewer errors and smoother builds. * Default project visibility has been updated to private for all Lovable workspaces that previously had default project visibility set to public. * Saving visual and code edits is now \~20% faster. ### **MCP servers** MCP servers integration panel showing connections to Atlassian, Notion, Linear, and n8n Connect Lovable to your work tools: Atlassian (Jira, Confluence), Notion, Linear, and n8n. Pull in PRDs, tickets, and wireframes directly into your builds. n8n workflows let you integrate with 400+ apps like Salesforce, Slack, and Google Sheets. Business and Enterprise plans can add custom MCPs and control which servers are available. [Learn more about MCP servers](https://docs.lovable.dev/integrations/mcp-servers). ### **Design view** Design view panel showing tabs for Visual edits, Themes, and AI image generation tools The new Design view provides a dedicated panel where you can seamlessly switch between your project's design tools. This includes updates to Visual edits, as well as new features including Themes and AI image generation. ### **Themes** Themes panel showing color, typography, and spacing customization options Set your brand standards once: colors, typography, spacing. Apply them to any project. Preview themes before applying to see how they'll look. ### **All new Visual edits** Visual edits interface showing element selection with margin, padding, and style controls Access Visual edits from the Design view or use the Visual edits shortcut in the prompt box (previously Edits), and make your edits directly in the left-hand panel. You can now edit text in elements with mixed content, like buttons containing both text and icons. Select and edit multiple elements at once. Change text directly on the page. Adjust margins, padding, borders, shadows, colors, and icons. Update images or generate images with AI. ### **AI-powered image generation in Visual edits** AI image generation dialog with a text prompt field for describing custom images Generate custom images by describing what you want. Create original visuals for your projects without leaving Lovable. AI image generation does not consume Lovable credits. ### **Private projects for everyone** All plans now include workspace-only projects (enabled by default). Change your default in Settings → Privacy & security. [Learn more about private projects](https://docs.lovable.dev/features/private-projects). ### **Shopify integration improvements** You can now **connect your existing Shopify store** to Lovable. For security, the Lovable user’s email must match the Shopify store owner’s email. When creating a **new store**, you now select the store’s location during setup, and the claim flow has been improved with clearer states. When the store is claimed, the Lovable user who claims it becomes the Shopify store owner. Authorization updates * Only the user who connected an existing store or claimed a new store has write access (create, update, delete products, variants, and discount codes). * Collaborators maintain read-only access to Shopify data (search and retrieve products, variants, and discount codes), but can still fully build the storefront. [Learn more about the Shopify integration](/integrations/shopify). ### **Gemini 3 Pro & image generation support** Lovable AI now supports Google's latest models including Gemini 3 Pro and Nano Banana Pro. Enable Lovable Cloud & AI to access these models in your apps. ### **Improved share & invite experience** The share dialog has been redesigned to make it clearer who can do what in your project. Better permission visibility, a more prominent share preview, and clearer collaboration concepts. ### **Cloud storage improvements** Manage your storage directly from the Cloud view. Create private or public buckets, organize folders, and upload, rename, delete, or download files. Private bucket files are now visible in the UI, too. ### **Questions** When your request has multiple ways forward, Lovable can now ask clarifying questions before building. Pick from multiple-choice options or add your own input to help Lovable understand exactly what you're looking for. ### **Integrations hub** The new Integrations tab in project settings brings together Lovable Cloud, Lovable AI, MCP servers, Supabase, Shopify, and Stripe. ### **Chat suggestions** Context-aware prompts appear in the chat suggesting what to build next. ### **Low credit alert** Users on Pro and Business workspaces now see an alert when fewer than 5 build credits remain, along with a shortcut to upgrade the plan to increase monthly credits. The alert appears above the prompt box and in the project and workspace menus, helping ensure you never run out mid-build. ### **Temporary education logins** Educators can create temporary student accounts at lovable.dev/login/temp for classroom use. ### **Improved remix experience** See step-by-step progress when remixing projects. Get clear error messages explaining why projects can't be remixed. Remixing runs in the background with a persistent notification, so you can continue working. Now supports remixing projects with custom secrets. ### **Better reverts and ability to edit and revert your messages** "Restore" is now "Revert". Jump back to any point in your chat history, or edit a past message to explore a new direction. Your original work stays in the chat and can be reapplied anytime. ### **Project URL** Project URLs are no longer automatically generated on project creation. Set your own unique project URL before publishing or have Lovable auto-generate one for you. ### **Project display name** Lovable now automatically generates a more meaningful display name for your project. The display name is only visible to you and members of your workspace, not to visitors of your published app. Display names are only unique across a workspace, reducing issues with already reserved names. You can always rename your project to something more meaningful by going to project settings. ### **Better commit messages** Commit messages now describe what actually changed in your project, not just what you asked for, making it easier to browse your project history. ### **Navigation update** Privacy & security settings have been moved into their own tab for easier access. ### **Bug fixes** * Fixed preview reload errors that previously got stuck on "Try to fix" until a page refresh. The system now detects transient errors and retries automatically. * Figma Import has been removed due to quality issues. We’re working on something new and exciting here - stay tuned. ### **Lovable × Shopify Integration** Lovable and Shopify integration showing a storefront builder with product management Build an online store by chatting with AI. Lovable sets up products, cart, and checkout; when you’re ready, claim the store in Shopify and publish. Great for everything from hobby shops to large catalogs. Bonus: 30‑day Shopify trial when you sign up through Lovable. [Learn more about the Shopify integration](/integrations/shopify). ### **Show the agent what you mean** Screenshot capture feature in chat showing the ability to capture and share screenshots with the agent The Lovable agent now understands your context better. It knows which tab you're viewing in Lovable - whether that's the Code Editor, SEO, Analytics, Cloud settings, or Secrets - so it can give you more relevant responses. You can ask the agent to screenshot your build, or capture screenshots from anywhere on your computer right from the chat interface. ### **Always have enough Cloud & AI funds** Top up automatically when your balance drops below \$10, but remain in control of your monthly charges by adding a monthly cap. You can now also track Cloud & AI usage for each project. [Learn more about adding Cloud & AI funds](https://docs.lovable.dev/integrations/cloud#adding-funds-paid-plans-only). ### **Better custom domain management** Set a primary domain for your project, with other custom domains automatically redirected to it. Adding a new domain is now easier with a clearer workflow and step-by-step guidance. We've also added domain validation to verify ownership before your domain goes live. [Learn more about custom domains](/features/custom-domain). ### **Request access to private projects** When navigating to a private project, you'll be able to request access from the project owner. Keeps private work secure while making collaboration easier. ### **Workspace-only publishing (Business & Enterprise plans)** Published projects can now be set to "workspace-only" access, requiring authentication and limiting access to your workspace members. Perfect for building internal tools and apps. [Learn more about publishing.](/features/publish) ### **Desktop notifications** Enable desktop notifications to know when long-running builds finish. No need to keep checking back to see if you're done. ### **Disconnect project from GitHub** You can now disconnect your project from GitHub when needed. Useful if you need to transfer it to a different GitHub organization. [Learn more about the GitHub integration](/integrations/github). ### **Bug fixes** * Fixed an issue where the agent's responses would appear all at once instead of typing out gradually. * Reduced the number of pop-up notifications you see right after signing up. * Error messages now appear more consistently when something goes wrong. * Cleaned up spacing and alignment issues in the chat interface. ### **Lovable Cloud** Lovable Cloud logo Build full‑stack apps with no manual Supabase setup. Lovable Cloud gives you on‑demand databases, user authentication, and storage that scales automatically as your app grows. Lovable Cloud is available for all new projects, and any existing projects that aren’t integrated with Supabase. [Learn more about Lovable Cloud](/integrations/cloud). ### **Lovable AI** Lovable AI logo You can now build AI-native apps in Lovable, just by prompting. We manage provider access & APIs so you can focus on building your product. Through October 13, we’re offering free embedded AI functionality powered by Google Gemini. You can now build things like: * **Special-purpose ChatGPT clones** — tailored conversational assistants for support, sales, or knowledge work. * **Avatar & image generators** — let users create, edit, and customize visual content. * **Coaching apps** — personalized guidance, onboarding coaches, habit builders, and more. Every plan includes free monthly credits to use towards embedded AI functionality. Yes, even free plans! Full pricing can be found [here](https://docs.lovable.dev/features/cloud#usage-based-cloud-and-ai-pricing). [Learn more about Lovable AI](/integrations/ai). ### **Voice mode** You can now talk to Lovable. We’re unlocking a more intuitive and conversational way of building: describe ideas and edits out loud and Lovable makes it. ### **Turn your files into apps** Illustration showing file types like spreadsheets, resumes, and slide decks being transformed into apps Drop any file type into Lovable to turn it into an app. For example: * Sheets → interactive dashboards * Resumes → portfolios * Slide decks → custom presentations ### **Sonnet 4.5** Anthropic’s latest model now helps power your builds on Lovable. Expect stronger reasoning, more consistent results, and better performance on multi‑step edits and structured data. ### **A smoother build experience** Building on Lovable just got smoother: quicker access to the Visual Editor, better long-run UX, and image support in the Code Editor. ### **Confidently publish and unpublish** Ship with confidence. The publish flow now includes link‑preview editing before you go live. Made a mistake? Unpublish with one click. ### **Stripe integration** We’ve updated our Stripe integration with clearer billing & payment flows. Setup all your Stripe logic in chat by just describing what you want to build - no manual setup required. [Learn more about the Stripe integration](/integrations/stripe). ### **Updated community resources** Both our Partner page and Remix got upgrades so you can extend what you build through the community. Visit the partner page to find specialized agencies (or apply to be featured), and use Remix on your favorite Lovable Cloud projects to get started faster. ### **Better workspace management** A new unified member view lets you understand usage and take actions across your team. Admins can now set session duration limits, turn on just-in-time provisioning (SSO), disable publishing and enforce project privacy settings. ### **Bug fixes** * Fixed in-chat sizing issues that caused horizontal scroll * Reduced build errors by 20% ### **Student + teacher discount live** We’re making it easier for students and educators to get building. Now, both students and teachers can save up to 50% off Pro, for up to a year. The discount applies if you’re starting from a free workspace—so you can unlock the full power of Lovable without stretching your budget. [Learn more about the offer here](https://lovable.dev/students). ### **Security upgrades** Security certifications badge showing SOC 2 Type 2 and ISO 27001:2022 compliance Security is our priority. We’ve expanded our security features, policies, and certifications including adding SOC 2 Type 2 compliance and ISO 27001:2022 certifications. We also hired an incredible CISO, Igor Andriushchenko – so you can trust us with your ideas, your data, and your customers. Read more about our security features [here](https://lovable.dev/security). ### **Your new Lovable Inbox** Lovable inbox interface showing project invites and recent updates Your new personal inbox helps you track project and workspace invites, and you can also check out updates we’ve recently shipped—so you’re always up to speed. ### **Smarter SEO for new apps** When you create a new app or webpage, Lovable now includes agentic SEO instructions that better respect SEO best practices. This helps your projects get better indexed on search engines and reach the audiences you’re building for. ### **Workspace viewer role (Pro+)** For Pro+ members, we’ve introduced a new Viewer role. Viewers can see workspace metadata, projects, and members, but can’t create or edit projects or invite others. It’s the perfect role for stakeholders who need visibility, but don’t need to edit projects. ### **Flexible plan management** Plan management interface showing upgrade and downgrade options You can now upgrade or downgrade your plan in just a few clicks—whether you need more credits or want to scale down to free. ### **Clearer error feedback** If the LLM ever misinterprets your request, Lovable now lets you know directly. You’ll see what went wrong so you can adjust your prompt and move forward faster. ### **Track your edits + streaks** We’ve added a personal dashboard where you can see how many edits you’ve made in Lovable and track your streaks. A great way to stay motivated and see your progress over time. Check it out under your Account Settings. ### **Agent Mode is the new default mode** With this upgrade, Lovable becomes a truly agentic partner—interpreting requests, understanding your codebase, fixing issues, executing complex multi-step edits across files, integrating with external tools, and reducing errors by 91%, so you can build more ambitious apps faster and with less friction. Legacy mode (where you don’t use agent) will be sunsetting on September 1, 2025. ### **Real-time analytics on your Lovable apps** Curious how your app is performing in the wild? You can now track live traffic and engagement directly inside Lovable including: * Visitors: How many people are using your app Pageviews: Which pages get the most attention * Visit duration: How long users stay * Bounce rate: What percentage leaves instantly * Views per visit: How deeply users engage The data updates in near real-time so you can spot trends, debug issues, or just celebrate your first users! Available now under Project Settings → Analytics ### **Lovable Business plan** Introducing the Lovable Business Plan, built for teams that need more control, privacy, and flexibility. It includes everything in Pro, plus powerful upgrades: * SSO for secure org-wide sign-in * Restricted projects only visible to you * Templates for consistent styling * Yearly plans now available You can now switch to a yearly subscription for any paid Lovable plan. Get a discounted rate, simplify billing, and worry less about monthly renewals. ### **Visual edits v2** We have refined the visual edits experience after tons of feedback. More responsive, precise, and delightful to use. It’s faster than ever to tweak your UI, fix copy, or adjust layout—without leaving the live preview. You can also jump to selected elements in code when using visual edits, tightens the loop between design and implementation. ### **Project invites workflow** Invited users must now formally accept or decline access to a project—both from email and magic links. This avoids stale “pending” members and improves collaborator tracking. ### **Search all files in the code editor** Use the file search inside the code editor to quickly locate code and add file paths directly into chat. ### **Unified credits bar** We’ve shipped a new credits bar that combines all credit types into one clean, unified view—no more jumping between different displays to track usage. ### **Upgraded people tab** The People tab in workspace settings has been redesigned. It now includes pagination (20 users per page), search, and filtering by member status—making it much easier to manage large teams. ### **Scales to large workspaces** Thanks to backend improvements, we now support massive workspaces with tens of thousands of members without performance issues. ### **Published project badge** We’ve added a small but useful touch: all published projects now display a “Published” badge so it’s easier to see what’s live at a glance. ### **Bug fixes** * Fixed image upload bug causing >1% of initial generations to fail if the user wasn’t logged in. * Prevents redundant updates when a project is already up to date with the deployed version. * You can now disconnect a project from legacy Supabase when disconnecting the org. * Reconnecting orgs with invalid tokens is now seamless. ### **Spotlight** We've made collaboration on Lovable even more accessible by making it a free feature for all users. For Free and Pro users: * Workspace collaboration is now completely free – invite your teammates and start building together at no additional cost. * Unlocks workspace collaboration for up to 20 members on both Free and Pro plans. * On Free plans, additional members join as editors; Pro plans offer granular workspace roles and permissions. For Teams plan users: * We've simplified our pricing structure and moved you to the Pro plan with significant savings: * You've been automatically moved from the Teams plan to the Pro plan. * You'll now pay 20% less starting with your next renewal. * You still have access to all the same features and credits as before – just at a lower price. * All your project and workspace settings remain unchanged. ### **Improvements** * Redesigned the mobile experience for building apps and websites directly from your phone. * Shipped a Visual Edits refresh with new floating combo box controls positioned right next to elements you're editing * Added project search functionality with fuzzy matching by name – *tip: rename your projects for better discoverability*. * Rolled out full-stack initial generations to all users that will enable you to connect Supabase before doing an initial generation * Added a floating prompt bar to our homepage that lets you enter prompt even when scrolled down. * Enhanced the history view with a cleaner timeline prioritizing dates, restored versions now visible, and simplified version navigation. * Updated the careers page with latest information. [Check it out here](https://lovable.dev/careers). ### **Bug fixes** * Fixed admin access to integration settings for user projects. * Resolved issue where admins couldn’t properly access workspaces, causing editor display and functionality issues when visiting team projects. * Fixed iframe redirect issue that was causing unwanted redirects within the Lovable app. ### **Spotlight** * Enhanced project discoverability with new filtering options to easily find and manage your projects. * Added categorization to community projects to make it easier to discover projects by the community. ### **Improvements** * Chat mode now renders Mermaid diagrams to help visualize your app's back-end logic and structure (ask for it to chart things to trigger this). * Auto-configure redirect URLs for Supabase Auth integration - no more manual configuration needed for a more seamless authentication setup. * Added in-product feedback system - click the thumbs down button when edits cause issues to help us improve Lovable's AI for everyone. * Introduced smart nudges to guide you to Chat Mode when debugging issues that need conversational help. * Edit history now shows screenshot previews on hover, letting you quickly see what your app looked like at different stages without opening each version. ### **Security** * Added API key detection in chat that warns you before accidentally sharing sensitive information like secrets. * Rolled out AI-powered "Security review" feature to help identify potential vulnerabilities in your apps. Trigger it before publishing your app via the publish modal. ### **Spotlight** * Claude 4 is now being used in Lovable! It's powering most prompts, both for project creation and for edits on all projects (including old projects). This should make Lovable have 25% less errors and be 40% faster overall. ### **Improvements** * Revamped the setup flow for both GitHub and Supabase, simplifying multi-step onboarding to reduce confusion. * Added visual labels to featured projects on the homepage for better discovery. * Added support for removing custom domains from your Lovable app. * Several improvements in collaborator management: * Added validation to the email invite form in the People tab * Tooltips now explain the permissions for each role (admin / owner / editor) * You can now see the role of pending invites * Better error messages for edge cases like inviting someone already in the workspace * Commit messages now rely more on conversation history for better context. * Improved the quality of streaming: smoother experience and no more flashing text. * Users can now view public Lovable projects without being logged in. * Active edit cards are now highlighted so it’s easier to see which one is active. * The default “Edit Code” button now opens the preview instead of the raw code. ### **Bug fixes** * Fixed bugs that caused the wrong live preview to show in some cases. * Fixed a bug where refreshing the preview could change the current path. * Fixed a bug that caused infinite redirect loops when starting a live preview after logging in. ### **Spotlight** * We’ve added support for transferring projects between workspaces! * Lovable is now better at understanding images — whether you’re uploading a design reference or a real site asset, it knows the difference and will handle it accordingly ### **Bug fixes** * Fixed issues with published projects and deployed preview links not reflecting the latest version * Project visibility settings have returned to team workspaces, but will be disabled for now * Fixed issues where workspace owners were not able to edit projects created by non-owners in teams workspace * Fixed issue where “downgrade button” in billing page would link to wrong Stripe page * Fixed issue where some users were not seeing their plan after upgrading to a higher plan ### **Improvements** * Improved credit tracking by making it explicit when you have reached 30 monthly credit cap and being explicit about when both your daily and monthly credits will renew * ​Made it possible for you to invite non-users to team workspaces * Revamped errors modals to display more helpful messages (e.g. Supabase token issues), not just “Request failed” * Updated settings tabs (Projects, Knowledge, Domains) to new design ### **Bug fixes** * Fixed issues where credits were not refreshed except when refreshing the page * Fixed an issues where lovable failed to fetch edge function logs * Fixed issue that led GitHub branch switching to fail if you had renamed the repo * Fixed bug that was blocking users from applying some SQL migrations * Fixed poor styling in mobile pricing page * Fixed issue that was blocking project renames * Fixed issues where the projects counter in homepage was not showing right number * Fixed issues leading to Supabase re-authentication loop * Fixed the issues where edits made in Dev Mode where not being saved * Fixed the issues where the “Working…” indicator was not appearing for collaborators ### Lovable 2.0 We’re so excited to launch **Lovable 2.0**! This one’s all about collaboration, security, and giving you more control. Lovable 2.0 announcement banner featuring the new logo and branding * We’ve rebranded! New logo, brighter colors, and a much cleaner UI. Go check it out below— we hope it feels like a glow-up. * [Teams](https://docs.lovable.dev/user-guides/teams): Real-time collaboration is finally here! Invite others to co-edit apps or create shared team workspaces. * [**Simplified Pricing**](https://docs.lovable.dev/user-guides/messaging-limits#free-vs-paid-plans-comparison) with two clean options: Pro starts at \$25/month and Teams starts at \$30/month. * **Security Scan:** Lovable now checks for vulnerabilities when you publish (if you’re connected to Supabase). This is just the beginning of our work to make vibe coding safer by default. * When you try to revert to a past edit after which you ran a migration, Lovable will tell you we're not reverting the Database. * You asked, we listened. [Chat mode](/features/plan-mode) is now *way* smarter and **here to stay** for everyone. It doesn’t make edits, but it *can* help you reason through problems, plan features, inspect logs, query databases, and more. Think of it as your smart, hands-off pair programming buddy. This is a big step forward — and we're just getting started. Thanks so much for being on this journey with us * Shipped github reliability improvements. We should now be able to sync to GitHub even when the user token has broken. * Shipped some preview outdated fixes. * When transferring repos, orgs/users that are suspended will be marked so. If clicking you will go to the page to unsuspend it. * You can now purchase a domain directly from your project settings — just click “Buy a domain”, search for what you want, and complete the checkout in a few clicks. We’ve partnered with IONOS to make this possible. Read more [here](http://email.lovable.dev/e/c/eyJlbWFpbF9pZCI6ImRnVG1qZ29EQUotUVZKNlFWQUdXRzVfR2VPdTVlSEVGMnU1Wk5hbz0iLCJocmVmIjoiaHR0cHM6Ly94LmNvbS9sb3ZhYmxlX2Rldi9zdGF0dXMvMTkwOTYzMzY1NjQ0MTc4NjYwOCIsImludGVybmFsIjoiZTY4ZTBhMmRhZWRkMDE5ZjkwNTQiLCJsaW5rX2lkIjoyMDk2fQ/de4d0c380fdfac4a4accea202b7884c14b49d33fc1c0ca808b5a4ebc9e6540fe). * Updating the favicons is now easier to set up directly from Lovable. * Loading larger projects should now be much faster since not all messages are loaded when the project is opened. Additional messages are loaded only when a user scrolls up. * Clicking on the Supabase button (shown in first generation) now opens the setting pane. Also added a small What is Supabase? callout for first time users also linking to our docs and tutorials. * **New UI:** Updated the editor nav bar design, which moves pages dropdown and related buttons from preview panel header to nav bar. * Refactor of diff creation which handles multiple edits to the same file. * Upgraded the [Stripe integration](/integrations/stripe). * New chat scrolling: Scrolls new user messages to the top of the viewport instead of autoscrolling as text is generated. * Lovable now has a Dev Mode. Enabling Dev Mode lets you not only read your project's code, but also edit it directly inside Lovable. Read more about it [here](http://email.lovable.dev/e/c/eyJlbWFpbF9pZCI6ImRnVG1qZ29EQUotUVZKNlFWQUdXRzVfR2VPdTVlSEVGMnU1Wk5hbz0iLCJocmVmIjoiaHR0cHM6Ly94LmNvbS9sb3ZhYmxlX2Rldi9zdGF0dXMvMTkwNzgxNjU2Nzk0NzA5NjM0MSIsImludGVybmFsIjoiZTY4ZTBhMmRhZWRkMDE5ZjkwNTQiLCJsaW5rX2lkIjoyMDk1fQ/c876becf4f48a97a1c3fd592a50e2bb9bcb03651afcb81988c68b031dc617425). * Fixed Supabase integration where the AI was creating `config.toml` file in the wrong folders. * Fixed so you can close the visual edits with `x` button again, and the `alt+s` hotkey works again in the preview. * Turn your LinkedIn profile into a personalized website. * Wondering if something’s down? You can now check our status page for live updates. Check it out [here](https://status.lovable.dev/). * Shipped that try to fix shows up when screen gets blank. * Fixed bug where only the first edge function log is fetched. * Fix bug causing infinite requests when going to profile page. * Fixed a panic caused by concurrent map writes in the experiment service. * Reduced by 4x occurrences of messages where we mix `lov-sql` and `lov-code`. * Fixed a bug when labs settings were not being saved now. * Previews are back online. Please let us know if your domains are not working. * Fixed bug where only the first edge function log is fetched. * We made some maor improvements/fixes to Supabase especially how to invoke edge functions. * Supabase functions now get deployed when updated in code editor. Also, Supabase functions are updated live in code editor when changed by AI. We heard the issues you've shared with us and we're working hard to fix them all. This is what we've shipped on product reliability this week: * Fixed bug where AI would create new edge functions instead of fixing existing ones. * Labs features settings are now saved to your user account instead of local storage, ensuring they persist across devices. * The monthly credits counter is now in the settings menu for quick access. * Fixed bug causing the live preview window to go out of sync after AI edits. * Fixed Supabase authentication session persistence issues. * A complete rewrite of the Custom Domains backend(s). System should more stable now, quicker, self-healing and support unicode domains. * *Connect custom domain* as action in publish dialog for users that have not connected any domains to their project yet. * Chat mode is faster than ever, fixing the bug where it sometimes just stopped. * Added a supabase icon for connected projects in the project card, clickable for your own projects to take you to the supabase dashboard. * Full support for SEO and Open Graph images so links (e.g. on X) now show proper card previews. * UI update to clarify that Supabase connections happen at the organization level. * Shipped memory leak fixes to prevent backend crashes during user requests including long intial runs. * Shipped continuous project lock extensions and sandbox pings to support long-running requests without premature termination. * We’ve made some improvement to Lovable’s project settings layout for a more intuitive experience. You can now find Project Settings in the top left corner of your project page for quicker access and better navigation. [Here's what's new](https://discord.com/channels/1119885301872070706/1120705825317593149/1350101727768084491). * Introducing [custom domains](/features/custom-domain) in Lovable. * Announcing the \$10K [Lovable's Build Competition](https://build-launch-win.lovable.app/) with Lovable, Anthropic, Supabase & Sentri. * Best website design, \$3K cash winner. [Tweet here](https://x.com/lovable_dev/status/1900574280011731167). * [Introducing Versioning 2.0](https://x.com/lovable_dev/status/1896637541618778574) enabling bookmarking, easier restores and improved history view. * [Dev Mode:](https://x.com/lovable_dev/status/1897693825767768542) Easily edit any code of your project directly in Lovable. All paid users can enable dev-mode in settings. * Fixed a **Chat Mode streaming bug.** * Resolved **internal server errors** in default mode. * Addressed **main regressions** introduced with [Sonnet 3.7](https://lovable.dev/blog/anthropic-sonnet-3-7-lovable-diff-viewer). * Fixed **SQL syntax errors.** * Resolved **issues with mixing migrations and secret management** in a single edit. * All Lovable users are now using Sonnet 3.7 for the main workflow, which means that Lovable is now smarter than ever before. * [Introducing Code viewer to Lovable](https://x.com/lovable_dev/status/1895500151889768596): You can now view the code of your lovable project. As before you can also make code edits to lovable projects through Github. * No more requests to support asking "*Why is my project broken*". Now we show the actual error messages in the error dialog that should help you fix the error yourself. * Bug fix of users reporting project version reversion due to Supabase connection. * '*Edit*' mode auto close after editing an element. * [Improvements in visual edits](https://x.com/lovable_dev/status/1892249059718484100) that includes editing font weights, alignment and image resizing. * Fixed Supabase syntax issues for smoother integration and fewer errors during deployment. * Resolved an issue where some users were redirected to the homepage unexpectedly. * Connecting to APIs and external data sources can be tricky. We’ve made it easier. Lovable now reads network logs directly, using them as context to debug and implement third-party integrations more effectively. No more disruptive error pop-ups—Lovable now uses real-time network insights to help you fix issues faster and keep building. * Fixed issues with last fetch commits, ensuring accurate and up-to-date project syncing. * No more stuck on `saving changes...`  for messages that produces code and don't result in a commit (for instance the AI tries to edit a file without permission or no changes were made) * [Introducing Visual Edits.](https://lovable.dev/blog/introducing-visual-edits) * [Supabase Integration 2.0.](https://lovable.dev/blog/lovable-supabase-integration-second-version) * Changelog is now posted here on the documentation rather than scattered places. * Improved documentation with new integrations, prompt guide and user guides. * Worldwide Lovable Hackathon. [Apply here](https://lu.ma/1dl5m906). * Increased capacity for LLM calls, reducing the risk of mid-process rate limits. * Preview deploys and production deploys of apps working again. * Resolved issue where users were redirected to the homepage upon entering a project. * Fixed inconsistency in fetching the last commit due to misconfigured repositories using both S3 and GitHub. * Fixed failure in remixes and transfers for projects with a custom main branch override. * Resolved a Python logging name conflict that occasionally caused errors. * Fixed the issue where the select and edit tool was missing for new projects. * Beautiful revert buttons * Chat mode is getting smarter & will now start counting towards your message limit. * [From Python to Go](https://lovable.dev/blog/from-python-to-go) for stability, responsive platform and faster feature releases. * Introduction of [Lovable Launched](https://lovable.dev/blog/2025-01-30-how-to-launch-and-get-traffic-to-an-app-built-with-lovable) where you can publish your app to get in front of users. * [Cloudflare R2](https://www.cloudflarestatus.com/) is down. It's back again running. * [Lovable support 2.0](https://lovable.dev/support) is up and running. * Figma to Lovable: Turn Designs into code with Builder.io. * Improved visibility of reverts. * Support for Replicate has improved. * Support for Resend has improved with the transition to the Node SDK. * When creating signup and login flows, Lovable builds custom authentication UIs tailored to match your app. * Managing roles in a Supabase-powered application is now more reliable. * Lovable now supports building on top of Realtime OpenAI using RTC. * lovable.app DNS issues resolved. * Sandbox issues are resolved, and the service is fully operational again. * Supabase connection issue resolved, simply press the "Add another organization". * [GitHub Integration Outage](https://lovable.dev/news/github-incident-2025-01-02). * New Labs section, accessible via Settings -> Account Settings -> Labs. * Visit [our support page](https://lovable.dev/support) to get help, submit issues, or learn more about using Lovable. * Better Support for Scraping and Node Graphs with Firecrawl and React Flow. * “Edit with Lovable” Badge enabled for all users. * Select-to-Edit is now located directly in chat composer. * Upcoming 5-part live series to build & launch an AI-powered Spanish tutor. * Unlimited weekend! * Customisable messaging limits to the Scale plan. * “Ask the AI to fix” won’t count toward your usage limits.  * Showcase Your Builds in the Hall of Fame. * Integrate Stripe, Three.js, p5.js, Resend & Fabric.js. * [Christmas Hackathon](https://hackathon.lovable.app/submit) to win \$3,000+ in prizes. * Issues with our cloud provider resolved. * **Templates**: Build Faster with Pre-Built Designs. * Introducing feedback.lovable.dev for feature and integration request. * Added the shadcn sidebar and support for 3D apps with three.js.  * You can now track your remaining messages by visiting your [settings page](https://lovable.dev/settings). * Lovable will no longer introduce refactors automatically. * Added support for the new [shadcn sidebar component](https://ui.shadcn.com/docs/components/sidebar). * Improved the stability of the page dropdown. * Added a new [FAQ](https://docs.lovable.dev/faq) and an [E2E tutorial](/introduction/getting-started) to guide users through. * Issues with our cloud provider resolved. * When you send a chat request, we make sure to check that all project deps are up-to-date. # Advanced settings Source: https://docs.lovable.dev/features/advanced-settings Manage your Lovable Cloud instance: resize it, increase disk space, export your data, and pause or permanently remove Cloud. Advanced settings is where you manage the infrastructure behind a Cloud project: its instance size, disk space, data exports, and lifecycle. To open it, go to **Cloud tab → Overview → Advanced settings**. The **General** card shows the project's hosting region (**Project location**) and its Postgres **Database version**. The region is set when Cloud is enabled and cannot be changed afterwards; see [Region selection](/features/cloud#region-selection). ## Upgrade instance Use the advanced settings to view and manage your current instance size. A larger instance allows your app to handle more users and traffic. Keep in mind that a larger instance can increase Cloud usage and use more credits as your app usage grows. * **Free plan users**: upgrade from **Tiny** to a larger instance by upgrading your plan at any time * **Paid plan users**: choose a new instance size (**Tiny**, **Mini**, **Small**, **Medium**, or **Large**) from the options below. Larger sizes handle more traffic and cost more credits per hour while your app runs: * **Tiny**: great for trying things out * **Mini**: reliable for early projects * **Small**: room to grow with your app * **Medium**: steady choice for regular use * **Large**: confident option for higher demand Resizing takes a couple of minutes, with a brief interruption while the instance restarts. You can't make further changes until the resize finishes. Lovable **alerts** you when approaching your Lovable Cloud resource limits. This lets you upgrade your instance in a timely manner to ensure fast and reliable performance. The alert is triggered when any of the following happens: * There is less than 10% of disk space left * IO budget is less than 50% * CPU load is above 80% The upgrade alert also includes a detailed breakdown of usage (disk space, disk IO, CPU). Alert notification showing Cloud instance resource limits with disk space, IO budget, and CPU usage breakdown, prompting user to upgrade instance size Before upgrading, check whether slow queries are the real bottleneck. See [Find and fix database performance problems](/features/database#find-and-fix-database-performance-problems). ### Ask Lovable to resize your instance On **Pro plans and higher** with a **Lovable Cloud** project, you can also ask Lovable to resize the instance directly in chat, instead of opening Advanced settings yourself. When you describe database slowness, Lovable can surface a resize approval card with a size picker (Tiny through Large, with your current size pre-selected). The resize only applies after you pick a size and approve it. Prompt Lovable in chat with something like: ```text wrap theme={null} My database feels slow under load. Resize my Cloud instance to a larger size. ``` Lovable first confirms that compute (not disk space or a slow query) is the bottleneck, then offers the size picker. Downgrades to a smaller size are allowed. ## Increase disk space The **Disk space usage** card shows how much of the instance's disk your project uses. If the disk is nearly full, enter a larger size and click **Increase disk size**. A few constraints apply: * Disk size can only be increased, never decreased. * You can resize the disk once every 4 hours. * Resizing takes a few minutes, and a larger disk increases Cloud usage. ## Export Lovable Cloud data Use **Export project data** when you need a copy of your database before moving backend infrastructure outside Lovable Cloud. The export contains your full database, both structure and data. It does not include files in storage buckets, edge function code, or your project's secrets, so plan to move those separately. User passwords are not exported in a usable form either, so plan a password reset flow for migrated users. You can run one export per day. In your project, go to **Cloud tab → Overview → Advanced settings**. In **Export project data**, click **Export data**. In the **Database** card, click **Export**. In the confirmation dialog that appears, click **Start export**. Lovable emails you when the export is ready. The export is saved to your project's Cloud storage, so download it from **Cloud tab → Storage**. Exports can no longer be downloaded after Cloud is removed. Database exports are limited to 5 GB, and you can request one export every 24 hours. To download storage files, go to **Cloud tab → Storage**. Storage files are separate from your database and aren't included in the database export. See [Storage](/features/storage). ## Pause Cloud If you want to save credits on a project you're not actively using, choose **Pause Cloud** to pause its backend: database, authentication, storage, and Edge Functions. You can resume the project at any time. Lovable automatically pauses Cloud projects after a period of inactivity, so you usually don't need to pause an idle project yourself. Pause manually when your project has scheduled jobs or other background activity that keeps it active, since auto-pause won't kick in for those projects. ### How to pause your project To pause your project, go to **Cloud tab → Overview → Advanced settings**, then in **Pause Cloud**, click **Pause**. In the confirmation dialog that appears, click **Pause Cloud**. While paused, your backend is unavailable, and your deployed app can't read or write data until you resume. ### Resume a paused project When a project is paused due to inactivity, open it in the editor and click **Wake up** in the chat notice. A project can also pause with the message "This project is paused due to a low balance", which happens when your workspace runs out of credits or a credit limit is triggered. In that case, add credits or adjust the limit first. See [Credits and usage](/introduction/credits-and-usage). Storage usage continues while a project is paused because your data stays in place. To stop storage usage entirely, remove Lovable Cloud from the project instead. If your app uses Edge Functions for AI features, payments, or sending emails, those stop working while paused, since Edge Functions are unavailable. This mainly affects apps built before May 2026, since newer apps don't depend on Edge Functions. ## Remove Lovable Cloud Use **Remove Lovable Cloud** when you no longer want a project to use the built-in database, storage, authentication, or Edge Functions. Removing Lovable Cloud permanently deletes your Cloud instance and cannot be undone. Export your database and download any storage files you need before continuing. In your project, go to **Cloud tab → Overview → Advanced settings**. In **Remove Lovable Cloud**, click **Remove**. Check both boxes to confirm you understand Lovable Cloud features will stop working and that unexported data may be lost. The second box unlocks only after the first is checked. Enter the project's display name exactly to confirm. Click **Remove** to permanently delete the Cloud instance for the project. ## FAQ This can happen if you have too much data running on a smaller Cloud project instance. To fix it, go to **Cloud tab → Overview → Advanced settings**, then choose a larger instance size. After you switch to a larger instance, give it a few minutes to update. Your data should then load, and your Cloud project should work again. A larger instance size can increase Cloud usage and use more credits. To review Cloud usage, go to **Settings → Plans & credit usage → Usage details** and select **Run credits**. No. Pausing stops compute usage, but storage usage continues while paused because your data stays in place. To stop Cloud usage for the project entirely, remove Lovable Cloud instead. A paused Cloud project only resumes when you explicitly click **Wake up** on the paused project card in **Cloud tab → Overview**. Visiting your deployed app, other traffic, or waiting does not resume a paused project. Lovable does not provide a one-click transfer from Lovable Cloud to Supabase. You can export your database from **Cloud tab → Overview → Advanced settings** and move your code through the [GitHub](/integrations/github) or [GitLab](/integrations/gitlab) integration. Storage files are exported separately from **Cloud tab → Storage**. You must reconfigure authentication, secrets, environment variables, and any external services in the destination platform. For a step-by-step walkthrough, see [Host backend and data on a managed provider](/tips-tricks/external-deployment-hosting#host-backend-and-data-on-a-managed-provider-supabase-example). # Publish your app as an MCP server Source: https://docs.lovable.dev/features/agent-integrations Turn a published Lovable app into an MCP server for ChatGPT, Claude, and other AI assistants. Configure tools, sign-in, permissions, and access. Agent integrations make a published Lovable app available to AI assistants. Users connect your app in ChatGPT, Claude, or another compatible assistant, then ask the assistant to read information, run workflows, create or update records, or apply your app's logic. People use your app by clicking buttons, filling out forms, and moving through screens. An AI assistant cannot click: it needs a list of actions it can call instead. That list is what an MCP server provides. [Model Context Protocol](https://modelcontextprotocol.io/), or MCP, is an open standard that lets AI assistants discover and call an app's actions, called tools. When a user asks their assistant for something your app handles, the assistant picks the matching tool, and your app does the work. Lovable creates and hosts the MCP server for you, with proposed tools based on your app's functionality, such as looking up an order, generating a quote, or pulling information from a knowledge base. For your users, connecting your app works like adding a plugin. The assistant gets access only to the tools you publish, not to your Lovable project. Agent integrations are available on all plans, for publicly published apps. A publicly published app is reachable on the web, but that does not make its tools available without sign-in. Tool access is configured separately, and sign-in is the default. Workspace and internal apps are not supported yet. ## How it works You enable the integration on a publicly published app. Lovable then: 1. Generates an MCP server for the app. 2. Proposes a set of tools based on what the app does. 3. Asks who should be able to call the tools: signed-in users or anyone. 4. Sets up authentication to match your answer. The proposed tools are a starting point: you can ask Lovable to add, remove, rename, or change them at any time. Before anything goes live, you review the tools and access setup, then publish your app. Lovable gives you an MCP link to share with your users. They add the link to their AI assistant as a custom connector, sign in if your app requires it, and start asking the assistant to use your app. Your integration runs on your live published app, not a copy. Enabling it adds tool code and connection endpoints to your project, and nothing changes for the people using your app. Lovable hosts the MCP server and keeps it compatible as the standard evolves. You control which actions are exposed, who can call them, and when changes are published. When you change the app or its tools, publish again. Users need to refresh their connector when you add, remove, or rename tools. Step-by-step instructions are in [Set up your agent integration](#set-up-your-agent-integration). ## How this differs from Lovable's other MCP features Lovable uses MCP in three different ways, each connecting a different system for a different purpose. Agent integrations let AI assistants use the published app you built. They do not let an assistant edit the Lovable project itself. That is the Lovable MCP server, a separate feature. | Feature | Direction | What it does | | ------------------------------------------------------ | --------------------------- | -------------------------------------------------------------------------------------- | | **Agent integrations** (this page) | AI assistants use your app | Your users' assistants call the actions you expose in your published app | | [Lovable MCP server](/integrations/lovable-mcp-server) | AI tools build in Lovable | External AI tools create, edit, and manage your Lovable projects | | [Chat connectors](/integrations/mcp-servers) | Lovable uses external tools | The Lovable agent pulls context from services such as Notion or Linear while you build | ## Should you add an agent integration? ### Why use it * **Reach users where they already work.** Your users can work with your app from inside their AI assistant, without opening the app itself. * **Give your app a new experience without rebuilding it.** The integration is generated from your existing published app, so assistants become another way to use the same features. * **Control access and monetization.** You review every proposed tool before publishing and decide whether the integration requires sign-in or is available without sign-in. Your app keeps enforcing roles, plans, and its other access rules, so you can make assistant access a benefit of your paid plan. * **Lovable hosts and maintains the server.** Lovable runs the MCP server and keeps it compatible as the standard evolves. The tools, access rules, and app behavior you publish stay yours to manage. ### Use cases and examples Agent integrations work best when your app contains data, workflows, knowledge, or repeatable expertise. Each tool is one action from your app. Take a client portal: Lovable might propose a read-only `list_open_requests` tool, a `create_request` tool, and a `get_request_status` tool. When a client asks their assistant "do I have any requests waiting on me?", the assistant recognizes that `list_open_requests` matches the question, calls it, and answers with live data from your app. | App type | Example tools | What a user might ask | | ---------------------------------------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Customer relationship management, or CRM, apps | `find_customer`, `update_deal_stage`, `draft_follow_up` | "Cross-check my stalled deals against last week's notes and draft the follow-ups." | | Quoting and estimation tools | `generate_quote`, `compare_options` | "Generate a quote for this job from the specs." | | Client portals | `create_request`, `get_request_status`, `submit_document` | "Submit this document and check what is still waiting on me." | | Operational consoles with sign-in | `list_pending_approvals`, `approve_item` | "Show submissions that need review and approve the ones that meet the bar." | | Dashboards | `query_metrics`, `summarize_trends` | "Summarize this week's signups and flag anything unusual." | | Knowledge bases | `search_articles`, `get_policy` | "What is our refund policy? Pull the exact wording." | An app can span several of these. It only needs one clear, useful task that works well through an assistant. ### When it may not be a good fit Not every app that can have an agent integration needs one. Lovable proposes tools, but it does not decide whether an integration is valuable or appropriate for your app, so consider that yourself first. An agent integration may provide limited value when: * Your app's value is mainly visual or interactive, such as a game or a portfolio site. A game can still have useful tools, such as retrieving statistics or managing a tournament, but turn-by-turn gameplay is usually better suited to the app's own interface. * The app is a static site with no meaningful action or information for an assistant to use. * The only possible tools would be slow, expensive, destructive, difficult to reverse, or unsafe to run twice. * The tools would expose more data or capability than the use case requires. Once connected, users can call your exposed tools repeatedly from their assistant. Agent integrations do not include a built-in rate limit or spending cap, so expose actions that consume paid resources or change data only when your app already enforces usage, plan, and permission limits for them. ## Prerequisites Before you add an agent integration, make sure your app meets these requirements. * **A publicly published app.** Your integration serves the published version of your app, and the MCP link becomes available only after the app is published publicly. On Business and Enterprise workspaces, the app must be published publicly before you can enable the integration. On other plans, you can generate and review the tools before publishing, but the integration does not become available to users until the app is published publicly. * **A backend.** Your app needs a backend to run the integration and sign users in: either Lovable Cloud, or a Supabase project you have connected. An app with no backend, such as a front-end-only site with no database or sign-in, cannot host an agent integration. * **OAuth 2.1 for connected Supabase projects.** If you connected your own Supabase project, enable the OAuth 2.1 authorization server in your Supabase dashboard, then reconnect the project in Lovable. Without it, the integration cannot require sign-in, and Lovable will not build it. Lovable Cloud apps already have this set up. * **A supported stack.** Agent integrations support newer apps built on TanStack Start and older React + Vite apps, which host the integration as a Supabase Edge Function. You do not need to know which one your app is on. Lovable handles the difference. ## Costs, credits, and usage limits A tool call costs what the action behind it costs. Each call runs your app's normal backend logic, so database operations, Lovable Cloud usage, AI features, and third-party services count toward usage or incur charges the same way as direct app usage. Lovable does not charge a separate fee for hosting the integration, publishing it, or tool calls. There is no built-in rate limit or spending cap, so expose paid or resource-intensive actions only when your app already limits them. See [Can I rate limit an agent integration?](/features/agent-integrations#can-i-rate-limit-an-agent-integration) for details. Enabling or changing an agent integration uses Lovable's normal build credits. When you select **Enable agent integrations**, Lovable generates or updates the MCP server and its tools. The number of credits depends on the app and the work required. ## Set up your agent integration Start with a small number of focused tools. Prefer read-only tools before exposing actions that modify data, trigger paid services, or consume significant resources. Before you publish, check what each tool can do, what inputs it accepts, what data it returns, whether the action enforces your app's permission and plan checks, and whether it is safe if an assistant retries the call. ### Add the integration Open your app in Lovable and go to **More → Agent integrations**. Select **Enable agent integrations**. Lovable adds an MCP server to your app and proposes a set of tools based on what your app does. Selecting **Enable agent integrations** starts a build, which uses credits like any other build work in Lovable. During the build, Lovable asks **Who should be able to call this MCP server?** Choose one of the following: * **Protected with OAuth (recommended)**: users sign in to your app before their assistant can call the tools. This is the default. If you skip the question, Lovable uses protected access. * **Public — no login**: anyone can call the tools without signing in. You must choose this option explicitly. At the end of the build, Lovable summarizes which actions can be called and what data they can return without sign-in. See [Access, sign-in, and permissions](#access-sign-in-and-permissions) for details. Review the generated tools in the **AI tools** section. Ask Lovable to add, remove, rename, or adjust tools if needed. ```text wrap theme={null} Add a read-only tool that looks up an order by ID and returns its current status and items. ``` Publish your app. Once it is live, the MCP link becomes available. Lovable runs [automated security checks](#automated-security-checks) at publish and warns you if the integration allows access without sign-in. In **More → Agent integrations**, copy the link from the **Your MCP link** card at the top of the panel, then share it with your users. You can also start the setup from Lovable chat. ```text wrap theme={null} Add Agent integrations to this app so users can connect it to AI assistants like ChatGPT and Claude. ``` ### Review the tools The **AI tools** section shows the tools available through your integration and what each one can do. Each tool shows a status: * **Active**: the tool is live in your published integration, and assistants can call it. * **Not published**: you added or changed the tool after your last publish, so assistants do not see the updates yet. Publish your app to make them live. Tools from your last publish keep working in the meantime. * **Inactive**: the integration is not currently available, for example because the app is no longer published publicly. Assistants cannot call its tools. Each tool also has a capability label: * **Read-only**: the tool only reads information. * **May modify data**: the tool can create, change, or delete data. Review these most carefully. Tools go live when you publish your app. There is no separate tool-approval step, so review every active tool before sharing the MCP link. For each tool, check: * **The action it performs.** Confirm the tool does only what its name and description say. * **The inputs it accepts.** Prefer narrow inputs that match the task, such as a specific record identifier, rather than broad queries or arbitrary field values. * **The data it returns.** Return only the fields the task needs. A read-only tool can still expose sensitive or unnecessary information. * **Its access checks.** Confirm the action enforces the ownership, role, permission, and paid-plan requirements your app expects. * **Its retry behavior.** For tools that change data, confirm that repeating the call does not create duplicate or unintended changes. Tool names and descriptions matter, because the assistant chooses which tool to call based on what the user asks and how the tool is described. Compare: * Vague: `get_data`, described as "Gets data." * Clear: `list_open_orders`, described as "Returns the signed-in customer's open orders with order number, status, and total." You can ask Lovable to adjust tools in plain language. ```text wrap theme={null} Remove any tool that can delete records. ``` ```text wrap theme={null} Rename the customer lookup tool so it is clear that it searches by email address. ``` ### Access, sign-in, and permissions Agent integrations require sign-in by default. When Lovable generates your MCP server, it proposes an authenticated setup, and making tools public always requires your explicit choice. Sign-in, permissions, and tool exposure are three different layers, and it helps to keep them apart: * **Sign-in identifies the caller.** People connecting through an AI assistant authenticate through your app: they see your app's sign-in screen, then a consent screen that asks them to approve the assistant's access. Both are expected parts of connecting. * **Your app's rules decide what the caller can do.** A tool acts as the signed-in user. Rules your app enforces in its backend, such as each customer only seeing their own records, apply to tool calls too, and generated tools are not allowed to work around them. Extra requirements, such as owning the record, having a role, or being on a paid plan, apply only when the action itself checks them. * **The tool definition decides what is exposed.** Review each tool's inputs, the action it performs, and the data it returns. A tool call does not go through your app's screens. Buttons you hid, pages you removed from menus, and other interface-level controls do not protect a backend action on their own. #### Choose an access configuration You choose between two access configurations: * **Sign-in required, which is the default.** Every tool requires the user to authenticate. Individual actions can then enforce role, ownership, or paid-plan requirements in your app's backend, so an app that limits a feature to paying users keeps that limit for assistant calls. Lovable activates the OAuth capability on your app's backend when you publish, without changing how your users sign in to the app itself. * **No sign-in.** Every tool can be called without authenticating a user. This is a deliberate choice: Lovable asks you to confirm it, and it summarizes what the tools expose without sign-in. Publishing tools without sign-in makes every active tool callable without authenticating a user. Treat those tools as publicly accessible, and assume the MCP link can be copied or shared. Lovable warns you at publish, and on workspaces with strict security policies, publishing an unauthenticated integration may be blocked. Only allow this when every active tool is safe for anyone to use. Access is configured for the whole integration. You cannot make some tools public and others protected within one integration. Inside a protected integration, individual actions can still apply different role, ownership, and plan checks. #### Check the current access setting The **Agent integrations** panel shows your current setup as a status card: * **Access is protected**, with a **Sign-in enabled** badge, when tools require sign-in. * **Anyone can connect to your app**, with a **Public access** badge, when tools do not require sign-in. This card includes an **Add sign-in** button. Selecting it starts a build that adds authentication to the integration. If you set up your integration a while ago, open the panel and confirm the status card shows the access you expect. Switching between public and protected later is a build, not a settings toggle: select **Add sign-in** on the public card as the shortcut, or ask Lovable in chat, and it updates your app's authentication setup. For example, you can ask Lovable: ```text wrap theme={null} Require users to sign in before they can use this agent integration, and make sure the export report action checks whether the user is on a paid plan. ``` ### Automated security checks Lovable runs two automated security checks on your integration: * **A basic check, at every publish.** It checks whether your integration allows access without sign-in and warns you in the publish flow. On workspaces with strict security settings, publishing is blocked when a non-public app exposes unauthenticated tools. * **A deep scan, when you publish a public integration.** If your tools do not require sign-in, publishing a new or changed integration also starts a deeper scan of the tools themselves. It checks what each tool actually exposes and flags common risk patterns: private-data exposure, unintended record changes, bulk data access, and paywall bypass. Findings from both checks appear under **More → Security** in your project, with deep-scan findings listed under **App MCP data exposure**. Serious deep-scan findings are marked critical. If your workspace blocks publishing on critical security findings, you cannot publish again until they are resolved. Open a finding to review the issue, then ask Lovable to fix it, or mark it as ignored if it does not apply. Automated checks do not replace your own review, and they may not detect risks that depend on your app's custom business logic. Before sharing the integration, work through the checks in [Review the tools](#review-the-tools) and [Test before you share](#test-before-you-share). For how Lovable's security scanning works more broadly, see the [Security overview](/features/security) and [Project security view](/features/security-view). ### Test before you share Connect your own app in an assistant your users are likely to use, such as ChatGPT or Claude, and test the main workflows before sharing the MCP link. If the integration requires sign-in, test the full connection flow, including your app's sign-in and consent screens. Connection and authentication issues often appear there first. Test at least the following: * Run each tool as an ordinary signed-in user. * Try protected tools as a user without the required role, ownership, or paid plan, and confirm access is denied. * Request a record that does not exist or belongs to another user. * Confirm that each tool returns only the fields needed for its task. * Run a write action twice and confirm it does not create duplicate or unintended changes. * Test any paid or resource-intensive action against your app's usage or plan limits. * For an integration without sign-in, connect from a session where you are not signed in to the app and verify exactly which actions and data are available. ## Connect your users Once the integration is live, users connect your app to their AI assistant with the MCP link. ### Supported assistants Your app works with any AI assistant or agent that can connect to a remote MCP server and complete its sign-in flow. Lovable provides in-product connection steps for: * ChatGPT * Claude Other MCP clients, such as Claude Code, Cursor, and VS Code, connect with the same MCP link through their own custom-connector setup. Setup flows differ by assistant and can change over time. Open **More → Agent integrations**, then expand **How to connect** for the current ChatGPT and Claude steps. For other assistants, refer users to the assistant's official documentation. ### Share the MCP link After you publish, Lovable shows your app's MCP link in the **Your MCP link** card under **More → Agent integrations**. Users add this link as a custom connector in their assistant. You can share the link directly, or create a connection page inside your app that explains what the integration does, includes the MCP link, and helps users connect it in the assistant they use. To create a connection page, expand **How to connect** and select **Ask Lovable to build**. Because assistant setup flows can change, avoid copying detailed connection steps into a page that will not be maintained. Link to each assistant's official documentation, or review the page whenever a setup flow changes. ## Maintain the integration After launch, revisit the integration whenever you change tools, access logic, backend behavior, or your app's domain. Changes reach users through publishing, and you stay responsible for what the integration exposes. ### Keep it up to date Your integration serves the published version of your app. After you change your app, tools, access logic, or domain: Publishing updates the live MCP server with your latest tools and settings. For older React + Vite apps, ask Lovable to redeploy the app's backend function after your changes so the live integration picks them up. Users need to refresh the connector in their assistant when you add, remove, or rename tools. Changes to existing app behavior take effect after publishing and normally do not require a connector refresh. If the MCP link changed, ask users to reconnect with the new link. Open **More → Agent integrations**, then expand **Refresh after app changes** to see the refresh steps for ChatGPT and Claude. For other assistants, refer users to the assistant's official documentation. Lovable maintains the hosted MCP setup as the standard evolves, and protocol changes ship as versioned updates. When an update needs a change in your app, Lovable provides an upgrade path. ### When your MCP link changes The MCP link cannot be changed on demand. * For TanStack Start apps, the link is based on your app's web address, so it changes when you change the app's primary custom domain, and users then need to paste the new link into their assistant. * For older React + Vite apps, the link points to the app's backend function, so it does not change with your domain. ### Monitor, disable, and remove Tool errors surface in your app's logs like other backend errors. If you need tool calls tied to identities, keep sign-in on, so every call comes from a signed-in user of your app. To stop or restrict the integration: * **Remove a tool.** Ask Lovable to remove it, then publish. The tool disappears from the integration. * **Remove the whole integration.** Ask Lovable to remove agent integrations from the app, then publish. Lovable removes the generated code and takes the MCP server offline. Your app keeps working as before. * **Unpublish the app.** This takes the MCP server offline immediately along with the app itself. Existing assistant connections cannot call it while the app is unpublished. * **Delete the project.** This permanently removes the app and its MCP server. Unpublishing an app removes its live MCP server, and connected users lose access. If you publish the app again later, Lovable recreates the server, but the link may change. ## Best practices * **Start with the main user jobs.** Create tools for the actions users already come to your app to complete. New app features do not become tools automatically, so ask Lovable to expose each action you want assistants to use. * **Write clear tool names and descriptions.** Explain what the tool does, what inputs it needs, and what result it returns. Clear names and descriptions help the assistant choose the right tool. * **Return only the data the task requires.** A tool exposes its returned data as well as its action. Ask Lovable to limit results to the fields the tool's purpose requires. * **Separate read and write actions.** Make it clear which tools only retrieve information and which tools can create, update, or delete data. * **Make write actions safe to retry.** An assistant may retry a call after a timeout or connection error, and a tool that creates or changes something could then do it twice, such as creating the same order two times. Ask Lovable to design write tools so a repeated call does not duplicate the change, for example by checking whether the change was already applied or by using a request identifier. * **Keep sign-in on by default.** Allow access without sign-in only when every exposed action and returned field is safe for anonymous use. * **Enforce restricted access in your app.** If a tool returns private information, changes records, or runs a paid feature, verify the user's permissions, ownership, role, and plan before completing the action. * **Publish after changing tools.** New, removed, or updated tools do not reach users until you publish the app. * **Add a connection page.** Give users the MCP link, explain what the integration can do, and point them to current setup instructions. See [Share the MCP link](#share-the-mcp-link). ## Limitations * **Long-running tools can time out.** Tools run one action at a time, and the assistant waits for the result with a time limit. Work that takes more than tens of seconds, such as processing a large file or generating media, can show as stuck or interrupted in the assistant. Keep tools fast, and run heavier work inside the app. * **Integrations cannot send alerts on their own.** Your app cannot notify an assistant. Assistants only act when a user asks, so "watch this and alert me" workflows do not work. * **Users must refresh after tool changes.** Assistants keep a copy of your tool list. After you add, remove, or rename tools and publish, users see the previous list until they refresh the connector, which slows down iteration on a live integration. * **There is no discovery directory.** Users cannot browse a directory of agent integrations. You share the MCP link with your users yourself. ## FAQ An MCP server exposes your app's actions as tools that an AI assistant can call. MCP stands for Model Context Protocol, an open standard for connecting assistants to external tools. Neither. The agent integration is a new way into the same app. Your app does not move into the assistant. The assistant gets a way to call your live app, your app does the work, and the integration follows the published version whenever you update it. Your visible pages and normal user flow stay the same. Lovable adds the tool code and connection endpoints the integration needs. Lovable does not detect a hand-built MCP server in advance. If your existing server uses the same routes, the build fails rather than overwriting your code. Ask Lovable to rebuild your existing server as an agent integration, or to set the integration up on a different path. Not when the integration and its tool actions are configured correctly. Agent integrations require sign-in by default. Backend rules that use the signed-in user's identity apply to tool calls, while each protected action must still enforce any additional ownership, role, permission, and paid-plan requirements. Review both what each tool can access and what it returns before publishing. No. Sign-in applies to the whole integration: all tools require sign-in, or none do. Inside a protected integration, individual tools can apply their own checks in your app's logic, such as requiring a specific role or plan. Not today. There is no built-in rate-limit control or tool-call quota. Requiring sign-in prevents anonymous calls and ties every call to a user, but it does not limit how often a signed-in user can call a tool. Avoid exposing expensive actions unless your app already enforces a usage or plan limit for them. Lovable does not show tool-call activity, but tool errors appear in your app's logs like other backend errors. If your integration requires sign-in, every call runs as a signed-in user of your app, so any changes it makes show up in your app's data like normal user activity. Ask Lovable to remove a tool or the whole integration, then publish. Unpublishing the app also takes the MCP server offline immediately. See [Monitor, disable, and remove](#monitor-disable-and-remove). There is no separate Lovable charge for tool calls. A tool call runs in your app's backend like normal app usage, so if a tool uses Lovable Cloud or AI features, that usage counts against your app's balance the same way it does when someone uses your app directly. Require sign-in to prevent anonymous calls, and make sure your app enforces a plan or usage limit for expensive actions. Any AI assistant or agent that can connect to a remote MCP server and complete its sign-in flow. Lovable provides in-product connection steps for ChatGPT and Claude, and other MCP clients, such as Claude Code, Cursor, and VS Code, connect with the same MCP link. Not yet. The current version supports publicly published apps. ## Troubleshooting On Business and Enterprise workspaces, **Enable agent integrations** stays disabled until your app is published publicly. Publish your app publicly, then try again. On other plans you can enable the integration before publishing, and the MCP link becomes available after you publish. Publish your app after your changes, then have users refresh the connector in their assistant (such as ChatGPT or Claude). For older React + Vite apps, ask Lovable to redeploy the app's backend function after your changes. * Confirm your app is published publicly and that you pasted the current MCP link. * If your app requires sign-in, make sure users complete the sign-in step when the assistant prompts them. * If your tools do not require sign-in, check the connector's authentication setting: ChatGPT defaults new connectors to OAuth, so select the no-authentication option when adding a server that does not require sign-in. Older projects may use a token-signing setup that some assistants do not accept. Ask Lovable to migrate your project's signing keys. It asks for confirmation, runs the migration, and connecting works afterward. The sign-in screen is part of your app, so it only exists once the app is published. Publish your app, then have the user connect again. This usually means your app uses a Supabase project you connected yourself, without the OAuth 2.1 authorization server enabled. Enable OAuth 2.1 in your Supabase dashboard, reconnect the project, and ask Lovable to continue. Lovable does not build the integration without it, because the tools could not require sign-in. In most assistants, including ChatGPT and Claude, the connector has to be enabled from the chat composer for that conversation. Ask users to enable it, then make the request explicit, for example "Use \[app name] to check my open requests." The tool is probably doing work that takes longer than the assistant's timeout, such as processing a large file or generating media. Assistants can also retry timed-out calls, which can create duplicate records. Ask Lovable to make the tool respond immediately and add a separate tool to check the result, or move the heavy work into the app itself. Lovable refuses to overwrite MCP code you wrote by hand. Ask Lovable to move your existing server to a different path, or to rebuild it as the agent integration. For TanStack Start apps, changing the app's primary custom domain changes the MCP link too. Copy the new link from the **Your MCP link** card in **More → Agent integrations** and share it with your users. Older React + Vite app links point to the app's backend function and do not change with your domain. # Implement changes in Build mode Source: https://docs.lovable.dev/features/agent-mode Build mode lets Lovable implement and verify changes directly in your project, handling execution end to end with minimal supervision. **Choose a mode** Lovable has two modes: * [**Plan mode**](/features/plan-mode) → think through the problem, explore options, and decide on an approach * **Build mode** → implement changes and verify the outcome Plan mode is for decision-making. Build mode is for execution. The two modes are designed to work together, and you can switch between them at any time. ## Overview Build mode (previously Agent mode) is Lovable’s autonomous execution mode, designed to implement changes directly in your project. When you give Lovable a task, it takes ownership of execution end to end. It understands your intent, explores the codebase for context, applies changes across files, and resolves issues that appear during development. While it works, you can see progress through visible tasks and review the results before moving on. ## What Build mode is for You can use Build mode to: * Implement features or changes once an approach is decided * Fix bugs or errors end to end * Refactor code across multiple files * Apply coordinated changes across frontend, backend, and configuration * Debug issues that arise during implementation * Inspect logs and network activity to identify problems * Fetch external documentation or assets when needed * Generate or edit images and videos for use in your project * Verify results before finishing All changes are applied directly to your project and surfaced through file diffs and summaries. You can follow along step by step in the **Details view**. ## How to use Build mode Build mode is active unless you switch to [Plan mode](/features/plan-mode). To use it, describe what you want and send your message. Clear requirements and constraints help Lovable produce better results. **Be specific about what you want** ```text wrap theme={null} Add a contact form with name, email, and message fields. Validate email format and show error messages inline. ``` **Describe expected behavior** ```text wrap theme={null} When users click ‘Add to Cart’, show a success message and update the cart count in the header. Store cart items in local storage. ``` **Provide context for complex changes** ```text wrap theme={null} Update the dashboard to show sales data from the last 30 days. Use the existing Chart component and match the styling used on the analytics page. ``` **Set guardrails for sensitive areas** ```text wrap theme={null} Add a new feature to @src/pages/dashboard. Do not modify @src/shared/Layout.tsx or the existing authentication logic. ``` ## Tasks and execution visibility While Lovable is working, tasks appear in the chat interface showing: * Current step being executed * Files being modified * Tools being used (search, web fetch, image generation) * Progress through multi-step implementations This visibility helps you: * Follow progress on complex builds * Understand the steps being performed * Stay oriented during complex changes * Spot issues early if something seems off ## Prompt queue Lovable **processes one task at a time**. While Lovable is working, you can continue sending prompts and they will be added to a visible queue above the chat input. * Pause and resume the entire queue as needed * Reorder, edit, copy, or remove individual queued prompts * Repeat a queued prompt a specified number of times (up to 50) This makes it easier to batch work, collaborate without waiting, and automate repetitive workflows. ## Debugging and verification When using Build mode, Lovable does more than ensure code compiles. As part of investigation and problem solving, the agent can: * observe build errors and failures from test runs * inspect console output and network requests when verification tools are used * reproduce reported issues using browser testing or targeted backend calls * verify that fixes work as expected by running appropriate checks Lovable has access to verification tools such as browser testing, frontend tests, and edge function verification to help understand system behavior, validate user workflows, and ensure backend logic works as expected. Most of these tools run only when you ask for them. For a detailed explanation of testing and verification capabilities, see [Test and verify your app](/features/testing). ## Pricing Pricing for Build mode is **usage-based**. Cost depends on factors such as: * Number of files modified * Complexity of logic changes * Amount of codebase exploration required * Use of tools such as verification, browser checks, web search, or image generation Many requests cost less than one credit, while more complex tasks may cost more. You can view the cost of a message from the three-dot menu on that message. See [Credits and usage](/introduction/credits-and-usage) for more information. ## FAQ Yes. Lovable applies changes directly to your project when using Build mode. All modifications are visible through file diffs and summaries. Lovable can inspect logs, runtime output, and network activity and iterate on fixes until the issue is resolved or clarified. See [Test and verify your app](/features/testing) for more information. Yes. Visible tasks show each step of execution, including progress and which files are being modified. Yes. Additional messages are queued and processed in order. You can reorder, pause, or remove queued messages at any time. Click the **stop button** while Lovable is responding to immediately halt the current task. This lets you stop a request to provide more context or correct the agent. Lovable keeps all changes made up to that point, so you won’t lose completed work. Stopped requests are charged based on the work completed so far. If you want to remove the changes, use the **undo button** to revert to the previous state. Switch to [Plan mode](/features/plan-mode) when you want to: * Think through a complex change before implementation * Compare multiple architectural approaches * Review or edit a plan before any code is changed * Investigate an issue and decide on a solution first Yes. You can reference code files from your current project directly in chat to make edits and discussion faster and more precise. Type `@` and select a file, or use the **Reference file in chat** button in the [code editor](/features/code-mode). For example: ```wrap theme={null} @src/components/UserProfile.tsx add a loading state here ``` This only references files within your current project. To reference another project, see [Cross-project referencing](/features/cross-project-referencing). Yes. Lovable supports [cross-project referencing](/features/cross-project-referencing) within the same workspace. You can use `@` mentions to reference another project directly, or simply ask Lovable to reuse an existing implementation. The agent can access relevant code, files, assets, and chat history from other projects and adapt them to your current one. Cross-project access is read-only and respects workspace permissions. # AI features for your app Source: https://docs.lovable.dev/features/ai Add AI features like chatbots, summaries, and image generation to your Lovable app with the built-in AI connector. No API keys or provider setup required. Normally, adding AI to an app means choosing a provider, managing API keys, setting up billing, securing credentials, and wiring model calls into your backend. Lovable’s built-in AI connector handles that setup for you, so you can add AI features to your app by describing what you want to build. These AI features run inside your app. They are separate from the Lovable agent that helps you build and edit your project. Some examples include: * **Summaries**: automatically condense long text into clear takeaways. * **Chatbots and assistants**: build conversational helpers into your app. * **Sentiment detection**: understand user feedback at scale. * **Document Q\&A**: let users ask questions directly against your content. * **Creative generation**: brainstorm ideas, draft copy, or expand concepts. * **Translation**: serve users across languages. * **Image and document analysis**: extract, summarize, and interpret key information from unstructured content. * **Workflow automation**: handle repetitive or multi-step tasks inside your app. * **Semantic search and retrieval-augmented generation (RAG)**: search documents, knowledge bases, and content by meaning instead of exact keywords. * **Text-to-speech**: turn text into spoken audio for voice narration, read-aloud, and audio-first experiences. * **Speech-to-text**: transcribe voice notes, recordings, and meetings, and add voice input or dictation. ## Enabling the built-in AI connector For the best experience, use the built-in AI connector with [Lovable Cloud](/features/cloud), so your app has the backend needed to make secure model calls. By default, the built-in AI connector is enabled for your workspace, and Lovable can add AI features to your app when requested. To manage the built-in AI connector for your projects, open **Connectors**, select **AI**, and adjust the settings under **Manage my agent's permissions**. Workspace admins can also disable the built-in AI connector entirely for the workspace from **Connectors** → **Admin settings**. ### Permission preferences The default setting is **Always allow**, meaning the built-in AI connector can be used automatically in your projects. You can change your preference anytime: open **Connectors**, select **AI**, and adjust the settings under **Manage my agent's permissions**. Choose between: * **Always allow**: Lovable automatically performs the action without asking for review or approval. * **Ask each time**: Lovable asks for your approval whenever the action is needed. For example, if you want to add a chatbot, you can: * **Allow**: enable the integration for the current project. * **Deny**: decline the integration for this request. You may be asked again later. * **Adjust preferences**: change the default behavior for future projects. This does not affect the current project. * **Never allow**: Lovable blocks the action, informs you that AI is required, and instructs you to enable the built-in AI connector. ## How it works Lovable sets up the AI infrastructure for you: * **API key**: Lovable automatically generates and manages a `LOVABLE_API_KEY` for each project. You never need to create or provide it yourself. When a project is remixed, a fresh key is generated for the new project automatically. * **Backend calls**: AI calls run through a secure backend edge function that Lovable creates for you. Calls are never made directly from the browser, which keeps your credentials and prompts server-side. * **Streaming**: the built-in AI connector supports streaming responses with server-sent events (SSE). Lovable uses streaming by default for chatbot and assistant features, so responses appear token by token rather than all at once. ## Supported models for AI features in your app These models are available for AI features inside the apps you build, such as chatbots, image generation, semantic search, and voice. They are not the models Lovable uses to write, edit, or reason about your code. When you ask Lovable to add or update an AI feature, you can name a supported model or describe what you want and let Lovable pick the right one. Each model links to its official source for technical details. ### Choosing a model Not sure which to use? Describe what you want, and Lovable picks a model for you. This table shows where to start and when you might switch. | Use case | Start with | Switch when | | -------------------------------------------------------- | ----------------------------------- | --------------------------------------------------- | | Chat and assistant features | Gemini 3 Flash Preview | You need deeper reasoning or longer context. | | High-volume, simple text tasks | Gemini 3.1 Flash Lite or GPT-5 Nano | Accuracy matters more than cost. | | Image generation and editing | GPT Image 2 | You want lower-cost drafts or a Gemini image model. | | Semantic search and retrieval-augmented generation (RAG) | Gemini Embedding 001 | You need multimodal retrieval. | | Text-to-speech | GPT-4o Mini TTS | You need character or higher-fidelity voices. | | Speech-to-text | GPT-4o Mini Transcribe | You need higher transcription accuracy. | ### Chat models Chat models power conversational and text features: chatbots, assistants, summaries, document Q\&A, translation, classification, and extraction. They range from fast, low-cost models for simple tasks to high-reasoning models for complex work. Ask Lovable to: * Build a chatbot or in-app assistant. * Summarize long text, documents, or transcripts. * Answer questions from your own content. * Classify, extract, or translate text. | Model | Best for | | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | [Gemini 3 Flash Preview (default)](https://ai.google.dev/gemini-api/docs/models/gemini-3-flash-preview) | Fast, general-purpose chat and iterative builds where responsiveness matters. | | [Gemini 3.5 Flash](https://deepmind.google/models/model-cards/gemini-3-5-flash/) | Fast coding, reasoning, and agentic workflows. | | [Gemini 3.1 Pro Preview](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-pro-preview) | Advanced coding, long-context understanding, and complex multi-step reasoning. Slower and premium-priced. | | [Gemini 3.1 Flash Lite](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-flash-lite) | High-volume, lightweight tasks like classification, summarization, and translation. | | [Gemini 2.5 Pro](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-pro) | Deep reasoning, advanced coding, and research. Most capable 2.5 model, most expensive. | | [Gemini 2.5 Flash](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-flash) | Assistants and general workflows balancing speed and intelligence. | | [Gemini 2.5 Flash Lite](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-flash-lite) | Simple, high-throughput tasks at the lowest cost. | | [GPT-5.6 Sol](https://platform.openai.com/docs/models/gpt-5.6-sol) | Flagship GPT-5.6 preview. Strongest for the hardest reasoning, coding, and agentic tasks. | | [GPT-5.6 Terra](https://platform.openai.com/docs/models/gpt-5.6-terra) | Balanced GPT-5.6 preview for everyday work at lower cost. | | [GPT-5.6 Luna](https://platform.openai.com/docs/models/gpt-5.6-luna) | Fast, low-cost GPT-5.6 preview for simple or high-volume tasks. | | [GPT-5.5 Pro](https://platform.openai.com/docs/models/gpt-5.5-pro) | Frontier reasoning, in-depth research, and complex engineering. Slowest and most expensive. | | [GPT-5.5](https://platform.openai.com/docs/models/gpt-5.5) | Complex reasoning, advanced coding, and long-context knowledge work. | | [GPT-5.4 Pro](https://platform.openai.com/docs/models/gpt-5.4-pro) | Advanced coding, deep research, and long-context multi-step reasoning. Premium-priced. | | [GPT-5.4](https://platform.openai.com/docs/models/gpt-5.4) | Complex reasoning, coding, and long-context knowledge tasks. | | [GPT-5.4 Mini](https://platform.openai.com/docs/models/gpt-5.4-mini) | Assistants and mid-complexity reasoning at lower cost. | | [GPT-5.4 Nano](https://platform.openai.com/docs/models/gpt-5.4-nano) | Summaries, classification, and high-volume simple tasks. Cheapest and fastest 5.4. | | [GPT-5.2](https://openai.com/index/introducing-gpt-5-2/) | Complex reasoning and deep coding or analytical workflows. | | [GPT-5](https://openai.com/index/introducing-gpt-5/) | Accuracy-critical tasks and high-quality reasoning. | | [GPT-5 Mini](https://platform.openai.com/docs/models/gpt-5-mini) | Assistants and business workflows balancing speed and cost. | | [GPT-5 Nano](https://platform.openai.com/docs/models/gpt-5-nano) | Quick, simple responses and high-volume tasks. Cheapest and fastest GPT-5. | #### Faster responses with priority processing If low latency matters, you can ask Lovable to use **priority processing** for a chat feature. Priority processing sends the request to OpenAI's faster serving tier, so responses can come back more quickly during busy periods. Ask Lovable to: * Make an AI feature respond faster or with lower latency. * Use priority processing for a chat feature. Priority processing is available for supported OpenAI chat models only, not for Gemini models. It comes at a premium price: you are charged the priority rate only when OpenAI actually serves the request at the priority tier. If OpenAI falls back to standard processing, you pay the standard rate. See [Usage and pricing](#usage-and-pricing) for how AI usage is billed. ### Image models Image models generate and edit images from text prompts, uploaded images, or both. Use them for visual assets, product mockups, marketing imagery, and in-app image editing. Ask Lovable to: * Generate images from a text description. * Edit or restyle an uploaded image. * Create product mockups or marketing visuals. * Produce thumbnails or illustrations on demand. | Model | Best for | | -------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | [GPT Image 2 (default)](https://platform.openai.com/docs/models/gpt-image-2) | High-quality image generation and editing; product mockups, marketing imagery, and creative content. | | [GPT Image 1 Mini](https://platform.openai.com/docs/models/gpt-image-1-mini) | Cost-efficient image generation; thumbnails, drafts, and high-volume workflows. | | [Gemini 3.1 Flash Image](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/gemini/3-1-flash-image) | Fast image generation and editing with strong subject consistency and text rendering. Also known as Nano Banana 2. | | [Gemini 3.1 Flash Lite Image](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/gemini/3-1-flash-lite-image) | Faster, lower-cost image generation and editing for high-volume, cost-sensitive workflows. Also known as Nano Banana 2 Lite. | | [Gemini 3 Pro Image](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/gemini/3-pro-image) | Detailed visuals, text rendering in images, and multi-image composition. Also known as Nano Banana Pro. | | [Gemini 2.5 Flash Image](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/gemini/2-5-flash-image) | Very low-cost image generation and quick visual outputs. | ### Embedding models Embedding models turn content into a format that can be searched by meaning instead of exact keywords. Use them for semantic search, retrieval-augmented generation (RAG), FAQ bots, document search, and knowledge bases. Ask Lovable to: * Build semantic search over uploaded documents. * Create a FAQ bot that answers from your help content. * Build a company knowledge base that finds relevant internal docs. | Model | Best for | | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | [Gemini Embedding 001 (default)](https://ai.google.dev/gemini-api/docs/models/gemini-embedding-001) | General-purpose semantic search, document retrieval, and recommendations. | | [Gemini Embedding 2](https://ai.google.dev/gemini-api/docs/models/gemini-embedding-2) | Multimodal retrieval across text, images, video, audio, and PDFs. | | [Text Embedding 3 Small](https://developers.openai.com/api/docs/models/text-embedding-3-small) | Cost-sensitive or high-volume text embedding workloads. | | [Text Embedding 3 Large](https://developers.openai.com/api/docs/models/text-embedding-3-large) | Higher-quality text retrieval when accuracy matters more than cost. | ### Text-to-speech models Text-to-speech models turn text into natural-sounding spoken audio, so your app can read content aloud, narrate generated text, or talk back. Describe the voice feature you want, and Lovable wires up the backend and picks the right settings. Speech streams as it is generated by default, so playback can begin before the full clip is ready, and you can describe the tone or pacing you want in plain language (for example, "speak slowly and warmly"). Ask Lovable to: * Add a "read aloud" button that speaks an article or summary. * Narrate AI-generated stories, lessons, or briefings. * Turn a book or document into an audiobook. * Build a voice assistant that responds with spoken audio. | Model | Best for | | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | [GPT-4o Mini TTS (default)](https://platform.openai.com/docs/models/gpt-4o-mini-tts) | Natural-sounding speech for narration, read-aloud, and voice features. | | [Gemini 2.5 Flash TTS](https://ai.google.dev/gemini-api/docs/speech-generation) | Cost-effective speech for everyday and high-volume voice features. | | [Gemini 2.5 Pro TTS](https://ai.google.dev/gemini-api/docs/speech-generation) | Higher-fidelity speech when voice quality matters most. | | [Gemini 2.5 Flash Lite Preview TTS](https://ai.google.dev/gemini-api/docs/speech-generation) | Lightweight preview model for simple speech tasks. | | [Gemini 3.1 Flash TTS Preview](https://ai.google.dev/gemini-api/docs/speech-generation) | Newest Gemini speech model, in preview. | ### Speech-to-text models Speech-to-text models turn spoken audio into text, so people can talk to your app instead of typing and your app can work with what they said. Upload a voice note, call recording, or meeting audio, and the app transcribes it. Transcription streams as it is produced by default; because these features run in real time, very long recordings may time out, so transcribe long audio in segments. Ask Lovable to: * Build a meeting assistant that turns a recording into notes and action items. * Add voice input or dictation so users can speak instead of type. * Transcribe and search voice memos. * Caption or subtitle uploaded audio. | Model | Best for | | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | [GPT-4o Mini Transcribe (default)](https://platform.openai.com/docs/models/gpt-4o-mini-transcribe) | Fast, cost-effective transcription for most voice input and audio features. | | [GPT-4o Transcribe](https://platform.openai.com/docs/models/gpt-4o-transcribe) | Higher-accuracy transcription when quality matters more than cost. | Combine text-to-speech and speech-to-text to build apps people can have a real back-and-forth with, such as voice assistants, two-way translators, and hands-free helpers. ## Monitor AI usage and activity Every project has an AI activity dashboard under **Cloud → AI** that shows what your app's AI features cost and how they are performing. Use it to track spend, spot failed requests, and inspect individual AI calls. Lovable reads this activity too, so the agent can help you debug failures and improve your app's AI features. The **Cloud → AI** dashboard is a per-project view for monitoring and debugging AI features. It shows individual requests with their status, duration, models, token usage, cost, and, when request content is available, the redacted request and response. To review AI gateway spend across your workspace, go to **Settings → Plans & credit usage → Usage details** and select **Run credits**. There, you can see AI gateway usage as billed credits and filter usage by project. Choose a time range to summarize recent AI activity. Three cards show: * **Total cost**: the credits your app's AI requests used in the selected range. * **Success rate**: the percentage of requests that completed successfully. * **Avg. Duration**: the average time a request took, in milliseconds. How far back you can view activity depends on your plan: Free workspaces can view the last 24 hours, and paid plans can view the last 90 days. ### Recent requests The activity list shows recent AI requests, newest first. Each entry shows its status, a title taken from the request, when it ran, the model used, the input and output tokens, the credits it cost, and how long it took. When an AI action takes several steps, they appear together as a single run so you can see the cost of each step. Lovable always records this summary information for every AI request, so both the dashboard and the agent can see each call's status, model, tokens, cost, and duration, even when the request content is not available. ### Let Lovable debug and improve your AI features Give Lovable visibility into your app's AI calls so it can help you make them better. When this is on, Lovable keeps the full request and response for each AI call, so the agent (and you) can open a request to see exactly what was sent and returned. The agent can use this to debug failures, refine your prompts and knowledge, and reduce cost and latency. Secrets are removed automatically, and details are kept for 90 days. It is on by default on Free and Pro. On Business and Enterprise it is off by default; enable it from the prompt on **Cloud tab → AI**, or from the **AI app context** setting in [project settings](/features/projects/settings). Changing it requires permission to edit the project. When it is off, the dashboard and the agent still see summary metrics (status, model, tokens, cost, and duration); they just cannot open a request to see its full content. ## Usage and pricing **Temporary offering, subject to change:** Free, Pro, and Business workspaces receive a **4-credit monthly AI grant** for AI gateway usage in deployed apps. On Free plans, the grant resets on the 1st of each calendar month at **00:00 UTC**. On Pro and Business plans, it refreshes with the subscription billing cycle. The grant does not roll over. AI gateway usage is measured when AI features inside your deployed app make model calls. These requests are separate from the Lovable agent that helps you plan, build, and edit your project. AI gateway usage uses credits. Credit usage depends on the model used and the amount of work performed, such as text tokens, generated images, audio processing, call volume, or other provider-reported usage. AI gateway usage rates are based on the underlying provider model costs. To estimate relative model costs, refer to the official provider pricing sources linked from the [supported model list](#supported-models-for-ai-features-in-your-app). On Free, Pro, and Business plans, AI gateway usage draws from the monthly AI grant first. After that, it draws from general credits where available. To review AI gateway usage, go to **Settings → Plans & credit usage → Usage details** and select **Run credits**. For more information about AI gateway costs, monthly AI grants, top-ups, auto top-up, alerts, and usage tracking, see [Credits and usage](/introduction/credits-and-usage). ### Cancelled requests If your app cancels an in-flight AI request, some usage may still be counted. The built-in AI connector waits briefly for the provider to finish and report final usage before closing the connection. Provider behavior on cancelled requests varies, so some usage may still be billed even if the app closes the connection before the response finishes. ## Workspace rate limits To ensure reliable performance and fair access for all users, the built-in AI connector applies rate limits per workspace. These limits help maintain system stability, prevent abuse, control costs, and provide a consistent experience for everyone. Rate limits are measured in **requests (model calls) per minute**, not tokens per minute. If your app’s requests exceed the allowed rate, the server returns a `429 Too Many Requests` status code and the request will not be processed. If your workspace runs out of credits, the server returns a `402 Payment Required` status code. You can restore access by adding credits or enabling auto top-up in **Settings → Plans & credit usage**. For more information, see [Credits and usage](/introduction/credits-and-usage). Rate limits are more restrictive for free users, while paid plans include higher thresholds and greater flexibility. * **Free plan users**: upgrade anytime to increase your limits. * **Paid plan users**: contact [Lovable Support](https://lovable.dev/support) if you need additional capacity. ## FAQ No. The built-in AI connector adds AI features to the apps you build with Lovable. The Lovable agent is what helps you build and edit your project. The models listed on this page are available for AI features inside your app. They are not the models Lovable uses to write, edit, or reason about your code. No. Lovable automatically generates and manages the API key for each project. You do not need to create a provider account, configure billing with a model provider, or paste API keys into your app. AI calls run through a secure backend edge function that Lovable creates for you. Calls are not made directly from the browser, which helps keep credentials and prompts server-side. Yes. Each model type has its own default, and you can ask Lovable to use a different supported model or combination of models for a specific AI feature. See [Supported models for AI features in your app](#supported-models-for-ai-features-in-your-app). Yes. The built-in AI connector includes both text-to-speech (so your app can read content aloud or respond with voice) and speech-to-text (so your app can transcribe voice notes, recordings, and meetings, or take voice input). Ask Lovable to add a feature like a "read aloud" button, a voice assistant, or a meeting transcriber, and it sets up the backend for you. See [Text-to-speech](#text-to-speech-models) and [Speech-to-text](#speech-to-text-models). For higher-fidelity or character voices as a core part of your product, you can also connect [ElevenLabs](/integrations/eleven-labs). No. The built-in AI connector currently offers models from Google and OpenAI, listed under [Supported models](#supported-models-for-ai-features-in-your-app). Anthropic models are not available through it. If your app needs a specific provider that isn't offered, call that provider directly from a backend edge function using your own API key stored as a [secret](/features/secrets). Not with the built-in AI connector, which always runs through Lovable and bills your workspace credits. If you want usage billed to your own provider account instead, ask Lovable to call the provider's API directly from a backend edge function, with your key stored as a [secret](/features/secrets). That usage is billed by the provider, and your app only consumes regular Cloud usage for running the function. If your workspace runs out of credits, AI requests return a `402 Payment Required` status code. You can restore access by adding credits or enabling auto top-up in **Settings → Plans & credit usage**. For more information, see [Credits and usage](/introduction/credits-and-usage). # Project analytics Source: https://docs.lovable.dev/features/analytics Track visitors, pageviews, bounce rate, visit duration, traffic sources, and device usage for your published apps in real time. Track how your published project is performing with real-time insights. See key stats like visitors, pageviews, visit duration, and bounce rate. You can also discover where visitors are coming from, which devices they’re using, and which pages they’re viewing. Open the Analytics view from **More → Analytics** in the project toolbar at the top of the editor. ## Time periods By default, analytics data is shown for the **last 7 days**. You can change the time period using the dropdown at the top of the Analytics view. The available options are: * Today * Yesterday * Last 24 hours * Last 7 days (default) * Last 14 days * Last 30 days * Last 90 days * This month # Add Apple authentication to Lovable Cloud apps Source: https://docs.lovable.dev/features/apple-auth Add Sign in with Apple to Lovable Cloud apps using managed Apple OAuth or your own Apple Developer credentials. This page documents **Apple authentication in Lovable Cloud**. It is available only for apps using the [built-in backend (Cloud)](/features/cloud). For an overview of all sign-in methods, see [Users and authentication](/features/authentication). Let users sign in to your app with their Apple account instead of creating a password. Like [Google authentication](/features/google-auth), **Sign in with Apple** can be configured in two ways: * **Managed by Lovable**: Lovable manages the OAuth configuration and security updates. This is the default and requires no Apple Developer account. * **Your own credentials**: you connect credentials from your own Apple Developer account and manage their rotation yourself. Both options provide the same sign-in experience for users: 1. The user clicks **Sign in with Apple** in your app 2. Apple asks them to confirm with their Apple Account 3. The user chooses whether to share their email address with your app 4. Apple redirects the user back to your app, signed in ## Why use Apple sign-in Apple sign-in reduces signup friction for users in the Apple ecosystem, and it appeals to privacy-conscious audiences: * Faster onboarding without password creation * A trusted, familiar confirmation flow on Apple devices * Built-in privacy controls, including the option to hide the real email address * Reduced password reset and account recovery overhead * Pre-verified identity backed by the user's Apple Account ## Common use cases Apple sign-in is commonly used for: * Consumer apps with a large iPhone, iPad, or Mac audience * Apps that pair a Lovable web app with a mobile experience * Products for privacy-conscious users who prefer not to share their real email * Apps that already offer [Google sign-in](/features/google-auth) and want parity for Apple users ## Apple authentication setup options The end-user experience is identical in both modes; the difference is who manages the OAuth credentials. Lovable manages the OAuth configuration and related security updates. No Apple Developer account is required. Use this option if you: * want zero setup * do not need the flow tied to your own Apple Developer account * do not need to control whether users can sign in without sharing an email ```text wrap theme={null} Add an Apple sign-in button to my app. ``` Lovable enables the provider in **Cloud tab → Users → Auth settings → Apple** and adds the sign-in button to your app's login page. You can also enable it manually from the same settings. Verify that: * a **Sign in with Apple** button appears on your login page * users are redirected to Apple to confirm * users return to the app in a signed-in state * new users appear in **Cloud tab → Users** In Managed by Lovable mode, users must share an email address with your app to complete sign-in. Users who pick Apple's **Hide My Email** option still provide one: Apple shares a private relay address with your app instead of the real one. You create and manage Sign in with Apple credentials in your own Apple Developer account and connect them to Lovable. You are responsible for credential security and rotation. Use this option if you: * want the sign-in flow tied to your own Apple Developer account and identifiers * have security or compliance requirements for owning the credentials * want to control whether users can sign in without sharing an email You need a paid Apple Developer Program membership with admin access to the account. In the [Apple Developer portal](https://developer.apple.com/account), you need: * an **App ID** with the **Sign in with Apple** capability enabled * a **Services ID** to act as the client identifier for the web flow * a **key** with Sign in with Apple enabled, downloaded as a `.p8` file (note its **Key ID** and your **Team ID**) See Apple's [Sign in with Apple documentation](https://developer.apple.com/sign-in-with-apple/get-started/) for the portal walkthrough. In **Cloud tab → Users → Auth settings → Apple**, choose **Your own credentials** and fill in: * **Client ID**: your Services ID (or Bundle ID) in reverse domain name notation, for example `com.example.app`. * **Client secret (JWT)**: a JSON Web Token generated from your `.p8` key. Use the built-in **Generate secret** helper: upload the `.p8` file and enter your Key ID, Services ID, and Team ID, and it builds the JWT for you. Copy the redirect URLs shown in Lovable (the **Redirect URL(s)** field; Apple calls them **Return URLs**) into your Services ID configuration in the Apple Developer portal. Sign-in fails with a redirect error until these match. Sign in with an Apple account, including once with **Hide My Email** selected, and confirm the user appears in **Cloud tab → Users**. Apple requires you to generate a new client secret every 6 months using your signing key. Generate a new JWT before the current one expires, or users will not be able to sign in. ### Allow users without an email Apple lets users hide their email address when signing in. With your own credentials, the **Allow users without an email** toggle controls whether such users can sign in to your app. If your app's features depend on reaching users by email, consider leaving it off. ## Managing Apple authentication You can switch between **Managed by Lovable** and **Your own credentials** at any time from **Cloud tab → Users → Auth settings → Apple**. Existing accounts are kept, but Apple identifies users per developer team: users who signed up under the previous mode may not be recognized when they next sign in with Apple, and Hide My Email relay addresses change with the team. Plan the switch before your app has many Apple users. To remove the sign-in option, ask Lovable in chat: ```text wrap theme={null} Remove the Apple sign-in button from my app. ``` Or disable the provider in the auth settings. Users who signed up with Apple keep their accounts but need another enabled sign-in method to get back in. ## Troubleshooting Your client secret has probably expired. Apple limits each JWT to 6 months. Generate a new secret from your `.p8` key with **Generate secret** and save it in the Apple auth settings. The return URLs in your Apple Services ID configuration don't match the redirect URLs Lovable shows. Copy every return URL from Lovable into the Apple Developer portal exactly, then retry. If sign-in fails only on your published app or custom domain, also check your project's [redirect URLs](/features/authentication#site-url-and-redirect-urls). Apple forwards mail sent to the relay address only while the user keeps forwarding on. Treat the relay address like any other email in your app, and offer an in-app way for users to update their contact details. ## FAQ Only if you use your own credentials. In Managed by Lovable mode, Lovable provides the OAuth configuration and no Apple Developer account is needed. Apple shares a private relay address with your app instead of the real one, so the user still has an email your app can use. With your own credentials, the **Allow users without an email** toggle additionally controls whether users can sign in without providing any address. If you use your own credentials, the most common cause is an expired client secret: Apple limits each JWT to 6 months. Generate a new secret from your `.p8` key and save it in the Apple auth settings. No. It is an additional sign-in method, and you can offer it alongside [email](/features/email-auth), [Google](/features/google-auth), and other methods. Yes, anytime from **Cloud tab → Users → Auth settings → Apple**. Existing accounts are kept, but Apple identifies users per developer team, so users who signed up under the previous mode may not be recognized after the switch. Plan the switch before your app has many Apple users. No. Sign in with Apple works in any browser. Users sign in with their Apple Account credentials, and users on Apple devices get the smoothest flow. # Audit logs Source: https://docs.lovable.dev/features/audit-logs Monitor workspace activity with Enterprise audit logs. Filter by action, member, resource, or time range to review events such as membership changes, project actions, authentication events, and workspace settings or configuration changes. Audit logs provide a searchable audit trail of activity in your workspace. They show who performed an action, when it happened, what changed, and which resource was affected. Use audit logs to review workspace settings and configuration changes, track access updates, and investigate unexpected behavior. Audit logs can also support security and compliance workflows when needed. * **Available on:** Enterprise plans * **Access:** Workspace admins and owners * **Location:** [Audit logs](https://lovable.dev/settings/audit-logs) (**Settings → Security → Audit logs**) ## Audit log events Workspace audit logs include events across categories such as: | **Category** | **Example events** | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Workspace membership** |
  • Member added, removed, or role updated
| | **Workspace management** |
  • Workspace settings updated
  • Workspace deleted
| | **Workspace groups** |
  • Group created, updated, or deleted
  • Group members added or removed
| | **Identity and access** |
  • Verified domain added or removed
  • SSO provider added, updated, or removed
  • SCIM provisioning actions
| | **Secrets and integrations** |
  • GitHub or Slack app installed or removed on workspace
  • Custom MCP server created or deleted
  • Secrets changed
| | **Projects** |
  • Project created, deleted, published, unpublished, or moved
  • Collaborators added, joined, removed, or their role updated
  • Custom domains created or deleted
  • Supabase project or Shopify store connected or disconnected
  • Prompt sent
  • Knowledge updated
  • Database query executed
  • Remix initiated
| | **Lovable Cloud** |
  • Project auth settings updated
  • Cloud auth users created, invited, or deleted
  • Storage buckets created or deleted
  • Disk configuration updated
| | **Authentication** |
  • SSO workspace access
  • SSO identity token issued or refreshed
| This table shows common examples. The **All actions** filter on the audit logs page lists the full set of event types recorded for your workspace. ## Audit log table By default, the page shows logs for **All actions**, **All actors**, and the **Last 90 days**. The total number of matching logs appears in the top right of the table. The table is organized into four columns: | Column | Description | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Timestamp** | When the event occurred, such as `4 minutes ago` or `about 11 hours ago`. Hover to see the exact date and time. | | **Actor** | The member who performed the action. Clicking the member’s name opens a popover showing their `Email`, `User ID`, `IP Address`, and `User Agent`. From this popover, you can copy these details or filter the table by that user. | | **Action** | The type of activity, displayed as a label such as `Prompt sent`, `Workspace updated`, `Member added`, or `Project created`. | | **Resource** | The affected object, such as a project, workspace, or user. Some resources are clickable. For example, clicking a project name opens that project. | Click any row to expand it and see structured JSON details describing the event. This includes the metadata associated with that action, such as message IDs for prompt activity or specific fields that were updated in a workspace setting. Events triggered through the Lovable API are also attributed to the access token that made the request. The expanded JSON details include an `api_key_id` field alongside the acting user, so you can trace which token drove a given change. ## Filtering audit logs You can combine the filters to focus on specific activity: * **All actions** lets you select one or more action types, such as `Member added`, `Member removed`, `Workspace updated`, `Project created`, or `Prompt sent`. The dropdown is searchable. * **All actors** lets you select one or more workspace members using the searchable picker. * **Resources** lets you search for projects and people and show only events that affected them. * **Time range** includes presets for **Last 7 days**, **Last 30 days**, **Last 90 days**, **This month**, and **Last month**. ## How to use audit logs A typical workflow: 1. Set a relevant **time range**. 2. Filter by **actor** to review activity from a specific member. 3. Filter by **action type** to narrow results to a specific kind of change. 4. Expand entries to inspect the full JSON details. 5. Open affected projects or jump to related messages to review context. 6. Use the actor popover to copy details such as email, user ID, IP address, or user agent if needed. ## Exporting audit logs Click **Export** in the top right of the page, then click **Start new export**. Lovable generates a JSONL file (one JSON event per line) of the audit logs matching your active action, actor, and time range filters. Finished exports stay available for download for 7 days, and each export is itself recorded in the audit log. Export is not available while a resource filter is active. Clear the **Resources** filter first. ## Audit log data retention Logs are retained for 13 weeks, or approximately 90 days. Events older than that are automatically removed. Logs before February 26, 2026 may be incomplete. ## FAQ Audit logs are available on Enterprise plans and are visible to workspace owners and admins. Audit logs are retained for 13 weeks, or approximately 90 days. Events older than that are automatically removed. Yes. Click **Export** in the top right of the audit logs page to download audit logs as a JSONL file. The export respects your active filters, and finished exports stay available for download for 7 days. If you need to integrate audit logs with a SIEM or external monitoring system, contact your account team to discuss enterprise integration options. If audit logs are not available or do not appear as expected: * Confirm your workspace is on an Enterprise plan. * Confirm your role includes permission to view audit logs. You must be a workspace admin or owner. * Clear filters and try a broader time range. # Users and authentication Source: https://docs.lovable.dev/features/authentication Manage your app's users and configure how they sign in to your Lovable Cloud app: email, phone, Google, Apple, and SAML SSO. Lovable Cloud includes built-in authentication for your app. Ask Lovable to add login, and it generates the signup and login pages, wires them to your backend, and protects user data with row level security. For example, tell Lovable: ```text wrap theme={null} Add login to the app. Require login before accessing the CRM dashboard. Also, add a 'Sign in with Google' button so users can log in with their Google accounts. ``` The **Users** view lets you manage the people who sign up and configure how they sign in. To open it, go to **Cloud tab → Users**. ## Manage users The Users view shows a **Signups** chart of new users over the last 7, 30, or 90 days, and a searchable list of every user in your app. To add users yourself, click **Add user**: * **Send invitation**: enter an email address and Lovable sends the person an invite email to join your app. * **Create new user**: enter an email address and password to create the account directly. Users created this way are automatically confirmed. Click a user to open their details, including their user ID, sign-up and last sign-in timestamps, and which login methods they use. The **Raw JSON** tab shows the full user record. To remove a user, open their details and choose **Delete user**. The user loses access to your app, and the action cannot be undone. ## Authentication settings Click **Auth settings** in the Users view to configure how users sign in. The **Sign in methods** list shows each available method with an **Enabled** or **Disabled** badge. You can change these settings directly, or ask Lovable in chat. When you enable a sign-in method, Lovable can also update your app's login page, for example by adding the matching sign-in button. On Business and Enterprise workspaces, admins can block sign-in methods for all projects in the workspace with the [App login methods](/features/privacy-and-security-settings#app-login-methods) setting (**Settings → Security → Privacy & security → App login methods**). The policy controls what you can change in your project's auth settings: you cannot enable a method the policy blocks, and a blocked method that was already enabled can still be disabled, but not enabled again. Locked methods show a **Workspace policy** badge. Building an internal tool for your own workspace members? Apps can recognize the signed-in workspace member with no login page at all. See [Reuse Lovable workspace identity](/features/lovable-workspace-identity-reuse). Each sign-in method has its own page with full configuration details: * [Email](/features/email-auth): the default method, with settings for confirmation, password rules, one-time codes, and sending limits. * [Phone](/features/phone-auth): SMS one-time codes through your own SMS provider (Twilio, Twilio Verify, TextLocal, Vonage, or MessageBird). * [Google](/features/google-auth): managed by Lovable with no setup, or your own Google Cloud OAuth credentials. * [Apple](/features/apple-auth): managed by Lovable, or your own Apple Developer credentials. * [SAML SSO](/features/saml-sso): sign-in through a SAML 2.0 identity provider such as Okta or Microsoft Entra ID. ## Sign-up controls Two settings on the main auth settings form control who can join your app: * **Disable sign-up**: prevent new users from signing up. Existing users can still sign in, and you can still add users with **Add user**. * **Enable anonymous users**: let visitors use your app without creating an account. Ask Lovable in chat to build flows that use anonymous sessions, such as guest checkouts. ## Site URL and redirect URLs Under **Advanced** in the auth settings: * **Site URL**: the default URL users are redirected to after authentication when no redirect URL is specified. * **Redirect URLs**: up to 50 URLs that auth providers are permitted to redirect to after authentication. Custom schemes (for example, `myapp://callback`) are supported for mobile apps. If sign-in works in preview but breaks on your published app or custom domain, these URLs are usually the reason. Ask Lovable in chat to update them for your domain. ## Auth emails Authentication flows send emails for signup confirmation, password resets, invites, magic links, email changes, and re-authentication. By default they come from a generic sender. To send them from your own domain with custom branding, set up the **Emails** section of the Cloud tab. See [Custom emails](/features/custom-emails). ## FAQ No. Google and Apple sign-in work in Managed by Lovable mode, where Lovable handles the OAuth configuration and security updates. You only need your own credentials if you want the consent screen to show your own branding and verified domain. Yes. On Business and Enterprise workspaces, admins can block sign-in methods for every project in the workspace with the [App login methods](/features/privacy-and-security-settings#app-login-methods) setting (**Settings → Security → Privacy & security → App login methods**). Blocked methods are locked: project owners can turn them off but cannot turn them back on. No. Remixing copies the structure of backend data, such as tables and auth configuration, but not the data itself. The remixed project starts with no users. The published URL or custom domain is probably missing from your project's redirect URLs. Ask Lovable in chat to add your domain to the auth redirect URLs, or add it under **Auth settings → Advanced → Redirect URLs**. # Publish apps with branded URLs Source: https://docs.lovable.dev/features/branded-workspace-urls Create consistent, branded URLs for every app in your workspace. Branded app URLs let your workspace publish apps under a shared, branded URL pattern instead of the default `your-app.lovable.app`. To enable this, you configure a single workspace subdomain that is used across all app URLs. When enabled, your app URLs follow this format: \ `https://{app-name}.{workspace-subdomain}.lovable.app` For example, if your workspace subdomain is `acme`, a project named `dashboard` is published at `dashboard.acme.lovable.app`. Project names are scoped to your workspace, so they do not conflict with names in other workspaces. * **Available on:** Business and Enterprise plans * **Access:** Workspace admins and owners * **Location:** Workspace settings → Branded app URLs ## Why use branded app URLs Branded app URLs create a consistent and recognizable URL structure across all apps in a workspace. This is especially useful for client-facing or internal enterprise deployments. Use this feature when you: * Want a consistent URL identity across all apps in a workspace. * Need a predictable workspace-level naming pattern for governance and recognition. * Want to keep project URLs branded even before adding custom domains. ## Prerequisites You must [verify at least one domain](/features/verified-domains) in your workspace’s **Identity** settings. Branded app URLs use a workspace subdomain derived from a verified domain. ## Set up branded app URLs You can only have one branded subdomain per workspace. Go to **Workspace settings → Branded app URLs**, select a verified domain from the dropdown, and enable the feature. You'll see a preview of what your app URLs will look like. Lovable automatically derives the workspace subdomain, for example: * `acme.com` → `acme` * `acme.ai` → `acme-ai` * `acme.co.uk` → `acme-co-uk` Lovable provisions DNS and SSL for your branded subdomain. When it shows **Active**, you can publish your apps under the branded subdomain. [Publish a project](/features/publish) as you normally would. The project URL is automatically updated to the branded format. ### Branded subdomain statuses After enabling, the branded workspace subdomain can move through these states: | Status | Meaning | | --------------------------- | -------------------------------------- | | **Provisioning DNS** | DNS provisioning is in progress | | **Issuing SSL certificate** | DNS is ready and SSL is being issued | | **Active** | Branded workspace subdomain is ready | | **Failed** | Provisioning failed and requires retry | | **Disabling** | Deprovisioning is in progress | ### Which URL your app uses When branded app URLs are enabled and a branded workspace subdomain is active: * Apps published for the first time publish to `app-name.workspace-subdomain.lovable.app` * Previously published apps remain accessible at their current URL. A branded app URL is assigned when you republish. * A project can have both a branded URL and a custom domain. If a project has its own custom domain (for example, `app.acme.com`), the custom domain remains the primary URL and takes precedence. * Preview URLs use `preview--app-name.workspace-subdomain.lovable.app` ## Disable branded app URLs You must unpublish all apps that are currently using branded URLs before you can disable the feature. The UI will show you how many published apps are affected and block the action until they're unpublished. To disable branded URLs, go to **Workspace settings → Branded app URLs** and click **Disable.** ## Troubleshooting * Confirm that your workspace is on a Business or Enterprise plan * Confirm that your workspace has at least one verified domain If status shows **Failed**, disable and re-enable branded app URLs, then wait for provisioning again. If it continues to fail, contact [Lovable Support](https://lovable.dev/support). This usually means one or more apps are still published under branded app URLs. Unpublish those apps first, then disable again. # Test your app in a browser Source: https://docs.lovable.dev/features/browser-testing Learn how Lovable uses browser testing to verify your app by clicking buttons, filling forms, testing flows, and checking behavior across screen sizes. Browser testing lets Lovable interact with your app in a real browser running in a virtual environment. The agent can click buttons, fill forms, navigate pages, and verify real user behavior with screenshots instead of relying on code alone. Use browser testing to validate user flows, debug visual or behavioral issues, and confirm that changes work as expected across different screen sizes. ## What browser testing can do When browser testing runs, the agent can: * Capture screenshots of the app * Click buttons and links * Fill inputs and submit forms * Navigate between pages * Read console logs and network requests * Detect runtime errors while interacting with your app * Test different screen sizes, including mobile, tablet, and desktop layouts. By default, it uses the same size as your preview. ## How browser testing works Lovable uses browser testing selectively, after trying faster verification methods first. Browser testing may run when: * You explicitly ask to verify something works. Common trigger phrases include:\ “verify it works”, “make sure it works”, “test this”, “check if it’s working” * Visual or UI issues can’t be pinpointed through logs or code inspection * There is a larger feature change, and Lovable offers to test the flow and you confirm Avoid asking Lovable to *make a large change and test it* in the same prompt. If browser testing gets stuck and you stop it, any work done during that step may be lost. A safer flow is to build first, then test in a follow-up prompt. ### Where it runs The browser runs remotely in a secure virtual environment. It is not your personal browser and does not take over your local session. * Browser testing always runs against the preview of the project you are currently working on and tests exactly the version of the app you are viewing. * If your app uses authentication, browser testing runs using the same app user you are currently logged in as in the preview. Be explicit if there are actions or areas that should not be clicked or triggered. * Some Lovable Cloud apps use the test and live environments feature. When this feature is enabled, browser testing runs against the project preview in the **test** environment. ### What happens during a browser testing run You can follow the testing process in a dedicated **Details view**, where the agent: * Shows the steps it is taking, such as clicking buttons or navigating pages * Captures screenshots of the app * Displays the URLs and results of interactions * Summarizes what worked and what did not Browser testing is slower than normal actions because the agent is interacting with a real browser and verifying results. ### Example: Manually trigger browser testing The example below shows how to manually trigger browser testing after discovering an issue with the profile page. Ask Lovable to reproduce the issue, fix it, and then verify the fix. For example: ```text wrap theme={null} The page crashes when I click my profile. Reproduce in the browser, fix it, and then verify that your fix worked. ``` Manually triggering browser testing ## Limitations * It cannot interact with canvas-based or drawing tools * Standard file inputs work, but custom or complex file upload widgets can be unreliable * It may perform drag-and-drop interactions, but they are less reliable than clicks * It may perform clipboard actions and text selection, but these are unreliable * It is not reliable for evaluating subtle visual design details or color differences * It may have difficulty interacting with icon-only buttons compared to text-labeled buttons * Signed-in testing requires Lovable Cloud. For apps that use their own external Supabase project or another authentication provider, it can only test pages that don't require signing in ## FAQ Yes, in some cases. Lovable may automatically suggest or use browser testing when verification is needed, but it is conservative by default and tries lighter methods first. You can always explicitly ask for browser testing at any time. Common trigger phrases include: “verify it works”, “make sure it works”, “test this”, “check if it’s working”. For example: ```text wrap theme={null} Use browser testing to verify this flow. ``` Browser testing always runs against the preview of the project you are currently working on. It tests exactly the version of the app you are viewing. If your project uses **test and live environment separation**, browser testing runs against the test environment preview. Yes. If your app uses authentication, the agent is logged in as the same app user you are currently logged in and browser testing runs using the same app user. Be explicit if something should not be clicked or triggered. No. Browser testing uses a real browser running in a remote virtual environment. It does not take over your local browser or session. If the agent repeatedly fails to interact with the same element, this could be due to browser interaction limitations (more likely) or an underlying issue in your app, such as a hidden element, broken state, or unexpected layout. Try the following: 1. Review the screenshots and logs from the testing run in the Details view 2. Ask Lovable to make the element easier to interact with (for example, by adding visible text or an accessibility label) 3. If the issue persists, explicitly instruct the agent to avoid interacting with that element # Manage training data and privacy Source: https://docs.lovable.dev/features/business/data-opt-out Control whether your workspace data is used for AI model training and understand how Lovable handles personally identifiable information. We believe trust is the foundation of great experiences. This page explains how Lovable may use your data for model training and how you can opt out. **Customer data** means any content, code, text, images, files, or other data that you input, upload, submit, host, or generate through Lovable services, including applications you create using the Lovable platform. Customer data *may* be used for model training and other business purposes as described in our [Terms of Service](https://lovable.dev/terms). ***Only customer data that does not identify you may be used.*** ## Data opt-out Every customer and organization can decide how their customer data is used in Lovable. * **Free and Pro plans**\ If you want to opt out of model training or other training-related data usage, contact [Lovable Support](https://lovable.dev/support). * **Business and Enterprise plans**\ If your organization wants to prevent its data from being used for training, you can opt out of any training-related data usage at the workspace level. Workspace admins and owners can enable **Data collection opt out** in **Settings → Privacy & security** to ensure your proprietary code, projects, and workspace data are never used to train AI models or perform internal evaluation. ## How Lovable handles PII **Personally Identifiable Information or PII** means any information that identifies, relates to, describes, or could reasonably be linked to a specific individual. We treat PII separately from other customer data: * We will not use raw or identifiable PII for model training. * We do not sell PII. * We may anonymize and aggregate PII, and once anonymized and aggregated, we may use it for business purposes such as improving the service. These rules apply across plans and are designed to protect individual users while still allowing us to improve performance, reliability, and product quality using non-identifiable data. ## FAQ Customer data may be used for model training and other business purposes as described in our [Terms of Service](https://lovable.dev/terms). Only customer data that does not identify you *may* be used. * **Free and Pro:** Customer data may be used for model training unless you opt out by contacting [Lovable Support](https://lovable.dev/support). * **Business and Enterprise:** Customer data may be used for model training unless your workspace enables **Data collection opt out**. If you’re on Free or Pro plan, you can request an opt-out of model training and other training-related data usage by contacting [Lovable Support](https://lovable.dev/support). If you’re on the Business or Enterprise plan, admins and owners can enable **Data collection opt out** at the workspace level in **Settings → Privacy & security**. No. The **Data collection opt out** setting is a workspace-level control for Business and Enterprise workspaces. Customers on other plans can still opt out of training-related data usage by contacting [Lovable Support](https://lovable.dev/support). # Design templates Source: https://docs.lovable.dev/features/business/design-templates Reuse Lovable projects as design templates. Templates copy the full codebase, including design, components, and structure, to maintain consistency and accelerate development. ## What are design templates? Design templates are available on **Business** and **Enterprise** plans. They let teams reuse approved designs and project structures to maintain consistent styling, branding, and user experience across projects. A design template is a Lovable project that has been marked as reusable. When a template is used, the entire project codebase is copied into the new project, including: * File structure * Components and styles * Configuration files * Project setup and scaffolding Projects created from design templates are fully independent and can be edited freely. ## Why use design templates? Use design templates to: * Maintain consistent design systems and architecture * Start new projects from proven codebases * Reduce repetitive setup work * Share best practices across a workspace Design templates help teams move faster while keeping projects aligned. ## Prerequisites To use design templates: * You must be on a **Business or Enterprise plan** * The template project must have **public or workspace visibility** * You must be a project editor, admin, or owner to set projects as templates * You must be a workspace admin or owner to manage default templates ## Set up a design template To set up a design template, you must be a project editor, admin, or owner. 1. Open an existing project. 2. Open the **Share** menu in the top right of the editor and, under **General project access**, give your workspace access to the project. 3. Go to [**Project settings**](/features/projects/settings#details) and enable **Use as a template**. The toggle stays disabled while the project is restricted. The project appears in the **Workspace settings → Templates** section and can be used when creating new projects. ## Start a project from a design template To use a template when creating a new project: 1. Click `+` on the prompt box. 2. Go to **Design → Use a template**. 3. Choose a template and create your project as usual. The selected template is applied as the project foundation. Your prompt still controls what gets generated. ## Default templates Each workspace can have **one default design template**. Default templates help standardize how projects are created across a workspace. You need to be a workspace admin or owner to manage default templates. To set a default template: 1. Go to **Workspace settings → Templates**. 2. Hover over a template and select **Set as default**. When a default template is set, it appears in the prompt box and is applied automatically to new projects. You can override the selection at any time. To remove a default template: 1. Go to **Workspace settings → Templates**. 2. Hover over the template and remove the default. # Set up SCIM user provisioning Source: https://docs.lovable.dev/features/business/scim Configure SCIM provisioning to automatically create, update, and remove users in Lovable using your identity provider. Manage user access, roles, and lifecycle centrally with Okta, Microsoft Entra ID, and other SCIM 2.0 providers. **SCIM (System for Cross-domain Identity Management)** is available on the **Enterprise plan** only. It enables automated user provisioning and lifecycle management through your identity provider (IdP). With SCIM, you can manage workspace access centrally from your IdP. Users are automatically added when assigned, removed when unassigned, and assigned roles based on group membership, keeping your workspace in sync without manual user management. ## Prerequisites Before setting up SCIM provisioning, you need: * **IdP admin access** (Okta, Microsoft Entra ID, or any other SCIM 2.0 provider you’re using) * **Lovable workspace owner or admin role** * **At least one verified domain** for your workspace, since SCIM only provisions users whose email domain is verified. See [Verify a domain for your workspace](/features/verified-domains). * **An active SSO provider configured** (OIDC or SAML). See [**Set up single sign-on (SSO)**](/features/business/sso) for more information. * **If you don’t have SSO yet:**\ You’ll typically create a single application in your identity provider that handles both SSO authentication and SCIM provisioning. * **If you already have SSO configured:**\ You can optionally create a separate application in your IdP specifically for SCIM provisioning. This allows you to keep your existing SSO setup unchanged. Lovable will continue to use your current SSO provider for user authentication, regardless of which IdP application handles SCIM. Some identity providers require SCIM provisioning to be configured on a SAML application, even if SSO authentication uses OIDC. In this case, the SAML application with SCIM enabled is used only for provisioning and does not need to be configured as an SSO provider in Lovable. ## How SCIM works in Lovable This section explains how Lovable processes SCIM events from your identity provider. ### User provisioning When your IdP creates or assigns a user to the Lovable application: 1. The IdP sends a SCIM request to Lovable. 2. Lovable verifies that the user’s email domain is verified for your workspace. 3. The user receives an email invitation to join. 4. When the user accepts the invitation and creates an account, they are added to the workspace with the appropriate role based on SCIM configuration. ### User deprovisioning When your IdP removes or deactivates a user: 1. The IdP sends a deactivation request to Lovable. 2. The user is removed from your workspace. 3. The user can no longer log in to the workspace. ### Group push and role updates When group-based provisioning is enabled in your IdP: 1. Group membership changes are pushed to Lovable. 2. Users added to a mapped group receive the corresponding role. 3. Users removed from all mapped groups are removed from the workspace. ### Supported SCIM operations Lovable implements the SCIM 2.0 specification and supports the following operations: | Resource | Supported operations | | :------- | :---------------------------------------------- | | Users | Create, read, update, delete, list | | Groups | Create, read, update, delete, list, member push | ## Set up SCIM provisioning Setting up SCIM provisioning requires configuration in both Lovable and your identity provider. You start in Lovable to enable SCIM provisioning and generate the required credentials, then complete the setup in your IdP. ### Step 1: Configure SCIM in Lovable First, enable SCIM provisioning in Lovable and copy the values needed by your identity provider. Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → SCIM provisioning**) and enable **SCIM provisioning**. When SCIM provisioning is enabled, Lovable generates and displays the following values: * **API key:** A secure API token used for authenticating SCIM requests (shown only once) * **Base URL:** The endpoint your IdP uses to sync users. **Save the API key immediately**. The full API key is shown only once. If you lose it, you must rotate the key to generate a new one. You’ll need these values when configuring SCIM in your identity provider. The setup wizard opens on the **Configure group mappings** step. Map your IdP groups to Lovable workspace roles for fine-grained access control. See [Configure role mapping](/features/business/scim#configure-role-mapping) for details. The **default role** is assigned to newly provisioned users who do not match any group mapping. The available roles are: * **Viewer**: Read-only access * **Editor**: Can create and edit projects * **Admin**: Full workspace management Use the **Send welcome email to provisioned users** toggle to control whether Lovable emails an invitation to each user provisioned through SCIM. * **On (default):** Each newly provisioned user receives a welcome email with a link to join the workspace. * **Off:** Users are provisioned silently. They can still sign in through your configured SSO provider once they're assigned in your IdP. You can change this setting later from [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → SCIM provisioning**). ### Step 2: Configure SCIM in your identity provider Use the values generated in Lovable to configure SCIM provisioning in your identity provider. | Setting | Value | | :------------- | :----------------------------------- | | Base URL | `https://api.lovable.dev/scim/v2` | | Authentication | Bearer token | | API key | \ | Select your identity provider below and follow the instructions to complete SCIM configuration. For more information, refer to your IdP's official documentation. SCIM provisioning uses the same **Lovable** app you added from the Okta App Catalog for SSO. Complete [Set up single sign-on (SSO)](/features/business/sso) first. In the **Okta Admin Console**, open the **Lovable** application you created for SSO and go to the **Provisioning** tab. * Click **Configure API Integration**, then check **Enable API integration**. * Enter the **Base URL** (`https://api.lovable.dev/scim/v2`) and paste your Lovable **SCIM API key** into the **API Token** field. * Click **Test API Credentials**. You should see "Lovable was verified successfully!" * Click **Save**. * In the **Provisioning** tab, click **To App** in the left sidebar. * Click **Edit** and enable: * **Create Users** * **Update User Attributes** * **Deactivate Users** * Click **Save**. * Assign users (or groups) to the Lovable app under **Assignments**. * If you use group-based role mapping in Lovable, enable group push in Okta and push the same groups you mapped in Lovable. SCIM provisioning in Microsoft Entra ID is supported only through a SAML application. If you use OIDC for SSO, you’ll need to create a separate SAML app in Microsoft Entra ID for SCIM provisioning. * Go to **Microsoft Entra admin center** **→** **Enterprise applications.** * Create a new SAML application or select your existing SAML Lovable app. * Select **Provisioning → New configuration.** Under **Admin credentials**, enter the following values: * Authentication method: Bearer Authentication * Tenant URL: `https://api.lovable.dev/scim/v2` * Secret token: `` Click **Test connection** to verify the setup. Click **Create.** In the provisioning configuration **Overview (Preview)** page, click **Start provisioning**. If you're using any other identity provider that supports SCIM 2.0, follow these general instructions to configure provisioning. * In your IdP admin console, locate the SCIM or provisioning settings for your Lovable application. * Enable SCIM provisioning or automatic provisioning. Configure the SCIM connection with the following values: * SCIM base URL / Tenant URL: `https://api.lovable.dev/scim/v2` * Authentication method: `Bearer token (HTTP header)` * API token / Secret token: `` * Unique identifier field: `userName (email address)` Enable the provisioning actions you want to use: * Create users * Update user attributes * Deactivate or delete users * Push groups (if using group-based role mapping) Test the connection using your IdP's built-in test feature. Save the configuration and enable provisioning. When SCIM provisioning is configured in both Lovable and your identity provider, user provisioning and deprovisioning will begin automatically based on assignments in your IdP. ## Configure role mapping SCIM supports automatic role assignment based on IdP group membership, allowing you to control workspace permissions centrally. ### Map IdP groups to roles Map your IdP groups to Lovable workspace roles for fine-grained access control. To add a group role mapping: 1. Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → SCIM provisioning**). 2. Under **Group role mappings**, enter the **Group name** exactly as it appears in your IdP (for example, `engineering-admins`). 3. Select the **Role** to assign (viewer, editor, or admin). 4. Click **Add** to save. Group names are case-insensitive. For example, `Engineering-Admins` and `engineering-admins` both match. **Example mappings** | IdP group | Lovable role | | ---------------- | ------------ | | `lovable-admins` | Admin | | `engineering` | Editor | | `contractors` | Viewer | When a user is provisioned: * Lovable checks whether the user belongs to any mapped groups. * If a match is found, the corresponding role is assigned. * If no match is found, the **default role** is assigned. ## Manage SCIM provisioning Use the identity settings to manage SCIM provisioning over time. ### Rotate the API key Rotate the API key if it may have been compromised or needs to be regenerated: 1. Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → SCIM provisioning**). 2. Click **Rotate** next to the API key. 3. Confirm the rotation. 4. Copy and save the new API key immediately. 5. Update your IdP with the new API key. Rotating the API key immediately invalidates the previous API key. Update your IdP configuration right away to avoid provisioning interruptions. ### Toggle welcome emails for provisioned users Control whether Lovable sends a welcome email to each user provisioned through SCIM: 1. Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → SCIM provisioning**). 2. Toggle **Send welcome email to provisioned users** on or off. 3. The change applies to users provisioned after the toggle is updated. Existing members are not affected. Turn this off if you onboard users through a different channel (for example, an internal announcement) and don't want them to receive a separate Lovable invitation email. ### Disable SCIM provisioning To stop automatic provisioning: 1. Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → SCIM provisioning**). 2. Disable **SCIM provisioning.** Disabling SCIM stops automatic provisioning but does not remove existing workspace members. Users previously provisioned via SCIM will remain in the workspace until manually removed. Deleting your workspace SSO provider also removes SCIM provisioning as part of the same action: the SCIM API key is revoked and SCIM-managed groups are deleted, all in a single audited step. See [Delete an SSO provider](/features/business/sso#delete-an-sso-provider). ## Troubleshooting SCIM only provisions users whose email domain is verified for your workspace. To fix: 1. Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**) 2. Add and verify the email domain under **Verified domains** 3. Retry provisioning from your IdP. Verify that: * Your SSO provider is correctly configured. * Users are assigned to the SSO application in your IdP. Users provisioned via SCIM must authenticate through SSO. Check that: * Group names in your mappings exactly match what your IdP sends (case-insensitive) * Your IdP is configured to send group membership data in SCIM requests * Group push is enabled in your IdP ## FAQ No, SCIM requires an active SSO provider. Users provisioned via SCIM authenticate using your configured SSO provider. Existing workspace members are not affected when you enable SCIM. SCIM manages users provisioned through your IdP. Previously invited users continue to exist alongside SCIM-provisioned users. The API key is only shown once when generated. If you've lost it: 1. Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → SCIM provisioning**). 2. Click **Rotate** next to the API key and confirm the rotation. 3. Update your IdP with the new API key. Yes. During SCIM setup, turn off **Send welcome email to provisioned users**. You can also change this setting at any time from [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → SCIM provisioning**). When disabled, provisioned users can sign in through your configured SSO provider without receiving an invitation email from Lovable. When a user belongs to multiple mapped groups, Lovable assigns the highest-privilege role from those groups. SCIM is recommended for managed environments where user lifecycle and access should be controlled centrally from your identity provider. Just-in-time (JIT) provisioning applies only to users who sign up through SSO. When a user is created via SSO sign-up, the JIT role is applied. When users are provisioned via SCIM, user creation and role assignment are managed by SCIM, including group-based role mappings, user metadata, or the default SCIM role. In this case, SCIM provisioning and role assignments take precedence over JIT. # Set up workspace single sign-on (SSO) Source: https://docs.lovable.dev/features/business/sso Connect Okta, Auth0, Microsoft Entra ID, or any OIDC/SAML 2.0 provider to enable secure, centralized authentication for your workspace. This page documents **workspace-level SSO for your team's access to Lovable itself**. It is configured at the workspace level under [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**). Looking for SAML SSO for the **end users of your Lovable Cloud app**? See [Add SAML single sign-on to Lovable Cloud apps](/features/saml-sso). Want apps you build to **recognize signed-in workspace members without a login page**? See [Reuse Lovable workspace identity in your app](/features/lovable-workspace-identity-reuse). Both are different features. Single sign-on (SSO) is available on **Business** and **Enterprise** plans and enables secure, centralized authentication across your organization. With SSO, users can access Lovable with one set of credentials, simplifying access management and improving security. **Service provider (SP)-initiated sign-in** is supported for all providers: users start sign-in from Lovable. **Identity provider (IdP)-initiated SSO** (starting from an IdP dashboard tile) can optionally be enabled for **SAML** providers. See [Set up IdP-initiated sign-in (SAML)](#set-up-idp-initiated-sign-in-saml). OIDC providers support SP-initiated sign-in only. ## Supported SSO protocols Lovable supports both **OIDC** and **SAML 2.0** protocols, enabling integration with all major **identity providers (IdP)** including Okta, Auth0, Microsoft Entra ID (Azure AD), and more. * **OpenID Connect (OIDC)**: recommended; a modern identity layer built on top of OAuth 2.0 that provides identity verification. * **SAML (Security Assertion Markup Language) 2.0**: XML-based protocol for exchanging authentication and authorization data, widely used in enterprise environments. ## Prerequisites To connect your identity provider to Lovable using OIDC or SAML, you need: * **IdP admin access** (Okta, Auth0, Microsoft Entra ID, or any other provider you're using) * **Lovable workspace owner or admin role** * A **verified domain** in Lovable, to prove domain ownership To verify your domain, add the `TXT` record displayed in the UI to your DNS provider. See [Verify a domain for your workspace](/features/verified-domains) for the full walkthrough, including record details and troubleshooting. ## Start SSO setup in Lovable SSO configuration is a **two-way setup** between Lovable and your identity provider: * **Lovable → IdP:** copy Lovable URLs and settings into your IdP app. * **IdP → Lovable:** copy your IdP’s issuer, metadata, and certificates back into Lovable. The workspace **owner** or **admin** can set up SSO. To start, go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → Add SSO provider**), then choose **OIDC** or **SAML**. ### IdP configuration reference When you start the SSO provider setup in Lovable, you see: * **What to configure in your IdP** (for example, app type, scopes, and attribute mappings) * **Lovable URLs and identifiers** you may need to enter in the IdP. Use the reference below while configuring OIDC or SAML in your IdP. * Application type: `Web Application` * Grant type: `Authorization Code` * Token method: `POST` (if configurable) * Redirect URI to copy and add to your IdP: `https://auth.lovable.dev/__/auth/handler` * OAuth scopes: * Required: `openid`, `email` * Recommended: `profile` * ACS URL (Assertion Consumer Service): `https://auth.lovable.dev/__/auth/handler` * SP Entity ID / Audience URI: `https://auth.lovable.dev/__/auth/handler` * IdP-initiated ACS URL (optional, see [Set up IdP-initiated sign-in (SAML)](#set-up-idp-initiated-sign-in-saml)): `https://api.lovable.dev/sso/saml/idp-consume` * Attribute mappings: * `email` (required): ensure the format is set to `EmailAddress` * `displayName` (recommended): map to user's full name * `photoURL` (recommended): map to user's profile picture URL ## Provider-specific setup guides If you use Okta, Auth0, or Microsoft Entra, you can find provider-specific documentation for setting up SSO. If you use another provider, see [Configure other providers](#configure-other-providers). Before you begin, complete [Start SSO setup in Lovable](#start-sso-setup-in-lovable) to get the settings and values you need to use in your IdP. For more information, refer to your IdP's official documentation. ### Configure Okta as your SSO provider * In the **Okta Admin Console**, go to **Applications → Browse App Catalog**. * Search for **Lovable**, then click **Add Integration**. * On the **General Settings** screen, set the **Application label** (for example, `Lovable OIDC`), then click **Next**. * On the **Sign-On Options** screen, select **OpenID Connect**. * Set **Application username format** to **Email**. * Click **Done**. In Okta, copy the following values from the **Sign On** tab and enter them in Lovable. * Okta `Issuer URL` → Lovable `OIDC Issuer URL/Discovery Endpoint` To find your issuer, click the **OpenID Provider Metadata** link on the **Sign On** tab. The issuer is your Okta domain, for example `https://your-org.okta.com`. * Okta `Client ID` → Lovable `OAuth Client ID/Application ID` * Okta `Client Secret` → Lovable `OAuth Client Secret` In Lovable, update these values as desired. The values are prepopulated based on your verified domain. * **Display name**: The name shown to users during authentication. * **SSO login identifier (tenant ID)**: The URL users will use to sign in directly with SSO. In Lovable, click **Test configuration**. If you configured everything accurately, the validation should be successful. In Lovable, click **Configure provider** to finish the configuration of Okta as your OIDC SSO provider. * In the **Okta Admin Console**, go to **Applications → Browse App Catalog**. * Search for **Lovable**, then click **Add Integration**. * On the **General Settings** screen, set the **Application label** (for example, `Lovable SAML`), then click **Next**. * On the **Sign-On Options** screen, select **SAML 2.0**. * Set **Application username format** to **Email**. * Click **Done**. The SAML settings (ACS URL and Audience URI) are pre-configured by the Lovable integration. You do not need to enter any SAML values manually in Okta. Because these settings cannot be changed, the catalog app does not support [IdP-initiated sign-in](#set-up-idp-initiated-sign-in-saml) yet. For now, users signing in through Okta must start sign-in from Lovable. In Lovable, choose between quick SAML provider setup or manual configuration: **Option 1: Quick setup - import from metadata URL** * In Okta, open the **Sign On** tab of the Lovable application, scroll to **Metadata details**, and copy the **Metadata URL**. * In Lovable, paste the metadata URL in **Quick setup: Import from Metadata URL** field. * Click **Test & Import** to automatically populate the required fields below. **Option 2: Manual configuration** Open the metadata URL in a new tab. Copy the following values and enter them in Lovable. * Okta `SingleSignOnService Location` → Lovable `SAML SSO Sign-on URL from your IdP` * Okta `EntityID` → Lovable `Identity Provider Entity ID / Issuer` * Okta `X509Certificate` → Lovable `X.509 Signing Certificate (public key)` Paste the certificate value between the `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` lines. In Lovable, update these values as desired. The values are prepopulated based on your verified domain. * **Display name**: The name shown to users during authentication. * **SSO login identifier (tenant ID)**: The URL users will use to sign in directly with SSO. In Lovable, click **Configure SAML Provider → Confirm & Enable SSO** to finish the configuration of Okta as your SAML SSO provider. ### Configure Auth0 as your SSO provider * Go to **Auth0 Admin Dashboard → Applications**. * Click **Create application**. Select the **Regular Web Applications** application type. * Give the app a name, for example `Lovable OIDC SSO`. * Click **Create**. * In Auth0, go to your application settings. * Add the **Allowed Callback URLs**: `https://auth.lovable.dev/__/auth/handler` * Click **Save**. In Auth0, copy the following values from the **Settings** tab and enter them in Lovable. * Auth0 `Domain` → Lovable `OIDC Issuer URL/Discovery Endpoint` (include `https://`) * Auth0 `Client ID` → Lovable `OAuth Client ID/Application ID` * Auth0 `Client Secret` → Lovable `OAuth Client Secret` In Lovable, update these values as desired. The values are prepopulated based on your verified domain. * **Display name**: The name shown to users during authentication. * **SSO login identifier (tenant ID)**: The URL users will use to sign in directly with SSO. In Lovable, click **Test configuration**. If you configured everything accurately, the validation should be successful. In Lovable, click **Configure provider** to finish the configuration of Auth0 as your OIDC SSO provider. * Go to **Auth0 Admin Dashboard → Applications.** * Click **Create application**. Select the **Regular Web Applications** application type. * Give the app a name, for example `Lovable SAML SSO`. * Click **Create**. * In Auth0, go to your application settings. * Add the **Allowed Callback URLs**: `https://auth.lovable.dev/__/auth/handler` * Click **Save**. * In Auth0, navigate to **Addons**, and enable **SAML2 Web app**. * In **Addon: SAML2 Web app → Settings**, set: * Application Callback URL: `https://auth.lovable.dev/__/auth/handler` * Settings: paste the following `mappings` JSON ```json theme={null} { "mappings": { "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" }, "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" } ``` * Click **Enable.** In Lovable, choose between quick SAML provider setup or manual configuration: **Option 1: Quick setup - import from metadata URL** * In **Auth0 → Addon: SAML2 Web app → Usage**, locate the **Identity Provider Metadata**, and click the arrow icon to get the URL. * In Lovable, paste the metadata URL in **Quick setup: Import from Metadata URL** field. * Click **Test & Import** to automatically populate the required fields below. **Option 2: Manual configuration** In **Auth0 → Addon: SAML2 Web app → Usage**, copy the following **SAML Protocol Configuration Parameter** values and enter them in Lovable. * Auth0 `Identity Provider Login URL` → Lovable `SAML SSO Sign-on URL from your IdP` * Auth0 `Issuer` → Lovable `Identity Provider Entity ID / Issuer` * Auth0 `Identity Provider Certificate` (`X509Certificate`) → Lovable `X.509 Signing Certificate (public key)` Download Auth0 certificate and copy the `X509Certificate` value. Paste the certificate value between the `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` lines. In Lovable, update these values as desired. The values are prepopulated based on your verified domain. * **Display name**: The name shown to users during authentication. * **SSO login identifier (tenant ID)**: The URL users will use to sign in directly with SSO. In Lovable, click **Configure SAML Provider → Confirm & Enable SSO** to finish the configuration of Auth0 as your SAML SSO provider. ### Configure Microsoft Entra ID as your SSO provider * Go to **Microsoft Entra admin center → App registrations → New registration**. * Give the app a name, for example `Lovable OIDC SSO`. * Configure **Redirect URI**: * Select **Platform** as `Web`. * Paste the redirect URL `https://auth.lovable.dev/__/auth/handler` and click **Save**. * Click **Register**. * In Microsoft Entra, go to **Token configuration → Add optional claim**. * Select **ID token** and add the `email` claim. * Click **Add**. * In Microsoft Entra, go to **API permissions → Add a permission → Microsoft Graph**. * Select **Delegated permissions** and add: * `email` * `openid` * `profile` * Click **Add permissions**. In Lovable, enter the following: * `OIDC Issuer URL/Discovery Endpoint`: format the URL as `https://login.microsoftonline.com/{TENANT_ID}/v2.0` Replace the `{TENANT_ID}` with the **Directory (tenant) ID** from the **Overview** page in Microsoft Entra. In Microsoft Entra, copy the **client ID** value from the **Overview** page and enter it in Lovable. * Microsoft Entra `Application (Client) ID` → Lovable `OAuth Client ID/Application ID` In Microsoft Entra, configure the **client secret** and enter it in Lovable. * Go to **Certificates & secrets → New client secret.** * Create a secret, and copy the secret value immediately (it won't be shown again). * Paste the Microsoft Entra `Client secret` → Lovable `OAuth Client Secret` In Lovable, update these values as desired. The values are prepopulated based on your verified domain. * **Display name**: The name shown to users during authentication. * **SSO login identifier (tenant ID)**: The URL users will use to sign in directly with SSO. In Lovable, click **Test configuration**. If you configured everything accurately, the validation should be successful. In Lovable, click **Configure provider** to finish the configuration of Microsoft Entra ID as your OIDC SSO provider. * Go to **Microsoft Entra ID admin center → Enterprise applications**, and select **New application**. * Select **Create your own application** and choose **Integrate any other application you don’t find in the gallery (Non-gallery)**. * Give the app a name, for example `Lovable SAML SSO`. * Click **Create**. Your application is now created. In Microsoft Entra, navigate to the **Single sign-on** setup page and select **SAML**. Under **Basic SAML Configuration**, enter the following: * Identifier (Entity ID): `https://auth.lovable.dev/__/auth/handler` * Reply URL (Assertion Consumer Service URL): `https://auth.lovable.dev/__/auth/handler` Leave the other values blank and select **Save**. To let users sign in to Lovable from the Microsoft **My Apps** portal, add a second **Reply URL (Assertion Consumer Service URL)**: `https://api.lovable.dev/sso/saml/idp-consume`, and select it as the **Default** reply URL. See [Set up IdP-initiated sign-in (SAML)](#set-up-idp-initiated-sign-in-saml) for requirements. When the application is set up in Microsoft Entra, you can choose between quick SAML provider setup or manual configuration in Lovable. **Option 1: Quick setup - import from metadata URL** * In Microsoft Entra, go to **SAML Certificates** and copy the **App Federation Metadata URL**. * In Lovable, paste the **App Federation Metadata URL** in **Quick setup: Import from Metadata URL** field. * Click **Test & Import** to automatically populate the required fields below. **Option 2: Manual configuration** Copy the following values in Microsoft Entra and enter them in Lovable. * Microsoft Entra `Login URL` → Lovable `SAML SSO Sign-on URL from your IdP` * Microsoft Entra `Microsoft Entra Identifier` → Lovable `Identity Provider Entity ID / Issuer` * Microsoft Entra `X509Certificate` → Lovable `X.509 Signing Certificate (public key)` You can download the certificate (Base 64) or open the `App Federation Metadata URL` in a new tab and copy the `X509Certificate` value. Paste the certificate value between the `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` lines. In Lovable, update these values as desired. The values are prepopulated based on your verified domain. * **Display name**: The name shown to users during authentication. * **SSO login identifier (tenant ID)**: The URL users will use to sign in directly with SSO. In Lovable, click **Configure SAML Provider → Confirm & Enable SSO** to finish the configuration of Microsoft Entra ID as your SAML SSO provider. ## Configure other providers You can configure any OIDC or SAML-compliant provider with Lovable SSO. Before you begin, complete [Start SSO setup in Lovable](#start-sso-setup-in-lovable) to get the settings and values you need to use in your IdP. **Provider mapping** Common field names across providers: * Redirect URI: `Callback URL`, `Sign-in redirect URI` * Issuer/Domain: `Issuer URL`, `Authority`, `Okta domain`, `Auth0 domain`, `Tenant domain` * Client credentials: `Client ID` and `Client Secret` **Steps** Create a new OIDC Web application in your identity provider. In Redirect/Callback URLs, add `https://auth.lovable.dev/__/auth/handler` Ensure `openid` and `email` scopes are enabled and consented if needed. In your IdP, locate the corresponding values and enter them in Lovable: * `Domain` or `Issuer URL` → Lovable `OIDC Issuer URL/Discovery Endpoint` * `Client ID` → Lovable `OAuth Client ID/Application ID` * `Client Secret` → Lovable `OAuth Client Secret` In Lovable, update these values as desired. The values are prepopulated based on your verified domain. * **Display name**: The name shown to users during authentication. * **SSO login identifier (tenant ID)**: The URL users will use to sign in directly with SSO. **Provider mapping** Common field names across providers: * ACS URL: `Single Sign-On URL`, `SSO URL`, `Reply URL`, `Assertion Consumer Service URL` * Audience: `SP Entity ID`, `Audience URI`, `Identifier` * Attribute mapping: `Attribute Statements`, `User Attributes & Claims` **Steps** Create a new SAML 2.0 application in your provider. * ACS URL: `https://auth.lovable.dev/__/auth/handler` * Audience / Entity ID: `https://auth.lovable.dev/__/auth/handler` Ensure `email` is included in the SAML assertion. `displayName` is optional. Assign the application to users/groups who should access Lovable. In Lovable, choose between quick SAML provider setup or manual configuration: **Option 1: Quick setup - import from metadata URL** * In your IdP, locate your SAML metadata URL (typically found in the SAML application settings or metadata details) * In Lovable, paste the metadata URL in **Quick setup: Import from Metadata URL** field. * Click **Test & Import** to automatically populate the required fields below. **Option 2: Manual configuration** In your IdP, locate the corresponding values and enter them in Lovable: * `Login URL` → Lovable `SAML SSO Sign-on URL from your IdP` * `Identifier/Issuer/Entity ID` → Lovable `Identity Provider Entity ID / Issuer` * `X509Certificate` → Lovable `X.509 Signing Certificate (public key)` In Lovable, update these values as desired. The values are prepopulated based on your verified domain. * **Display name**: The name shown to users during authentication. * **SSO login identifier (tenant ID)**: The URL users will use to sign in directly with SSO. ## Set up IdP-initiated sign-in (SAML) With **IdP-initiated SSO**, users start sign-in from your identity provider's app portal (for example, an Okta dashboard tile or the Microsoft **My Apps** portal) instead of from Lovable. IdP-initiated sign-in is **optional** and available for **SAML** providers on **Business** and **Enterprise** plans. It requires no additional configuration in Lovable. SP-initiated sign-in from Lovable keeps working as long as your IdP app still accepts the standard ACS URL (`https://auth.lovable.dev/__/auth/handler`); if your provider has only one ACS URL field, use a dedicated app for IdP-initiated sign-in so both flows keep working. ### Requirements * A configured **SAML** SSO provider. OIDC providers support SP-initiated sign-in only. * Your workspace is the **only** workspace that has verified your email domain. IdP-initiated sign-in is disabled automatically while another workspace has the same domain verified. * Your IdP **signs** the SAML response (or the assertion within it) and scopes it to the Lovable SP Entity ID (`https://auth.lovable.dev/__/auth/handler`) through an Audience Restriction. When a requirement is not met (for example, a second workspace verifies the same email domain), IdP-initiated sign-in stops working and users see an error page such as `Forbidden` or `Unauthorized`. Sign-in from Lovable is not affected, and you can switch back to SP-initiated sign-in only at any time. See [Troubleshooting](#troubleshooting). ### Enable IdP-initiated sign-in Configure your SAML app (or a dedicated IdP-initiated app) to post the SAML response to the IdP-initiated ACS URL: `https://api.lovable.dev/sso/saml/idp-consume` Keep the SP Entity ID / Audience URI unchanged: `https://auth.lovable.dev/__/auth/handler`. The Lovable app in the Okta App Catalog does not support IdP-initiated sign-in yet. Its SAML settings are pre-configured and cannot be changed. For now, users signing in through Okta must start sign-in from Lovable. * In your Lovable SAML enterprise application, go to **Single sign-on → Basic SAML Configuration**. * Add `https://api.lovable.dev/sso/saml/idp-consume` as an additional **Reply URL (Assertion Consumer Service URL)** and select it as the **Default** reply URL. Microsoft Entra sends IdP-initiated responses to the default reply URL. * Keep the **Identifier (Entity ID)** as `https://auth.lovable.dev/__/auth/handler`, and select **Save**. * Users can now sign in to Lovable from the **My Apps** portal. * In your SAML application, set the ACS URL used for IdP-initiated sign-in to `https://api.lovable.dev/sso/saml/idp-consume`. Providers also call this field **Single sign-on URL**, **Reply URL**, or **Assertion Consumer Service URL**. In Auth0, it is the **Application Callback URL** in the **SAML2 Web App** addon; the addon has a single callback URL, so create a dedicated Auth0 application for IdP-initiated sign-in. * Keep the Audience / Entity ID as `https://auth.lovable.dev/__/auth/handler`. * Make sure your provider signs SAML responses or assertions. IdP-initiated sign-in is optional. If it does not work for your setup, point your SAML app back to `https://auth.lovable.dev/__/auth/handler`. This disables IdP-initiated sign-in, and users sign in from Lovable as usual. See [Troubleshooting](#troubleshooting). ## Map IdP groups to workspace roles You can map the groups your identity provider sends in its sign-in claims to Lovable workspace roles, so people land at the right role automatically, and optionally restrict SSO sign-in to mapped groups only. Mappings can also add members to your workspace [groups](/features/groups); see [Add members to workspace groups automatically](#add-members-to-workspace-groups-automatically). Group mappings work with both OIDC and SAML providers on **Business** and **Enterprise** plans. To manage group mappings, go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**), click your SSO provider, and open the **Groups** tab. There you can: * **Map an IdP group to a workspace role.** Enter the group name as your IdP sends it and choose a role (viewer, editor, or admin). Users whose sign-in includes a matching group claim get that role when they join. Matching between claims and mappings is case-insensitive, and if several mapped groups match, the highest-privilege role wins. A group mapping can never grant the **owner** role. * **Turn on Group restriction.** With the toggle off, matched users get their group's role and everyone else signs in with the provider's default JIT role. With the toggle on, only users whose IdP group matches one of your mappings can sign in through the provider; everyone else is denied. Your IdP must include group information in its sign-in claims for mappings to match. See [Send group claims from your IdP](#send-group-claims-from-your-idp). Role mapping and group membership sync also require [SSO sign-in (JIT) provisioning](/features/workspace-identity#sso-sign-in) to be enabled. With JIT disabled, matched users sign in without receiving a mapped role or group membership; **Group restriction** still applies either way. ### Add members to workspace groups automatically Group mappings also provision group membership. When a user signs in through SSO with a group claim that matches a mapping, and your workspace has a [group](/features/groups) with the same name as that mapping, Lovable adds the user to that group. * **Groups are matched by name.** The mapping name must match the Lovable group name exactly, including capitalization. In the **Groups** tab, your existing workspace groups appear as suggestions, so you can add mappings that match them exactly. * **No matching group means no membership.** If your workspace has no group with the same name, the mapping is used for role provisioning only: matching users still get the mapped role, but no group membership is created. * **Lovable never creates groups from claims.** Groups control access to projects, folders, and published apps, so creating them stays a deliberate admin action. To sync membership for a group, first create it in [Groups](https://lovable.dev/settings/groups) (**Settings → Access → Groups**), then add a mapping with the same name. * **Membership is only added, never removed.** Lovable does not remove anyone from a group based on sign-in claims; remove members from groups manually if needed. To manage the full group lifecycle from your IdP, including removals, use [SCIM provisioning](/features/business/scim) on the **Enterprise** plan. ### Send group claims from your IdP Lovable reads groups from a claim named `groups` in the sign-in response, for both OIDC and SAML providers. The default SAML group claim names used by Microsoft Entra ID (`http://schemas.microsoft.com/ws/2008/06/identity/claims/groups`) and AD FS (`http://schemas.xmlsoap.org/claims/Group`) are also recognized, so you can keep those defaults. The claim must contain group **names**, not group IDs. Send names as multiple attribute values, or as a single value separated by commas or semicolons. Configure the group claim on your Lovable app in the **Okta Admin Console**. **SAML** Where the group attribute is configured depends on how you added the Lovable app: * **App Catalog app**: the app's SAML settings are pre-configured and cannot be edited. Open the app's **Sign On** tab and look for a **Group Attribute Statements** section there. If the app doesn't offer one, it cannot send group claims: use the Lovable OIDC app instead, or create a custom SAML app following [Configure other providers](#configure-other-providers). * **Custom SAML app**: open the app's **General** tab and click **Edit** under **SAML Settings**. Add a group attribute statement with: * Name: `groups` * Name format: `Unspecified` * Filter: a filter matching the groups to send, for example **Matches regex** `.*` to send all of the user's groups. Save your changes. **OIDC** * Open your Lovable OIDC app and go to the **Sign On** tab. * Under **OpenID Connect ID Token**, click **Edit** and set **Groups claim type** to **Filter**. * Set the groups claim name to `groups` with a filter matching the groups to send, for example **Matches regex** `.*`. * Save your changes. Okta sends group names in the claim, so values match your mappings as long as the names line up. * In your Lovable enterprise application, go to **Single sign-on → Attributes & Claims → Edit**. * Click **Add a group claim**. * Choose which groups to include. **Groups assigned to the application** is recommended: it sends only the groups assigned to the Lovable app and avoids token size limits. * Set **Source attribute** to an option that emits group **names**, such as **Cloud-only group display names**, or `sAMAccountName` for groups synced from on-premises Active Directory. * Save the claim. You can keep the default claim name: Lovable recognizes Microsoft Entra's default group claim. By default, Microsoft Entra ID sends group **object IDs** (GUIDs) instead of names. Object IDs never match name-based mappings, so make sure the claim's source attribute emits group names. * In your SAML or OIDC application, include a group attribute or claim named `groups` in the sign-in response. * Make sure the values are group **names** (not IDs) and cover the groups you mapped in Lovable. ## Delete an SSO provider To remove your workspace SSO provider, go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**), find the provider, and click **Delete**. Because a workspace can only have one SSO provider, deleting it retires the whole SSO setup. Lovable shows a **Delete SSO provider** confirmation dialog that lists exactly what will be turned off, based on what your workspace currently has configured: * **Turn off Enforce SSO**: members can sign in again with email/password or third-party login. * **Remove SCIM provisioning**: the SCIM API key is revoked and SCIM-managed groups are deleted. Existing workspace members are not removed. See [Set up SCIM user provisioning](/features/business/scim). * **Disable the domain lock**: people with emails on your [verified domains](/features/verified-domains) can sign up without SSO again. * **Delete IdP group role mappings**: IdP groups will no longer grant workspace roles when users sign in. The dialog shows a line for each of these only when it applies to your workspace, along with the number of IdP group role mappings that will be removed. Deleting a provider cannot be undone. To use SSO again, you need to reconfigure the provider from scratch; its previous configuration is not retained. Members keep their workspace access after the provider is deleted. Members whose **only** sign-in method was that provider can recover their account themselves at the next sign-in; see [Recover access after an SSO provider is removed](#recover-access-after-an-sso-provider-is-removed). Each side effect is recorded in the [audit log](/features/audit-logs): both the `SSO provider removed` entry (with the exact settings that were turned off) and, when SCIM was configured, a separate `SCIM disabled` entry. ## Troubleshooting Ensure the redirect/callback URL exactly matches `https://auth.lovable.dev/__/auth/handler` in your IdP. Use the provider's OIDC Issuer URL (not just the domain). * For Okta, copy from the **Sign-on** tab * For Auth0, use your tenant domain. Grant the `email` scope and ensure the user account has a primary email. Use `Authorization Code` with a confidential client and client secret. Avoid implicit or PKCE-only app types. Ensure both ACS and Audience/Entity ID exactly match `https://auth.lovable.dev/__/auth/handler` in your IdP. Make sure to map an email claim. For Microsoft Entra ID, map `email` to `user.mail`. If `user.mail` is empty, use `user.userprincipalname`. Paste the correct `X.509` certificate. If the certificate rotates, update it in Lovable. If users get the default role instead of their mapped role, or **Group restriction** denies people it shouldn't: * Make sure the assertion includes a group attribute named `groups` (Microsoft Entra ID's and AD FS's default group claim names also work). See [Send group claims from your IdP](#send-group-claims-from-your-idp). * Make sure the claim contains group **names**, not IDs. Microsoft Entra ID sends object IDs unless the group claim's source attribute is set to emit names. * Claim matching is case-insensitive, but the names must otherwise match your mappings exactly. * Make sure [SSO sign-in (JIT) provisioning](/features/workspace-identity#sso-sign-in) is enabled. With it disabled, users sign in without receiving mapped roles or group memberships. If starting sign-in from your IdP's app portal shows an error page (for example, `Forbidden` or `Unauthorized`): * Make sure your email domain is verified in **only one** Lovable workspace. IdP-initiated sign-in is disabled automatically while more than one workspace has verified the same domain. * Make sure your IdP signs the SAML response (or the assertion within it) and the Audience Restriction matches `https://auth.lovable.dev/__/auth/handler`. * If your provider restricts access by group, make sure the user's SAML assertion includes a matching group claim. This also applies when signing in from Lovable. * If sign-in still fails, change the ACS URL in your IdP app back to `https://auth.lovable.dev/__/auth/handler`. This disables IdP-initiated sign-in and restores SP-initiated sign-in from Lovable. IdP-initiated sign-in is optional, so you can stay on SP-initiated sign-in only and try again once the requirements are met. Workspace members who only ever signed in through the deleted SSO provider can recover access themselves from the standard Lovable login page, with no admin action or support request required. When they enter their email on the login page, Lovable detects that their only sign-in method was the removed provider and shows a recovery panel: * **If the workspace has a replacement SSO provider on the same verified domain,** the panel shows **Reconnect your account** with a sign-in button for the new provider. Clicking it signs the user in with that provider and links the new identity to their existing account, so their projects, roles, and history are preserved. If linking cannot happen automatically (for example, the new provider does not verify the same email), the panel falls back to the password path below. * **If there is no replacement SSO provider,** the panel shows **Set a password for your account** and offers to email a link. The user opens the link, sets a password, and signs in with email + password from then on. This uses the same mechanism as a normal password reset, framed as adding a password because the old SSO sign-in was removed. Users with any other working sign-in method (password, Google, GitHub, Apple, or another still-valid SSO provider) are not affected and continue to sign in normally. ## FAQ If you created your account using another login method (like email/password, Google, or GitHub), you need to log in that way **first**. Once you're logged in, navigate to **Settings → Your account → Link SSO**. This will link your existing account to your company SSO. **Important:** If you attempt to log in with SSO before linking your existing account, you'll see an error. This is a security measure to prevent unauthorized access. Log in using your original method first to complete the linking process. No. **Forgot password?** only works for accounts that have an email and password sign-in method. If your account signs in through **Google**, **GitHub**, **Apple**, or a **SAML/OIDC SSO** provider, Lovable does not send a password reset email and shows a **Password reset unavailable** message, because completing a reset would add a password to an account that is meant to sign in through your provider. Reset your credentials with your identity provider instead (for example, [Google Account recovery](https://accounts.google.com) or your company IdP). **Exception for deleted SSO providers:** if your only sign-in method was an SSO provider that has since been removed from your workspace, you can set a password for the first time through the recovery flow on the login page. See [Recover access after an SSO provider is removed](#recover-access-after-an-sso-provider-is-removed). Lovable supports the industry-standard OIDC and SAML protocols, so you can integrate with any SSO provider that supports them. No. A workspace can have **one active SSO provider** configured at a time. Yes. The workspace **owner** or **admin** can enable **Enforce SSO** in [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**) and choose the **session duration** to configure how long users stay signed in before requiring re-authentication (8 hours, 24 hours, 48 hours, or 7 days). This requires all workspace members to use SSO for authentication. External collaborators and invite links will be disabled. Yes. **SAML** providers can optionally enable IdP-initiated sign-in: users start sign-in from your IdP's app portal once your SAML app posts the SAML response to `https://api.lovable.dev/sso/saml/idp-consume`. It only works while your workspace is the only workspace that has verified your email domain, and SP-initiated sign-in from Lovable keeps working either way. See [Set up IdP-initiated sign-in (SAML)](#set-up-idp-initiated-sign-in-saml). OIDC providers support **SP-initiated sign-in only**: users must start sign-in from Lovable. An error page such as `Forbidden` or `Unauthorized` means the [requirements](#set-up-idp-initiated-sign-in-saml) are not met. First, make sure your email domain is verified in **only one** Lovable workspace. IdP-initiated sign-in is disabled automatically while more than one workspace has verified the same domain. If sign-in still fails, change the ACS URL in your IdP app back to `https://auth.lovable.dev/__/auth/handler`. IdP-initiated sign-in is optional: users sign in from Lovable as usual, and you can try again once the requirements are met. Yes, Lovable supports **JIT (just-in-time) provisioning** through SSO. User accounts are created automatically the first time someone signs in via SSO, and they’re added to your company workspace. You can also set a **default role for JIT-created users** (admin, editor, or viewer) that will be applied when they join via SSO for the first time. On **Enterprise** plans, workspace owners and admins can toggle SSO JIT themselves from the **SSO sign-in** row in [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → User provisioning**). The toggle appears once an SSO provider is configured. On **Business** plans, SSO JIT is automatically enabled when an SSO provider is configured, and the row shows a read-only **Enabled** or **Disabled** status. Contact Lovable support if you need it changed. See [Manage workspace identity and user provisioning](/features/workspace-identity) for how the provisioning options work together. Existing members keep their current role. Group-to-role mappings are applied when someone joins the workspace through SSO; if several mapped groups match, the highest-privilege role wins. On each SSO sign-in, members are also added to any [workspace groups](/features/groups) whose names match their IdP group claims. Lovable never removes anyone from a group automatically; remove members from groups manually if needed. Turning on **Group restriction** does affect existing members: anyone signing in through the provider without a matching group claim is denied, so make sure your mappings cover everyone who should keep access. See [Map IdP groups to workspace roles](#map-idp-groups-to-workspace-roles). No. Group claims never create groups in Lovable; they are used for provisioning only. If a mapping matches but your workspace has no [group](/features/groups) with the same name, matching users still get the mapped role, but no group membership is created. To sync membership, create the group in [Groups](https://lovable.dev/settings/groups) (**Settings → Access → Groups**) first, using the same name as your mapping. Lovable then adds matching users to it when they sign in through SSO. See [Add members to workspace groups automatically](#add-members-to-workspace-groups-automatically). Yes. Lovable supports **SCIM provisioning** for automated user provisioning and deprovisioning on the **Enterprise plan**. With SCIM, user creation, removal, and role assignment are managed centrally from your identity provider based on assignments and group membership. See [Set up SCIM user provisioning](/features/business/scim) for more information. Your tenant ID is the `{tenantId}` value used in your **SSO login URL**:\ `https://lovable.dev/sso-login/{tenantId}`. It matches the **SSO login identifier** you configured when setting up your SSO provider in Lovable. You can also find it in [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**) after you have configured your provider. You can change a provider's **display name**, **SSO login identifier**, and **JIT default role** at any time by clicking the provider in [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**). Credentials and protocol settings (issuer, client ID and secret, certificates) cannot be edited. To change those, delete the existing SSO provider and configure it again. Deleting the provider also turns off Enforce SSO, removes SCIM provisioning (revoking the SCIM API key and deleting SCIM-managed groups), disables the verified-domain lock, and deletes any IdP group role mappings. The delete dialog lists exactly which of these apply before you confirm. See [Delete an SSO provider](#delete-an-sso-provider). They keep their workspace access and can recover their account themselves from the login page: either by signing in through a replacement SSO provider (Lovable links the new identity to their existing account) or by setting a password through an emailed link. See [Recover access after an SSO provider is removed](#recover-access-after-an-sso-provider-is-removed). # Lovable Cloud Source: https://docs.lovable.dev/features/cloud Lovable Cloud is a full-stack hosting platform with built-in database, authentication, storage, edge functions, and AI, no infrastructure setup required. Lovable Cloud is a full-stack cloud platform that takes care of every part of your application, from the frontend your users see to the backend that powers it behind the scenes. Describe what you want directly in Lovable, and Lovable generates both the frontend and backend, ready to run in the Cloud. Instead of managing hardware or complex infrastructure, you get on-demand access to hosting, compute, and storage that scale automatically as your app grows. Lovable Cloud utilizes Supabase's open-source foundation, which means you get a production-ready environment from day one, without needing to set up Supabase separately: a database, real-time updates, user authentication, and storage, with none of the manual setup steps. Across the docs, this is called the **built-in backend (Cloud)**, as opposed to an external backend you connect yourself, such as [Supabase](/integrations/supabase). ## Why choose Lovable Cloud Three things make Cloud the default choice for most projects: * **Scales as you grow**: From your first prototype to millions of users, Lovable scales seamlessly with your needs. * **Secure by default**: Enterprise-grade authentication, fine-grained access controls, and compliance best practices protect your app and data. * **Cost-effective**: Manage multiple projects in one workspace with credit-based usage. Lovable includes monthly Cloud grants on Free, Pro, and Business plans. For details, see [Credits and usage](/introduction/credits-and-usage). ## What's included You'll find the **Cloud** tools inside any Lovable project by opening the [**More** tab](/features/projects/editor#the-more-menu) in the project toolbar and selecting **Cloud**. Each area has its own page with full details, in the order they appear in the Cloud view: | Area | What you can do | | ------------------------------------------------ | ------------------------------------------------------------------------ | | [AI](/features/ai) | Add AI features to your app with built-in Lovable AI | | [Emails](/features/custom-emails) | Send branded emails from your own domain | | [Database](/features/database) | View tables, edit records, review security policies, and restore backups | | [Users](/features/authentication) | Manage app users and configure sign-in methods | | [Storage](/features/storage) | Create buckets and manage the files your app stores | | [Secrets](/features/secrets) | Store API keys and other sensitive values securely | | [Jobs](/features/jobs) | Review scheduled background tasks and their run history | | [Edge functions](/features/edge-functions) | Run serverless backend code and monitor how it performs | | [SQL editor](/features/database#run-sql-queries) | Run SQL queries and commands against your database | | [Logs](/features/logs) | Debug errors and track backend activity | | [Usage](/features/usage-and-costs) | See what drives the project's run credit usage | | [Advanced settings](/features/advanced-settings) | Resize the instance, export data, and pause or remove Cloud | ## Enabling Lovable Cloud By default, Lovable Cloud is enabled for your workspace. When a feature you ask for requires backend functionality (for example, authentication or file storage), Lovable enables Cloud automatically or asks for your approval in chat first, depending on the **Enable Cloud** permission described below. On some Enterprise workspaces, Lovable Cloud is disabled at the workspace level, and projects show "Lovable Cloud has been disabled by your workspace admin". This setting is not self-serve; contact your Lovable account team to change it. ### Cloud permissions Each Cloud tool has three permission options: * **Always allow**: Lovable automatically performs the action, without asking for review or approval. This is the default for Cloud. * **Ask each time**: Lovable asks for your approval whenever the action is needed. * **Never allow**: Lovable blocks the action, informs you that Cloud access is required, and instructs you to enable Cloud. ### Tool settings and defaults | Setting | Description | Default behavior | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------- | | Enable Cloud | Create and connect a Cloud project to add backend features (database, auth, storage). Required to use Cloud tools. | Always allow | | Where projects are hosted | Select the default region (Closest to me, Americas, Europe, or Asia Pacific) where new projects are hosted. If Cloud is auto-enabled using Always allow, this region is used automatically. | Region closest to your location | | Read database | Allow Lovable to read your database. | Always allow | | Read analytics | Query logs to investigate issues and behavior. | Always allow | | Run security checks | Run automated security checks on your database. Not a full audit. | Always allow | | Modify database | Make schema and policy changes via SQL migrations. Updates generated types. | Always allow | | Add data | Add data to your database tables. | Always allow | | Read project info | Read project configuration and environment details. | Always allow | | Configure auth | Allow Lovable to configure authentication settings (for example, signup policies). | Always allow | | Read backend logs | Read logs from backend services. | Always allow | You can change your Cloud tool preferences anytime: open **Connectors**, select **Cloud**, and adjust the settings under **Manage my agent's permissions**. ### Region selection Lovable Cloud projects can be hosted in three regions: * Americas * Europe * Asia Pacific You can set a preferred default region for new Cloud projects under **Where projects are hosted** in the same permissions view. If no preferred region is set, Lovable automatically preselects the region closest to your current location, and you can change it before confirming. Choosing a region closer to your users results in: * Lower latency * Faster database responses * Region-based data hosting * Better overall backend performance After Cloud is enabled, you cannot change the selected region, and you cannot move existing projects between regions. To see which region an existing project is hosted in, go to **Cloud tab → Overview → Advanced settings → General → Project location**. ### Workspace-level default hosting region On **Business** and **Enterprise** workspaces, admins can set a required default region for every new Lovable Cloud project from [Privacy & security](https://lovable.dev/settings/privacy-security) (**Settings → Security → Privacy & security → Default hosting region**). When a default hosting region is set, workspace members cannot choose a different region when creating a project. The setting applies only to new projects. Existing projects keep the region they were created in. **Country-specific regions** (for example, Germany, Japan, or United States East) are available on Enterprise plans by request. Contact your Lovable account team to enable them for your workspace. See [Default hosting region](/features/privacy-and-security-settings#default-hosting-region) for more information. ## Tutorial: build a CRM by prompting This walkthrough builds a real app, a customer relationship manager (CRM), entirely by prompting. Each step introduces one backend capability and shows the kind of prompt that activates it. ```text wrap theme={null} Build me a CRM tool to manage clients, track deals, handle invoices, and keep notes organized. Keep the design simple, modern, and business-friendly with a sidebar for navigation. ``` ### Step 1: Organize the data (Database) Tell Lovable what kind of information the tool should keep track of for you. Lovable will automatically create the tables for you, so you don't need to touch databases yourself. ```text wrap theme={null} I want a place to keep track of my clients with their name, email, phone number, and notes. I also need a way to track deals, including which client it's for, the value, the stage it's in, and when I expect it to close. And I need a section for invoices with the client it belongs to, the amount, the status, and the due date. ``` ### Step 2: Make it secure (Users & Auth) Add login so data is private and users can sign in easily. ```text wrap theme={null} Add login to the app. Require login before accessing the CRM dashboard. Also, add a 'Sign in with Google' button so users can log in with their Google accounts. ``` ### Step 3: Handle files (Storage) You can let users upload and see files right inside the app. Lovable takes care of the storage and linking, so you just describe what files should go where. ```text wrap theme={null} Add a contract upload field to each deal. Let clients have profile pictures and display them on the client detail page. Upload invoice PDFs and show a download link on the invoices table. ``` ### Step 4: Automate workflows (Edge Functions and Jobs) Set up automatic actions that save you time. Prompt one automation at a time so each one is set up and tested properly: ```text wrap theme={null} When a new lead is added to the Clients table, send me an email notification. ``` ```text wrap theme={null} Analyze client meeting notes with Lovable AI and save a sentiment score in the Clients table. ``` ```text wrap theme={null} Schedule a daily job at 7 AM that emails me a summary of today's follow-ups. ``` ```text wrap theme={null} When a payment is marked 'paid' in Stripe, automatically update the related invoice's status to 'Paid'. ``` Sending emails from your app requires an email domain you own. See [Custom emails](/features/custom-emails) for setup. ### Step 5: Connect to other tools (Secrets) Services like Stripe or Resend give you private API keys. Lovable prompts you to add them securely whenever they're needed, and only your app can use them. Tools that sign in with an account instead of a key, such as Google services, connect through [Connectors](/integrations/introduction). ```text wrap theme={null} Connect Stripe so clients can pay invoices online. Ask me for any API keys you need. ``` ### Step 6: Add AI superpowers (AI) Make the tool act like your assistant. ```text wrap theme={null} Summarize each client's meeting notes and save them to their profile. Suggest next steps for every open deal. Generate personalized email drafts for following up with leads. Classify client messages into categories: sales, support, or billing. ``` ## Cloud and AI gateway usage costs Lovable uses one credit balance for building your app, hosting and running it with Lovable Cloud, and AI features in deployed apps. Cloud and AI gateway usage is measured as part of **Run credits**. See [Usage and costs](/features/usage-and-costs) for the per-project usage breakdown and monthly grants, and [Credits and usage](/introduction/credits-and-usage) for how credits work across your workspace. ## FAQ Don't worry, nothing changes for your existing projects. Your Supabase integration will continue to work exactly as it does today, and we will continue to support it. * For existing projects: continue using Supabase with no changes. * For new projects: choose either Lovable Cloud or Supabase. Yes. If you no longer want a project to use Lovable Cloud, go to **Cloud tab → Overview → Advanced settings** and use [Remove Lovable Cloud](/features/advanced-settings#remove-lovable-cloud). This permanently deletes your Cloud instance and cannot be undone. Export your database and download any storage files you need before continuing. Yes, Cloud projects can be remixed to Cloud projects only. This creates a copy of your project that you can edit separately in your currently selected workspace. The structure of backend-related data, such as tables and Edge Functions, is copied over without any information. For any automatically generated keys in the original project, Lovable generates fresh keys in the remixed project. Manually added keys are not copied over. When remixing, you can select which region to host the new project's backend (Americas, Europe, or Asia Pacific). Lovable preselects the region closest to you based on your location. Once selected, the region cannot be changed for that project. Keep in mind that in a remixed Cloud project you can't [revert](/features/projects/history) to versions from before the remix. Versions created after the remix revert normally. At the moment, migration from Supabase to Cloud is not supported. If your project is already connected to Supabase, we recommend continuing to use it, as we will keep supporting Supabase moving forward. Yes. You can set a preferred default region for new Cloud projects: open **Connectors**, select **Cloud**, and choose a region under **Where projects are hosted**. On **Business and Enterprise** workspaces, admins can also set a required default region for every new Lovable Cloud project from [Privacy & security](https://lovable.dev/settings/privacy-security) (**Settings → Security → Privacy & security → Default hosting region**). When this workspace-level default is set, members cannot choose a different region when creating a project. See [Default hosting region](/features/privacy-and-security-settings#default-hosting-region) for more information. If your workspace has a required default hosting region (available on Business and Enterprise), Lovable uses that region automatically and members cannot change it when creating a project. If your workspace does not have a required default hosting region, Lovable automatically preselects the region closest to your current location, but you can change it before confirming. No. Once Cloud is enabled for a project, the selected region is locked and cannot be changed. Existing projects cannot be moved across regions. # View and edit your project's code Source: https://docs.lovable.dev/features/code-mode Open the code editor in Lovable to browse and search your app's source code, make manual edits, reference exact lines in chat, and download your codebase. Everything Lovable builds is real, standard code, and the **code editor** is where you see it. Open it with the **Code** tab in the [project toolbar](/features/projects/editor#project-toolbar) to browse your project's files, make manual edits, point Lovable at exact files and lines from chat, or download your code. You never need the code editor to build with Lovable. It's there for when you want to see exactly what Lovable built, make a quick manual tweak, or work alongside a developer. ## Browse and search your files The left panel shows your project's file structure. Click a folder to expand or collapse it, or use the **Expand all** and **Collapse all** buttons at the top of the panel. Files you open appear as tabs at the top of the code area, so you can keep several open, drag them into a different order, and close them when you're done. Right-click any file or folder for its menu: * **Open**: Open the file in the editor. * **Reference in chat**: Add the file to the chat input as a reference, so your next message points Lovable at it. To find something across your project, use the **Search code** box at the top of the file panel, or press **Cmd+Shift+F** (Mac) or **Ctrl+Shift+F** (Windows/Linux). Results are grouped into **Files** (matching file names) and **In files** (matching content). To find text inside the open file, press **Cmd+F** (Mac) or **Ctrl+F** (Windows/Linux). On paid plans, the same panel also lets you replace text. ## View a file While reading a file, the toolbar above it gives you: * **Preview markdown**: For `.md` and `.markdown` files, click the eye icon to switch between the raw source and rendered text. The preview supports common Markdown formatting, including tables, task lists, links, and code blocks, which makes READMEs and docs easy to read without leaving the editor. * **Copy file content**: Copy the whole file to your clipboard. * **Download**: Save the open file to your computer. Available to everyone with project access. ## Edit code Code editing is available on paid plans. On the Free plan the editor is read-only: you'll see a **Read only** label and an **Upgrade** option. To edit a file, click into it and type, like in any code editor. While you work: * Save your changes with the **Save** button or **Cmd+S** (Mac) or **Ctrl+S** (Windows/Linux), or throw them away with **Discard**. If you leave the code editor with unsaved changes, Lovable asks you to confirm first. * Each save becomes a version in your project's [version history](/features/projects/history), so a manual edit is as easy to revert as anything Lovable does. * Use the format button in the file toolbar to clean up indentation and style. * While Lovable is working on your project, the **Save** button is disabled until it finishes. Saved changes apply to your project immediately, just like changes Lovable makes. Lovable doesn't review your manual edits, so if a change breaks something, revert it from [version history](/features/projects/history) or ask Lovable in chat to fix it. ## Reference code in chat The code editor makes your chat messages more precise: * **Reference a file**: click the **Reference file in chat** button in the file toolbar, use **Reference in chat** in a file's right-click menu, or type `@` in the chat input: ```text wrap theme={null} @src/components/UserProfile.tsx add a loading state here ``` * **Reference exact lines**: hover over a line number and click the **+** chip to add a file and line reference to the chat input, or drag the chip to reference a range of lines. You can also press **Cmd+Shift+L** (Mac) or **Ctrl+Shift+L** (Windows/Linux) to reference the line or selection at your cursor. References appear as pills like `Button.tsx:42`, and clicking a pill takes you back to that line. Pointing at the exact file or line is often faster than describing it. Lovable gets the precise context and doesn't have to search for what you mean. ## Download your project's codebase You can download your project's full source code at any time. On paid plans, everyone with edit access to the project can click **Download codebase** at the bottom of the file panel to save the entire project as a `.zip` file. To save just one file, use the **Download** button in the [file toolbar](#view-a-file) instead, on any plan. On Enterprise workspaces, admins can restrict codebase downloads so that only workspace admins and owners can use them. Everyone else sees the **Download codebase** option disabled. See [Privacy and security settings](/features/privacy-and-security-settings#code-downloads). For ongoing work outside Lovable, connect your project to [GitHub](/integrations/github) or [GitLab](/integrations/gitlab) instead of downloading snapshots. [Git sync](/integrations/git-sync-overview) keeps a repository and your project in sync both ways, so you or a developer can edit in any tool and push changes back. ## FAQ No. Lovable writes and manages the code for you, and most people never open the code editor. It's optional, for inspection, quick manual tweaks, and developer collaboration. Opening the code editor requires edit access to the project: project viewers see the app preview only, not the code. Editing and saving files additionally requires a paid plan. On the Free plan the editor is read-only. No. Editing and saving code yourself doesn't use credits. Credits are only used when Lovable does work for you in chat. See [Credits and usage](/introduction/credits-and-usage). Yes. Every save from the code editor creates a version in [version history](/features/projects/history), so you can review or revert manual edits the same way as Lovable's changes. Yes. On paid plans, anyone with edit access can click **Download codebase** in the code editor to save the project as a `.zip` file. You can also sync your project to [GitHub](/integrations/github) or [GitLab](/integrations/gitlab) to get a full repository that stays up to date. Git sync is available on all plans. On Enterprise workspaces, admins can restrict `.zip` downloads to workspace admins and owners. # Collaboration Source: https://docs.lovable.dev/features/collaboration Invite teammates to projects or workspaces, assign roles and permissions, and see changes in real time as you build together. Lovable lets you build websites together. Invite your designer, developer, agency, or anyone else. Everyone sees changes as they happen. There are two ways of collaborating. You can invite collaborators to a specific project or to your entire workspace. ## Collaboration in a specific project You can invite users to work together on a specific project by pressing **Share** in the project editor. Add their email, and they'll receive an invite to their email. See [Share a project](/features/share-project) for more information. Collaborators will use credits from the project owner's workspace. ### Check your role on a project To see your role on a project, open the project and click **Share**. The **Project access** section lists everyone with access, including you, with the current role shown next to each name. To see your role in a workspace, go to **Settings → People**. Your role appears next to your name in the members list. ### Project permissions Please note that free plans do not have admin roles. Some of the features presented might be available on specific plans only. Project roles are managed from the **Share** menu in the editor. See [project roles](/features/projects/overview#project-roles) for how they interact with workspace roles. | | **Viewer** | **Editor** | **Admin** | **Owner** | | ----------------------- | --------------- | -------------------- | -------------------- | -------------------- | | **Project access** | | | | | | Magic Link | **Yes** | **Yes** | **Yes** | **Yes** | | Add Viewer | **Yes** | **Yes** | **Yes** | **Yes** | | Remove Viewer | **Yes** | **Yes** | **Yes** | **Yes** | | Add Editor | No | **Yes** | **Yes** | **Yes** | | Remove Editor | No | **Yes** | **Yes** | **Yes** | | Add Admin | No | No | **Yes** | **Yes** | | Remove Admin | No | No | **Yes** | **Yes** | | **Project management** | | | | | | Remix project | **Yes** | **Yes** | **Yes** | **Yes** | | Add Custom domain | No | **Yes** | **Yes** | **Yes** | | Edit project | No | **Yes** | **Yes** | **Yes** | | Remove Lovable badge | No | **Yes** | **Yes** | **Yes** | | Change project access | No | **Yes** | **Yes** | **Yes** | | Manage GitHub | No | **Yes** | **Yes** | **Yes** | | Publish\* | No\* | **Yes**\* | **Yes**\* | **Yes**\* | | Manage project settings | No | **Yes** | **Yes** | **Yes** | | Disconnect Supabase | No | No | **Yes** | **Yes** | | Transfer project | No | No | No | **Yes** | | Delete project | No | No | No | **Yes** | \*By default, editors and above can publish projects on all plans. * On Business and Enterprise plans, this includes both publishing internally to the workspace and publishing externally to the web. * On **Enterprise** plans, workspace admins and owners can go to **Workspace settings → Privacy & security → Who can publish externally** to restrict **external publishing** to: * Admins & owners * Owners only If a project uses a connection with restricted access, only people with access to that connection can be viewers or editors in the project. Learn more about [Who can manage connections](/integrations/introduction#who-can-manage-connections). ## Collaboration in a workspace ### What is a workspace? A workspace is your shared space for building and collaborating on projects. You can invite as many teammates as you need into your workspace, and they can see, edit, and publish the workspace's projects (unless a project's access is [restricted](/features/project-visibility)). Each member can also create and work on as many of their own projects as they want. For granular permission control and role assignment in your workspace, a paid subscription is needed. When you subscribe to a plan, it gets tied to your desired workspace, and all projects in the workspace share the workspace's credits, no matter who sends the messages. See [Workspace basics](/features/workspace#workspace-basics) for the key rules. You can customize your workspace in the workspace settings by: * Renaming it * Changing the avatar * Writing a description See [Lovable workspace](/features/workspace) and [Workspace admin settings](/features/workspace-admin-settings) for more information. ### How do I add and manage collaborators in a workspace? You manage and add collaborators from the People tab in the workspace settings. You can access it by going to **Settings** > **People**. Here you can: * Add new collaborators by inputting their email. They'll receive an invite to their email that they then can accept. * Manage existing collaborators by changing their roles or removing them. * Manage monthly credits usage for each collaborator See [People](/features/people) for more information. ### Workspace permissions Please note that free plans do not have admin roles. | | **Viewer** | **Editor** | **Admin** | **Owner** | | :--------------------------------- | :--------- | :--------- | :-------- | :-------- | | **Workspace access** | | | | | | Add Viewer | **Yes** | **Yes** | **Yes** | **Yes** | | Remove Viewer | **Yes** | **Yes** | **Yes** | **Yes** | | Add Editor | No | **Yes** | **Yes** | **Yes** | | Remove Editor | No | **Yes** | **Yes** | **Yes** | | Add Admin | No | No | **Yes** | **Yes** | | Remove Admin | No | No | **Yes** | **Yes** | | Add Owner | No | No | No | **Yes** | | Remove Owner | No | No | No | **Yes** | | **Workspace management** | | | | | | View members | **Yes** | **Yes** | **Yes** | **Yes** | | Create new projects in a workspace | No | **Yes** | **Yes** | **Yes** | | Manage Supabase | No | **Yes** | **Yes** | **Yes** | | View usage | No | No | **Yes** | **Yes** | | Manage plans & billing | No | No | **Yes** | **Yes** | | Manage SSO (Business plan) | No | No | **Yes** | **Yes** | | Manage Integrations | No | No | **Yes** | **Yes** | # Cross-project referencing Source: https://docs.lovable.dev/features/cross-project-referencing Reuse implementations across projects in your workspace, including code, assets, files, and chat history. Maintain consistency and avoid rebuilding the same features. Cross-project referencing lets Lovable access and reuse implementations from other projects in your workspace. When referencing other projects, Lovable can explore file structures, read source code, search for relevant patterns, access related chat history, and reuse or copy assets such as images and fonts. This allows the agent to understand how something was built and recreate or adapt it in your current project. You can explicitly reference a project using `@` mentions, or simply ask Lovable to use an existing project when relevant. **The referenced projects remain unchanged**. ## How to reference other projects Type `@` in the chat and select a project, for example: ```text theme={null} Use the logo and color palette from @BrandSite. ``` Ask Lovable to use an existing project, for example: ```wrap theme={null} Build this using the same authentication setup as our existing main app. ``` Reference multiple projects in the same prompt. For example: ```text theme={null} Build this onboarding flow using the auth setup from @MainApp and the form validation pattern from @ContactApp. ``` Cross-project referencing works when prompting Lovable in [Build mode](/features/agent-mode) and [Plan mode](/features/plan-mode), or when responding in the **questions tool by selecting “Other.”** You can also add references directly from the prompt box by clicking `+` and selecting **@ Add reference**. When project names are similar or vague, the project picker helps you choose the right one. It shows the full project name, description, and a preview image for each match, the same layout used in the command palette, and you can click the preview image to open that project in a new tab. Large files or results may be truncated. ## What you can reference You can reuse: * Components and layout systems * Animations and styling systems * Auth flows and API integrations * Feature implementations * Assets such as images and fonts * Relevant chat history for implementation context All access is read-only and limited to projects within your workspace. ## Permissions and access Cross-project referencing is restricted by workspace boundaries and sharing settings. * Only projects within the same workspace can be referenced. Cross-workspace referencing is not supported. * Any workspace member, including collaborators, can reference any project they have permission to access. * Cross-project access is read-only. Referenced projects cannot be modified. ## Disabling cross-project sharing Cross-project sharing can be disabled at different levels: * **Workspace level:** \ Workspace admins and owners can disable cross-project sharing for the entire workspace in\ **Workspace settings → Privacy & security → Cross-project sharing.** * **Project level:** \ Project editors and above can disable cross-project sharing for a specific project in\ **Project settings → Cross-project sharing.** When disabled at the project level, that project cannot reference other projects, and other projects cannot reference it. If any of these controls block access, the reference will fail. ## FAQ No. Cross-project referencing only works within the same workspace. Cross-workspace referencing is not supported. No. All cross-project access is read-only. The referenced project cannot be modified. No. Projects with **Restricted** visibility can only be referenced by their owner. Team members cannot reference restricted projects, even within the same workspace. If Lovable cannot access a project, check the following: * Verify that cross-project sharing has not been disabled at the workspace or project level. * Make sure both projects are in the same workspace. Cross-workspace access is not supported. * Verify project access. Projects set to **Restricted** are only accessible to their owner. * Confirm you have permission to access the project. You can only reference projects you have access to. If any of these controls block access, the reference will fail. # Set up a custom domain Source: https://docs.lovable.dev/features/custom-domain Learn how to buy, connect, verify, troubleshoot, and manage custom domains in Lovable. A **custom domain** lets you use your own domain or subdomain for your Lovable project instead of the default `xxx.lovable.app` URL. Connecting a custom domain improves your site's: * **Brand identity**: look more trustworthy and professional * **Search engine visibility**: better SEO and discoverability * **Memorability**: easier for users to share and remember Custom domains are available on **paid plans**. ## Choose how to set up your domain You can set up a domain at any time, but you need to **publish your project** before your domain can start serving your site. You can access the domain setup from: * **Project → Settings → Domains** * **Publish modal → Custom domain** * **Workspace settings → Workspace domains** You'll see two options on the **Domains** page: * **Buy a new domain** \ Register and set up a domain in Lovable. All domains bought through Lovable belong to your **workspace**, not a single project. * **Connect existing domain**\ Connect an existing domain from your workspace or a domain from another provider. ## Buy a domain through Lovable Buy and manage domains directly in Lovable without manually configuring domain records. Domains bought through Lovable belong to your workspace, not to a single project. You need to be a workspace **admin** or **owner** to buy and connect a domain through Lovable. You can buy a domain in two ways: ### Buy and connect to a project Use this option when you want the domain to serve a specific project right away. You can start from: * Project → Settings → Domains * Publish modal → Custom domain * Workspace settings → Workspace domains When you buy from a project, Lovable connects the domain to that project automatically. When you buy from Workspace settings, you choose the project during checkout. ### Buy without connecting to a project Use this option when you want to buy a domain for your workspace and connect it to a project later. This is only available from **Workspace settings → Workspace domains**. During checkout, leave the **Connect to project** step empty. You can connect the domain later from **Workspace settings → Workspace domains**, or from **Project → Settings → Domains → Connect existing domain**. Follow the steps below: You can access the domain setup from: * **Project → Settings → Domains** * **Publish modal → Custom domain** * **Workspace settings → Workspace domains** Click **Buy new domain.** Search for a domain name or choose one of the suggested options. * Prices are shown in USD. * Premium domains cost more than standard domains. * We support most major generic top-level domains and a limited set of country code top-level domains. Review and adjust the details of your purchase before checkout. You can edit: * **Term length**\ Choose how long to register the domain, from 1 to 10 years. Multi-year registration may offer cost savings. * **Auto-renew**\ Enabled by default and recommended. When enabled, your domain renews automatically before it expires using your saved payment method. You'll be charged the renewal price shown at the time of purchase (subject to change based on registrar pricing). * **Registration details**\ Required contact information for domain registration, see next step. * **Connect to project** (optional)\ This option is only available when buying from **Workspace settings → Workspace domains**.\ Choose a project to connect the domain to after registration completes, or leave it empty to buy the domain as a standalone workspace domain and connect it later. When buying from Project → Settings → Domains, or the Publish modal → Custom domain, Lovable connects the domain to the current project automatically. * Enter your registration details required by [ICANN](https://www.icann.org/) (the organization that manages domain registration worldwide). Registration details cannot be changed after purchase. * Click **Save**. ICANN requires you to verify your registrant email address. * If the email you provided matches your verified Lovable account email, verification is handled automatically. * Otherwise, you receive a verification email and must click the link before the deadline to confirm ownership and avoid suspension. [WHOIS privacy protection](https://en.wikipedia.org/wiki/Domain_privacy) is enabled automatically for domain extensions that support it. You can disable or re-enable WHOIS privacy after purchase from **Workspace settings → Workspace domains → Configure → ··· → WHOIS privacy**. Click **Confirm purchase** and complete the Stripe checkout flow. * The purchase price and renewal price may differ. * The renewal price is shown during checkout and in your domain settings. When your payment is confirmed, you're redirected back to Lovable and a progress dialog tracks the registration. Lovable automatically: * **Registers the domain on your behalf**\ You see **Registered on Lovable** next to your domain. * **Configures DNS records** \ `A` records and verification `TXT` records are created automatically. * **Sets up SSL/HTTPS** \ Your domain gets a free SSL certificate, so your site is served securely. * **Connects the domain to a project** (if you selected one) \ Both `yourdomain.com` and `www.yourdomain.com` are set up automatically and listed separately. If you bought the domain without connecting it to a project, the progress dialog shows a **Manage domain** button when registration completes. Click it to go to the domain's detail page in your workspace and connect it to a project from there. To use a subdomain instead of the root domain (for example, `blog.yourdomain.com` or `app.yourdomain.com`), go to **Connect domain → Your domains**, click **Connect** next to the root domain, then select **Use a subdomain**. Domain setup typically completes within a few minutes, but can take up to several hours. You can follow the progress in the UI. After your domain becomes **Live**, run an [SEO review](/features/seo-aeo) and verify the domain in Google Search Console. This helps Lovable check indexing, canonical URLs, sitemap status, metadata, and other live-site SEO signals for the correct host. ### Domain statuses Your domain bought through Lovable may show one of these statuses: | **Status** | **Description** | User action | | :---------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Pending** | Your domain is being registered and configured. DNS records and SSL are being set up.
If the setup takes longer than expected, you see a warning. | No action required. Wait for setup to complete.
If you see the warning, click **Check status** to refresh. Contact support if it doesn't complete within a few hours. | | **Live** | Domain is fully configured and serving your project. SSL is active. | No action required. | | **Ready** | Domain is correctly configured, but your project isn't published yet. Domain will start serving automatically when you publish. | Publish the project. | | **Removed** | The domain is no longer connected to this project, for example because registration expired. | Reconnect it from your workspace domains if needed. | You can disconnect a domain at any point regardless of its status. ### Manage workspace domains bought through Lovable All domains bought through Lovable belong to your **workspace**, not a single project. This means you can view them in one place and connect them to any project in the workspace. To buy, view, and manage all domains that belong to your workspace, go to **Workspace settings → Workspace domains**. You can: * **View all domains**\ See all domains in your workspace, including their name and expiry. * **Search and filter**\ Find domains by name. * **Buy a domain**\ Buy a new domain for your workspace. You can connect it to a project during checkout, or leave it unconnected and connect it to a project later. * **Configure specific domains**\ Click Configure on a domain to view and manage: * Registration details and alerts * Expiration and renewal details and alerts * Auto-renew settings * Manual renewal for another year * Transfer out to another registrar (turn off the transfer lock and reveal the EPP authorization code) * WHOIS privacy (toggle on or off, for TLDs that support it) * Connected projects, including a link to each project * DNS records * **Disconnect a domain from a project**\ Project editors and above can disconnect a domain from a project. This does not cancel your registration. The domain remains in your workspace and can be reconnected. * **Move a domain to another workspace**\ Click on the three dots menu in the upper right corner and choose **Move domain** to transfer a domain to a different workspace. The destination workspace must be on a Pro plan or above, and you must be an admin or owner of that workspace. When the move completes, the domain leaves the source workspace and becomes available in the destination workspace, where you can connect it to any project there. Existing project connections in the source workspace are disconnected as part of the move. ### Manage project domains bought through Lovable To manage a **specific project domain** bought through Lovable, go to **Project → Settings → Domains** and click the three dots menu next to the domain. You can: * **Configure domain details**\ Opens the **Configure** page, where you can view registration, renewal, and connection details. * **Set or unset as primary**\ Choose which domain should be the main domain for your project. * **Disconnect the domain from a project**\ Project editors and above can disconnect a domain from a project. This does not cancel your registration. The domain remains in your workspace and can be reconnected. ### Change nameservers for a domain bought through Lovable By default, Lovable manages the DNS for domains bought through Lovable using **Lovable's nameservers**. If you'd rather manage DNS elsewhere, you can point a domain to your own **custom nameservers** (for example, Cloudflare). You need to be a workspace **admin** or **owner** to change nameservers. Go to **Workspace settings → Workspace domains**, click **Configure** next to the domain, and find the **Nameservers** section. * **Edit**\ Enter your custom nameservers (at least two) and save. * **Reset to Lovable**\ Switch back to Lovable's nameservers so Lovable manages the domain's DNS again. When you switch to custom nameservers, Lovable stops managing the domain's DNS. You become responsible for every DNS record at your provider, and any connected project and its email stay offline until you recreate those records there. Custom nameservers stop Lovable from managing DNS. Connected sites and email break until you recreate the records. ## Connect a domain from another provider You can connect a domain you already own using **automatic** setup (powered by Entri) or **manual** DNS configuration. Both methods require verifying ownership of your domain. Connecting points your domain at your project while it stays registered with your current provider. If you'd rather have Lovable manage the domain's registration, renewals, and DNS in one place, [transfer the domain to Lovable](/features/transfer-domain) instead. ### Prerequisites * You have project editor permissions or higher to connect and disconnect domains. * You have access to the DNS settings for the domain or subdomain you want to connect. **Ownership verification** requires adding DNS `A` and `TXT` records provided by Lovable during setup. * There are no `AAAA` records set for the domain you are connecting. Having an `AAAA` record can interfere with domain setup and cause traffic to be routed incorrectly. ### Connect your domain Follow the steps below to connect the domain: Click **Connect domain**. * Enter your domain or subdomain (for example, `yourdomain.com` or `blog.yourdomain.com`). * Click **Connect domain**. This opens the Entri modal. * Click **Continue.** When adding a domain purchased outside Lovable, the `www` subdomain is not automatically added. You can add it separately if you want both. Connect your domain in one of two ways: * **Automatic setup with Entri**\ Your domain provider is detected automatically. Log in and authorize Entri to update your DNS records. * **Manual setup**\ Select your domain provider from the list. If your provider is not listed, scroll to the bottom of the **Select your domain provider** modal and choose **Go to our manual setup**. Copy the `A` record and `TXT` record and input them directly into your domain registrar or DNS provider. The records Lovable asks you to add look like this: * The `A` record points your domain to Lovable's edge IP address `185.158.133.1`. * The verification `TXT` record uses the host `_lovable` and a value starting with `lovable_verify=`. If you see the IP `185.158.133.1` in your DNS settings, that is Lovable's server, not a previous host. When connecting a domain, we suggest a default host name for the `A` record. Depending on your provider, the host name may need to be: * `@` * left blank * or set to your domain name (for example, `example.com`) For example, Amazon Route 53 requires the host name to be left blank or set to the domain name. Click **Done**. Wait for verification and SSL certificate to be issued. When complete, the domain will become **Live** and your Lovable app will be live at your custom domain. DNS changes may take up to 72 hours to propagate, though most updates are live within a few hours. After your domain becomes **Live**, run an [SEO review](/features/seo-aeo) and verify the domain in Google Search Console. This helps Lovable check indexing, canonical URLs, sitemap status, metadata, and other live-site SEO signals for the correct host. ### Advanced: Use a CDN or reverse proxy Lovable can be used behind your own CDN or reverse proxy, such as Cloudflare, CloudFront, or Fastly. To do this, enable the advanced **Domain uses Cloudflare or a similar proxy** option when connecting a domain from another provider. When this option is enabled: * You are responsible for configuring and maintaining your CDN or proxy * Lovable does not configure, validate, or monitor your CDN or proxy setup Follow these steps: Lovable will provide a `CNAME` record. Add the `CNAME` record to your domain’s DNS settings at your DNS provider. Wait for the domain status to become **Live**. When the `CNAME` record is pointed correctly, Lovable issues the SSL certificates. Traffic will then flow through your CDN or proxy before reaching Lovable. ### Domain statuses When you connect domains purchased outside Lovable, you see clear statuses that reflect verification progress, DNS propagation, SSL certificate readiness, and required user action. | Status | Description | User action | | :------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Unpublished** | Shown only for your `xxx.lovable.app` project URL when the project is not yet published. | Publish the project. | | **Ready** | The domain is ready but the project was unpublished. When published again, the status automatically becomes **Live**. | Publish the project. | | **Action required** | The custom domain setup was not completed. | Click **Complete setup** to finish connecting. | | **Verifying** | Waiting for DNS records to propagate. | Click **Check status** to check the latest status and verify the DNS records.

Check that your `A` and `TXT` records are added correctly **at your DNS provider**, especially the full TXT value. | | **Unable to verify** | DNS verification did not complete within one hour. This usually means your DNS records are incorrect or still propagating.

**Note**: *DNS propagation can take up to 72 hours, although most updates are applied within a few hours.* | Click **Check status** to refresh the status and re-verify your DNS records.

Check that your `A` and `TXT` records are added correctly **at your DNS provider**, especially the full TXT value. | | **Setting up** | Verification complete; SSL certificates are being issued. | No action required; domain will automatically move to **Live** or **Failed.** | | **Stalled** | SSL certificate provisioning is taking longer than expected. | Click **Retry** to attempt setup again. You do not need to remove and re-add the domain. | | **Failed** | Ownership verified, but SSL certificate could not be provisioned. | Click **Retry** to attempt again. | | **Live** | Domain is live and serving your project. | No action required. | | **Offline** | Domain was **Live** but DNS records are no longer valid. Your domain is no longer pointing to your project. | Click **Recover**. Review displayed DNS records and update them **at your DNS provider** to reconnect your domain. | | **Removed** | This domain was removed because it was added to another project or DNS verification never completed (DNS records weren't added correctly or didn't finish propagating). | Click **Reconnect** to connect the domain again. | ### Manage project domains from other providers To manage a **specific project domain** bought from another provider, go to **Project → Settings → Domains** and click the three dots menu next to the domain. You can: * **Set or unset as primary**\ Choose which domain should be the main domain for your project. * **Disconnect from project**\ Remove the domain from your project. This does not cancel your registration with your domain provider. Make sure to clear DNS settings in your domain provider to completely clear the connection. ## Primary domain Lovable allows you to set **one domain as the primary domain**. * The domain status must be **Live** in order to mark it as primary. Click the three dots menu next to your domain and click **Set as primary**. * The first custom domain you add to a project automatically becomes the primary domain (for domains added after October 29, 2025). * If a domain is primary, all other connected domains redirect to it using a **302 temporary redirect**. * Lovable hosting does not support **301 permanent redirects** between connected project domains. Primary domains can be changed, so Lovable uses temporary redirects to keep domain changes reversible. * Only one domain can be primary at a time. * You can unset the primary domain; in that case, all connected domains serve the project equally. Click the three dots menu next to your primary domain and click **Unset as primary**. ## FAQ These terms come up when connecting a custom domain from another provider: * **DNS** determines where your domain points on the internet. * A **DNS provider** is the service where you manage DNS records for your domain, such as `A`, `TXT`, or `AAAA` records. * An **A record** points a domain or subdomain to an IP address. * A **TXT record** is used to verify domain ownership. * An **AAAA record** points a domain to an IPv6 address and can interfere with domain setup if present. * An **SSL certificate** enables HTTPS and allows browsers to securely connect to your site. Your DNS provider probably still has `A`, `AAAA`, or `CNAME` records left over from your previous website or hosting provider. Remove the old records for the host you are connecting so that only Lovable's `A` record (`185.158.133.1`) and verification `TXT` record remain, then wait for DNS propagation. These errors come from Cloudflare's proxy, not from Lovable. If your DNS is managed by Cloudflare, open the DNS settings and set the records for your Lovable domain to **DNS only** (gray cloud) instead of **Proxied** (orange cloud), then wait a few minutes and try again. Yes. When you connect a custom domain to your Lovable app, we automatically generate and install an SSL certificate for it. This ensures your site is served over HTTPS, keeping your visitors' data secure and improving your site's SEO ranking. If it hasn't been issued after 72 hours, please reach out to [Lovable Support](https://lovable.dev/support). You do not need to install, upload, or reissue an SSL certificate from your domain registrar (for example, Namecheap or GoDaddy). Lovable issues and serves its own certificate for the connected domain, and any SSL certificate at your external registrar is not used by Lovable's hosting. Yes, you can buy and set up a domain at any time. However, your custom domain won't serve any content until you publish your project. Yes. You can buy a domain as a standalone workspace domain from **Workspace settings → Workspace domains**. During checkout, leave the **Connect to project** step empty. The domain will belong to your workspace, and you can connect it to a project later from **Workspace settings → Workspace domains**, or from **Project → Settings → Domains → Connect existing domain**. This option is only available when buying from **Workspace settings → Workspace domains**. When you buy from a project's Domains settings or the Publish modal, Lovable connects the domain to the current project automatically. Yes. A custom domain helps consolidate your brand, backlinks, canonical URLs, and search visibility under a domain you control. After your domain becomes **Live**: * Run an [SEO review](/features/seo-aeo) to check indexing, metadata, canonical URLs, sitemap status, performance, and other live-site SEO signals. * Verify the domain in Google Search Console. * Submit your sitemap through the [Google Search Console connector](/integrations/google-search-console) or directly in Google Search Console. * If you changed your primary domain, rerun the SEO review so Lovable can re-check the new host. Lovable supports both custom domains and subdomains, and lets you choose one primary domain so all other connected domains redirect to it automatically. Lovable hosting does not support **301 permanent redirects** between connected project domains. A primary domain is a reversible project setting. You can choose a different primary domain later, or unset the primary domain entirely. Because of this, Lovable uses temporary redirects instead of permanent redirects. * For domains purchased through Lovable, both the root domain and `www` subdomain (`yourdomain.com` and `www.yourdomain.com`) are set up automatically and listed separately. * For domains purchased outside Lovable, the `www` subdomain is not included when you set up your domain. You need to add it separately, and it will be listed separately. Yes. You can connect a subdomain (for example, `blog.yourdomain.com` or `app.yourdomain.com`) instead of the root domain. When connecting your domain, include the subdomain you want to use. Yes. You can connect multiple subdomains, but each one must be added and configured individually in **Project → Settings → Domains**. For example, you can connect `blog.yourdomain.com`, `shop.yourdomain.com`, and `app.yourdomain.com`. Not the same exact domain, but you can connect different subdomains of the same domain to different projects (for example, `yourdomain.com` to project A, `blog.yourdomain.com` to project B). Yes. As long as you can verify ownership, you can connect a domain or subdomain used by another project, even if the project has been deleted. You can see your connected domains in the following locations: * **Project → Settings → Domains**: all domains connected to a project * **Publish modal**: all **Live** domains connected to a project * **Workspace settings → Workspace domains**: all domains bought through Lovable The domain status must be **Live** in order to set it as primary. Go to **Project → Settings → Domains**, click the three dots menu next to a **Live** domain, and click **Set as primary**. Go to **Project → Settings → Domains**, click the three dots menu next to your primary domain, and click **Unset as primary**. You can disconnect a domain at any time regardless of its status. 1. Go to **Project → Settings → Domains.** 2. Click the three dots menu next to your domain, click **Disconnect**, then click **Disconnect** again to confirm. This will disconnect the domain from the project. * For **domains bought through Lovable**, this only disconnects the domain from the project. It does not cancel your registration. The domain remains in your workspace and can be reconnected. * For **domains purchased outside Lovable**, this only disconnects the domain from the project. It does not cancel your registration with the external provider. The domain is just removed from Lovable. Make sure to clear DNS settings in your domain provider to completely clear the connection. Connected domains keep serving your published app. Downgrading or canceling does not disconnect your domains or unpublish your project. * **Already-connected domains keep working**, and you can still [disconnect them](#how-do-i-disconnect-a-custom-domain) on any plan. * **Connecting a new domain requires a paid plan.** After a downgrade to Free, you can't buy domains or connect domains to projects, including domains already in your workspace, until you upgrade again. * **Domains bought through Lovable are billed separately** from your subscription, so a plan change does not affect their registration or renewal. Auto-renew keeps renewing and charging as usual, and the workspace owner can still manage the domain from **Workspace settings → Workspace domains**, including turning off auto-renew or transferring the domain out. For the rest of your published app, see [What happens to my published app if I downgrade or cancel my plan?](/features/publish#what-happens-to-my-published-app-if-i-downgrade-or-cancel-my-plan) Currently, there is no way to remove the `xxx.lovable.app` project URL from your project. However, you can add a custom domain and set it as your primary domain. This allows visitors to access your app from a branded URL instead of the default `xxx.lovable.app` project URL. We support most major generic top-level domains (gTLDs) and a limited set of country code top-level domains (ccTLDs). Supported ccTLDs: ```text wrap theme={null} "ai", "io", "ag", "bz", "cc", "co", "fm", "im", "la", "me", "sc", "tv", "vc", "ws" ``` Availability and pricing vary by extension. If registration fails after payment, the system automatically retries three times. If it still can't be completed, your payment will be refunded automatically. Your domain stops serving traffic, but it is in the registrar's redemption grace period (around 30 days), where it can still be recovered with support help. After that, it's released and may become available to anyone. No. Registration details are entered during purchase and cannot currently be changed afterward. Yes, for TLDs that support it. WHOIS privacy is enabled by default at registration. To change it, go to **Workspace settings → Workspace domains**, click **Configure** next to the domain, open the three dots menu in the upper right corner, and toggle **WHOIS privacy**. The change takes effect at the registrar shortly after. Go to **Workspace settings → Workspace domains**, click **Configure** next to the domain, open the three dots menu in the upper right corner, and select **Transfer out**. In the **Transfer out** dialog: 1. Turn off the **Transfer lock** switch. The lock is on by default and marks your domain as protected. 2. Click **Reveal authorization code** to get the EPP code, then provide it to your new registrar. The button stays disabled until the transfer lock is off. Generating a new code invalidates any previous one, so only the most recently generated code will work. Lovable tracks the transfer status and automatically disconnects the domain from any connected projects when the transfer completes. **60-day lock on new domains:** if the domain is within 60 days of registration, the transfer lock switch is disabled. ICANN requires this lock on new domains and Lovable cannot override it. The dialog shows the exact date the domain becomes eligible for transfer. See the next FAQ for what happens once the transfer finishes. When the transfer out completes at the registrar, Lovable automatically disconnects the domain from any project it was connected to. The domain remains visible in **Workspace settings → Workspace domains** but is marked as transferred out and can no longer serve traffic from Lovable. After the transfer: * Update DNS records at your new registrar to point your domain where you want it to resolve. * If you want to keep using the domain with a Lovable project, reconnect it as a [domain from another provider](#connect-a-domain-from-another-provider). Transferring a domain out is irreversible from Lovable's side. Connected projects stop serving traffic on that domain as soon as the transfer out completes. Yes. Domains bought through Lovable can be moved between workspaces. Go to **Workspace settings → Workspace domains**, click **Configure** next to the domain you want to move, and select **Move domain** from the three dots menu in the upper right corner. The destination workspace must be on a Pro plan or above, and you must be an admin or owner of that workspace. Domains connected from external providers cannot be moved. Your app's auth redirect URLs probably don't include the new domain yet. Ask Lovable in chat to add your domain to the auth redirect URLs, or add it under **Cloud tab → Users → Auth settings → Advanced**. See [Site URL and redirect URLs](/features/authentication#site-url-and-redirect-urls). ## Troubleshooting domains from other providers This usually means Lovable is still waiting for the correct DNS configuration or for changes to fully propagate. Try the following: * Use a DNS lookup tool like [dnschecker.org](https://dnschecker.org/all-dns-records-of-domain.php) to confirm that your domain resolves to the expected records. DNS changes can take up to **72 hours** to propagate. * Go to **Project → Settings → Domains** and confirm the DNS records Lovable expects. * Clear your browser cache or test the site in an incognito window. * Try removing and re-adding the domain in **Project → Settings → Domains**. This often happens when traffic is being routed incorrectly due to an IPv6 (`AAAA`) record. Check whether your domain has any `AAAA` records configured. An `AAAA` record can interfere with domain routing and cause traffic to bypass the expected destination. To resolve this: * Review your DNS settings at your DNS provider. * Remove any `AAAA` records for the domain. * Retry connecting the domain after the change has propagated. When connecting a custom domain in Lovable using manual setup, Lovable provides the exact DNS records required for verification. These records must remain unchanged until verification is complete. If the provided `A` record is modified before verification finishes, Lovable cannot verify the domain or issue SSL certificates. **While verification is in progress:** * Do not enable proxying on the `A` record. * Do not point the `A` record to a CDN or reverse proxy. If either of these happens, the domain remains in the **Verifying** state. **To fix this:** 1. Disable proxying (DNS-only) on the provided `A` record. 2. Ensure the `A` record points directly to **Lovable's IP address.** 3. Wait for the domain status to change to **Live.** # Send branded emails from your own domain Source: https://docs.lovable.dev/features/custom-emails Send branded emails, including authentication emails and custom app emails, from your own email domain with automatic DNS, SPF, DKIM, and DMARC setup to improve deliverability, protect your domain reputation, and strengthen brand trust. ## Overview Emails allow your Lovable Cloud app to send **authentication emails** and custom **app emails** from your own email domain. For example: `noreply@notify.yourdomain.com` or `noreply@yourdomain.com` Using a dedicated sending subdomain helps protect your root domain's reputation while keeping your branding consistent. You can customize: * Which email domain your project uses * The sender subdomain configuration * Email branding and visual style * Email templates and subject lines Lovable handles domain verification, DNS configuration, email authentication (SPF, DKIM, and DMARC), and delivery infrastructure. No external email provider accounts or API keys are required. ## Supported email types You can send authentication emails and custom app emails. ### Authentication emails Authentication emails are a type of transactional email related to account access and identity verification. They are automatically triggered by Cloud Auth when users perform specific security-related actions. Lovable provides six built-in templates you can use: * **Confirm signup**\ Sent when a user creates an account and email confirmation is enabled. Verifies that the user owns the email address before activating the account. * **Password reset**\ Sent when a user requests to reset their password. Allows secure password recovery. * **Magic link**\ Sent when passwordless login is enabled and a user requests a login link. Authenticates the user without requiring a password. You can ask Lovable to enable magic link authentication if it is not already configured. * **Invite**\ Sent when you invite a user to join your project (from Cloud → Users). Grants account access through a secure invitation link. * **Email change**\ Sent when a user updates their email address. Confirms ownership of the new address before applying the change. * **Reauthentication**\ Sent when a user must verify their identity before performing a sensitive action, such as changing a password. Typically includes a short-lived verification code. You can ask Lovable to enable reauthentication if it is not already configured. See [Generate and customize email templates](#generate-and-customize-email-templates) for more information. ### App emails App emails are a type of transactional email sent in response to user activity or events in your app. They are triggered by your application logic when something happens, like a purchase or update. There are no built-in templates, you decide when to send them and what they contain. Ask Lovable to add the required functionality, such as shipping notifications, order confirmations, purchase receipts, and other updates, and it will generate the templates for you. Lovable also handles unsubscribe automatically by adding an unsubscribe link to the email footer. See [Generate and customize email templates](#generate-and-customize-email-templates) for more information. ## Availability and usage * Emails are available on **paid plans**. * Each paid workspace includes **50,000 transactional emails per month** at no additional cost. Usage is calculated across the entire workspace. Additional emails are billed 4 credits per 1000 emails. * Emails are rate limited to **100 emails per hour per workspace** to protect deliverability and system stability. If you need a higher limit, contact [Lovable Support](https://lovable.dev/support). ## Why use emails * **Better deliverability:** Emails sent from your own domain are more likely to reach the inbox instead of spam. * **More trust:** Users see your domain in the `From` address, reinforcing credibility. * **Consistent branding:** Emails match your product identity. * **Managed setup:** Lovable verifies your domain and configures the required DNS records. * **Authenticated sending:** Lovable automatically sets up [SPF, DKIM, and DMARC](#what-are-spf-dkim-and-dmarc-and-do-i-need-to-configure-them) to authenticate your emails and improve inbox placement. * **Continuous monitoring:** Lovable alerts you if DNS changes could impact email delivery. ## Prerequisites To use emails: * The [built-in backend (Cloud)](/features/cloud) must be enabled for your project. Projects connected to your own Supabase project can't use built-in emails. * Your workspace must be on a paid plan. * You must own a domain and have access to manage its DNS settings. * You must be a workspace admin or owner to add, delete, or verify domains. ## How emails work When you configure an email domain, Lovable: * Creates a transactional sender subdomain under your root domain, such as `notify.yourdomain.com` * Guides you through DNS configuration using an automated setup flow * Verifies your domain by checking required DNS records * Provides six built-in branded authentication email templates that you can generate and customize * Generates custom app email templates based on the functionality you request, such as confirmations, notifications, and updates * Activates email delivery once DNS verification completes After domain verification, emails are sent from your domain. ### Email domain scope and usage Email domains are provisioned at the workspace level. * A workspace can have multiple email domains * A verified domain can be used across multiple projects * Each project selects which verified domain it uses * Only one email domain can be active per project at a time * Only domains with status **Verified** can send emails * Emails can be enabled or disabled per project ## Add an email domain Select the domain you want to use for sending emails. This will be the domain your users see in their inbox. There are two ways to start: * **From the chat**: Ask Lovable to set up emails and it will present a setup button. For example: ```text theme={null} I want to send password reset emails from my domain. ``` * **From Cloud settings**: Go to **Cloud tab → Emails** and click **Get started**. This takes you to the email setup flow. - Choose an existing workspace domain from the dropdown, or select **Add a new email domain**, then enter your root domain or subdomain, for example `yourdomain.com`. Domains can have up to 5 levels, for example `a.b.c.example.com`. - Click **Continue**. Configure the subdomain prefix that will be used for sending emails. The right-side preview shows a simulated inbox with example emails from your configured domain. * By default, Lovable creates a `notify` subdomain for delivery, for example `noreply@notify.yourdomain.com`, but you can change the subdomain. * Optionally, enable **Show as sent from @yourdomain.com** so recipients see emails from `@yourdomain.com` in their inbox, while your transactional sender subdomain handles delivery behind the scenes. * Click **Set up domain**. After clicking **Set up domain**, Lovable launches an **automated DNS configuration flow** (powered by Entri) that guides you through setting up the required `NS` zone delegation for your domain. If your DNS provider is not listed or you prefer manual control, you can configure DNS records yourself. Scroll to the bottom of the **Select your domain provider** Entri modal and choose **Go to our manual setup**. Both the automated and manual methods require verifying ownership of your domain. Lovable will provision your domain and generate the required DNS records. Follow the on-screen prompts to log in to your DNS provider and authorize Entri to update your DNS records. 1. Copy the displayed DNS records. * `TXT` record for domain verification * `NS` records pointing to Lovable's nameservers 2. Track your progress with the **I have copied X/Y records** counter. 3. Add the copied DNS records directly into your domain registrar or DNS provider. Add the `NS` records as **records inside your DNS zone** for the subdomain host shown (for example `notify`). Do not replace your domain's nameservers at your registrar. Replacing the registrar-level nameservers takes your entire website and email offline. You can also forward these instructions to a colleague if someone else manages your DNS. After DNS is configured, you're taken back to the **Emails** page in your project. A progress panel shows the current state of your domain setup and a countdown timer for each setup step. See [Email domain statuses](#email-domain-statuses) to learn what each status means. DNS changes typically propagate within a few hours, but may take up to 48 hours. While DNS verification is in progress, you can start setting up your authentication and app email templates. See [Generate and customize email templates](#generate-and-customize-email-templates) for more information. Lovable automatically detects when DNS verification completes and activates your domain. Once the domain status changes to **Verified**, emails begin sending from your domain. Newly provisioned domains start with a neutral reputation. Initial deliverability may fluctuate while your domain builds trust with inbox providers through consistent, legitimate sending. See [Email deliverability best practices](#email-deliverability-best-practices) for more information. ## Email domain statuses Email domains can move through the following statuses: | Status | Meaning | | :-------------------- | :-------------------------------------------------------------- | | **Pending** | Setup has started and DNS configuration is in progress | | **Verifying** | DNS records have been detected and verification is in progress | | **Setting up** | Domain provisioning in progress | | **Verified (Active)** | Domain is ready and can be used to send emails | | **Offline** | Required DNS records were changed or removed after verification | | **Failed** | Verification or provisioning failed | | **Domain removed** | The domain was deleted from the workspace | Domains are continuously monitored. If required DNS records drift, are removed, or expire, the domain may move to an inactive state until re-verified. ## Generate and customize email templates The **Emails** page includes two tabs, **Auth emails** and **App emails**, where you can preview the generated templates for your app. Email templates are not generated automatically. To generate email templates: * **Auth email templates**\ Go to the **Auth emails** tab and click **Customize auth emails**. Lovable generates six built-in branded templates. * **App email templates**\ Ask Lovable to add the required functionality, such as notifications, confirmations, or receipts. It will generate the corresponding email templates for you. For example: ```text wrap theme={null} Add order confirmation emails to my app. When an order is placed, send a confirmation email to the customer. ``` Each template shows: * **From** address * **Subject** line * **Live preview** of the email template rendered in an iframe * **Send test** options, including sending a test email to your account or to a custom address. Emails sent from newly configured domains may initially land in spam while reputation builds. ### Automatic branding When generating the email templates, Lovable applies your app's branding automatically by: * Extracting CSS variables from `src/index.css` (primary colors, fonts, border radius) * Detecting logo files in `public/` and `src/assets/` * Uploading a detected logo to a dedicated email assets storage bucket * Adapting email copy to match your app's tone and language The outer email body background is always `#ffffff` to ensure consistent rendering across email clients. Inner components can use your brand colors. ### What you can customize You can ask Lovable to update: * Copy and tone * Brand colors * Layout and structure * Images and logo placement * Subject lines The outer email body background must remain white (`#ffffff`) to ensure consistent rendering across email clients. Inner components can use your brand colors. For example: ```wrap theme={null} Match the emails to my brand by using #2563eb for buttons and headings, add my logo at the top, remove emojis, make the tone professional but friendly, move the button higher in the layout, add a footer with support@myapp.com, and update subject lines to start with my app name. ``` Lovable updates templates while preserving required information, such as authentication variables, secure callback links, and the unsubscribe footer. ### Edit templates manually If you prefer to edit code directly: * **Authentication emails** * Templates are located at `supabase/functions/_shared/email-templates/` * The sending logic is located at `supabase/functions/auth-email-hook/` Required authentication variables and callback links must remain intact, or authentication flows will break. * **App emails** * Templates are located at `supabase/functions/_shared/transactional-email-templates/` * The sending logic is located at `supabase/functions/send-transactional-email/` The unsubscribe footer in app email templates must remain intact. Removing it violates email sending requirements and will affect deliverability. Templates use React Email components with inline styles (email clients do not support external CSS). After editing template files or subject lines, you must ask Lovable to redeploy for changes to take effect. For example: ```text theme={null} Redeploy my email templates ``` ## Managing email domains In **Cloud tab → Emails**, use the domain dropdown to access: * **Analytics and logs**: View delivery metrics for the email domain and email activity for the current project using that domain. * **Manage domains**: View all workspace email domains and their status badges, inspect and copy DNS records, switch which domain the current project uses, manually verify a domain, add a domain, or delete a domain. Deleting a domain is a **workspace-wide action**. This will stop sending emails from that domain. Any project using that domain will automatically fall back to default authentication emails and other app emails will stop sending. * **Add a new domain:** Add a new workspace email domain. * **Disable emails**: Enable or disable emails for the current project. When disabled, authentication emails continue sending using the default Cloud Auth sender instead of your custom email domain and templates, and other app emails stop sending. ### Analytics and logs The analytics and logs view shows delivery metrics for the connected domain over 7, 30, or 90 days, and a log of recent emails sent for the current project. * **Metrics cards**: * **Sent**: Emails accepted and queued for delivery * **Delivered**: Emails successfully delivered to recipient inboxes * **Bounced**: Emails rejected by the recipient mail server * **Delivery chart**: Delivered (blue) vs. failed (red) emails for the email domain. Hover over any point to see the exact counts for that hour. * **Email activity log**: An expandable list of recent emails sent for the current project, showing recipient, status (completed, failed, pending), type (auth email, app email, or test email), timestamps, and detailed execution traces with error messages for failures. ## Email deliverability best practices When sending emails from a new domain, inbox placement may take time to stabilize. Inbox providers evaluate sender reputation over time based on engagement, authentication, and sending patterns. Follow these practices to improve deliverability and build a strong sender reputation. New email domains have no sending history. Inbox providers treat them cautiously because spammers often use fresh domains and abandon them quickly. Initial deliverability may fluctuate during the first few days or weeks. This is normal. Your domain's reputation builds gradually as real users engage with emails. This includes: * Authentication emails: Signups, password resets, email verifications * App emails: Order confirmations, shipping notifications, account updates Both email types contribute to your overall domain reputation. Using a dedicated transactional subdomain helps isolate authentication traffic and protect your primary domain reputation. **Typical timeline** * First few days: Test emails may land in spam * First few weeks: Deliverability improves as legitimate traffic builds reputation * First few months: Reputation stabilizes with consistent, engaged sending **What helps:** * Start sending with normal authentication traffic (user signups, password resets) * Let volume grow naturally as your user base expands * Add app emails gradually as transaction volume grows * Maintain consistent sending patterns over weeks and months * Ensure emails are expected and triggered by real user actions * Mark legitimate emails as “Not spam” in your inbox **What hurts:** * Sudden large spikes in email volume from a brand-new domain * Sending bulk test emails immediately after setup * Inconsistent sending (long gaps followed by sudden bursts) * Panic-driven changes to domains or sender identity Reputation builds automatically with consistent, legitimate sending behavior over time. Authentication must pass for emails to reach the inbox. Lovable automatically configures `SPF`, `DKIM`, and `DMARC` when you set up your email domain. If DNS records are modified or misconfigured, authentication can fail and emails may land in spam. Always confirm the domain status is **Verified** in **Cloud tab → Emails**. Authentication emails should only be triggered by real user actions, such as signing up or resetting a password. App emails should only be sent when directly related to user activity, for example: * Order confirmations: Only to the customer who placed the order * Shipping notifications: Only to customers with active shipments * Account updates: Only to users who made changes or need to be notified Avoid generating artificial traffic for testing or automation purposes. Unnatural traffic patterns can negatively affect domain reputation. Don't send to: * Email addresses that previously bounced * Users who unsubscribed from non-essential notifications * Inactive or closed accounts Authentication emails should clearly match the user's recent action and explain why the email was sent. App emails should focus on information relevant to the specific transaction or event. **Good practices**: * Use straightforward subject lines ("Reset your password", "Verify your email") * Include all necessary details (order numbers, tracking links, amounts, dates) * Clearly explain what the user needs to do * Match the email to the action the user took **Avoid**: * Adding marketing content or upsells to auth emails * Misleading or clickbait subject lines * Promotional language in authentication emails Mixing promotional content into transactional emails can trigger spam filters and reduce trust. Use a consistent: * From address * Sender name * Domain Frequent changes to sender identity reduce trust signals with inbox providers. Authentication emails (password resets, email verification, magic links) don't require unsubscribe links as they're necessary for service functionality. Lovable automatically adds unsubscribe functionality to all app email templates. When a user unsubscribes, their email is added to a suppression list and future app emails to that address are blocked automatically before sending. Don't remove the unsubscribe footer as this violates email sending requirements and will affect deliverability. When customizing email templates: **Do**: * Use clear, descriptive subject lines ("Your order has shipped", "Reset your password") * Keep formatting simple and clean * Use a balanced text-to-image ratio * Include your brand name and a recognizable sender address * Ensure links in the email match your sending domain whenever possible **Don't**: * Use ALL CAPS in subject lines * Add excessive punctuation (!!!) * Create misleading subject lines * Use image-heavy layouts * Link to unrelated or mismatched domains Inbox providers look for consistency between the sender domain and the domains used in links. If your email is sent from `yourdomain.com`, links inside the email should ideally point to `yourdomain.com` or its subdomains. Mismatched domains are commonly used in phishing attacks and may trigger spam filtering. Clear, predictable formatting and domain alignment improve trust and engagement. High bounce rates damage sender reputation. Use **Analytics and logs** to monitor: * Sent * Delivered * Bounced Hard bounces caused by invalid or mistyped addresses are especially harmful. Repeatedly sending to invalid addresses can reduce inbox placement. If bounce rates increase: * Review how email addresses are collected * Validate inputs at signup * Avoid retrying failed deliveries repeatedly Spam complaints also negatively affect reputation. Both authentication and app emails should always be expected and clearly explained. The **Send test** option in **Cloud tab → Emails** is useful for validation, but limit your testing. **Why this matters**: * Inbox providers evaluate engagement signals from all emails you send * Repeated test emails to the same address create artificial traffic patterns * Bouncing test emails to fake addresses damages your reputation **Better approach**: * Send a few test emails to yourself or your team * Use real email addresses you control * Avoid sending large batches of test emails If authentication emails are marked as spam: 1. Confirm the domain status is **Verified** 2. Ensure DNS records are correctly configured 3. Review subject lines and content 4. Check bounce rates in **Analytics and logs** 5. Reduce sudden spikes in sending volume 6. Be patient. New domains need time to build trust with inbox providers Deliverability improves with consistent, legitimate sending behavior over time. Inbox providers consider engagement when evaluating sender reputation. Authentication emails naturally generate positive signals when users: * Open the email * Click the verification or reset link * Complete the intended action App emails generate positive signals when users: * Open order confirmations to check details * Click tracking links in shipping notifications * Interact with account update information Clear messaging and expected flows increase engagement and improve long-term inbox placement. Gmail clips emails larger than 102 KB. Keep your total email size under 100 KB to ensure your content displays fully. **Best practices:** * Optimize images before embedding them in app emails * Avoid large embedded images in receipts or order confirmations * Keep order details and transaction information concise * Consider linking to images hosted on your domain instead of embedding large files Lovable includes plain text versions of emails automatically for accessibility and as a fallback for email clients that don't support HTML. While link tracking and open tracking can be useful for measuring engagement with marketing emails, they can hurt deliverability for transactional emails. Why this matters: When a shipping notification or order confirmation link doesn't lead directly to your domain, it can make the email look suspicious to inbox providers. Recommendation: For app emails like order confirmations and shipping notifications, use direct links to your domain rather than tracking redirects whenever possible. Inbox providers don't share their spam filtering criteria publicly (to prevent spammers from gaming the system). However, they generally evaluate: * **Sender authentication**: Are `SPF`, `DKIM`, and `DMARC` configured correctly? (Lovable handles this automatically) * **Sender reputation**: What's your history of bounces, complaints, and engagement? * **Content quality**: Are subject lines clear? Is formatting clean? Do links match your domain? * **Engagement signals**: Do users open emails? Click links? Reply? Or mark them as spam * **Sending patterns**: Are you sending consistently? Or in sudden bursts? Think: "What would a phisher do?" Then do the opposite. Inbox providers want to protect their users, so demonstrate at every step that you're a legitimate sender with no malicious intent. ## Troubleshooting Possible causes: * DNS records not fully propagated * `NS` delegation incorrect * `TXT` verification record missing * DNS configured on wrong domain level **What to do:** * Recheck the exact DNS records shown in **Cloud tab → Emails** * Confirm records were added to the correct root domain * Wait up to 48 hours for propagation * Retry verification This means required DNS records were changed, removed, or expired after verification. **What to do:** * Review DNS records in **Cloud tab → Emails** * Restore missing `NS` or `TXT` records * Re-verify the domain The domain was deleted while this project was still using it. Go to **Cloud tab → Emails → Manage domains**, connect a different verified domain to this project, or add and verify a new one. Check: * Email domain is linked to your project * Domain status is **Verified** * Emails are enabled for the project * For authentication emails: Cloud Auth is enabled, and you are triggering a supported auth event type * The correct edge function is deployed * Emails are rate limited to **100 emails per hour per workspace** to protect deliverability and system stability. If you need a higher limit, contact [**Lovable Support**](https://lovable.dev/support). Use **Send test** on a template tab and check **Analytics and logs** for delivery failures or bounces. Common causes: * Invalid email addresses * Typos during signup * Repeated retries to invalid addresses Validate email input at signup and avoid retrying hard bounces. This is common for newly provisioned domains. Avoid sending large volumes of internal test emails. Allow organic user-triggered emails to build reputation over time. If you edited template files but users are still receiving old versions: * Ensure the corresponding edge function was redeployed * Ask Lovable to redeploy your email templates Template changes only take effect after redeployment. If emails are consistently landing in spam or being rejected, you can use the following tools for deeper diagnostics. These tools are optional and most useful for higher-volume senders. * [Google Postmaster Tools](https://postmaster.google.com/)\ View sender reputation, spam rates, and authentication alignment for Gmail recipients. * [Yahoo Sender Hub](https://senders.yahooinc.com/)\ Monitor complaint rates and sender reputation for Yahoo inboxes. * [Spamhaus blocklist lookup](https://check.spamhaus.org/)\ Check whether your domain, IP address, or email URLs appear on major blocklists. * [Google Safe Browsing](https://transparencyreport.google.com/safe-browsing/search)\ Test links used in your emails to ensure they are not flagged as unsafe. These tools help diagnose reputation or blocklist issues that may impact inbox placement. ## FAQ **Authentication emails** are a type of transactional email related to account access and identity verification. They are automatically triggered by Cloud Auth when users perform specific security-related actions, such as sign up, reset a password, or accept an invite. Lovable provides six built-in templates that you can generate when needed. **App emails** are a type of transactional email sent in response to user activity or events in your app. They are triggered by your application logic when something happens, like a purchase or update. There are no built-in templates, you decide when to send them and what they contain. Ask Lovable to add the functionality, such as notifications, confirmations, receipts, and other updates, and it will generate the templates for you. No. Both email types use the same custom domain and the same setup process. No. Only transactional emails are supported, such as signup confirmations, password resets, order confirmations, and shipping notifications. Marketing emails, such as newsletters, promotional emails, product announcements, and similar messages are not supported. Yes. Emails require the built-in backend (Cloud) and integrate with Cloud Auth to send authentication emails. Projects connected to your own Supabase project can't use built-in emails. No. Your web custom domain controls where your app is hosted. A custom email domain controls which domain your emails are sent from. These are separate configurations because web hosting and email delivery use different DNS records and infrastructure. You can use a completely different root domain for email sending as long as you control its DNS. However, using a domain that aligns with your product brand is recommended for user trust and deliverability. Hosting your app on a custom domain does not automatically configure email sending. Yes. Lovable automatically creates a transactional subdomain such as `notify.yourdomain.com` for delivery. You can optionally display emails as coming from your root domain while delivery happens through the subdomain behind the scenes. Using a dedicated email subdomain is recommended because it helps protect your root domain's reputation. No. Lovable manages domain verification, DNS configuration, authentication records such as `SPF`, `DKIM`, and `DMARC`, and delivery infrastructure. You do not need to manage API keys or third-party email provider accounts. `SPF`, `DKIM`, and `DMARC` are email authentication standards that help inbox providers verify that your emails are legitimate and not spoofed. When you send an email, providers such as Gmail or Outlook check that: * The email is authorized to be sent from your domain * The message has not been altered in transit * The domain owner has defined a policy for handling suspicious emails If authentication fails, emails may be marked as spam, rejected, or damage your domain reputation. Lovable automatically configures and maintains: * **SPF (Sender Policy Framework):** Authorizes which servers can send email for your domain * **DKIM (DomainKeys Identified Mail):** Cryptographically signs emails to prevent tampering * **DMARC (Domain-based Message Authentication, Reporting, and Conformance):** Defines how providers handle failed authentication and protects against spoofing You do not need to manually configure these records. Lovable sets them up during domain verification and continuously monitors them. If authentication records are modified, removed, or expire, you are notified so they can be restored. Each paid workspace includes **50,000 transactional emails per month** at no additional cost. Usage is calculated across the entire workspace. Additional emails are billed 4 credits per 1000 emails. No. Emails are available on **paid plans only**. Free plans use the default Lovable Cloud Auth sender. DNS changes typically propagate within a few hours, but can take up to 48 hours. You can check the domain status in **Cloud tab → Emails**. The status updates automatically once verification completes. New email domains start with no sending reputation. If emails land in spam: • Confirm the domain status is **Verified**\ • Ensure DNS records have not changed\ • Avoid sudden spikes in sending volume\ • Avoid spam-trigger formatting\ • Check bounce rates in **Analytics and logs** Deliverability improves over time with consistent, legitimate user activity. Yes. You can customize: * Copy and tone * Brand colors * Layout and structure * Logos and images * Subject lines You can ask Lovable to update the templates or edit them directly in `supabase/functions/_shared/`. Required authentication variables and callback links must remain intact in auth emails, as well as the unsubscribe footer in app email templates. The outer email body background must remain white (`#ffffff`) to ensure consistent rendering across email clients. Inner components can use your brand colors. If emails are disabled for a project, authentication emails continue sending using the default Lovable Cloud Auth sender instead of your branded templates. App emails stop sending. Deleting an email domain is a **workspace-wide action**. All projects using that domain will immediately fall back to the default Lovable Cloud Auth sender and app emails will stop sending. # Database Source: https://docs.lovable.dev/features/database View, edit, and manage your Lovable Cloud database: browse tables, edit records, run SQL, review security policies, and restore backups. Every Lovable Cloud project includes a managed Postgres database. Describe the data your app needs in chat, and Lovable creates the tables and schema for you. For example, tell Lovable: ```text wrap theme={null} I want a place to keep track of my clients with their name, email, phone number, and notes. I also need a way to track deals, including which client it's for, the value, the stage it's in, and when I expect it to close. ``` The **Database** view lets you inspect and manage that data directly, without writing code. To open it, go to **Cloud tab → Database**. ## View tables and data The Database view lists your project's tables and views with their row counts. Tables populate as soon as your app saves information. Click a table to browse its records. Views are read-only. Tables open in an editable records view. ## Edit records Open a table to view and edit its records. Double-click a value to edit it in line. You can also: * **Filter**: add one or more column filters. Available operators depend on the column type, for example equals or contains for text, greater than or less than for numbers, and before or after for dates. * **Add row**: opens a form generated from the table's schema. Auto-generated columns are filled in for you. * **Edit row**: opens the full row for editing. Updating rows currently supports tables with a single primary key. * **Delete rows**: select rows and click **Delete**. Deleting rows cannot be undone. * **Export CSV**: download the table's records as a CSV file. * **Refresh**: reload the table after your app writes new data. The view does not update live. Records are paginated. You can show 10, 25, 50, or 100 rows per page. Edits apply directly to your project's database. On projects with Test and Live environments, check which environment you are viewing before editing. See [Test and Live environments](/features/environments). ## Run SQL queries For direct database access, use the SQL editor at **Cloud tab → SQL editor**: * The query editor autocompletes table and column names from your schema. * **Run** executes the query (or press **⌘/Ctrl + Enter**), and **Clear** empties the editor. * Results appear in a table below the query. If a query fails, the error message appears in its place. If a query contains a destructive statement such as `DELETE`, `DROP`, `TRUNCATE`, `ALTER`, or `UPDATE`, Lovable asks you to confirm before running it. You rarely need SQL. For most changes, describing what you want in chat is safer, since Lovable applies schema changes as reviewed migrations and updates your app's generated types. ## Row level security (RLS) policies Row level security (RLS) controls which data users can access across your database, storage, and realtime features. Think of a policy as a rule that decides which rows a signed-in user can see or change, for example "users can only read their own orders". Lovable sets up these rules automatically when it builds features that store user data, so one user's private data is never served to another. To review the rules, go to **Cloud tab → Database → RLS policies**. The RLS policies view lists each policy with: * **Policy name**: what the rule is for. * **Command**: the action the rule applies to. SELECT is reading data, INSERT is adding it, UPDATE is changing it, and DELETE is removing it. * **Applies to**: which users the rule covers, such as signed-in (authenticated) or anonymous (anon) users. * **Rule expression**: the condition that must be true for the action to be allowed. You can filter by section (**Tables**, **Storage**, or **Realtime**) and by table. The RLS policies view is read-only. To change a policy, ask Lovable in chat, for example: ```text wrap theme={null} Only allow users to see their own invoices. ``` ## Backup and restore Lovable Cloud takes a daily backup of your project's database. You can browse and restore them from **Cloud tab → Database → Backups**. Up to roughly 14 days of backups are retained. Each entry shows the snapshot timestamp in UTC (for example, `18 May 2026, 04:27:12 UTC`). Click **Restore to this backup** on any backup row and confirm in the dialog. Lovable rolls the database back to that point, schema and data, and the project's database is unavailable for a few minutes while the restore runs. Restoring is permanent. Any data created or changed after the chosen backup is lost. Because the schema is also reverted, your app may no longer match the database if it changed after the backup. When the restore finishes, ask Lovable in chat to test your app and patch any schema mismatches. Restoring is available to anyone with edit access to the project. On Enterprise plans, every restore is recorded in your workspace audit log. ## Database health check Get an on-demand snapshot of your Cloud database, including connections, memory, disk usage, uptime, and more, directly from Lovable chat. Prompt Lovable in chat with something like: ```text wrap theme={null} Run a health check on my Cloud database. ``` Lovable returns a summary of your database's current status so you can quickly spot issues such as high connection counts, low disk space, or memory pressure before they impact your app. ## Find and fix database performance problems Lovable can pinpoint the slowest queries in your database and use that data to optimize performance, so you can fix real bottlenecks before considering a [larger instance](/features/advanced-settings#upgrade-instance). Prompt Lovable in chat with something like: ```text wrap theme={null} My app feels slow. Find the slowest database queries and optimize the worst ones. ``` Lovable reads your database's query statistics and ranks the heaviest queries by total execution time, with call counts and timing data for each. It then investigates the worst offenders, inspects their query plans, and applies targeted optimizations, such as adding an index, where they help. A few things to know: * Query statistics build up as your app handles real traffic. A brand new or recently restarted database may have nothing to report yet. * Finding slow queries is read-only. Lovable only changes your database when it applies a fix, and it tells you what it changed. ## FAQ No. Every Cloud project gets its own isolated backend, and there is no way for one project to read another project's Cloud database. If several apps need to share one database, connect them to the same external [Supabase](/integrations/supabase) project instead. No. Backups cover the database only, both schema and data. Files in [storage buckets](/features/storage) are stored separately and are not part of database backups or database exports. No. Lovable Cloud takes one backup per day and retains up to roughly 14 days of backups. You can restore to any of those daily snapshots, not to an arbitrary moment between them. # Design guidance Source: https://docs.lovable.dev/features/design-guidance Pick from three design previews before Lovable builds, and steer typography, color, and layout when you want a specific look. **Design guidance** helps you shape the visual direction of your project before Lovable starts building. Depending on your prompt, Lovable either: * shows three lightweight **design directions**, * asks a short set of **design questions**, or * **builds directly** when the visual direction is already clear. **Design directions** help you compare different visual approaches before committing to one. **Design questions** help you steer typography, color, and layout when you already have preferences. Both are designed to help you land closer to your intent on the first build, with fewer revision cycles. ## Key benefits * **See before you build**. Compare three rendered previews side by side before committing to a direction. * **Steer the visual identity**. Choose typography, color palettes, and layouts when you want a specific look. * **Refine without restarting** Iterate on a direction while keeping its overall design language consistent. * **Explore variations later**. Generate alternatives for specific sections of an existing project, such as a hero, navbar, pricing card, or footer. * **Faster iteration**. Start with a stronger visual foundation and reduce back-and-forth revisions. ## Design directions Design directions generate three different visual approaches for your project before Lovable starts the full build. Each direction is rendered as a lightweight HTML and Tailwind preview so you can compare layouts, typography, color, spacing, and overall visual tone side by side. ### When design directions appear Lovable shows three design directions when your request is visually open-ended. For example, when you: * Ask for design options, directions, alternatives, concepts, or variations. * Ask for something beautiful, polished, well-designed, high-end, visually impressive, or with strong visual quality. * Ask to explore or draft designs, or see different concepts. * Describe an open-ended UI without specifying colors, fonts, or a brand reference. Example prompts that trigger three directions: ```text wrap theme={null} Build me a beautiful landing page for a coffee subscription Design a polished portfolio site with a high-end feel Create a visually impressive marketing page for a new product Show me some design options for a portfolio site Give me a few directions for a travel blog Landing page for a trendy tech company Explore some concepts for a pricing page ``` ### How to use design directions Open Lovable and write a prompt for what you want to build. Keep the prompt high-level if you want a wider range of visual ideas. Lovable generates three design directions in parallel. You can: * compare them side by side, * open one full-screen, * and switch between directions using thumbnails. If none of the three directions feel right, you can ask Lovable to generate another set, or continue refining the closest option. Each direction includes a **Describe changes** input and three **suggestions** with prompts for common next iterations. Click a suggestion to paste its prompt into the input field, then press the up-arrow to refine. You can also type your own refinement prompt, for example: ```text theme={null} Make it warmer Improve readability Use more whitespace Make it feel more premium ``` Lovable preserves the overall design language while applying your requested changes. You can refine up to **six times total** before submitting. Refinements can be on any of the three directions, in any order, and each one shows up as a new card. Refined versions appear after you exit the fullscreen view. Press the up-arrow once, then close fullscreen to see the new version alongside the originals. Each press of the up-arrow counts as one refinement. When you choose a direction, click **Submit**. Lovable locks in that visual direction and starts the full build. ### Design directions for existing projects Design directions also work on existing projects. Ask Lovable for variations of a specific section or component, such as: ```text theme={null} Show me three options for the hero section Three navbar variations Give me three pricing card designs Redesign the pricing page with three different concepts Three options for the footer with a darker theme ``` You can also upload a screenshot of an existing section and ask Lovable to generate redesigns based on it. ## Design questions Design questions help you define a visual identity before Lovable builds your project. Lovable walks you through a short set of guided choices for: * **Typography**\ Pick from font pairs (heading + body) grouped by feel: modern tech, editorial, creative, lifestyle, technical, and others. * **Color palette**\ Pick from curated swatches grouped by mood: warm and earthy, cool and calm, bold and vibrant, soft pastels, professional, and more. * **Layout**\ Pick from wireframe options: hero grid, single column, split screen, sidebar, masonry, bento grid, magazine, full-width sections, zigzag, card grid, asymmetric, broken grid, feed, gallery, and others. After you submit, Lovable turns your choices into a detailed design brief with named fonts, hex colors, layout approach, and uses it as the spec for the build. ### When design questions appear Lovable shows design questions when the project benefits from a stronger visual identity, or your prompt leaves important visual decisions open-ended. This commonly includes: * landing pages, * portfolios, * blogs, * marketing sites, * and other visually expressive surfaces. You can also trigger design questions directly with prompts like: ```text theme={null} Build me a portfolio site with a serif typeface Landing page with a muted color palette Marketing site with a split-screen layout ``` ## When Lovable skips design guidance Lovable builds directly when the visual direction is already clear or unnecessary. This includes prompts that: * specify fonts, colors, or branding, * reference another product or style directly, * include a URL to clone, * or use a named design system. Lovable also skips design guidance for: * dashboards, admin panels, internal tools, and games, * functional requests with little or no UI design work, such as authentication, database schema, RLS policies, and edge functions, * projects created from a [design template](/features/business/design-templates) or connected to a [design system](/features/design-systems), as the design is already set. To skip design guidance intentionally, include a detailed visual brief directly in your prompt. ## Limitations * **Previews are placeholders.** Generated previews use generic copy and image placeholders. The full build replaces them with content tailored to your app. * **Generation adds time.** The three-direction step takes a few seconds before the full build starts. * **Refinements are capped.** You can refine **up to six times** total before submitting. The dialog disables further refinements when the limit is reached. * **Curated assets.** The design questions flow draws from a curated set of font pairs, palettes, and layouts. To use custom tokens, components, or guidelines, see [Design systems](/features/design-systems). * **No off switch.** To skip the design step, write a specific design brief into your prompt and Lovable will build directly. ## FAQ Yes. Ask for variations of a specific part. For example: ```text theme={null} Show me three options for the hero section Show me three navbar variations ``` Lovable generates alternatives you can pick from. You can also attach a screenshot of a section and ask for redesigns based on it. Ask Lovable to generate new ones, or refine and describe what you want changed in the **Describe changes** input on the closest direction. Yes. Pick the closest direction, then refine. For example: ```text theme={null} Use this layout but the warmer palette from the second option ``` Lovable keeps the overall visual language consistent while applying your requested changes. Up to six refinements per round. Refinements can be on any of the three directions. After that, submit a direction to continue with the build, or generate a fresh set of three directions. Not through the design questions flow, as it draws from a curated list. You can choose **Describe your own** on any question to write a preference in your own words. To use custom tokens, components, or guidelines across projects, see [Design systems](/features/design-systems). Lovable focuses the design step on surfaces where the visual direction matters most, such as landing pages, marketing sites, blogs, and portfolios. Dashboards, admin panels, internal tools, and games skip the step and use Lovable's standard build flow. Lovable skips design guidance automatically and builds using the existing tokens, components, and visual rules from the template or design system. No. Design guidance uses standard chat messages and does not add additional credit costs. # Design systems Source: https://docs.lovable.dev/features/design-systems Create reusable design systems in Lovable to standardize React component libraries, styling guidelines, and setup across enterprise projects. Lovable design systems are available on **Enterprise plans** and work natively with design systems that are implemented as React components. **Design systems** let you define your component library, styling guidelines, and installation instructions once, and reuse them across every project in your workspace. When a design system is connected to a project, components, rules, and updates flow from the design system project into every project connected to it. In Lovable, a design system is created as a **dedicated project**. This project serves as the source of truth for your design system and can be connected to other projects in your workspace. ### What you get * Centralized source of truth for UI components, tokens, and styles * Your library's React components delivered directly into every connected project, ready for use * One-click updates: when you release a new version, connected projects see an **Update available** prompt in the chat * Automatic setup verification after every connect or update — Lovable checks the wiring (build config, CSS imports, theme providers, dependencies) and fixes anything missing * Adherence enforcement during ongoing work: Lovable catches raw colors, custom or customized components, and other deviations from your design system ## How design systems work A design system in Lovable defines how components, styles, and setup instructions are applied across projects. Design systems *are* Lovable projects and can be opened and edited like any other project. ### What a design system consists of A design system in Lovable combines three core parts: 1. **Components**: your React component library 2. **Schema and guidelines**: a machine-readable schema (tokens, component catalog, constraints) plus rendered documentation Lovable reads on every generation 3. **Installation**: setup instructions and required configuration If you already have these in place, you can create a **design system project** in Lovable and reference your existing materials. If your documentation is scattered or incomplete, you can create and improve the design system directly inside Lovable. ### The design system project and the `.lovable` folder The design system project owns a special `.lovable` folder. When you release your design system, Lovable generates the following: * `design-system.json`: the standardized, machine-readable schema, including tokens, component catalog (variants, props, examples), and stack constraints. This is the source of truth. * `rules/components.md`: component catalog, rendered from the schema. * `rules/design-tokens.md`: token reference, rendered from the schema. * `rules/library-guidelines.md`: stack requirements and usage rules, rendered from the schema. * `system.md`: high-level installation instructions and design philosophy. This file is preserved across releases, meaning that Lovable does not regenerate it from the schema. You can edit `system.md` through the Knowledge tab in the project settings or by chatting with Lovable directly. The other files are regenerated on every release. ### How design systems are applied to projects When a project is connected to a design system, Lovable performs a **file-copy attach**: * The design system's React components are copied into the connected project at `src/design-system//`. Lovable imports components from there. * The design system's `.lovable` knowledge files (schema, rendered rules, and `system.md`) are copied to `.lovable/rules/libraries//`. Lovable reads them on every generation. * Required runtime dependencies are merged into the connected project's `package.json`. * A `[[libraries]]` entry in `lovable.toml` records which design system is connected and at what version. The components are then ordinary local, readable, and usable React resources in the connected project. Avoid editing them: local edits are replaced the next time you accept an update from the design system. If you need permanent changes, propose them in the relevant design system project. ### Updates When you release a new version of your design system, every connected project sees an **Update available** prompt in the chat. Accept the update and Lovable reruns the *file-copy attach* against the new version: old design system files are removed, new ones are copied in, dependencies are remerged, and setup verification reruns. The connected project's own code is untouched. ### Setup verification After a design system is attached to a project (either at project creation or in an existing project), the agent runs a silent verification pass to confirm that the design system is wired up correctly. This pass checks that: * Your build pipeline picks up the design system's source folder, and does not fail. * The design system's styling entry is imported wherever your project loads styles. * Any wrapper components or providers the design system requires are in place at the appropriate scope. * All required dependencies are declared in `package.json`. If everything is correctly wired up, the verification leaves no trace in the chat. If anything is missing, Lovable corrects it in a follow-up generation and reruns the check, until everything is in place or a short checklist of what couldn't be fixed surfaces in the chat. Setup verification turns are billed at **zero credits** and do not count toward your workspace usage. ### Adherence checks While you're working in a connected project, every generation is scanned for violations of the design system: * Raw color literals where a design system token should be used * One-off values that bypass the design system's tokens or scale * Inline styles that override the design system's defaults * Local component implementations for things that should come from the design system When violations are found, Lovable automatically retries to correct them before finishing the generation. ### Key notes and limitations * The `.lovable` folder is owned by the design system project and cannot be edited from connected projects. * Connected projects record the version of the design system they were last attached at. Updates apply when accepted from the chat prompt. * Lovable design systems work natively with React component libraries. * A design system is created as its own dedicated project from the **[Create a design system](#create-a-design-system)** flow. * An unreleased design system cannot be used as the basis for a new project. Create an initial release first. * A project can be connected to at most one design system at a time. To switch, remove the current one first: open the **Design system** section in **Project settings → General**, then choose **⋯ → Remove** on the connected one. * Removing a design system severs the managed link: the project stops receiving updates and the agent no longer enforces its rules. The copied files stay under `src/design-system/` as ordinary, editable code, so nothing using them breaks; they are now yours to maintain. * If your design system or related documentation is hosted within your VPC, reach out to your account team for guidance. * Design systems are supported for React. Other frameworks such as Vue, Angular, or Svelte are not supported today, so your mileage may vary. Reach out to your CSM or FDE if you need them. * New projects created from a design system currently scaffold on a TanStack template, even when the design system is a Vite/React one, and the styling framework is not always wired into the build automatically. A consumer that uses Vite can pull in Tailwind 3, which conflicts with Tailwind 4. When this happens, Lovable's setup verification usually corrects the wiring on the first generation; if styles still look wrong, ask Lovable in the connected project to wire up the design system's styling framework. Deterministic scaffolding and styling setup are known limitations being improved. ## Create a design system If your component library or packages are private, go to **Workspace settings → Build secrets** and add the required build secrets (for example, npm tokens). From the `+` dropdown of the [lovable.dev](https://lovable.dev) prompt box, select **Design** and select **Use a design system**. In the modal, select **Create design system**. This creates a new design system project. Lovable assigns a name to your project, which you can change from the project settings. Give your design system a meaningful name. This name is used when connecting the design system to projects later. You can set up your design system in two main ways. **Option A: Bring an existing library** Tell Lovable in chat how your design system is distributed: * **An npm package**: give the package name. Public packages are fetched automatically; for a private package, add its npm token under **Workspace settings → Build secrets** first. * **A public Git repository**: share the repository URL and Lovable imports the components from it. * **A private repository, or loose files**: there is no private-repository fetch. Clone the repository yourself (or export the files) and upload them, and Lovable integrates them. Once imported, Lovable extracts a schema from your component source on release: variants, props, and examples are captured automatically. For usage context the schema can't infer (design philosophy, narrative usage rules, installation quirks), edit `system.md` via the Knowledge tab in project settings or by chatting with Lovable directly. When bringing an npm package or a public repository, you can skip the guided questions and just give the package name or repository URL. **Option B: Build your design system with structured instructions** If your documentation is scattered or incomplete, guide Lovable explicitly to build your design system. This approach lets you: * Import PDFs, Markdown files, screenshots, and other assets * Define components, patterns, tokens, and styling guidelines * Write installation and setup instructions * Update everything dynamically across connected projects **Suggested prompt structure** ``` [High-level goal] [Install instructions] [Other context for setting up the system, for example tech stack and constraints] [Component library request] [Links to documentation, sites, PDFs, MCPs for more context. Lovable can crawl websites so feel free to include wide context here.] ``` After the first run, Lovable will generate a working design system project, for example: [https://design-system-demo.lovable.app/](https://design-system-demo.lovable.app/) Select **Release version** in the design system project. Lovable generates the schema, renders the documentation, bumps the version, and commits everything to the design system project's repository. The design system is now selectable when creating new projects or attaching to existing ones. Re-release whenever you want to push updates to connected projects. ## Prepare your library to release cleanly How a design system releases depends on where its components come from. There are two paths, each with its own prerequisites: * **Local source (Path A)**: the component source lives in the design system project itself, whether built in Lovable, imported from a public Git repository, or uploaded by you. Releasing reads tokens and components straight from that source. * **npm wrapper (Path B)**: the design system wraps an external npm package. Releasing reads the component surface from the package's published type definitions, and the project holds only a thin wrapper layer. Lovable records the path when the project is created and uses it to build the schema on release. Get the prerequisites below right, and release, attach, and adherence all work without manual cleanup. ### Local source (Path A) A local design system releases cleanly when Lovable can find your tokens and components: * **Tokens** are discovered from top-level styling files: CSS custom properties in files like `src/index.css` or `src/styles/tokens.css`, a `tailwind.config`, or a `theme`/`tokens` source file. Component-local stylesheets buried deeper in the tree are not treated as the token source. * **Components** are discovered from a barrel (`src/index.ts` or `src/index.tsx`) when one exists, otherwise from the files under `src/components/`. * **`system.md`** carries everything the schema can't infer: design philosophy, narrative usage rules, and installation quirks. Author it by hand; releasing never overwrites it. When you build a from-scratch design system with structured instructions, you can seed it with uploads (PDFs, Markdown, screenshots, and other assets). Lovable interprets these on a best-effort basis. There is no guarantee that every file or format is turned into working components or tokens, so review the generated schema and components after the first run and iterate where the result isn't what you expected. ### npm wrapper (Path B) A wrapper design system releases cleanly when the upstream package and the wrapper are both in good shape: * **The upstream package must ship typed exports** (a `.d.ts` entry or an `exports` map). Releasing reads the component surface from those types. A package that ships no types has nothing to extract, and the release fails. * **Keep `src/` near-empty.** With a wrapper, the real components come from the npm package, so the project only needs thin wrapper or provider files. Everything in `src/` that isn't excluded is copied into connected projects, so extra scaffolding in `src/` becomes noise in every consumer. The wrapper itself splits into two cases depending on where the upstream package is hosted. #### Public npm package If the upstream is published to the public npm registry, nothing else is required: the design system just needs to be marked as wrapping that package name. Releasing fetches the package from the public registry. #### Private registry package If the upstream lives on a private registry (for example GitHub Packages or a self-hosted registry), two things are required so that both releasing and the connected projects can install it: * **The package must be scoped** (`@scope/name`). * **A scoped `.npmrc` backed by a workspace build secret.** Add the registry and auth lines for the scope, for example: ```text theme={null} @scope:registry=https://your-registry.example.com //your-registry.example.com/:_authToken=${NPM_TOKEN} ``` `NPM_TOKEN` references a token stored under **Workspace settings → Build secrets**. You can provide the registry URL and secret when you create the design system (Lovable writes the `.npmrc` for you) or author the `.npmrc` lines yourself. Without recorded auth for a scoped private package, releasing stops and asks you to add these lines, because the same configuration is what lets connected projects authenticate on attach. This also covers packages you publish to your own private registry, including the Lovable-managed workspace registry (see [Private registry](/features/private-registry)). When the registry is set up and your package is published there, wrap it by name like any other scoped private package. ### What gets copied to connected projects Attach copies only two parts of the design system project into each connected project: your component source under `src/`, and your `.lovable/` knowledge files. A few things are excluded by default so they don't leak into consumers: * **Showcase and demo pages.** Anything under `src/pages/` or `src/routes/`, and any `*.stories.ts`/`*.stories.tsx` file, is excluded. Put your showcase there so you can preview the library without shipping the preview app to every consumer. * **Tests and scaffold entrypoints** (`src/main.tsx`, `src/App.tsx`, test files, and similar) are excluded too. * **Knowledge files** live in `.lovable/rules/*.md` and are always propagated. Knowledge is never excluded. You can adjust the exclusions with a `.dsignore` file at the project root, which uses gitignore syntax and layers on top of the defaults. Use it to exclude extra internal files, or to re-include something a default would otherwise drop. ## Connect a design system to projects A project uses one design system at a time. You can remove it later from the **Design system** section in **Project settings → General** (open it, then **⋯ → Remove** on the connected one): this severs the managed link and leaves the copied files under `src/design-system/` as ordinary, editable code (nothing using them breaks, but they are no longer managed or updated). In each project's settings, you can see which design system is connected and which ones are available to connect. ### Connect a design system to new projects From the `+` dropdown of the [lovable.dev](https://lovable.dev) prompt box, go to **Design** and select **Use a design system**, select the design system you want to use, then enter your prompt. Lovable generates your new project using the selected design system. Only released design systems are available for selection. If the design system you want to use is marked as **Draft**, open the design system project and release it first. ### Connect a design system to existing projects To connect a design system to an existing project, follow the steps below: 1. Select the project name in the top bar and choose **Design system** (or open **Project settings → General** and find the **Design system** section). 2. Click **Attach design system** to open the design-system dialog in the editor. 3. Select a design system from the grid. Lovable copies the design system's components and knowledge files into your project, merges dependencies, and runs setup verification automatically. ## Refine your design system Design systems are meant to evolve. After the initial setup, iterate on the contents of the `.lovable` folder and your component source. 1. **Check the structure**\ Open the `.lovable` folder to see how Lovable generated your schema and documentation. These files are what gets applied to all connected projects on the next update. 2. **Fix inconsistencies**\ If components do not render correctly, ask Lovable to fix them and update the schema at the same time. Re-release to push the fix to connected projects. 3. **Add detail**\ Request additional component documentation, token definitions, or usage patterns as needed. Each release bumps the version and notifies connected projects of an available update. ## `.lovable` folder structure Lovable generates this automatically when you release. In the **design system project**: ``` .lovable/ ├── design-system.json # canonical schema (tokens, components, constraints) ├── system.md # high-level installation instructions, hand-authored └── rules/ ├── components.md # rendered from design-system.json ├── design-tokens.md # rendered from design-system.json └── library-guidelines.md # rendered from design-system.json ``` In a **connected project**, the design system's `.lovable` files are copied to a namespaced subfolder: ``` .lovable/ └── rules/ └── libraries/ └── / ├── design-system.json ├── system.md ├── components.md ├── design-tokens.md └── library-guidelines.md ``` The corresponding component source lives at `src/design-system//` in the connected project, imported as `@/design-system//...`. ## Fetch external design system documentation with MCP servers MCP servers can be used to fetch design system documentation that is stored separately from your npm packages. See [Integrate with your tools using chat connectors (MCP servers)](/integrations/mcp-servers) for more information. ## Troubleshooting If your design system uses React 19 but the project defaults to React 18, or vice versa, tell Lovable explicitly. For example: ```text wrap theme={null} My design system requires React 19. Please update the project dependencies accordingly. ``` If your design system uses a different styling solution than the project's defaults, ask Lovable to remove the conflicting dependencies. For example: ```text wrap theme={null} Please uninstall the project's default styling dependencies. My design system uses [your styling solution] instead. ``` Setup verification usually catches this and fixes the wiring automatically. If something still looks off, open the chat in the connected project and ask Lovable to verify the design system is wired up correctly. It will rerun the check and propose fixes. The adherence scanner catches most violations automatically. If it misses something, point it out in the chat. For example, "use the Button from the design system here, not a custom one." Lovable will replace the local implementation with the design system component. Your design system wraps a package on a private registry, but Lovable has no recorded way to authenticate to it. Make sure the package is scoped (`@scope/name`) and add the registry and auth lines for that scope to `.npmrc`, backed by a workspace build secret: ```text wrap theme={null} @scope:registry=https://your-registry.example.com //your-registry.example.com/:_authToken=${NPM_TOKEN} ``` Add the `NPM_TOKEN` secret under **Workspace settings → Build secrets**, then release again. The upstream package could not be fetched. Confirm the build-secret token can read the package, that the package name and scope are correct, and that the `.npmrc` registry line points at the right host. For the Lovable-managed registry (see [Private registry](/features/private-registry)), make sure the workspace's private npm registry is enabled in workspace settings. Then release again. A wrapped npm package is read through its published type definitions. If the upstream package ships no `.d.ts` types or `exports` map, there is nothing to extract. Wrap a package that ships types, or build the components as a local (from-scratch) design system instead. Lovable could not identify any tokens or components in the project. For a local design system, check that tokens live in a top-level styling file (CSS variables, `tailwind.config`, or a `theme`/`tokens` file) and that components are exported from `src/index.ts` or live under `src/components/`. Ask Lovable to run the design system discovery step, then release again. ## FAQ Yes, a design system is a regular Lovable project that is marked as a design system. It can be opened and edited like any other project, and other projects can connect to it. If the design system wraps an external npm package, the package itself isn't editable from Lovable, only the wrapper layer in the design system project is. Changes to the underlying components have to be made in the upstream npm package and republished there. No. A project can be connected to at most one design system at a time. To switch, remove the current one first: open the **Design system** section in **Project settings → General**, then choose **⋯ → Remove** on the connected one. No. A design system is created as its own dedicated project from the **[Create a design system](#create-a-design-system)** flow. An existing project can't be converted into one. Once created and released, it becomes available for other projects in the workspace to connect to. Select the project name in the top bar and choose **Design system**, or go to **Project settings → General** and open the **Design system** section. It shows the connected design system and opens a dialog to browse and attach available ones. Yes. Every release bumps the version. Connected projects record the version they were last attached at, and an **Update available** prompt appears in the chat whenever a newer version is released. A draft design system exists as a project but has not been released yet, so it has no schema or rendered documentation. You cannot use a draft design system as the basis for a new project. Release it first. Once released, the design system gets a version number and becomes selectable in the design system picker. Yes. In **Project settings → General**, open the **Design system** section, then choose **⋯ → Remove** on the attached design system and confirm. This severs the managed link: your project stops receiving updates from that design system, and the agent no longer follows its rules. The component files stay under `src/design-system/` as ordinary, editable code, so nothing already using them breaks; they are now yours to maintain. The design system's source and documentation are managed by the design system project. The files in `src/design-system//` and `.lovable/rules/libraries//` are present in a connected project's git, so you can read and import them, but local edits will be replaced the next time you accept an update. For permanent changes, propose them in the design system project. No. Design systems are an in-Lovable feature. Components and documentation flow directly between your Lovable projects. If you also want to publish your design system to a public npm or a private registry for use outside Lovable, that's a separate flow. A from-scratch (local) design system holds its component source directly in the design system project. Lovable reads tokens and components from that source when you release. An npm-wrapper design system wraps an external npm package: Lovable reads the component surface from the package's published type definitions, and the project holds only a thin wrapper layer. For a public npm package nothing extra is needed. For a package on a private registry, the package must be scoped (`@scope/name`) and you add a scoped `.npmrc` backed by a workspace build secret so both releasing and connected projects can authenticate. Lovable design systems support **React-based component libraries** out of the box. The design system declares its required stack and dependencies through its schema, and Lovable adapts the setup automatically. Your library determines what gets wired up, not a fixed list of supported frameworks. If your design system is built with other frameworks such as Vue, Angular, or Svelte, reach out to your CSM or FDE. When you attach a design system, Lovable runs an automatic setup verification pass to check that the design system is wired up correctly (configuration, CSS imports, theme providers, dependencies, and import paths). If the agent finds gaps, it applies fixes and reruns verification. Successful verifications are silent and do not appear in the chat. Verification turns are billed at zero credits. No, design systems do not replace templates. Templates and design systems serve different purposes and are often used together. Templates are best for initial project scaffolding, while design systems provide ongoing UI and design guidance across projects. # Edge functions Source: https://docs.lovable.dev/features/edge-functions Run serverless backend code in your Lovable Cloud app and monitor invocations, success rates, and logs for each function. Edge functions run your app's custom backend code: the work that can't happen in the user's browser, such as talking to other services, processing payments, or sending emails. Think of them as small programs that run on Lovable's servers whenever your app needs them. There are no servers for you to set up, and they scale automatically with traffic. You don't create edge functions by hand. Describe what you need in chat, and Lovable writes, deploys, and maintains the function for you. For example: ```text wrap theme={null} When a payment is marked 'paid' in Stripe, automatically update the related invoice's status to 'Paid'. ``` **Common use cases:** * AI-powered features, such as AI summaries or AI chatbots, using built-in [Lovable AI](/features/ai) * Sending emails or push notifications * Payment processing, for example with [Stripe](/integrations/stripe) * Heavy computations or external API calls Edge functions read API keys and credentials from your project's [secrets](/features/secrets), so sensitive values never appear in code. For recurring work on a schedule, see [Jobs](/features/jobs). ## Monitor your functions Go to **Cloud tab → Edge functions** to see every function in your project, with its status, invocation count, success rate, and when it was last updated. The time range selector has two modes: **Relative** covers ranges from the last 15 minutes up to the last 5 days, and **Absolute** lets you pick an exact start and end time. Click a function to see how it performed over time: * **Succeeded** and **Failed** invocation counts with a chart over the selected range. * **Copy URL** to copy the function's endpoint. * **View logs** to open [Logs](/features/logs) pre-filtered to this function's output. * **View code** to open the function's source in the code editor. If a function fails, Lovable surfaces the error so you can ask it to fix the problem in chat. ## FAQ Ask Lovable in chat. There is no create button in the Edge functions view: Lovable writes and deploys functions as part of building the feature you describe. To change one, describe the new behavior, or open its code with **View code**. No. Edge functions are unavailable while a project is paused, so features that depend on them stop working until you resume the project. See [Pause Cloud](/features/advanced-settings#pause-cloud). Open the function and click **View logs**, which opens the Logs view filtered to that function. Each failed invocation includes the error output. You can also paste the error into chat and ask Lovable to fix it. # Email authentication in Lovable Cloud apps Source: https://docs.lovable.dev/features/email-auth Configure email sign-in for your Lovable Cloud app: confirmation, password rules, one-time codes, and sending limits. This page documents email authentication settings for apps using the [built-in backend (Cloud)](/features/cloud). Projects connected to your own Supabase project manage authentication in Supabase instead. For an overview of all sign-in methods and user management, see [Users and authentication](/features/authentication). Let users sign up for your app with an email address and password. Email is the default sign-in method, and Lovable generates the signup, login, and password reset flows for you. For example, tell Lovable: ```text wrap theme={null} Add login to the app with email and password. Require login before accessing the dashboard. ``` To configure it, go to **Cloud tab → Users → Auth settings → Email**. ## How email sign-in works for users * **Signing up**: the user enters an email address and password. Unless auto-confirm is on, they receive a confirmation email and verify the address before they can sign in. * **Signing in**: email and password, or a passwordless flow if you build one (see below). * **Resetting a password**: the user requests a reset, receives a password reset email, and picks a new password. * **Changing an email address**: with secure email change on, both the old and new address must confirm the change. Every email in these flows can be sent from your own domain with your own branding. See [Custom emails](/features/custom-emails). ## Passwordless sign-in Email sign-in doesn't have to mean passwords. Ask Lovable to build a magic link or one-time code flow instead: ```text wrap theme={null} Let users sign in with a magic link sent to their email instead of a password. ``` The **One-time codes** settings below control how long emailed codes and magic links stay valid, and how many digits codes have. ## Email confirmation Two settings control how addresses are verified: * **Auto-confirm email**: sign users in immediately without requiring them to confirm their email address. With auto-confirm off, users receive a confirmation email and must verify the address before signing in. * **Secure email change**: require confirmation on both the old and new address when a user changes their email. Auto-confirm makes testing easier, but confirmed emails are worth keeping for real apps: without confirmation, anyone can sign up with an address they don't own. ## Password rules Four settings set the bar for passwords: * **Minimum password length**: minimum 6 characters; 8 or more is recommended. * **Required password characters**: choose between letters and numbers; lowercase, uppercase, and numbers; or lowercase, uppercase, numbers, and special characters. * **Password HIBP check**: reject known or easy-to-guess passwords using the Have I Been Pwned database of leaked passwords. * **Require re-authentication for password changes**: require a recent login before a password can be changed. Stricter rules protect accounts but add signup friction. The HIBP check is the highest-value setting here: it blocks the passwords attackers try first, without making rules harder for everyone else. ## One-time codes For login flows that email a one-time code instead of using a password: * **Email OTP expiration (seconds)**: how long a code or magic link stays valid, from 60 seconds to 24 hours. * **Email OTP length**: 4 to 8 digits. ## Sending limits **Rate limit for sending emails**, found under **Advanced** in the email settings, caps how many authentication emails your project sends per hour. If your app signs up many users at once and confirmations stop arriving, this limit is the first thing to check. To raise it, first set up email sending for the project, either managed email or a verified custom domain. See [Custom emails](/features/custom-emails). ## Troubleshooting Ask users to check their spam folder first, since emails from new domains often land there. If many signups happen at once, your project may have hit its hourly email rate limit. For better deliverability and branded senders, set up [custom emails](/features/custom-emails). The published URL or custom domain is probably missing from your project's redirect URLs. See [Site URL and redirect URLs](/features/authentication#site-url-and-redirect-urls). Their confirmation email may have expired or landed in spam. Signing in again does not resend it; the user can trigger a new confirmation email by signing up again with the same email address. You can also create the account for them: users added with **Add user → Create new user** in **Cloud tab → Users** are confirmed automatically. ## FAQ Ask users to check their spam folder first, since emails from new domains often land there. If many signups happen at once, your project may have hit its hourly email rate limit. For better deliverability and branded senders, set up [custom emails](/features/custom-emails). Auto-confirm is convenient while building and testing, because you can create accounts without checking an inbox. For a live app, leaving confirmation on ensures every account belongs to a real, verified address. Yes. Ask Lovable to build a magic link or one-time code flow: users receive an email and sign in without typing a password. The **One-time codes** settings control how long codes stay valid and how many digits they have. Yes. Disable it under **Cloud tab → Users → Auth settings → Email**, for example if your app should only offer [Google](/features/google-auth) or [SAML SSO](/features/saml-sso) sign-in. Make sure at least one sign-in method stays enabled. Lovable generates the reset flow when it builds email sign-in: users request a reset, receive a password reset email, and choose a new password. You can customize the reset email under **Cloud tab → Emails**. Signup confirmations, password resets, invites, and magic links are sent using your project's email templates. Set up sending from your own domain and preview each template under **Cloud tab → Emails**. See [Custom emails](/features/custom-emails). # Generate files and analyze data Source: https://docs.lovable.dev/features/generate-files Analyze data, generate files, and build from the results directly in the chat. Ask Lovable to analyze data, create documents, transform files, and generate downloadable outputs directly in the chat. Lovable writes and runs scripts in an isolated environment, then returns the result as a generated file. Your project's source code is never affected. You can build on top of the result in the same conversation. After Lovable analyzes your data or generates a file, ask it to create app features based on what it found, for example by turning a spreadsheet into a dashboard or a product spec into a working app flow. On projects using the built-in backend (Cloud), code execution has access to your database only if the `Read database` and `Add data` permissions are set to `Always allow`. See [Lovable Cloud](/features/cloud) for more information. ## What you can do Upload a CSV, spreadsheet, or any supported file and ask Lovable to analyze, transform, or combine it with other data sources, such as your database or connected tools. | Use case | Example prompt | | :------------------ | :---------------------------------------------------------------------------------------------- | | Data analysis | *Analyze the sales data in my uploaded CSV and tell me the top 5 products by revenue.* | | PDF report | *Generate a PDF report summarizing this quarter's metrics from my database.* | | CSV export | *Export all orders from the last 30 days as a CSV file.* | | Data transformation | *Convert the uploaded JSON file to a formatted Excel spreadsheet.* | | Chart generation | *Create a bar chart showing monthly signups from my users table.* | | Slide deck | *Create a presentation summarizing the key findings from this dataset.* | | Diagram | *Generate an architecture diagram for my app as a Mermaid flowchart.* | | Image processing | *Resize these product images to 800x600 and convert them to WebP.* | | Database query | *How many users signed up this week? Break it down by day.* | | Data import | *Import the uploaded CSV into my products table.* | | Connected tools | *Read my open Linear issues and generate a status report as a PDF.* | | Build from a file | *Turn this Excel tracking sheet into a web app with dashboards and user login.* | | Build from a spec | *Read this PDF product spec, summarize the requirements, and build the first version.* | | Build from analysis | *Analyze my user drop-off data, then build an improved onboarding flow based on what you find.* | ## How it works Describe what you need in the chat. You do not need to configure commands, write scripts, or choose tools yourself. Lovable decides when to run code and when to build features based on your request. Lovable typically follows this flow: 1. It reads the files, data, or context you provide. 2. It writes and runs the scripts needed to complete the task. 3. It checks the result and fixes issues before delivering, for example layout problems in PDFs or missing data in generated files. 4. It returns the result as inline analysis, a generated file, or both. 5. It keeps that context in the same conversation so you can refine the output or build on it. The more specific you are about structure, formatting, tone, data sources, and the result you want, the better the output will be. ## What Lovable can run Lovable writes and executes scripts in an isolated Linux environment. If something can run in a Linux shell, Lovable can likely run it. Common tools are preinstalled, for example: | Category | Examples | | :-------------- | :--------------------------------- | | Languages | Python 3, Node.js, Bun, Deno, Bash | | Data processing | pandas, NumPy, SciPy, DuckDB | | Visualization | matplotlib, Pillow | | Database | psql for database access | | Utilities | curl, jq, and standard Unix tools | If a task needs an additional package or command line interface (CLI) tool, Lovable can install it automatically. ## Supported file types Lovable can read files you upload and generate new files in the following formats: | Category | Formats | | :------------ | :------------------------------------ | | Documents | PDF, DOCX, PPTX, TXT, Markdown | | Spreadsheets | CSV, XLSX, XLS | | Images | PNG, JPEG, WebP, SVG, GIF, AVIF, HEIC | | Video | MP4 | | Audio | MP3, M4A | | Code and data | HTML, JSON, JS, TS, Python | | Diagrams | Mermaid | | Archives | ZIP, GZIP, TAR | Files you upload for analysis can be up to **20 MB** each on the Free plan, **256 MB** each on paid plans, and **1 GB** on Enterprise, with up to 10 files per message. Generated files are stored in your project's **Files** area, not in your project's code, so they are not subject to these upload limits or to the [10 MB per-file code limit](/features/projects/chat). ## Manage generated files When Lovable creates a file, it appears in the chat as a file card. You can open it directly from the chat, or open the **Files** tab to search, preview, and download all files created in your project, or reference a file directly in the chat. You can refine generated files through follow-up prompts. When a file is revised, Lovable creates and stores a new version (for example, `report_v2.pdf`) so you can compare them. Files are securely and permanently stored with the project. To delete a file, open the file's actions menu in the **Files** tab and select **Delete**, or ask Lovable. Deleting a file cannot be undone. In the **Files** tab's grid view, images display at their real proportions, and each file has quick actions to reference it in chat, download it, copy an image to your clipboard, or delete it. ## Tips for best results * **Be specific about formatting**\ *"Create a PDF report with a cover page, section headers, and a summary table"* produces better results than *"Make a report"*. * **Name your output**\ If you want a specific filename, ask Lovable to add it, for example *"Save it as `q1-summary.pdf`."* * **Iterate**\ If the first result is not perfect, describe what to change. Lovable keeps context from prior outputs. * **Chunk large datasets**\ For very large files, ask Lovable to process a subset first, then scale up. * **Use connected tools as data sources**\ Ask Lovable to pull data from tools like Slack, Linear, or Notion, for example *"Summarize the last 50 messages from my Slack feedback channel and generate a report"*. * **Combine steps**\ You can ask for analysis and file generation in one prompt, for example *"Analyze this CSV and export the top 10 rows as an Excel file."* # Add Google authentication to Lovable Cloud apps Source: https://docs.lovable.dev/features/google-auth Add Google authentication to Lovable Cloud apps using managed Google OAuth or your own Google Cloud credentials. This page documents **Google authentication in Lovable Cloud**. The managed Google authentication flow and your own credentials setup described here are available only for apps using the [**built-in backend (Cloud)**](/features/cloud). ## Overview Lovable supports **Sign in with Google** using industry-standard OAuth 2.0, allowing users to authenticate with their Google accounts instead of creating a password. Google authentication in [Lovable Cloud](/features/cloud) can be configured in two ways: * **Managed by Lovable**: Lovable manages the OAuth client, credentials, redirect handling, and security updates. This is the default and recommended setup. * **Your own credentials** (sometimes referred to as BYOK): You connect OAuth credentials from your own Google Cloud project and manage credential security and rotation. Both options provide the same sign-in experience for users. Building an internal tool that only workspace members will use? They are already signed in to Lovable, so you may not need Google sign-in at all. See [Reuse Lovable workspace identity in your app](/features/lovable-workspace-identity-reuse). 1. The user clicks **Sign in with Google** in your app 2. Google displays a consent screen 3. The user reviews and approves access 4. Google redirects the user back to your app, signed in From a technical perspective, OAuth relies on: * a **Client ID** (identifies the application) * a **Client secret** (authorizes the application) * **redirect URLs** (where Google sends users after approval) Lovable integrates this flow directly into your application and UI. ## Why use Google sign-in Google sign-in provides a familiar authentication experience and reduces friction during signup and login. * Faster onboarding without password creation * Trusted Google consent experience * Reduced password reset and account recovery overhead * Pre-verified email addresses provided by Google * Reliable user identity with profile information ## Common use cases Google sign-in is commonly used for: * Consumer applications where social login is expected * SaaS products targeting professional users * Internal tools using Google Workspace * E-commerce accounts and order history * Communities or products that require verified email addresses ## Google authentication setup options Lovable Cloud supports setting up Google authentication in two ways: * **Managed by Lovable** * **Your own credentials** The end-user experience is identical in both cases; the difference is how OAuth credentials are managed. Lovable manages the OAuth client, credentials, redirect handling, and related security updates for this flow. No Google Cloud Console configuration required. Use this option if you: * want the simplest setup * do not want to configure Google Cloud manually * do not need ownership of OAuth credentials * do not need custom OAuth scopes beyond the defaults (email and basic profile) When using **Managed by Lovable**, the Google **consent screen** is shown the first time a user signs in. The consent screen: * Shows your application name * Indicates that the app is requesting access via Google authentication * Requests access to the user’s email address and basic profile information Users are asked to approve access once. After approval, they are redirected back to your app and will not see the consent screen again unless permissions change. ``` Add Google login to my app so that users can sign in with their Google account ``` Lovable will enable Google authentication automatically in **Cloud tab → Users → Auth settings → Google** and: * configure Google OAuth in the backend * create or update sign-in UI components * set up authentication state management * add sign-out functionality You can review the changes in the **Details** view. After enabling Google sign-in, verify that: * a **Sign in with Google** button appears * users are redirected to Google for authentication * users return to the app in a signed-in state * the consent screen behaves as expected * users can sign in and sign out successfully You create and manage OAuth credentials in your own Google Cloud project and connect them to Lovable. You are responsible for managing credential security and rotation. Use this option if you: * require OAuth under your own Google Cloud project * need full control over consent screen branding * have security or compliance requirements * need custom OAuth scopes beyond the defaults When using **your own credentials**, the Google **consent screen** is fully controlled by your Google Cloud project, including: * app name and branding * consent screen configuration * OAuth scopes Lovable uses the credentials and settings you provide without modifying the consent screen. In the [Google Cloud Console](https://console.cloud.google.com), you must: * select or create a Google Cloud project * configure an **OAuth consent screen** * create an **OAuth Client ID** of type **Web application** See [Google Auth Platform documentation](https://support.google.com/cloud/topic/15540269) for all details. * Go to **Cloud tab → Users → Auth settings → Google**. * Enable **Google sign-in** and select **Your own credentials**. * Enter your **Client ID** and **Client secret**. When using your own Google OAuth credentials, Lovable may display **multiple possible redirect URIs**, for example: * your default Lovable domain (`https://myapp.lovable.app`) * one or more custom domains you’ve added (`https://myapp.com`) In Google Cloud Console, you must add **every redirect URI you intend to use** as an **Authorized redirect URI** on your OAuth client. Redirect URIs must match exactly. Scheme, domain, path, and trailing slashes all matter. Lovable needs to know **which redirect URIs are authorized in your Google OAuth client**. After adding them in Google Cloud, return to Lovable and **select the redirect URIs you have whitelisted**. By selecting redirect URIs in Lovable, you are confirming: * which domains are authorized in your Google OAuth client * which domain Lovable is allowed to redirect users back to after sign-in This ensures Google authentication continues to work correctly across default and custom domains. Click **Save** to save and confirm your Google credentials and selected redirect URIs. Prompt Lovable to add the Google sign-in UI to your app: ``` Add Google sign-in to my app using my own Google OAuth credentials. ``` Lovable will generate the UI using your custom credentials. Before deploying to production, verify that: * a **Sign in with Google** button appears * redirect URIs are configured correctly * users return to the app in a signed-in state * the consent screen behaves as expected * users can sign in and sign out successfully ## Managing Google authentication You can switch between **Managed by Lovable** and **Your own credentials** at any time from **Cloud tab → Users → Auth settings → Google**. Switching the Google authentication setup does not affect existing user accounts. Users can continue signing in with the same Google accounts. Projects that configured their own credentials before the current setup existed may see a third option, **(Legacy) Your own credentials**. It is deprecated: switch to **Your own credentials** for automatic updates and improved branding and security. ## Troubleshooting "Your own credentials" setup * Ensure every redirect URL you selected in Lovable is added to Google Cloud * Check for missing or extra trailing slashes * Verify the scheme (`https` vs `http`) matches exactly * Ensure the OAuth consent screen is configured correctly in Google Cloud * Add your account as a test user if the app is not published * Verify required scopes are configured * Use a **Web application** OAuth client * Mobile or desktop client types are not compatible with Lovable’s redirect flow * Confirm Google sign-in is enabled in **Users → Auth settings → Google** * Verify `Client ID` and `Client secret` values (your own credentials setup) * Ensure authentication UI is connected to the backend ## FAQ No. **Lovable-managed** Google authentication is available for **Lovable Cloud apps only**. Yes. Google authentication can be added to apps not using Lovable Cloud, but it requires a manual setup outside of Lovable Cloud. For example, in apps not using Lovable Cloud, you might: * integrate Google OAuth directly in your frontend or backend code * use Google’s One Tap or standard OAuth sign-in flows * use a third-party authentication service such as Supabase Auth * manage OAuth credentials, redirect handling, and session logic yourself This page documents the **Lovable Cloud implementation**, including managed Google authentication and your own credentials flow specific to Lovable Cloud. Use **Managed by Lovable** unless you specifically need to manage your own Google Cloud OAuth credentials, customize the consent screen branding, or configure custom OAuth scopes. By default, Google provides the user’s **email address** and **basic profile information**. No additional data is shared unless you configure custom OAuth scopes (your own credentials setup only). No. Users are shown the consent screen the **first time** they sign in with Google, or if requested permissions change. Yes. You can switch between **Managed by Lovable** and **Your own credentials** at any time. Existing user accounts are not affected. This usually means the redirect URLs you selected in Lovable do not exactly match the **Authorized redirect URIs** configured in Google Cloud. * Ensure every redirect URL you selected in Lovable is added to Google Cloud. * Check the scheme, domain, path, and trailing slashes. No. Google authentication is an additional sign-in method. You can offer Google sign-in alongside other authentication methods. No. Google Cloud Console configuration is only required when using **your own credentials**. # Groups Source: https://docs.lovable.dev/features/groups Organize workspace members into groups for granular control over project access and published app visibility. Groups let you organize workspace members into named collections, making it easier to manage access across your workspace. Instead of managing permissions for individual users, you can grant access to an entire group at once. With groups, you can: * **Share projects with groups** so that an entire team gets access at once, instead of adding collaborators one by one * **Share folders with groups** so that all projects inside a folder are accessible to an entire team at once * **Control who can access published apps** by restricting a published website or internal tool to specific groups instead of the entire workspace * **Sync groups from your identity provider** so that groups created through [SCIM provisioning](/features/business/scim) appear alongside manually created groups Groups are available on **Business and Enterprise** plans. ## Create and manage groups Workspace admins and owners can create and manage groups from the workspace settings. ### Create a group 1. Go to **Settings → Groups** 2. Click **Create group** 3. Enter a group name 4. Search for and add members to the group 5. Click **Create group** ### Manage group members To add or remove members from an existing group: 1. Go to **Settings → Groups** 2. Click a group to open its detail page 3. To add a member, click **Add member** and search for the person you want to add 4. To remove a member, click the menu on a member row and select **Remove** On the detail page, you can filter the member list by name or email and by group role. Each group member has a role within the group: **Admin** or **Member**. Group admins can add and remove members from the group. You can change a member's group role from the member menu. A workspace member can belong to multiple groups. Changes to group membership take effect immediately. ### Delete a group 1. Go to **Settings → Groups** 2. Click a group to open its detail page 3. Click **Delete group** Deleting a group removes the group and its associated access. It does not remove members from the workspace. ### **Export group membership** You can download a CSV of group membership. Use this for record-keeping, auditing, or migrating membership data outside Lovable. 1. Go to **Settings → Groups** 2. Click **Export** The CSV includes one row per group membership, with the following columns: * Workspace name and ID * Group name and ID * User name and ID * Email * Date added * Who added them ## SCIM groups If your workspace uses [SCIM provisioning](/features/business/scim), groups pushed from your identity provider automatically appear in **Settings → Groups** alongside manually created groups. SCIM-managed groups are marked with a **SCIM** badge and cannot be edited directly in Lovable. Membership for SCIM groups is managed from your identity provider. Both types of groups work the same way when granting access. For details on configuring group push and role mappings, see [Set up SCIM user provisioning](/features/business/scim). ## Share projects with groups Instead of inviting individual collaborators to a project, you can share it with an entire group. This is useful when onboarding a new team to a project or when multiple people across a department need access. ### Add a group to a project 1. Open the project you want to share 2. Click **Share** 3. Search for a group name 4. Select the group and assign a role 5. Click **Share** All members of the group are granted access to the project with the assigned role. Each group member receives a notification, and the project appears in their **Shared with me** section. ### Remove a group from a project 1. Open the project and click **Share** 2. Find the group in the list of collaborators 3. Click the menu on the group row and select **Remove** Removing a group revokes access for all members of that group, unless they also have individual access to the project. ### How group and individual access interact * If a member has both individual access and group access to a project, the **higher permission level** applies. * Removing a group from a project does not affect members who were also added individually. ## Share folders with groups On Business and Enterprise plans, you can add groups as collaborators on a folder. All projects inside the folder become accessible to members of that group with the role you assign. This is useful when a team needs access to a collection of related projects without having to be added to each one individually. ### Add a group to a folder 1. Go to your dashboard and find the folder 2. Click the folder menu (**⋯**) and select **Share** 3. Search for a group name 4. Select the group and assign a role 5. Click **Share** ### Remove a group from a folder 1. Click the folder menu (**⋯**) and select **Share** 2. Find the group in the collaborator list 3. Click the menu on the group row and select **Remove** Removing a group from a folder revokes access to all projects in the folder for members of that group, unless they have individual access to a specific project. ## Publish to specific groups On Business and Enterprise plans, you can restrict who can access your published app to specific groups or individual users, rather than making it available to the entire workspace. This is useful when you want to: * Share internal tools with only the teams that need them * Restrict access to sensitive dashboards, for example financial reports for leadership only * Control app visibility across different departments The **Selected members** option is only available when workspace access for the project is set to **No access** in the Share dialog. If the workspace can edit the project, member restrictions on the published website are not available. Project collaborators always retain access regardless of this setting. ### First-time publish 1. Open your project and click **Publish** 2. Configure your website address and click **Continue** 3. Under **Who can see the website**, select **Selected members** 4. Click **Continue** to open the member selection page 5. Search for and select the groups or individual users who should have access 6. Click **Continue** to proceed to website info, then review and click **Publish** ### Updating an already published project 1. Open your project and click **Publish** 2. Click **Edit settings** 3. Click the edit icon next to **Website access** 4. Select **Selected members** 5. Click **Edit** or **Add** to open the member selection page 6. Search for and select the groups or individual users who should have access 7. Click **Done** to save your changes For more information on publishing and website access control, see [Publish your project](/features/publish). ## FAQ Groups are available on **Business and Enterprise** plans. There is no limit to the number of groups you can create in a workspace. Yes. A workspace member can be part of multiple groups. When publishing to groups, a member only needs to be in one of the selected groups to have access. SCIM groups are synced from your identity provider and cannot be edited in Lovable. Manually created groups are managed directly in Lovable. Both types appear in **Settings → Groups** and work the same way when granting access. SCIM-managed groups display a **SCIM** badge. All members of the group receive access with the role you assign. Each member gets a notification, and the project appears in their **Shared with me** section. The **higher permission level** applies. For example, if a user has viewer access individually but their group has editor access, they get editor access. Removing the group does not affect their individual access. Yes. On Enterprise plans, group creation, updates, deletions, and membership changes are recorded in [audit logs](/features/audit-logs). Yes. On Business and Enterprise plans, you can add groups as collaborators on folders. All projects inside the folder become accessible to members of that group with the role you assign. Yes. Workspace admins and owners can download a CSV of group membership from **Settings → Groups**. The export includes workspace name and ID, group name and ID, user name and ID, email, date added, and who added them. # Jobs Source: https://docs.lovable.dev/features/jobs Review your Lovable Cloud project's scheduled background jobs, check their run history, and enable or disable them. Jobs are scheduled background tasks, used when your app needs to perform recurring work such as checking for new information, posting updates, or syncing data. Ask Lovable to set one up. For example: ```text wrap theme={null} Schedule a daily job at 7 AM that emails me a summary of today's follow-ups. ``` To review your project's jobs, go to **Cloud tab → Jobs**. ## Review and control jobs The Jobs view lists every scheduled job. Click a job to see: * **Scheduled**: the job's schedule in plain language, for example "Every day at 08:00 AM" or "Every 15 minutes". * **Last run**: when the job last executed. * A run history table showing each execution's start time, end time, and status (**Succeeded**, **Failed**, or **Running**). Use **Enable** or **Disable** to control a job. A disabled job does not run again until you enable it. The view does not update live. Use **Refresh** to reload the job list, or the run history's own **Refresh** to load new executions. Creating a job, changing its schedule, or deleting one happens by asking Lovable in chat or through SQL, not from the Jobs view. Jobs that run often or take longer to complete can increase credit usage. See [Usage and costs](/features/usage-and-costs) to review what your project's jobs consume. [Project monitoring](/features/project-monitoring) can alert you when scheduled jobs fail, so you don't have to check the run history manually. ## FAQ Ask Lovable in chat, for example "Schedule a job that cleans up expired sessions every night at midnight" or "Delete the daily summary job". The Jobs view is for reviewing, enabling, and disabling jobs, not creating them. Lovable auto-pauses Cloud projects after a period of inactivity, but scheduled jobs and other background activity keep a project active. If a project only exists to run jobs you no longer need, disable the jobs or [pause the project manually](/features/advanced-settings#pause-cloud). Yes. Each run consumes Cloud usage like any other backend work, so frequent or long-running jobs increase the project's run credit usage. Review the impact in [Usage and costs](/features/usage-and-costs). # Define workspace and project knowledge Source: https://docs.lovable.dev/features/knowledge Define persistent instructions for Lovable using workspace knowledge and project knowledge. Set shared coding standards, architecture rules, and project context that Lovable remembers across conversations and projects. Knowledge lets you provide persistent instructions and context to the Lovable agent. Instead of repeating the same explanations in every conversation, you can define them once and Lovable will consider them when generating edits. Knowledge is defined at two levels: * **Workspace knowledge** defines shared rules that apply across all projects in a workspace, such as coding standards, preferred libraries, or naming conventions. * **Project knowledge** adds context that is specific to a single project, such as the application purpose, database schema, architecture decisions, or domain terminology. Both are plain text fields that provide persistent instructions to the Lovable agent. ## Skills vs. knowledge Skills and knowledge complement each other. * **Knowledge** is always included in context. Use it for rules and conventions that apply to everything Lovable does, such as coding standards, brand guidelines, or your project's domain terminology. * [Skills](/features/skills) are loaded on demand. Use them for instructions that only matter for specific kinds of tasks, such as running a release checklist, drafting a customer reply, or producing a particular kind of content. If an instruction is relevant on every message, put it in workspace knowledge. If it is only relevant when a specific topic comes up, make it a skill. ## Workspace knowledge Workspace knowledge is a text field that lets you define shared rules once and apply them across all projects in your workspace. Project knowledge can then add context that is specific to a particular project. It is best used for **rules and conventions that should be consistent across multiple projects**. By defining these guidelines once, you avoid repeating the same instructions in every project's knowledge field. Workspace knowledge is especially useful in team environments where multiple people are building projects. Workspace admins can define guardrails such as coding standards, testing requirements, or architectural rules so every project follows the same conventions automatically. Only **workspace owners and admins** can manage workspace knowledge. To manage workspace knowledge, go to either: * **Settings → Knowledge** * **Project settings → Knowledge** Workspace knowledge supports up to **10,000 characters**. ### What to include Workspace knowledge is best for: * Coding style conventions * Naming conventions * Preferred libraries or frameworks * Shared architectural patterns * Testing requirements * Code quality or linting rules * Language or formatting preferences * Brand voice, UI copy, or design guidelines * Things Lovable should avoid doing ### Example ```text wrap theme={null} Coding standards - Always enable TypeScript strict mode. - Never use `any`. Use `unknown` and narrow the type. - Prefer named exports. Do not use default exports. - Prefer `const` over `let`. Never use `var`. Naming conventions - Use camelCase for variables and functions. - Use PascalCase for components and types. - Use kebab-case for file names. Styling - Use Tailwind CSS for styling. - Do not use inline styles. - Do not use CSS modules. Libraries - Use shadcn/ui components when possible. - Use React Query for server state. - Use Zustand for client state. Architecture - Route API calls through a service layer. - Do not call `fetch` directly from React components. Testing - Write unit tests for new utility functions and hooks. - Run existing tests after making changes. - Verify new functionality in the browser before marking it complete. Code quality - Run the linter after significant changes. - Remove unused imports and dead code. Localization - Write code comments and variable names in English. - Use date format DD/MM/YYYY. - Use European number formatting (comma as decimal separator). Brand voice - Use a friendly, professional tone in all user-facing copy. - Use sentence case for headings and buttons (for example, "Create new project", not "Create New Project"). - Do not use placeholder text like "Lorem ipsum", always write realistic copy. General rules - Do not add `console.log` statements. - Do not use deprecated React patterns. - Write code comments in English. ``` ### Important notes * **Changes apply immediately**\ If you update workspace knowledge during an active conversation, Lovable will use the updated instructions on follow-up messages. * **One workspace knowledge per workspace**\ Each workspace has a single workspace knowledge shared across all projects. You cannot define different workspace-level instructions for subsets of projects inside the same workspace. * **Workspace knowledge in long conversations**\ Workspace knowledge is always included together with project knowledge alongside project code and other context sources. However, in very long conversations with a lot of context, instructions may not always be followed consistently. ## Project knowledge Project knowledge is a text field that stores persistent instructions and context for a single project. Use it to provide information that applies only to that specific project, such as the application purpose, architecture, or domain terminology. Anyone with permission to edit the project can update project knowledge. To manage project knowledge, go to **Project settings → Knowledge**. Project knowledge supports up to **10,000 characters**. ### What to include Good project knowledge usually includes: * What the application does * User personas or target audiences * Database schema or key tables * Architecture decisions * Domain terminology * Project specific constraints * Design guidelines (colors, typography, or layout) * Links to important references such as API documentation or internal tools * Security or compliance requirements ### Example ```text wrap theme={null} Project overview This is a B2B SaaS application for restaurant managers to track food inventory across multiple locations. Users Primary users are restaurant managers who need quick visibility into stock levels and ingredient usage. Secondary users are staff responsible for logging inventory changes. Key database tables - inventory_items (id, name, category, quantity, unit, location_id) - locations (id, name, workspace_id) - transactions (id, item_id, quantity_change, type, created_at) Design guidelines - Use Tailwind CSS for styling. - Follow the existing color palette and spacing scale. - Use consistent spacing and layout patterns across pages. - Prefer shadcn/ui components when available. Architecture rules - Store monetary values in cents as integers. - Use optimistic updates for all mutations. - Place reusable components in /components. Domain terminology - "Inventory item" refers to a tracked ingredient or product. - "Transaction" represents a change in inventory quantity. External references - API documentation: https://docs.example.com/api ``` ## Best practices Use **workspace knowledge** to define coding standards, preferred libraries, architectural conventions, and other rules that should apply across multiple projects. Then use **project knowledge** to add context specific to each project, such as the application purpose, database schema, domain terminology, or integrations. If a project needs different behavior from the workspace defaults, you can define those rules in **project knowledge**. When the same instruction appears in both places, Lovable will generally prioritize **project knowledge**, since it is more specific to the current project. Clear instructions produce better results. Good example: ```text theme={null} Always enable TypeScript strict mode. Never use any. ``` Less useful example: ```text theme={null} Write clean code. ``` Imagine explaining the project to a new developer joining the team. Include the important architectural decisions so Lovable does not attempt to change them. Short instructions work better than long paragraphs. Prefer bullet lists and direct rules. If your stack or architecture changes, update your knowledge so Lovable does not follow outdated patterns. You do not need to document everything. Even a few clear rules or a short project description can significantly improve the quality of edits. ## FAQ Both project knowledge and workspace knowledge support up to 10,000 characters. No. Each workspace has one workspace knowledge shared across all projects. Yes. Instruction files such as `AGENTS.md` or `CLAUDE.md` can also provide guidance to the Lovable agent. For technical users managing instruction files directly in their repositories, root-level `AGENTS.md` files are always read by the Lovable agent regardless of session length. When you send a message, Lovable reads your **project knowledge**, **workspace knowledge**, and **project code** to understand how your project works before generating edits. It also looks at any integration knowledge from connected services and instruction files in your project's GitHub repository such as `AGENTS.md` or `CLAUDE.md`. Project knowledge and workspace knowledge are included together when Lovable generates responses. If the instructions conflict, Lovable is encouraged to prioritize the instructions defined in **project knowledge**, since they apply specifically to the current project. To avoid confusion, keep shared rules in workspace knowledge and project-specific details in project knowledge. Knowledge is always included as background context for Lovable. [Skills](/features/skills) are loaded on demand when the request matches the skill's description. Use knowledge for rules that apply to every message, and skills for instructions that only matter for specific kinds of tasks. # Logs Source: https://docs.lovable.dev/features/logs Debug errors and track activity in your Lovable Cloud app with searchable backend logs across functions, database, auth, and storage. Logs record what happens in your app's backend: requests, function output, database activity, sign-ins, and errors. When something misbehaves, this is where you find out why. You can also paste a log entry into chat and ask Lovable to fix the problem. To open logs, go to **Cloud tab → Logs**. ## Log types Use the log type selector to choose which service's logs to view: | Log type | What it shows | | ----------------------- | ------------------------------------------------------------------------------------------------------ | | Server logs | Execution logs from your deployed server worker | | Function edge logs | Edge Function execution logs with request and response data | | Authentication logs | User authentication events and security logs | | PostgreSQL logs | Database queries, errors, and performance metrics | | Realtime logs | WebSocket connections and realtime subscriptions (live updates such as chat messages or notifications) | | Storage logs | File uploads, downloads, and storage operations | | Cron job logs | Scheduled [job](/features/jobs) executions and cron task logs | | Edge logs | HTTP requests and responses from Edge Functions | | Function logs | Serverless function execution logs and events | | PostgREST logs | API requests to your database through PostgREST (the layer your app uses to read and write data) | | Supavisor logs | Connection pooling and database proxy logs (how your app's database connections are shared) | | PgBouncer logs | Legacy connection pooling logs (an older connection pooler, relevant to older projects) | | PostgreSQL upgrade logs | Database upgrade processes and migration logs | The selector is filtered to your project type: **Server logs** appears only on TanStack Start projects, and the other types appear on projects with the built-in backend (Cloud), where **Edge logs** is the default view. ## Search and filter Three controls narrow down what you see: * **Search events** filters entries by text. * The **time interval selector** offers relative ranges from the last 15 minutes up to the last 5 days, or an absolute range with exact start and end times. * A **status filter** narrows results, for example to error responses only. Logs do not stream live. Click **Refresh** to load new entries, and **Show more** at the bottom to page further back in time. Above the table, **Download** saves the loaded entries as a JSON file, and **Copy** copies them to your clipboard. Expand an entry to see its full contents and copy it individually. ## FAQ No. The view shows a snapshot of the selected time range. Click **Refresh** to see the latest entries. The relative ranges go back up to 5 days, and you can pick an absolute start and end time for older windows. For long-term retention, ask Lovable to build logging or analytics into your app itself. You've requested logs too frequently in a short period. Wait a moment and refresh again. # Reuse Lovable workspace identity in your app Source: https://docs.lovable.dev/features/lovable-workspace-identity-reuse Let apps you build for your team recognize the signed-in Lovable user automatically, without a separate login flow. When you build an internal tool in Lovable, the people who use it are usually your own teammates, and they already sign in to Lovable every day. Workspace identity reuse lets your app treat that existing sign-in as its login: the app knows who is visiting (their name, email, and Lovable user ID) without showing a login page or asking anyone to create another account. It works no matter how someone signs in to Lovable: workspace SSO, Google, or email. The feature is available on **Business** and **Enterprise** plans. Workspace identity reuse is rolling out gradually, so it may not be available for every workspace yet. ## Which identity feature do you need? Lovable has three features that sound alike but do different jobs. If you are not sure this page is the right one, start here: | Feature | What it controls | Who it affects | | ------------------------------------------------ | --------------------------------------------------------------------------------------------- | -------------------------------------------------- | | **Lovable workspace identity reuse** (this page) | Whether apps you build can recognize the workspace member who is already signed in to Lovable | Your workspace members using apps your team builds | | [Workspace SSO](/features/business/sso) | How your team signs in to Lovable itself, through your identity provider | Workspace members signing in to Lovable | | [SAML SSO for Cloud apps](/features/saml-sso) | How external end users of a published Cloud app sign in with their own company credentials | Your app's outside users | A simple way to keep them apart: the [Identity settings](/features/workspace-identity) decide how people get into Lovable. Workspace identity reuse decides what your apps can know about people who are already in. Neither requires the other: identity reuse works even if your team signs in to Lovable with Google or email, and you do not need workspace SSO configured. ## Why use workspace identity reuse Identity reuse fits when everyone who uses your app is already in your Lovable workspace. Without it, you would need to build and maintain a second login system, and your teammates would sign in twice: once to Lovable, and once to your app. With it, the app already knows the current user. | Use case | Example | Why identity reuse fits | | ------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Internal admin tool | A billing review dashboard for your operations team | Team members already sign in to Lovable, so the app can identify them without another login page | | Employee portal | A workspace-only PTO request app | The app can show each user their own requests and route approvals by Lovable identity | | Workspace reporting | A dashboard that filters activity by the signed-in team member | The app can personalize views based on the current Lovable user | | Per-user data apps | A notes or tasks app where each member sees only their own rows | Your app can use the Lovable identity to personalize data access | For customer-facing apps, public signup flows, or apps where users do not have Lovable accounts, use [traditional app authentication instead](#when-to-use-traditional-app-authentication-instead). ## How workspace identity reuse works When a signed-in user opens the preview or the published app, Lovable creates a short-lived identity token for that project and user, and passes it along with the app request. Helper code that Lovable generates in your app verifies the token and exposes the current user to the rest of your app code. Lovable strips any identity information that visitors send themselves before attaching its own signed token, so a visitor cannot impersonate someone else by faking an identity. ### Who gets recognized The app recognizes people who are signed in to Lovable **and** have access to the project. Everyone else, including anonymous visitors and people who can only view the published app, gets no identity: the helper returns no user, and your app decides what they see, such as a guest view or an access-denied message. ### What your app can read * The signed-in user's Lovable user ID. * The user's display name, when available. * The user's email address, when available. ### Do you need Lovable Cloud? No. Workspace identity reuse works in any eligible project, with or without Lovable Cloud. Reading the current user's name or email needs no backend at all. You need Lovable Cloud when the app should store **per-user data**: for example, a task tracker where each member sees only their own tasks. Lovable passes the signed-in identity to your Cloud backend so the database can enforce per-user access. Do not mix workspace identity reuse with a traditional app sign-in flow unless you intentionally design a hybrid app. For most apps, choose one auth model: Lovable identity for workspace-member apps, or traditional app authentication for public and customer-facing apps. ## Prerequisites * A **Business** or **Enterprise** workspace. * A newer Lovable project that uses [TanStack Start](https://lovable.dev/blog/building-apps-using-tanstack-start). Some older projects are not eligible. * **Lovable workspace identity** allowed in your workspace's [App login methods](https://lovable.dev/settings/privacy-security) policy. It is allowed by default. If you are not sure which stack your project uses, ask Lovable: ```text wrap theme={null} What stack is this project on? ``` ## Set up workspace identity reuse Setup happens at two levels, usually by two different people: * **Workspace level**: a workspace admin or owner decides whether apps in the workspace may use workspace identity at all. This is a one-time policy decision, and it is allowed by default. * **App level**: the project editor asks Lovable to use the signed-in user in a specific app. Nothing uses the identity until you ask for it. There is no per-project setting to turn on or off. ### Workspace setup (admins and owners) Workspace identity is allowed by default, so in most workspaces there is nothing to do here. To confirm or change the policy: Open [Privacy & security](https://lovable.dev/settings/privacy-security) (**Settings → Security → Privacy & security**), then select **Configure** under **App login methods**. The **Lovable workspace identity** entry should show **Allowed**. Blocking a method locks it for every project in the workspace. The change takes effect immediately. This policy only affects apps your team builds. It does not change how workspace members sign in to Lovable. ### App setup (project editors) In your project, describe the identity behavior you want. Lovable makes the app changes needed to use the signed-in identity. For example: ```text wrap theme={null} Use Lovable workspace identity to show the signed-in user's name and email in the header. If no user is available, show a signed-out state. ``` ```text wrap theme={null} Build an internal task tracker where each signed-in workspace member only sees tasks assigned to them. Use Lovable Cloud for per-user data access. ``` Be explicit about which login model you want. If you only say "add login", Lovable may build a traditional sign-up flow with email or Google instead. Say that you want to use the signed-in Lovable user, like the prompts above do. Open the preview while signed in to Lovable. Wherever your app displays the current user, you should see your own details. With the header prompt above, the header greets you with your own name and email instead of showing a login button. To test what other people see, ask a teammate with access to the project to open the app. They see their own name, not yours. To test the signed-out experience, open the published app in a private browser window. Without a Lovable session, the app shows the guest or signed-out state you asked for. Identity works in preview. You do not need to publish the app to test it. ## Turning workspace identity reuse off * **For the whole workspace**: a workspace admin or owner blocks **Lovable workspace identity** in [Privacy & security](https://lovable.dev/settings/privacy-security) (**Settings → Security → Privacy & security → App login methods**). This applies to every project immediately and cannot be changed from a project. * **For a single app**: ask Lovable to remove it, for example: `Stop using workspace identity in this app and show a public landing page instead.` ## When to use traditional app authentication instead Use traditional app authentication when: * Your app is customer-facing or public. * Users should create accounts inside the app. * Users may not have Lovable accounts. * You need app-specific login methods such as email/password, magic links, [Google sign-in](/features/google-auth), or [SAML SSO for Cloud app users](/features/saml-sso). * You need app-owned user accounts, signup flows, or user management that is separate from Lovable workspace membership. In those cases, ask Lovable to add the sign-in method you need, such as [Google authentication](/features/google-auth), [email sign-in](/features/email-auth), or [SAML SSO for Cloud app users](/features/saml-sso). ## FAQ No. Workspace SSO controls how your team signs in to Lovable. Workspace identity reuse lets an app you build read the Lovable user who is already signed in. See [Which identity feature do you need?](#which-identity-feature-do-you-need) No. The identity is the signed-in Lovable account, regardless of whether the user signed in with workspace SSO, Google, email, or another supported method. No. Reading the current user works in any eligible project. You only need Lovable Cloud when the app stores per-user data. No. Only signed-in Lovable users with access to the project get an identity. Everyone else is treated as anonymous, including public visitors and workspace members without access to the project. Use traditional app authentication if public or customer users need accounts. No, workspace identity reuse has no separate cost. Any Lovable Cloud database, storage, hosting, or AI usage in the app follows normal [credits and usage](/introduction/credits-and-usage) rules. ## Troubleshooting The **App login methods** dialog shows the entry when the feature is available for your workspace. Confirm your workspace is on a Business or Enterprise plan. The feature is rolling out gradually, so it may not be available for your workspace yet. Workspace identity reuse needs all three of the following. Check each one: * Your project runs on [TanStack Start](https://lovable.dev/blog/building-apps-using-tanstack-start). Some older projects use an earlier stack and are not eligible. If you are not sure, ask Lovable: `What stack is this project on?` * **Lovable workspace identity** is allowed in [Privacy & security](https://lovable.dev/settings/privacy-security) (**Settings → Security → Privacy & security → App login methods**). * Your workspace is on a Business or Enterprise plan. Open the preview while signed in to Lovable, and make sure your account has access to the project itself, not only to the published app. If your app supports anonymous visits, make sure it handles the no-user state clearly. Ask Lovable to use the signed-in Lovable user as the app identity. For example: ```text wrap theme={null} Use Lovable workspace identity for this internal app. Do not add a separate email or Google login flow. ``` Ask Lovable to connect the signed-in identity to your Cloud data access. Avoid mixing this setup with a separate app sign-in flow unless you are intentionally building a hybrid auth model. # Add payments to your app Source: https://docs.lovable.dev/features/payments Accept subscriptions and one-time payments in any Lovable app using built-in Paddle or Stripe integration. Lovable's built-in payments let you monetize your app with subscriptions and one-time payments. Lovable handles the infrastructure, including creating accounts, connecting everything, and managing the technical setup, so you can focus on building your product. Built-in payments are currently powered by two providers: **Paddle** and **Stripe**. When you ask Lovable to add payments, it analyzes your project and either presents both options or recommends a specific provider based on what you are selling. ## Eligibility Built-in payments support **digital products** and **software**: * SaaS apps with subscription tiers * Consumer apps with premium unlocks or one-time purchases * Memberships and communities with recurring access fees * Digital downloads such as e-books, templates, courses, or music * Developer tools with API access or usage-based plans **Physical products** can use the [Shopify integration](/integrations/shopify) which provides a full e-commerce suite. Built-in payments powered by Stripe can also be used, but inventory and logistics will need to be managed separately. **Restricted and forbidden products** Some product categories are restricted or forbidden by Paddle and Stripe. Restricted products (such as certain financial services or regulated industries) may require additional review and are not guaranteed approval. Forbidden products (such as illegal goods) will be rejected outright. See [Paddle's acceptable use policy](https://www.paddle.com/help/start/intro-to-paddle/what-am-i-not-allowed-to-sell-on-paddle) and [Stripe's restricted businesses list](https://stripe.com/legal/restricted-businesses) for details. ## Before you start ### Requirements * **Pro plan or higher**: built-in payments require a paid Lovable plan. * **Built-in backend (Cloud)**: built-in payments use the built-in backend for webhooks and subscription data, and aren't available for projects connected to your own Supabase project. If Cloud is not already enabled, Lovable will ask you to activate it during setup. * **Authentication recommended**: your app should have authentication so purchases can be linked to individual users. * **Permission to set up payments**: any workspace or project member with edit access (editor, admin, or owner) can set payments up, with approval in the setup flow. Managing the integration afterward (disconnecting, switching) is restricted to the user who set it up, project owners and admins, and workspace owners and admins. ### How setup works The setup flow has two parts: 1. **Set up and test**: enable a payment provider, create products and prices, and test everything in the preview using test cards. No real money is charged. 2. **Go live**: complete your provider's verification process, run a readiness check, and publish. After going live, your test environment stays available for safe testing alongside the live environment. ### Test and live environments Lovable manages two separate payment environments that map to how you already use your project: **Test mode** applies when you use your project in the preview. Checkout only accepts test card numbers. Real cards will not work and no money is charged. Use this to build your payment flow and verify that everything works before going live. **Live mode** applies to your published app. Checkout processes real cards and customers are charged real money. Each environment has its own products, prices, and transaction history. When you publish your project, products and prices sync from test to live automatically (see [Publishing and product sync](#publishing-and-product-sync)). Payments in the preview work right away after setup. Checkout on your published app will not process real payments until you complete the [go-live steps](#go-live). The **Payments tab** has a toggle to switch between test and live data. In your app, Lovable adds a **test mode banner** that only appears in the preview and is hidden on your published site. After going live, both environments stay active. You can continue testing new products and changes in the preview before syncing them to live. ## Set up payments ### Choose your provider Lovable analyzes your project and either presents both providers or gives a recommendation. If your product is restricted under one provider's policies, Lovable will guide you to the other. Here is how they compare: | | **Paddle** | **Stripe** | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | **Operating model** | Merchant of Record (MoR) | PSP with optional MoR ([Managed Payments](https://docs.stripe.com/payments/managed-payments)) | | **Who is eligible** | Digital products and software in [supported countries](https://www.paddle.com/help/start/intro-to-paddle/which-countries-are-supported-by-paddle) | Digital products, services, and physical products in [Stripe-supported countries](https://stripe.com/global) | | **Benefits** | Dedicated merchant of record model that manages payments, tax, compliance, billing, and support. Routes and optimizes payment performance with simple, predictable per-transaction pricing. | Optional merchant of record on a per-transaction basis. Lower processing cost for domestic sales. Supports services in addition to digital products. | | **Cost** | 5.0% + 50¢ per transaction, no monthly fee | [Standard Stripe pay-as-you-go rates](https://stripe.com/pricing) | | **Best for** | SaaS apps and digital products selling to a global audience | Projects selling services, targeting domestic markets, or needing per-transaction control over MOR | Both Paddle and Stripe offer reduced rates for microtransactions. For Paddle, transactions under \$10 are charged a flat 10% so that payment fees never exceed 10% of the purchase price. See [Paddle's pricing](https://www.paddle.com/pricing) and [Stripe's pricing](https://stripe.com/pricing) for full details. Using Stripe or Paddle through Lovable costs the same as setting up the provider directly. **What is merchant of record (MOR)?** A merchant of record is the legal entity responsible for processing payments and handling tax compliance. When a provider acts as MOR, they are legally the seller. They calculate, collect, and remit taxes automatically, and handle invoices and receipts. You receive payouts after fees. Paddle is a dedicated MOR. All transactions are processed through their merchant of record service. Stripe offers optional MOR ([Managed Payments](https://docs.stripe.com/payments/managed-payments)) that can be enabled on a per-transaction basis for digital products. Managed Payments is available in [fewer countries](https://docs.stripe.com/payments/managed-payments/eligibility) than Stripe's standard payment processing. ### Enable payments Tell Lovable you want to accept payments. Examples: ```text wrap theme={null} Add a pricing page to my app with a $29/month subscription. ``` ```text wrap theme={null} I want to sell my digital course for $197. Set up checkout and make sure I can test it before going live. ``` Lovable will suggest the provider it finds best for your use case and help you enable the integration. An **Enable payments** dialog appears summarizing the provider's features and pricing. Click **Continue** to proceed. Lovable displays a short form to create your payment provider accounts. **For Paddle:** * **Email address**: must not already be registered with Paddle. If it is, use a plus alias like `yourname+lovable@gmail.com`. Emails sent to a plus alias automatically arrive in your main inbox (`yourname@gmail.com`), so you don't need a separate account. * **First and last name**: your legal name (pre-filled from your Lovable account). * **Project name**: used as your business name and statement descriptor on bank statements. * **Acceptable use policy**: you must agree to Paddle's acceptable use policy, terms of use, and privacy policy. **For Stripe:** * **Email address**: used to register your Stripe account (cannot be changed after setup). * **Name**: your business or personal name. * **Country**: where your business is registered. Tell Lovable what you want to sell: ```text wrap theme={null} Create three pricing tiers: Starter at $9/month, Pro at $29/month, and Enterprise at $99/month. ``` ```text wrap theme={null} Create a one-time payment of $49 for lifetime access. ``` Lovable creates the products and prices, builds your checkout flow, and adds the UI components to your app. You can also set up discounts and trials: ```text wrap theme={null} Add a 14-day free trial to the Pro plan. ``` ```text wrap theme={null} Create a 20% discount code LAUNCH valid for the first 3 months. ``` ### The payments tab Once payments are enabled, a **Payments** section appears under the [**More** menu](/features/projects/editor#the-more-menu) in the project toolbar. It includes: * **Environment toggle**: switch between test and live data * **Revenue analytics**: net revenue, active subscriptions, and charts over 7/30/90-day ranges * **Transactions**: product, customer, amount, status, and date for each transaction * **Adjustments**: refunds, credits, and chargebacks. Each entry shows action type, amount, reason, status, and date * **Go-live checklist**: tracks your progress toward accepting real payments You can also open your provider's dashboard directly from the Payments tab for settings that Lovable does not manage, such as checkout appearance (fonts, colors, logo) and payment method configuration. Transaction and subscription statuses (such as active, trialing, canceled, or past\_due) appear in the Payments tab. The available statuses depend on your provider. ### Customer portal Both Paddle and Stripe provide a hosted customer portal where end users can cancel subscriptions, update payment methods, and view invoices. To add it: ```text wrap theme={null} Add a Manage subscription button that opens the customer portal. ``` The customer portal opens in a new browser tab and cannot be embedded in an iframe. It will not function inside the Lovable preview panel. Test it by opening your deployed site in a standalone browser tab. ### Checkout display modes **Paddle** supports two checkout modes: * **Overlay** (default): a modal appears on top of the current page. * **Inline**: checkout is embedded inside the page layout. Ask Lovable to switch. ```text wrap theme={null} Show the checkout inline on my pricing page instead of as a modal. ``` **Stripe** uses embedded checkout only. The checkout form is embedded directly on the page. It cannot be customized through Lovable. Styling changes must be configured in the Stripe dashboard. ## Testing Your test environment is active immediately after setup. Use the preview to test the full payment flow before going live. ### Test cards | Card number | Result | | ------------------- | ---------------------- | | 4242 4242 4242 4242 | Successful payment | | 4000 0000 0000 3220 | Payment with 3D Secure | | 4000 0000 0000 0002 | Failed payment | Use any future expiry date, any 3-digit CVV/CVC, and any billing address. Lovable automatically adds a test mode banner to your app that only appears in the preview. ### What to test Verify that your business logic works end-to-end: 1. Complete a test purchase and confirm the correct features unlock. 2. Check that entitlements, modals, notifications, and redirects all behave as expected. 3. Review transactions in the Payments tab. In test mode, you can simulate subscription renewals without waiting for a full billing cycle. Ask Lovable: "How do I test a subscription renewal?" ### Scenarios to consider * **Upgrades and downgrades**: does switching tiers grant the correct features? * **Cancellations**: does the user retain access until the end of their billing period? * **Renewals**: does the subscription renew and continue granting access? * **Failed payments**: does the app handle `past_due` status gracefully? * **Trials**: does a trialing user get access, and does billing start correctly after the trial ends? * **Discount codes**: does the discounted price apply correctly at checkout? ## Go-live When your app is ready to accept real payments, open the Payments tab and follow the go-live checklist. Until all go-live steps are completed, live checkout will not work. ### Going live with Paddle Click **Run check**. Lovable reviews your live site to confirm: * Privacy policy exists * Terms of service exist * Refund policy exists * Site content is genuine and complies with Paddle policy If a check fails, the dashboard explains what to fix. Ask Lovable to resolve the issue and run the check again. Lovable checks that at least one product with a price exists and your latest changes are published. Click **Complete verification** to open Paddle's seller verification form. The form collects product information, compliance screening questions, and personal or business details. Business types include Individual (sole trader), Private company, and Public company. Starting as Individual is faster. You can upgrade later through the Paddle dashboard. Verification processing time depends on your location and product. Most users are approved within a day, but it can take several days. Paddle may contact you by email or through the Paddle dashboard to request additional identity or business documentation. While waiting, you can: 1. Ask Lovable to hide the checkout button in production until verification completes 2. Wait to publish your project 3. Publish anyway (checkout will not function until approved) See [Paddle's account verification documentation](https://www.paddle.com/help/start/account-verification) for details. Paddle reviews your live domain to confirm it represents a legitimate product with real content and legal pages. Make sure your deployed site is complete before submitting. Once all steps pass, your production app can accept real payments. A **Set up payouts** banner will appear prompting you to add bank account details in the Paddle dashboard. ### Going live with Stripe The Stripe go-live process happens partly in the Stripe dashboard, not in Lovable. You will need to complete steps directly on Stripe's site. Click the link in the Payments tab to claim the Stripe account that Lovable created for you. Stripe refers to this as your "sandbox" account. This opens Stripe's claim page where you take ownership. If you already have a Stripe account, you can link the sandbox to it during this step. You do not need to create a new account. Complete the onboarding checklist in the Stripe dashboard: * Set up your Stripe account * Verify your email * Complete account onboarding Stripe will prompt you to copy products, prices, and the Lovable app from your test account to your live account as part of this process. This also installs the Lovable app on your live account, which connects your live API keys and webhooks. Lovable reviews your live site to confirm: * Privacy policy exists * Terms of service exist * Refund policy exists * Site content is genuine and substantive Once all steps are completed, your production app can accept real payments. Payout configuration is managed directly in the Stripe dashboard. ### Publishing and product sync When you publish your project, products and prices created through Lovable sync automatically from your test environment to your live environment. This runs as part of the publish step, so you do not need to copy anything manually. Subsequent publishes re-sync any catalog changes you have made in test, so test stays the source of truth. Avoid editing products directly in your provider's dashboard. This may cause lost context in Lovable and ID mismatches between test and live environments. Always manage products through Lovable. Discounts are not included in the publish sync. Lovable only syncs products and prices from test to live so that pricing stays consistent between the two environments. Discount codes are usually short-lived and live-environment-specific, so you create them directly against the live provider. To add a discount in live, ask Lovable from a project that has gone live and be explicit about the environment, for example: ```text wrap theme={null} In live, create a 20% discount code LAUNCH valid for the first 3 months. ``` You can also create discounts directly in your provider dashboard. ## Disconnect payments You can remove payments from a project at any time. Open the **Payments** tab, click the three-dots menu in the top-right, and select **Disconnect payments**. In the confirmation dialog, type `DISCONNECT` (all caps) to confirm. Only the user who set payments up, workspace owners and admins, or project owners and admins can disconnect. If the option is greyed out, ask someone with the right access to do it. Disconnecting is permanent. Lovable deletes your API keys, webhook secrets, environment variables, and integration data from the project, and you cannot reconnect the same Paddle or Stripe account to the same project afterward. To set payments up again, use a different provider account. ### What disconnecting does * Removes the API keys, webhook secrets, and payment-related environment variables Lovable provisioned for the project. * Deletes the webhooks Lovable registered on your Paddle or Stripe account. This is best effort: if the call to the provider fails, the webhook stays on the provider side and Paddle or Stripe auto-disables it after repeated failed deliveries. * Stops checkout, subscription syncing, and provider webhooks from reaching your app immediately. Live checkout on your published site will not work until you set payments up again. ### What disconnecting does not do * Does not close or modify your Paddle or Stripe account. Your provider dashboard at [vendors.paddle.com](https://vendors.paddle.com) or [dashboard.stripe.com](https://dashboard.stripe.com) stays fully accessible. * Does not cancel active subscriptions or issue refunds. Customers continue to be billed by the provider until you cancel their subscriptions in the provider dashboard. * Does not notify your customers. Plan that communication yourself if checkout is going away. * Does not affect other Lovable projects connected to the same provider account. If your goal is to move from one provider to the other, see [Switch payment providers](#switch-payment-providers) below for the full flow. ## Switch payment providers Only one built-in payment provider can be active per project at a time. If you start with one provider and decide a different one fits better, you can switch. Switching providers is disruptive. Before you start, understand the trade-offs: * **Products and prices do not carry over.** You will recreate your catalog in the new provider. * **Existing subscriptions do not migrate.** Current subscribers stay on the old provider until they cancel and resubscribe, or you move them manually. * **Transaction and analytics history stays with the old provider.** Past payments, payouts, and reporting remain in the previous provider's dashboard and are not transferred to the new one. * **Webhooks, customer IDs, and provider-specific code are regenerated** for the new provider. Follow the [Disconnect payments](#disconnect-payments) steps to remove your current provider from the project. Lovable cannot do this for you; it must be done from the Payments dashboard. Before enabling the new provider, ask Lovable to clean up code tied to the previous provider, including SDK imports, hooks, server functions, webhook routes, and any database tables that only existed for the old provider. Removing this first matters: the agent gets confused when Paddle and Stripe code are mixed in the same project, which can lead to broken edits when wiring up the new provider. Once the old provider is disconnected and its code is removed, follow the standard [enable payments](#enable-payments) flow for the new provider. For example: ```text wrap theme={null} Switch my payments from Paddle to Stripe. ``` Lovable runs the eligibility check, enables the new provider, and helps you recreate products, prices, and checkout. ## Limitations * **Digital products by default**: for physical products, use the [Shopify integration](/integrations/shopify) or built-in payments powered by Stripe. * **One payment provider per project**: you cannot run Paddle and Stripe in the same project. You can [switch between providers](#switch-payment-providers), but products, prices, and subscriptions do not migrate. * **One subscription per user per environment by default**: each user can have one active subscription. If you need add-ons or multiple subscriptions, ask Lovable to adjust this. * **Projects with payments cannot be remixed**: once payments are enabled, the project cannot be forked. See [Remix a project](/features/projects/remix). * **Checkout styling and payment methods**: these must be configured in your provider's dashboard, not through Lovable. * **Do not create webhooks manually**: Lovable registers webhook endpoints automatically. Duplicates can cause issues. ## Best practices * **Run the readiness check before submitting verification**: fixing issues early prevents delays. * **Use a custom domain before going live**: providers review your live domain. A custom domain looks more legitimate than `.lovable.app`. * **Test the full subscription lifecycle in the preview**: purchase, cancellation, renewal, failed payments, and trials. * **Choose a clear statement descriptor**: customers should recognize the charge on their bank statement. * **Do not revoke access immediately when a subscription is canceled**: the user has already paid through the end of their current billing period and should retain access until then. * **Handle failed renewals gracefully**: prompt the user to update their payment method rather than immediately revoking access. * **Manage products through Lovable**: manual changes in the provider dashboard can create mismatches between environments. ## FAQ No. Lovable creates and manages your payment provider accounts automatically. For Paddle, you complete their verification form before going live. For Stripe, you claim the account Lovable created and install the Lovable app. Yes. Lovable creates a new empty sandbox environment for you, and when you claim it you can link it to your existing Stripe account. You do not need to create a new account. Paddle is a dedicated merchant of record that handles tax compliance, invoicing, and receipts for all transactions. Stripe offers an optional MOR service that you can enable on a per-transaction basis. See the comparison table above for details on eligibility, cost, and best-fit scenarios. Use a different email address. A plus alias like `yourname+lovable@gmail.com` is an easy option. Any email sent to a plus alias automatically arrives in your main inbox ([yourname@gmail.com](mailto:yourname@gmail.com)), so you don't need to create a separate account. It's just a way to use a variant of your existing address. Some countries are excluded because the provider cannot create seller accounts there due to international sanctions or regulatory restrictions. If your country is not listed for one provider, try the other. Fix the issues listed in the dashboard and run the check again. Common failures include missing privacy policy, missing terms of service, missing refund policy, or an unpublished site. Yes. Ask Lovable to create multiple prices for the same plan. Yes. Trials appear with `trialing` status and should grant access like active subscriptions. Yes. Lovable can create discount codes through your payment provider. Yes, but these settings must be configured directly in your provider's dashboard. For example, enabling additional payment methods such as **SEPA Direct Debit**, **iDEAL**, **Bancontact**, or local wallets (Apple Pay, Google Pay) is not something Lovable manages. You toggle them on in the Stripe or Paddle dashboard, and they then appear at checkout automatically. You can open your provider's dashboard directly from the Payments tab in Lovable. If your account has not completed verification, live checkout will not function. Check the go-live checklist in the Payments tab. Most reviews complete within a day, but it can take several days depending on your location and product. Track progress in the Payments tab. Adjustments are financial corrections applied after a transaction. Examples include refunds, credits, or chargebacks. The portal must open in a new browser tab. If you are testing inside the Lovable preview panel, open your deployed site in a standalone tab. No. Built-in payments currently require the built-in backend (Cloud) and are not yet available for projects connected to Supabase. Not directly. There is no seamless migration path yet. To switch, you need to first remove the existing Stripe connection, then ask Lovable to add built-in payments. The Stripe Connector (which requires your own `STRIPE_SECRET_KEY`) is a separate, legacy integration and is different from the built-in Stripe payments described on this page. Yes. Open the **Payments** tab, use the three-dots menu in the top-right to disconnect your current provider, and then ask Lovable to enable the new one. Products, prices, and existing subscriptions do not migrate, so you will recreate your catalog and current subscribers stay on the old provider until they cancel and resubscribe. See [Switch payment providers](#switch-payment-providers) for the full flow. Nothing changes on the provider side. Active subscriptions continue to renew in Paddle or Stripe, and customers keep being billed until you cancel their subscriptions in your provider dashboard. Disconnecting only removes the link between Lovable and your provider, so your app stops receiving payment events. Cancel, refund, or migrate subscriptions directly in [vendors.paddle.com](https://vendors.paddle.com) or [dashboard.stripe.com](https://dashboard.stripe.com). Not to the same project. Once you disconnect, that project can no longer be paired with the original Paddle seller account or Stripe account. To set payments up again on the project, use a different provider account. Other projects can still use the original account without restrictions. No. Disconnecting is permanent. You will need to set payments up again from scratch, using a different Paddle or Stripe account, and recreate your products, prices, and any discounts. You do not have permission to disconnect payments on this project. Only the user who set payments up, a workspace owner or admin, or a project owner or admin can disconnect. Other editors can set payments up on a project that does not have them yet, but they cannot manage an integration someone else set up. The integration is still connected and you can try again. If it keeps failing, wait a minute and retry. If the error persists, contact [Lovable support](https://lovable.dev/support). Stripe and Paddle are the only payment providers with built-in support. There is no native support for PayPal, Razorpay, or other providers, including region-specific payment methods that Stripe and Paddle don't offer in your country. You can ask Lovable to integrate another provider's API through backend edge functions with your own account and API keys, but this is custom code that you configure and maintain yourself, and it is not officially supported. No. The cost of using Stripe or Paddle through Lovable is the same as setting up either provider directly. # Manage workspace members from the People tab Source: https://docs.lovable.dev/features/people Manage workspace members, invitations, roles, access requests, and per-member credit limits. The **People** tab is the central place to manage everyone in your workspace. Every member appears here, whether they joined by invitation, through SSO, via SCIM, or as an external collaborator on a project. **Workspace owners and admins** can invite members, change roles, remove members, approve workspace and project access requests, and export the workspace member list as CSV. You can also track per-member credit usage and set individual credit limits that override the workspace default. Open it from **Settings → People**. ## People tab access and permissions The tab is visible to every workspace role except external collaborators. What each role can do inside it varies. * **External collaborators** do not see the People tab. * **Viewers** can browse the member list, search, filter, sort, view any active member's profile (if public), and export the CSV. They cannot take any management action. * **Editors** can do and see everything viewers can, plus: * Invite and remove viewers and external collaborators On **Enterprise plans**, you can choose to only allow **admins and owners** to invite people by email. Go to **Settings → Privacy & security → Restrict workspace invitations.** * Approve project-level access requests. * **Admins** can do and see everything except adding, removing, or promoting owners. * **Owners** can do and see everything. Only owners can invite and remove owners, and promote existing members to owner. ## The member list The list shows all current members, including external collaborators, along with any pending invitations. Members who have been removed or who have left the workspace are not retained on this list. Available information: * **Name and email** * **Role**: Owner, admin, editor, viewer, or collaborator * **Joined date**: When the member accepted an invitation or was provisioned * **Current month usage**: Credits used this calendar month * **Total usage**: Lifetime credit consumption on this workspace * **Credit limit**: Monthly limit per member, either the workspace default as set in [Workspace settings](/features/workspace-admin-settings#general-workspace-settings), or the individual override if set. Empty if neither is set. When a member hits their limit, they cannot consume more workspace credits until the 1st of the next month UTC. Available actions: * **Search** by name or email * **Filter** by role, or by SCIM-managed status for Enterprise workspaces with [SCIM](/features/business/scim) configured. This lets you show SCIM-provisioned seats or non-SCIM seats. The selection is reflected in the URL, for example `?scim=managed` or `?scim=unmanaged`, so deep links and browser navigation work. * **Sort** by name, role, joined date, current month usage, total usage, or credit limit * **Open a member's row menu** to: * View their profile in a new tab * [Set an individual credit limit](#set-a-per-member-credit-limit) * [Remove the member](#remove-a-member) or revoke their pending invitation. On your own row, the remove option becomes [Leave workspace](/features/workspace#leave-a-workspace). * [Change a member's role](#change-a-member’s-role) by clicking the role dropdown next to their name in the role column * **Select multiple members** for bulk actions (change role, set credit limit, remove members) * **Export** the full workspace member list as a CSV ## User insights Click any member row to open a **User insights** profile. Workspace owners and admins can use it to review what a member does in the workspace without leaving the People tab, for example to audit seat usage, set sensible credit limits, or review project access before offboarding. The profile shows: * **Identity**: the member's name, email, workspace role, and a SCIM badge if the seat is provisioned through your identity provider * **Credit usage**: credits used in the last 7 days and the last 30 days * **Created**: projects the member created in the workspace, with visibility and per-project credit usage over the last 30 days * **Collaborated on**: projects the member has direct access to, with their access level, per-project credit usage, and a **Pending** badge for project invitations they have not yet accepted Project lists are sorted by latest edit by default, and you can switch to sorting by highest usage. Clicking a project opens it in a new tab. On Enterprise workspaces with [audit logs](/features/audit-logs), the profile also includes an **Activity** tab showing the member's recent workspace actions. The profile is read-only. To change a role, set a credit limit, or remove the member, use the member list actions described above. ## Invite members You can invite members in two ways: by email or with an invite link (not available on Enterprise plans). Email invitations are limited per workspace each day: **5** on Free, **20** on Pro, **100** on Business, and no limit on Enterprise. Joining through an invite link does not count toward these limits. Invites can also be blocked with an "Invite was blocked due to suspicious activity" message by automated fraud checks. There is no self-serve way to lift this block. If you believe it is a mistake, contact [Lovable Support](https://lovable.dev/support). ### Invite by email 1. Go to **Settings → People** 2. Click **Invite members** 3. Enter one or more email addresses 4. Select a role: * **Owner** (only available to existing owners on Business and Enterprise plans) * **Admin** (available on paid plans) * **Editor** * **Viewer** (available on paid plans) 5. Click **Invite** Pending invitations appear in the list with status **Invited** and can be revoked from the row menu. Email invites are valid for **30 days**, and the invitation email states the expiry date. After 30 days, the invite disappears from the People list, the link in the invitation email stops working, and the invitation no longer grants access through any other path, such as domain auto-join or SSO sign-in. This also applies to invitations that were already pending when the 30-day limit was introduced. To bring someone in after their invite expires, invite them again. A new invitation starts a fresh 30-day window. On **Enterprise plans**, you can choose to only allow **admins and owners** to invite people by email. Go to **Settings → Privacy & security → Restrict workspace invitations.** ### Invite by link 1. Go to **Settings → People** 2. Click **Invite link** 3. Select the role: * Editor * Viewer (available on paid plans) 4. Click **Create invite link** 5. Copy and share the link Enterprise workspaces do not support invite links. On all other plans, admins and owners can disable invite links entirely from **Settings → Privacy & security → Invite links.** Invite links expire after **5 days** and can be regenerated or deleted at any time. * Only **one active link per role** can exist at a time. * Creating a new link replaces the previous one. On Business and Enterprise workspaces with **SSO enforcement** on, workspace invite links only work for users whose email is on a verified workspace domain and the link’s access level is within the workspace’s just-in-time provisioning role. ## Automatic user provisioning Beyond manual invites available in the People tab, Lovable can automatically add members. The provisioning options are configured in [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**); see [Manage workspace identity and user provisioning](/features/workspace-identity) for the full setup. Provisioned members appear in the People tab, where roles and access can be managed. * **SSO sign-in** (just-in-time, or JIT, provisioning): When a user signs in to Lovable through your configured SSO provider for the first time, they’re automatically added to your company workspace at the JIT default role you set (admin, editor, or viewer). On **Enterprise** plans, owners and admins can toggle this from the **SSO sign-in** row once an SSO provider is configured; on **Business** plans, it's enabled automatically with a configured SSO provider and shown as a read-only status. See [SSO](/features/business/sso) for more information. * **Verified email sign-up** (domain-based provisioning): When a user signs up to Lovable with an email matching one of your [verified domains](/features/verified-domains), Lovable adds them at the configured default role (editor or viewer). This works for any sign-up on a verified domain, with or without SSO. * **Add existing users**: A one-time action in the Identity tab that adds people who already have Lovable accounts with verified-domain emails to your workspace, so you don't have to wait for them to sign in or sign up again. * **SCIM provisioning (Enterprise)**: User and group lifecycle is managed centrally from your identity provider. When you assign a user to Lovable in the IdP, the user is created in the workspace at the configured role. Unassigning the user removes their membership, and changes to group membership or role mappings in the IdP are synced automatically. SCIM is configured separately from the User provisioning section. See [SCIM](/features/business/scim) for more information. ## External collaborators The **collaborator role** is for people outside your core team, such as freelancers, clients, contractors, or partners, who need access to specific projects but shouldn't have broad workspace access. Collaborators can only: * See basic workspace information * See and access projects that have been shared with them (via the **Shared with me** tab on the Lovable dashboard), according to the assigned project access level * Open the **Plans & credit usage** tab to see the current plan, credit balance, and usage, but every **billing control is disabled** for them. They cannot initiate or approve any charge against the workspace * Leave the workspace ### How collaborators are added The **collaborator role** is assigned when you **invite a non-member to a project** from that project's [Share dialog](/features/share-project). After that, they appear in the People list as members of your workspace with the **collaborator** role. This lets you track their activity, set a per-member credit limit, and remove their access when needed. Collaborators cannot be invited from the People tab. On **Business** and **Enterprise** plans, Lovable warns you before inviting someone who isn’t a member of your workspace. Project invitees whose email matches one of your [verified domains](/features/verified-domains) do not become collaborators when **Verified email sign-up** is enabled in Identity settings. They join the workspace as full members at your configured default role instead, and the invite is not subject to the **External project collaborators** setting. Existing verified-domain collaborators are upgraded to the default role the next time they're invited to a project. On Enterprise plans, you can track workspace membership events in [Audit logs](/features/audit-logs). ### Project access levels for collaborators When sharing a project with someone, the [Share dialog](/features/share-project) offers these project-level access options: * **Admin** (available on paid plans): Full access to the project, including all project settings, integrations, and external connections. * **Editor** (default on all plans): Can build, edit, and manage most project settings. Some advanced settings, like integrations and external connections, are reserved for admins. * **Viewer** (available on paid plans): Read-only access to the project editor. External collaborators receive whatever access level was selected in the Share dialog. ### How collaborators use workspace credits In Lovable, credits belong to the workspace that owns the project. Every prompt draws from that workspace's credit pool, regardless of who is prompting. External collaborators always consume **your workspace's** credits, not their own. ### Block or limit external collaborators On **Business and Enterprise** workspaces, owners and admins can control whether people outside the workspace can be added as project collaborators, and the highest project role they can have. This setting is available whether or not you enforce SSO. When **Enforce SSO** is on, external collaborators are blocked by default until an owner or admin explicitly allows them. To block or limit external collaborator access: 1. Open **Settings → Privacy & security** and find the **External project collaborators** control. 2. Choose the highest project role someone outside the workspace can have: * **None allowed**: block external collaborators entirely. If members try to invite someone outside your organization to a project, they get an error informing them that this is not allowed. * **Allow viewers**: external collaborators are capped at read-only access on every project they're invited to. * **Allow editors and viewers**: external collaborators can have at most editor access. * **Allow all**: external collaborators can be given any project role, including admin. ### How access setting changes affect existing collaborators When you turn on **Enforce SSO**, Lovable shows a confirmation dialog with a **Remove all external collaborators** checkbox, on by default. * If you leave it checked, existing external collaborators are removed at the same time SSO is enforced. * If you uncheck it, existing external collaborators keep their access on every project they were already invited to, capped at **editor** level. The workspace's **External project collaborators** setting is set to **Allow editors and viewers** as part of this flow. If you later change **External project collaborators** to **None allowed**, Lovable shows a similar confirmation dialog with a remove option. If you choose not to remove them, existing external collaborators remain in the People list but lose access. The next time they try to open the workspace or one of their projects, they see an **External collaboration disabled** error. If their email matches one of your verified domains, they're redirected to sign in through SSO instead. A successful SSO sign-in provisions them as a full workspace member through just-in-time provisioning, and they're no longer subject to the external-collaborator restriction. ## Manage existing members You can demote or promote existing members, remove members, or set individual credit limits from the People tab. This includes external collaborators as well. ### Change a member's role To change a member's role, click the role dropdown next to the member's row, then choose a new role. Changes take effect immediately. When you make someone an admin or owner, Lovable shows what the role includes and asks you to confirm first, and the workspace's other admins and owners receive an email about the change. * Only owners can promote existing members to owner. * Existing members cannot be downgraded to collaborator. See [External collaborators](#external-collaborators) above. * Existing collaborators can be promoted to a regular workspace role (viewer, editor, admin, or owner). After promotion, they become full workspace members with corresponding access. They're no longer limited to specific projects. ### Remove a member To remove a member, click on the three dots menu from that member's row, then click **Remove**. When you remove someone: * Their workspace-level access is revoked immediately * All of their project access within the workspace is revoked immediately * They receive an email letting them know they were removed from the workspace * For regular members (owner, admin, editor), any projects they owned are auto-transferred to the most senior remaining member of the workspace (owners first, then admins, then editors). Projects with access set to **Restricted** are not transferred automatically. External collaborators never own projects, so no transfer is needed. You cannot pick which member inherits their projects. If you want a specific person to take over their projects, transfer ownership manually from each [project’s settings](/features/projects/settings#transfer-project-ownership) before removing them. * This cannot be undone. To restore access, invite them again. ### Set a per-member credit limit The workspace default applies to all members without overrides (set in [Workspace settings](/features/workspace-admin-settings#general-workspace-settings)). Individual credit limits apply only to members where an explicit credit limit has been set. To override the workspace default monthly credit limit for a member, click on the three dots menu from that member's row, then click **Set credit limit.** When a member hits their limit, they cannot consume more workspace credits until the 1st of the next month UTC. ### Bulk actions Select multiple members using the row checkboxes, then use the bulk actions menu to: * Change roles * Set credit limits * Remove members ## Access requests When someone tries to join the workspace or asks for access to a specific project, the request appears on the People tab. ### Workspace access requests People who discover the workspace through the [Find workspaces](/features/workspace#find-your-team’s-workspace) flow can request to join it. The flow is driven by **Workspace discovery**, which is a **Business and Enterprise** feature. **Business and Enterprise** workspaces are discoverable by default. Owners and admins can turn this off in **Privacy & security → Workspace discovery**. The [Find workspaces](/features/workspace#find-your-team’s-workspace) flow is available to accounts using **non-public email domains** (such as `@yourcompany.com`). Public domains like `@gmail.com` or `@hotmail.com` cannot discover or request access to workspaces this way. Each incoming request includes the role the requester is asking for (viewer, editor, or admin). Owners and admins can approve the request (granting the requested role, or a different role if you adjust it) or deny it. ### Project access requests When a workspace member or external user clicks through to a project they don't have access to, they can request access at the role they need. Requests appear in the People tab for owners, admins, and editors. **What happens after you request access?** When a request is submitted, an email notification is sent to the project owner and to workspace owners and admins. If your request is approved, you'll receive an email with a link to the project. If it's denied, no notification is sent. Workspace owners and admins can approve requests for any project in the workspace. Editors see all project access requests, but can only approve requests for projects where they have admin or owner access. Approving a request grants the user the access level they requested on the specific project. Denying rejects the request without granting access. Approving a project access request does not change the user's workspace-level role, only their access to that one project. * Granting admin or viewer access additionally requires a paid plan. * Approving a request from someone outside your workspace is subject to the **External project collaborators** setting on Business and Enterprise workspaces. ## Related settings | Where | What it controls | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Settings → Workspace | Default monthly credit limit inherited by all members without overrides | | Settings → Privacy & security |
  • Restrict workspace invitations (Enterprise)
  • Disable invite links (Free, Pro, and Business)
  • Workspace discovery (Business and Enterprise)
  • External project collaborators (Business and Enterprise)
| | [Settings → Access → Identity](/features/workspace-identity) |
  • Verified domains
  • SSO providers
  • Enforce SSO
  • SSO sign-in (JIT provisioning)
  • Verified email sign-up
  • Add existing users
  • SCIM provisioning
| | Settings → Plans & credit usage | Plan tier that determines which roles exist | | Settings → Audit logs
(Enterprise) | Record of invites, role changes, removals, and access-request decisions | ## FAQ Workspaces support **unlimited members** on all plans. For Enterprise workspaces, custom member limits can optionally be set. Inviting people by email or invite link is limited to **20 people per workspace per day**. Yes. Owners can promote other members to owner. A workspace can have **multiple owners**. No. Only existing owners can promote another member to owner. Admins can manage every other role (admin, editor, viewer, collaborator). Editors can only invite viewers and external collaborators (the collaborator role is used when inviting non-members to a project). On Enterprise plans, owners and admins can remove this capability by turning on **Restrict workspace invitations** in Privacy & security. After that, only workspace owners and admins can invite. External collaborators have a workspace membership record so Lovable can track their access, bill credits to your workspace, and let you manage or remove them. They only have access to the specific projects you invite them to, never the full workspace. Email invitations expire after 30 days. When an invite expires, the link stops working, and the person will need a new invite to join. To send a new invite, go to **Settings → People** and invite them again. This resets the 30-day window. Removed members lose workspace and project access immediately. Any work they created stays in the workspace, they just can't open or edit it. If they own projects, ownership is automatically transferred to the most senior remaining member of the workspace (owners first, then admins, then editors). Projects with access set to **Restricted** are not transferred automatically. Transfer ownership manually beforehand if you want a specific person to take over. # Phone authentication in Lovable Cloud apps Source: https://docs.lovable.dev/features/phone-auth Let users sign in to your Lovable Cloud app with their phone number and an SMS one-time code, using your own SMS provider. This page documents phone authentication settings for apps using the [built-in backend (Cloud)](/features/cloud). Projects connected to your own Supabase project manage authentication in Supabase instead. For an overview of all sign-in methods and user management, see [Users and authentication](/features/authentication). Let users sign in to your app with their phone number: they enter it, receive a one-time code by SMS, and type the code to sign in. There are no passwords to remember and no email inbox involved. Unlike [Google](/features/google-auth) and [Apple](/features/apple-auth) sign-in, phone authentication has no managed mode: SMS delivery always runs through your own account with an SMS provider, and the provider bills you directly for messages. ## Why use phone sign-in * Works for audiences where email is uncommon or rarely checked * Suits mobile-first products where typing a phone number is natural * No passwords to create, forget, or reset * The phone number doubles as a verified contact channel for your app ## Common use cases Phone sign-in is commonly used for: * Marketplace and delivery apps where sellers and couriers coordinate by phone * Local-services and booking apps with walk-in customers * Apps for regions where phone numbers are the primary online identity * Internal field tools for staff without company email addresses ## Set up phone sign-in Phone sign-in requires an account with one of the supported providers. Create one and collect its credentials from the provider's console: | Provider | Credentials you enter | | ------------- | --------------------------------------------------------- | | Twilio | Account SID, Auth token, Content SID, Message service SID | | Twilio Verify | Account SID, Auth token, Verify service SID | | TextLocal | API key, Sender (6 characters max) | | Vonage | API key, API secret, From (sender number) | | MessageBird | Access key, Originator (11 characters max) | Pick a provider based on pricing and delivery coverage in the countries where your users are. Go to **Cloud tab → Users → Auth settings → Phone**, turn on **Enable phone sign-in**, select your **Active SMS provider**, and enter its credentials. Ask Lovable to build the phone sign-in UI: ```text wrap theme={null} Let users sign in with their phone number using an SMS code. ``` Sign in with a real phone number and verify that the code arrives, the code screen accepts it, and the new user appears in **Cloud tab → Users**. ## Configuration These settings control the sign-in flow: * **SMS template**: the message text sent to users. Use `{{ .Code }}` where the one-time code should appear. * **SMS OTP expiration (seconds)**: how long a code stays valid, from 60 to 600 seconds. * **SMS OTP length**: 4 to 8 digits. * **Auto-confirm SMS**: sign users in without OTP verification. Useful while testing, but leave it off in production, since it removes the proof that the user owns the phone number. ## Costs Lovable does not charge for SMS delivery. Your SMS provider bills your account directly for every message sent, at the provider's own rates. High signup volume means high SMS volume, so keep an eye on your provider's usage dashboard as your app grows. ## Troubleshooting Check your SMS provider's dashboard first: failed deliveries, an exhausted balance, or sender restrictions in the recipient's country (rules about which names or numbers are allowed to appear as the SMS sender) show up there. Also confirm the provider credentials in your auth settings are current. The code may be expiring before users can type it. Raise **SMS OTP expiration (seconds)** in the phone settings, and confirm users are entering the most recent code, since re-requesting a code invalidates earlier ones. Countries have different rules about which names or numbers may appear as the SMS sender, and some require senders to be registered in advance. Check your provider's coverage and compliance documentation for the affected country. ## FAQ No. Phone sign-in always uses your own SMS provider credentials. If you don't want to set up an SMS provider, consider [email](/features/email-auth) or [Google](/features/google-auth) sign-in instead. Your SMS provider bills you directly for every message sent, under your own Twilio, Vonage, MessageBird, or TextLocal account. Lovable does not charge for SMS delivery. Any supported provider works. Pick based on pricing and delivery coverage in the countries where your users are. **Twilio Verify** manages the verification message for you, while the other providers send the SMS template you define. Yes. Sign-in methods are independent: you can enable phone alongside [email](/features/email-auth), [Google](/features/google-auth), [Apple](/features/apple-auth), and others, and users choose how to sign in. Delivery depends on your SMS provider's coverage and each country's rules about who may appear as the SMS sender. Check your provider's coverage documentation for the regions where your users are. # Brainstorm in Plan mode Source: https://docs.lovable.dev/features/plan-mode Plan mode helps you think, explore, and decide before any code is written. Use it to ask questions, debug issues, compare approaches, or create a structured plan when you are ready to build. **Choose a mode** Lovable has two modes: * **Plan mode** → think through the problem, explore options, and decide on an approach * [**Build mode**](/features/agent-mode) → implement changes and verify the outcome Plan mode is for decision-making. Build mode is for execution. The two modes are designed to work together, and you can switch between them at any time. ## Overview Plan mode (previously Chat mode) is Lovable’s planning and reasoning mode, designed for moments when thinking, exploration, or clarity is more valuable than immediate execution. It can reason across multiple steps and inspect files, logs, or other relevant project context as needed. In Plan mode, you can explore ideas, investigate issues, and reason about changes before any code is written. Lovable often asks clarifying questions to better understand your goals and constraints. When there is a clear implementation to propose, Lovable creates a formal plan that you can inspect, edit, and refine. Plan mode never modifies your code. Every message in Plan mode deducts **one credit**. ## What Plan mode is for You can use Plan mode to: * Explore product or feature ideas before committing to a direction * Ask questions about your codebase or existing behavior * Investigate bugs, errors, or confusing behavior safely before making code changes * Compare multiple approaches and understand tradeoffs * Design architecture or database schemas * Understand the impact of potential changes before making them Many Plan mode conversations are exploratory and end with clarity or direction. When a conversation does lead to a concrete change, Plan mode provides a safe way to review and refine the proposed approach before anything is implemented. ## How to use Plan mode You can use Plan mode in two ways: * **Start in Plan mode** when beginning a new project or exploring an idea * **Switch to Plan mode** at any point during development to pause execution and think Plan mode is intentionally interactive. Lovable may ask clarifying questions to understand requirements, constraints, or tradeoffs before proposing a plan. ### Activate Plan mode Click **Plan** next to the message input, then describe what you want to explore or decide. **Be specific about what you want** ```text wrap theme={null} Add email/password authentication with password reset. Users should stay logged in for 30 days. Use Lovable Cloud. ``` **Use it for exploration** ```text wrap theme={null} What's the best way to implement real-time notifications in this project? Walk me through the options and their tradeoffs. ``` **Use it for debugging** ```text wrap theme={null} Users report the login form doesn't work on mobile. Help me figure out why. ``` **Request detailed breakdowns** ```text wrap theme={null} Break down the implementation of a shopping cart feature. What components, database tables, and API endpoints will I need? ``` **Ask for reviews and improvements** ```text wrap theme={null} Review my current authentication setup. What security improvements should I make? ``` ## When Plan mode creates a plan Plan mode does not always produce a structured implementation plan. A plan is created only when there is a clear implementation to propose. If a plan is generated, it appears in a dedicated **Plan view** as a readable, structured document. You can open it in full screen to review the entire approach before anything is implemented. A plan typically includes: * A high-level overview of the approach * Key decisions, assumptions, and constraints * Components, data models, and APIs * Step-by-step implementation sequencing * Optional diagrams such as schemas, flows, or architecture From the Plan view, you can: * **Edit** the plan directly as markdown to add constraints, remove steps, or rewrite sections * **Approve** the plan when you are satisfied with the approach You can ask follow-up questions or request changes directly in the chat, and Lovable will update the plan accordingly. When you approve a plan: * Lovable switches to **Build mode** * Implementation begins based strictly on the approved plan You can return to Plan mode at any time to generate a new plan based on the current state of your codebase. ## Plans and persistence When you approve a plan, the **latest approved version** is saved to `.lovable/plan.md`. This file represents the current plan that Build mode will implement, and you can inspect it like any other project file. **Previous plans are not lost**. They remain available in your **chat history** and can be reopened in the Plan view for reference or comparison, even though only the most recent approved plan is saved to `plan.md`. This allows you to: * Iterate on ideas over time * Compare different approaches * Re-plan safely as requirements evolve * Help new collaborators understand the reasoning behind implementations ## FAQ No. Code changes only happen after you approve a plan and Lovable switches to Build mode. Yes. Every message in Plan mode deducts **one credit**. The latest approved plan is saved to `.lovable/plan.md`. Earlier plans remain accessible from chat history. Yes. Earlier plans remain accessible from chat history. Yes. Plans are fully editable before approval. Yes. Plan mode is well suited for investigating issues and deciding on fixes before implementation. **Plan mode** was previously called **Chat mode**. The name was changed to better reflect how the mode is intended to be used before implementation. Yes. You can reference code files from your current project directly in chat to make edits and discussion faster and more precise. Type `@` and select a file, or use the **Reference file in chat** button in the [code editor](/features/code-mode). For example: ```wrap theme={null} @src/components/UserProfile.tsx add a loading state here ``` This only references files within your current project. To reference another project, see [Cross-project referencing](/features/cross-project-referencing). Yes. Lovable supports [cross-project referencing](/features/cross-project-referencing) within the same workspace. You can use `@` mentions to reference another project directly, or simply ask Lovable to reuse an existing implementation. The agent can access relevant code, files, assets, and chat history from other projects and adapt them to your current one. Cross-project access is read-only and respects workspace permissions. # Edit from the preview Source: https://docs.lovable.dev/features/preview-toolbar Select, edit, annotate, and comment directly on your app preview. The preview toolbar replaces the previous **Visual edits** experience. Instead of using a separate editing panel, choose a toolbar mode, point at what you want to change, and describe the update in plain language. The **preview toolbar** lets you interact with your app while you build. Pick a mode, take an action on the page, and either edit directly, describe a change, draw an annotation, or leave a comment. Use the toolbar when pointing is faster than describing, when you want to make several small updates in a row, or when a visual annotation explains the change better than text. You can start using the toolbar as soon as your app preview appears, without waiting for a separate editor to open. ## Preview toolbar modes Each toolbar mode changes how you interact with the preview. | Use | If you want to | | ---------------- | ---------------------------------------------------------------------------- | | Select elements | Point Lovable at one or more elements and request a change in plain language | | Edit text inline | Fix a typo or change wording directly | | Draw annotation | Show a layout or spatial change that's hard to describe | | Add a comment | Leave feedback for yourself or a teammate | You can switch modes any time. If you have unfinished work in the current mode, such as an unsent drawing or an unsaved text change, the other modes are not available until you send or discard your change. ### Select elements Use **Select elements** when you want to point Lovable at a specific part of the page and describe what should change. 1. Click the **Select elements** button in the toolbar, or press `S`. 2. Click the element you want to change. You can select multiple elements at once. Hold **Cmd** (Mac) or **Ctrl** (Windows) and click additional elements to add them to your selection. Each selected element attaches to the main chat input as a reference, and your prompt applies to all of them. 3. Type what you want to change in plain language. 4. Send your message. Example prompt: ```text wrap theme={null} Make this button the primary brand color and round the corners more. ``` Lovable uses the selected elements as context and applies the change based on your description. This is treated as standard chat usage and **consumes credits**. ### Edit text inline Use **Edit text inline** to change words on the page without writing a prompt. This is the fastest way to fix a typo, change a headline, or update a label. 1. Click the **Edit text inline** button, or press `T`. 2. Click into any text on the page. 3. Edit the text directly in place. 4. Click **Send** and Lovable applies the change. Inline text edits are **free up to a daily limit** of 100 edits per user. After that, additional inline text edits use credits from your workspace. The quota resets every 24 hours. ### Draw annotation Use **Draw annotation** to sketch on top of your app preview and send the sketch as an image alongside a message. This is useful when words are not precise enough, such as when you want to move a group of cards, remove a section, or show where a new element should go. 1. Click the **Draw annotation** button, or press `D`. 2. Draw on the preview. The sketch is attached as an annotation to the main chat input. 3. Type a message describing what you want Lovable to do. 4. Send your message. You can sketch freehand, or draw lines, arrows, rectangles, circles, and ovals. Rough shapes are recognized and cleaned up automatically, so a quickly drawn circle becomes a clean one. Example prompt with a circled section: ```text wrap theme={null} Remove everything inside this circle and replace it with a single call-to-action button that says "Get started". ``` Lovable receives both your message and the annotated screenshot. This is treated as standard chat usage and **consumes credits**. ### Add a comment Use **Add a comment** to leave notes pinned to specific parts of your app. Comments help you and your collaborators discuss the project in context, instead of describing locations in a separate channel. 1. Click the **Add a comment** button, or press `C`. 2. Click where you want to leave the comment. A pin appears, and a comment thread opens next to it with an **Add a comment** form. 3. Type your comment and send. Comments stay attached to the element you pinned them to. Teammates can reply, and you see a red badge on the **Add a comment** button when there are unread replies. When the preview toolbar is hidden, the comments button moves to the project toolbar at the top of the preview so you can keep seeing threads, replies, and the unread badge. Adding comments does not use credits. Sending a comment thread to Lovable is treated as standard chat usage and consumes credits. For more information, see [Project comments](/features/project-comments). ## Working with the toolbar The preview toolbar stays available while you work, but you can move it, change its appearance, or hide it when you want more space in the preview. ### Position, minimize, and hide The toolbar options menu includes **Dock**, **Minimize**, and **Hide**. The toolbar starts docked at the bottom center of the preview. You can: * Drag it anywhere in the preview. It snaps to the corners and to the bottom-center default position to make placement easier, but you can drop it wherever you want. * Minimize it to a small tab on the edge of the preview. Hover or tap the tab to expand it again. * Hide it when you want a clean preview. You can bring it back by clicking the **Show preview toolbar icon** in the [top right controls](/features/projects/editor#top-right-controls) above the preview (next to **Share** and **Publish**). The toolbar remembers its state and position. The next time you open the project, it appears where you left it. ### Theme From the options menu, you can pin the toolbar to **Auto**, **Light**, or **Dark**. In **Auto** mode, the toolbar adapts to what's behind it as you scroll, so it stays readable against any background. **Light** and **Dark** keep a fixed appearance. ### Queuing changes You do not have to wait for one change to finish before starting the next. If Lovable is still working when you send a new request from the toolbar, your request joins a queue. Lovable processes queued requests in order. You can clear the queue or let it run through on its own. ## Tips for best results * **Point first, then describe.** If you can click the thing you want to change, use **Select elements** so Lovable has the page context. * **Use Draw annotation for spatial changes.** Moving things around, grouping content, deleting regions, or sketching new layouts is often faster as a drawing than as a written description. * **Keep prompts short when you've selected an element.** Lovable already knows what you picked. "Make this the primary color" is enough. * **Combine drawing with words for ambiguous changes.** A sketch shows the where, and your description explains the what. * **Fix small text changes directly.** For typos, labels, and short copy changes, use **Edit text inline**. * **Use chat for image changes.** To replace an image, select it, attach a new image, or add an image URL, then describe the update. To edit an existing image, select it, or draw on it, then tell Lovable what to change. * **Send several edits in a row.** You can keep working while Lovable processes earlier requests. ## FAQ The preview toolbar replaces the previous Visual edits experience. Instead of using a separate editing panel, choose a toolbar mode, point at what you want to change, and describe the update in plain language. Select elements and Draw annotation are treated as standard chat usage and consume credits. Inline text edits are free up to a daily limit of 100 edits per user. After that, additional inline text edits use credits from your workspace. Adding comments is free. Sending a comment thread to Lovable is treated as standard chat usage and consumes credits. Yes. Hold **Cmd** (Mac) or **Ctrl** (Windows) and click additional elements to add them to your selection. Each selected element attaches to the main chat input as a reference, and your prompt applies to all of them. To replace an image, use **Select elements** to select the image in the preview, then attach a new image or add an image URL in the chat input. Describe what you want Lovable to do, then send your message. To edit an existing image, select the image or use **Draw annotation** to mark the area you want to change, then describe the edit in chat. Draw annotation mode recognizes simple shapes, including lines, arrows, rectangles, circles, and ovals, and cleans them up so Lovable sees a clear annotation. If you draw something the recognizer does not match, it stays as freehand. You can bring it back by clicking the **Show preview toolbar icon** in the [top right controls](/features/projects/editor#top-right-controls) above the preview (next to **Share** and **Publish**). Those controls sit in the row above the preview, separate from the preview toolbar inside the preview itself. # Privacy & security settings Source: https://docs.lovable.dev/features/privacy-and-security-settings Manage workspace-wide controls for member access, project publishing, external sharing, connected tools, security scans, and data protection. The **Privacy & security** tab is where **workspace admins and owners** manage workspace-wide controls for access, publishing, sharing, connected tools, security automation, and data protection. Open it from [Privacy & security](https://lovable.dev/settings/privacy-security) (**Settings → Security → Privacy & security**). After changing settings on this page, click **Save** to apply most updates. Settings are grouped into the same sections shown in the UI. ## Access & membership Controls how people join the workspace, what access new projects use by default, and whether projects can be moved to another workspace. ### Default project access **Available on:** All plans; Restricted is available on Business and Enterprise\ **Default:** Workspace Sets the visibility of every new project at the moment it is created. Changing the setting does not change the visibility of existing projects. | Option | Who can see the project | | :--------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Workspace** (default) | All members of this workspace can view, remix, or edit the project based on their role. | | **Restricted** (Business and Enterprise) | Only the owner and explicitly invited collaborators can access the project.
Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. | See [Control project access](/features/project-visibility) for more information. ### Restrict workspace invitations **Available on:** Enterprise\ **Default:** Disabled When disabled, editors, admins, and owners can invite viewers and external collaborators by email. When enabled, only **admins and owners** can invite members by email to this workspace. Editors lose the ability to invite. This restricts **manual invitations** only. JIT and SCIM provisioning continue to add users based on identity-provider configuration. If your workspace uses [verified-domain JIT](/features/workspace-identity#user-provisioning), users with matching email domains will still be automatically provisioned on sign-in. See [Invite by email](/features/people#invite-by-email) for more information. ### Invite links **Available on:** Free, Pro, and Business\ **Default:** Enabled When enabled, workspace admins and owners can generate a shareable link that lets anyone use it to join the workspace at a chosen role. Invite links expire 5 days after creation, and only one active link per role can exist at a time. When disabled, no one can create invite links. See [Invite by link](/features/people#invite-by-link) for more information. ### Workspace discovery **Available on:** Business and Enterprise\ **Default:** Enabled When enabled, anyone signing in to Lovable with an email address from your organization's [verified domain](/features/verified-domains) can find this workspace from the **Find your team's workspace** flow and request access. This helps new employees find the workspace without needing a direct invitation. When disabled, the workspace is invisible to domain-based discovery. Only users with a direct invitation can join. Public email domains (such as `@gmail.com`) cannot discover workspaces this way regardless of the toggle. Turning discovery off stops new requests but does not clear any access requests that were already submitted. Review and deny pending requests in **Settings → People**. See [Workspace access requests](/features/people#workspace-access-requests) and [Find your team's workspace](/features/workspace#find-your-team’s-workspace) for more information. ### Public member profiles **Available on:** Enterprise\ **Default:** Disabled (member profiles hidden) Controls whether members' public Lovable profiles at `lovable.dev/@` are visible to people outside the workspace. When disabled (the default for Enterprise workspaces), a member's profile URL returns a **404 Not Found** to anyone outside the workspace. On public project pages, the member's publisher name, avatar, and profile link are also hidden, and the project shows an anonymous "Lovable user" as the publisher instead. When enabled, member profiles are publicly visible, just like on other plans. Hiding only applies to people outside the workspace. Workspace members can still see each other's profiles, and everyone can see their own. A user has one global Lovable profile. If they belong to any Enterprise workspace that keeps this setting off, their profile stays hidden, even if another workspace allows public profiles. If a workspace leaves the Enterprise plan, its members' profiles are no longer hidden. When member profiles are hidden, each member's **Profile visibility** setting in **Settings → Your account** is locked and shows "Profile visibility is managed by one of your workspaces." See [Profile settings](/introduction/lovable-account-settings#profile-settings). ### Editor project transfers **Available on:** Enterprise\ **Default:** Disabled This setting controls whether **workspace editors** can transfer or remix **projects they own** into another workspace. Remixing within the same workspace is not affected by this setting. Regardless of this setting: * Workspace owners can always transfer or remix any project in the workspace, including restricted projects. * Workspace admins can always transfer or remix workspace-visible projects. When disabled, workspace editors cannot transfer or remix projects they own into another workspace. When enabled, workspace editors can transfer or remix projects they own into another workspace, including a personal workspace outside your organization. When the **Transfer** or **Remix** option is disabled, hover over it to see why. The tooltip explains what is limiting the action. For regulated environments, leave this off. When a workspace editor transfers or remixes a project into a personal workspace, the project leaves your organization’s governance boundary. ### Require workspace editor role **Available on:** Enterprise\ **Default:** Disabled When enabled, only workspace members with the **editor** role or higher can edit projects. Workspace viewers and external collaborators can still view projects but cannot edit them, even if they own a project or were given editor access to it directly, through a folder, or through a workspace group. When disabled, a viewer who is given editor access to a specific project can edit that project. Use this to enforce a read-only baseline for viewers and external collaborators across the workspace, regardless of how project access was granted. ### External project collaborators **Available on:** Business and Enterprise\ **Default:** Allow all Controls whether people outside your workspace can be added as collaborators on projects in this workspace, and the highest access level they can have. This setting is available whether or not you enforce SSO. | Option | What it means | | :------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Allow all (default) | External users can be added at any project role, including admin. | | Allow editors and viewers | External users can be added as project viewers or editors. | | Allow viewers | External users can be added as read-only project viewers. | | None allowed | External users cannot be added to projects. If members try to invite someone outside your organization to a project, they get an error informing them that this is not allowed. | When you turn on **Enforce SSO**, Lovable shows a confirmation dialog with a **Remove all external collaborators** checkbox, on by default. * If you leave it checked, existing external collaborators are removed at the same time SSO is enforced. * If you uncheck it, existing external collaborators keep their access on every project they were already invited to, capped at **editor** level. The workspace’s **External project collaborators** setting is set to **Allow editors and viewers** as part of this flow. If you later change **External project collaborators** to **None allowed**, Lovable shows a similar confirmation dialog with a remove option. If you choose not to remove them, existing external collaborators remain in the People list but lose access. The next time they try to open the workspace or one of their projects, they see an **External collaboration disabled** error. If their email matches one of your verified domains, they’re redirected to sign in through SSO instead. A successful SSO sign-in provisions them as a full workspace member through [just-in-time provisioning](/features/workspace-identity#user-provisioning), and they’re no longer subject to the external-collaborator restriction. See [Block or limit external collaborators](/features/people#block-or-limit-external-collaborators) for the full flow. ## Publishing Controls who can publish projects, what audience published projects use by default, and whether security checks can block publishing. ### Default website access **Available on:** Business and Enterprise\ **Default:** Anyone Sets the default audience for a project the first time it is published. Changing this setting does not retroactively change access for already published projects. | Option | Who can reach the published URL | | :-------------------------------------- | :----------------------------------- | | **Anyone** (default) | Anyone with the link | | **Workspace** (Business and Enterprise) | Authenticated workspace members only | Individual projects can override the workspace default during the publish flow. See [Publish your project](/features/publish) for more information. ### Who can publish externally **Available on:** Enterprise\ **Default:** Editors and above By default, any workspace editor, admin, or owner can publish externally on all plans. Enterprise workspaces can restrict this further. This setting sets the minimum workspace role required to publish a project to a public URL. | Option | Who can publish externally | | :--------------------------------- | :----------------------------------------------------------- | | **Editors and above** (default) | Any workspace editor, admin, or owner can publish externally | | **Admins and owners** (Enterprise) | Only workspace admins and owners can publish externally | | **Owners only** (Enterprise) | Only workspace owners can publish externally | Existing public projects can still be re-published by editors if they were already public before this setting was tightened. The stricter restriction applies only when a project is published publicly for the first time, or when a previously public project has been unpublished and is deployed publicly again. **Self-locking behavior:** If this is set to **Owners only**, only the owner can change it. An admin who tries to lower the restriction will find the control disabled with an explanation that their role is not high enough. The owner must relax the policy first. ### Block publishing with critical findings **Available on:** All plans\ **Default:** Disabled When disabled, projects can be published regardless of critical findings, although the publish dialog still surfaces them as security warnings. When enabled, a project cannot be published if its most recent security scan returned critical-severity findings. The publish action is blocked until error-level findings are resolved. We recommend enabling this on every workspace. See [Security overview](/features/security) for more information. ### Block publishing with PII **Available on:** Enterprise (only visible when Sensitive data scanning is enabled)\ **Default:** Disabled When disabled, personally identifiable information (PII) findings do not block publishing. When enabled, a project cannot be published or updated if it has unresolved sensitive data findings. See [Sensitive data scanning](/features/sensitive-data-scanning) for more information. ### Require basic security scan before first publish **Available on:** All plans\ **Default:** Disabled When disabled, no scan is required before the first publish. When enabled, every project must complete a basic security scan before it can be published for the first time. Re-publishing an already-published project is unaffected. This pairs well with **Block publishing with critical findings**. Requiring a scan before publishing ensures a baseline review happens, and blocking publishing with critical findings ensures bad results stop the deploy. See [Security overview](/features/security) for more information. ### App login methods **Available on:** Business and Enterprise\ **Default:** All methods allowed Controls which login methods apps built in this workspace may use. Blocked methods are locked for all projects in the workspace, and project owners cannot re-enable them. Click **Configure** to open the dialog. Supported sign-in methods include: * Email * Phone * Google * Apple * SAML SSO * Lovable workspace identity Use the toggle next to each method to allow or block it. Changes take effect immediately. This only affects login methods for apps built in this workspace. It does not change how workspace members sign in to Lovable itself. **Lovable workspace identity** is different from the other methods: it is not a login button in the app. It lets eligible apps recognize the workspace member who is already signed in to Lovable, without a login page. See [Reuse Lovable workspace identity in your app](/features/lovable-workspace-identity-reuse). ## Security automation Controls automatic security remediation for projects across the workspace. ### Auto-fix security issues **Available on:** All plans\ **Default:** Selected project (disabled) Lovable can automatically fix eligible security findings during regular agent work. When auto-fix is enabled, Lovable gets the latest critical Basic scan findings as part of its context whenever a member chats with it on a project. Lovable then attempts to resolve them as part of the next response. This counts as standard chat usage and consumes credits. Auto-fix is designed for findings that are safe to remediate automatically, such as common row-level security (RLS) misconfigurations and database access patterns. It does not apply fixes for Deep scan findings. This setting controls the default scope at which auto-fix is applied across the workspace. | **Option** | **What it means** | | :------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Selected project (default) | Auto-fix is disabled by default. You can enable or disable it for individual projects from **Project settings → Auto-fix security issues**. | | Externally published projects (Business and Enterprise) | Auto-fix runs automatically only after the project is published externally. After that, it runs each time you chat with Lovable on the project. You cannot disable it for externally published projects at the project level. You can still enable it manually for other projects. | | All published projects | Auto-fix runs automatically only after the project is published, internally or externally. After that, it runs each time you chat with Lovable on the project. You cannot disable it for published projects at the project level. You can still enable it manually for unpublished projects. | | All projects | Auto-fix runs automatically each time you chat with Lovable on any project in the workspace, whether or not it has been published. It cannot be disabled at the project level. | Anyone with project edit access can manage auto-fix for a specific project from **Project settings → Auto-fix security issues**, unless the workspace requires auto-fix for that project. See [Security overview](/features/security) for more information. ## Abandoned projects **Available on:** Enterprise\ **Default:** Marked abandoned after 60 days; auto-delete off Automatically identify projects with no recent activity, published and unpublished, and optionally delete them after a grace period. Configure both controls from [Privacy & security](https://lovable.dev/settings/privacy-security) (**Settings → Security → Privacy & security → Abandoned projects**). ### What counts as activity A project is marked **abandoned** when it has had no activity for the period set in **Mark as abandoned after**. Activity means any of: * someone working in the editor (editing or chatting with the AI) * a visitor using the published app (bots excluded) * a backend function call Simply opening or previewing a project is **not** activity, and publishing on its own does not reset the clock. One of the signals above must occur. ### Deleting abandoned projects When auto-delete is on (**Delete abandoned projects after**), an abandoned project is deleted once the grace period you choose (7, 14, or 30 days) passes. Owners and members with edit access get a warning email and an in-project banner 5 days and 1 day before the deletion date. Before the deadline you can cancel the deletion at any time by: * editing the project, or sending it a message, or * clicking **Keep it** on the in-project banner or in the warning email. A deleted project isn't removed right away. It's kept for up to 60 days, then permanently removed. You can't restore it yourself yet, so to bring a project back within that window, contact [Lovable support](https://lovable.dev/support). ## Sharing Controls whether members can create public preview links and reuse work across projects in the same workspace. ### Allow public preview links sharing **Available on:** All plans; disabling is available on Enterprise\ **Default:** Enabled When enabled, workspace members can generate a temporary public preview link for any project. Preview links are view-only URLs that anyone can open without a Lovable account. Preview links expire after 7 days. When disabled, the **Share preview** button is hidden for all projects in the workspace. Preview links bypass the **Default website access** setting. Even when published projects are workspace-only, an enabled preview link lets an external viewer in without authenticating. If you need a hard perimeter against external viewing, disable this setting. See [Share preview links](/features/share-project#share-preview-links) for more information. ### Code downloads **Available on:** Enterprise\ **Default:** Enabled Controls whether workspace members and collaborators can download project source code from Lovable. When enabled, members with edit access can [download a project's source code](/features/code-mode#download-your-projects-codebase) as a zip file. When disabled, only workspace admins and owners can download project source code as a zip file. Other members have the download option disabled and see a message that only workspace admins and owners can download the code. This setting only applies to zip downloads from Lovable. It does not affect access to connected GitHub or GitLab repositories, or the ability to view code in the editor. ### Cross-project sharing **Available on:** All plans\ **Default:** Enabled When enabled, workspace members can reference and reuse implementations from other projects in the same workspace. Members can reference a project by typing `@` in the chat or by asking Lovable to use an existing project. All cross-project access is read-only. Referenced projects cannot be modified. When disabled, cross-project sharing is turned off for all projects in the workspace. Members cannot reference other projects and other projects cannot reference them. Cross-project sharing can also be controlled at the project level. Project editors and above can disable it for a specific project from **Project settings → Cross-project sharing**. When disabled at the project level, that project cannot reference others and cannot be referenced. If any level blocks access, the reference fails. See [Cross-project referencing](/features/cross-project-referencing) for more information. ## Lovable MCP server Control third-party MCP client access to this workspace. ### Third-party MCP clients **Available on:** Business and Enterprise\ **Default:** Enabled for Business; Disabled for Enterprise When enabled, external MCP clients such as Claude Desktop and Cursor can connect to this workspace through [mcp.lovable.dev](https://mcp.lovable.dev). This allows developers to build and manage their Lovable projects directly from their preferred tools using the MCP protocol. On Free and Pro workspaces, this is always enabled and cannot be configured. On Business workspaces, it is enabled by default and can be turned off. On Enterprise workspaces, it is disabled by default and must be explicitly turned on by a workspace admin or owner. Connection details and client setup steps live in the [MCP server tab](/features/workspace-admin-settings#mcp-server) (**Settings → Build & deploy → MCP server**), which links back to this setting through its **Manage access** button. See [Lovable MCP server](/integrations/lovable-mcp-server) for more information. ## MCP connectors Controls whether members can connect external tools and data sources to Lovable through Model Context Protocol (MCP) servers. ### Remote MCP connectors **Available on:** Business and Enterprise\ **Default:** Enabled When enabled, workspace members can connect pre-built and custom MCP servers to their projects. MCP servers let the agent read from external databases, APIs, and other data sources during builds. When disabled, MCP servers access is turned off across the entire workspace. No new MCP connections can be created. See [Chat connectors (MCP servers)](/integrations/mcp-servers) for more information. ### **Local desktop MCP servers** **Available on:** Business and Enterprise\ **Default:** Enabled This setting has no effect when **Remote MCP connectors** is disabled. Both must be enabled for local desktop MCP servers to work. When enabled, members using the Lovable desktop app can connect MCP servers running on their own machine to their projects. This lets the agent reach localhost tools and private services that are not exposed to the internet. When disabled, only remote MCP connectors are allowed. Local desktop connections are blocked. See [Lovable desktop app](/integrations/desktop-app) for more information. ## Data protection Controls training data preferences, sensitive data detection, and storage exposure rules. ### Data collection opt out **Available on:** Business and Enterprise\ **Default:** Disabled Free and Pro customers can request an opt-out by contacting [Lovable Support](https://lovable.dev/support). When disabled, customer data may be used for model training and other business purposes as described in Lovable's [Terms of Service](https://lovable.dev/terms). Only customer data that does not identify you may be used. When enabled, Lovable does not use this workspace's content for AI model training or internal evaluation. See [Manage training data and privacy](/features/business/data-opt-out) for more information. ### Sensitive data scanning **Available on:** Enterprise\ **Default:** Disabled When enabled, Lovable scans workspace content for personally identifiable information (PII). This is the **workspace-level main switch for sensitive data protection features**, including on-demand scans (chat history, Lovable Cloud databases, and Lovable Cloud storage), chat send protection for new messages and attached files, and block publishing with PII findings. It also adds a **Sensitive data** tab to projects where recorded PII findings can be reviewed. See [Sensitive data scanning](/features/sensitive-data-scanning) for more information. ### Chat send protection **Available on:** Enterprise (only visible when **Sensitive data scanning** is enabled)\ **Default:** Log only Determines what happens when PII is detected in new chat messages or attached files. On-demand scans of chat history, Lovable Cloud Database, or Lovable Cloud Storage still work regardless of the chat send protection mode. | **Mode** | **Behavior** | | :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Off** | No scanning. Messages pass through to the agent without inspection or logging. | | **Log only** (default) | The scan runs. If PII is detected, a finding is recorded and available for review in the project's **Sensitive data** tab, but the message sends without interruption. This is the default when sensitive data scanning is first enabled. | | **Ask before sending** | The scan runs. If PII is detected, the message is paused and the user chooses whether to edit, send a redacted version, or send the original. Detected PII is logged only if the user sends the original message, otherwise the original message is discarded.
Can be overridden on project level by enabling **PII prompt auto-approval** from the **Sensitive data** tab. | | **Block original** | The scan runs. If PII is detected, the user cannot send the original. They can only edit the message or send a redacted version. The original message is discarded and nothing about the original PII gets logged. | See [Sensitive data scanning](/features/sensitive-data-scanning) for more information. ### Block public storage buckets **Available on:** All plans\ **Default:** Enabled When enabled, workspace members cannot create publicly accessible storage buckets in Lovable Cloud. All new buckets are forced to private access. When disabled, members can create public storage buckets. See [Storage](/features/storage) for more information on public and private buckets. ### Default hosting region **Available on:** Business and Enterprise\ **Default:** Not set Sets the default data region for every **new** Lovable Cloud project created in the workspace. Use it when your organization requires the backends to live in a specific geography. Choose one of the following regions: | Region | Geography | | :--------------- | :------------------------------ | | **Americas** | North and South America | | **Europe** | Europe, Middle East, and Africa | | **Asia Pacific** | Asia Pacific | Within a region, Lovable automatically distributes new projects across available data centers. **Country-specific regions** (for example, Germany, Japan, or United States East) are available on Enterprise by request. Contact your Lovable account team to enable them for your workspace. When a default hosting region is set: * It applies only to **new** projects created after the setting is saved. * Existing projects keep the region they were created in and are not migrated. * Workspace members cannot override the default region when creating a new project. To remove the default region, open the dropdown and select **Not set**. New projects then use the region closest to the member who creates them. Setting a default hosting region requires new projects to use a micro database instance or higher, which may use more credits. See [Lovable Cloud](/features/cloud#region-selection) for more information on how Cloud regions work. # Private registry Source: https://docs.lovable.dev/features/private-registry Set up a private npm registry inside your Lovable workspace to publish and install packages without exposing them publicly. Private registry provides your workspace with its own npm registry, hosted privately inside Lovable. You can publish npm packages directly to it without making them public, and any project in your workspace can install those packages. Setting up the private registry is limited to workspace owners and admins. Any editor can view the published packages in the registry. ## Why use a private registry Internal teams often maintain private npm packages for shared code like design systems, utility libraries, or proprietary API clients that shouldn't be published publicly. With a private registry in Lovable, you can: * Install internal packages in Lovable projects without workarounds. * Keep proprietary code private and secure. * Reuse versioned internal libraries consistently across your workspace's projects. ## Common use cases * **Internal UI component libraries**: install your organization's design system as a private package and use it in Lovable projects. * **Shared utilities**: use internal validation, formatting, or data-fetching packages across multiple projects. * **Proprietary integrations**: install internal SDKs or API clients that can't be published publicly. ## Prerequisites * A **Lovable Enterprise plan** * **Workspace owner or admin role** ## Set up the private registry Setting up the private registry consists of two parts: 1. **Enable the registry and create a service account key** in Lovable workspace settings. 2. **Configure your code project** by adding the `.npmrc` file, adding the service account key as an `npm-key.json` file, and running authentication against the private registry using the service account key. ### Part 1: Enable the registry Go to [Private registry](https://lovable.dev/settings/private-registry) (**Settings → Build → Private registry**). Select **Provision registry**. Lovable sets up a private npm registry for your workspace. When the registry is provisioned, you can create a service account key. Enter a name for the key, and select **Create key**. Save the service account key file immediately after creating it. You will not be able to retrieve it again. ### Part 2: Configure your code project In your code project's root directory, add the private registry details to the `.npmrc` file. Add the service account key you downloaded in Part 1 as an `npm-key.json` file in your project. Run the authentication command using the service account key to authorize your code project to publish to the private registry. ## View published packages Once packages are published to your private registry, you can view them in [Private registry](https://lovable.dev/settings/private-registry) (**Settings → Build → Private registry**). For each package, you can see the name, the latest published version, and when it was last updated. ## Use a private package To install a private package in a Lovable project, prompt Lovable with the package name just as you would for any public npm package. For example: ```text wrap theme={null} Install @my-org/ui-components and use it to replace the current button component. ``` Lovable resolves the package from your configured private registry automatically. ## Limitations * Only one private registry can be configured per workspace. * Only workspace owners and admins can configure the registry. Editors and viewers cannot access registry settings. ## FAQ Only workspace owners and admins can view and manage the private registry settings. The authentication token is not shown after it is saved. Yes. Once configured, the private registry is available to all projects in the workspace. There is no per-project configuration required. Yes. Scoped packages (for example, `@my-org/package-name`) are supported. Reference the package by its full scoped name when prompting Lovable. # Project comments Source: https://docs.lovable.dev/features/project-comments Leave comments directly on elements in your project. Project comments let you and your collaborators leave feedback directly on elements in the project preview. Click on any element to start a thread, discuss changes, and optionally send feedback to Lovable. ## Creating a comment 1. Click the **Add a comment** button in the [preview toolbar](/features/preview-toolbar), or press `C` to enter comment mode. When the preview toolbar is hidden, the comments button moves to the project toolbar at the top of the preview. 2. Click on any element in the preview to place a comment pin. 3. Type your comment in the text field that appears. 4. Press **Send** to create the comment thread. A pin appears on the element, visible to everyone with access to the project. Each pin is anchored to the specific element you clicked on. Comment pins only appear while you are in comment mode. ## Replying to comments Click on any comment pin to open its thread. Type your reply at the bottom of the thread and press **Send**. All project collaborators can see and reply to any thread. ## Sending feedback to Lovable There are two ways to send a comment thread to Lovable: * **Mention Lovable**: Type `@Lovable` in a comment to send the thread as context to Lovable. * **Send to chat**: Open a thread and press the **Send to chat** button in the thread header. Both options send the full thread, including the page, the element, and all comments, to chat as structured feedback. Lovable can then act on it directly. A system message is added to the thread to confirm it was sent. ## Resolving comments When feedback has been addressed, you can mark a thread as resolved: 1. Open the comment thread. 2. Click the **Resolve** button in the thread header. Resolved threads are hidden from the preview by default. You can toggle to show resolved comments from the comments panel. You can unresolve a thread at any time to reopen it. ## Editing and deleting comments * **Edit**: Click the menu on your own comment and select **Edit**. Update the text and save. * **Delete**: Click the menu on your own comment and select **Delete**. Deleted comments show as `[Deleted]` in the thread to preserve context. ## Reactions You can add emoji reactions to any comment. Click the reaction button on a comment and pick an emoji. Reactions are visible to everyone in the thread. ## Comments sidebar The comments sidebar gives you an overview of all comment threads in the project. It stays hidden when it is not in use. Open it to: * **Browse** all open and resolved threads in one place. * **Search** threads by comment text or author. * **Sort** threads by creation date or read status. * **Track unread threads**. Any thread with new replies since your last visit is highlighted. Click any thread in the panel to navigate to its pin in the preview. ## Notifications about comment activity Comments create notifications in your Lovable inbox: * Starting a new comment thread notifies the project owner. * Replying to a thread notifies everyone who has commented in that thread. * Mentioning someone with `@` notifies them directly. Only people with access to the project receive notifications. [Guest comments on a shared preview link](#guest-comments-from-preview-links) notify the project owner. ## Anchor behavior Each comment pin is anchored to the element you clicked on. As long as the element remains in the same position in the page structure, the pin stays attached. If the layout changes significantly, for example if items are reordered, new elements are added before the commented one, or the element is removed entirely, the pin may lose its reference or attach to the wrong element. When a pin can no longer find its original element, it will display an indicator so you know the reference was lost. The comment thread itself is always preserved. ## Guest comments from preview links Comments are not limited to project collaborators. When you share a preview link, anyone who opens it can leave comments on the preview, without needing access to the project. **Guest comments** are on by default and are managed from the **Share** dialog. See [Collect feedback with guest comments](/features/share-project#collect-feedback-with-guest-comments) for details. ## FAQ Anyone with access to the project can leave comments, regardless of their role.  People without project access can also comment through a shared preview link. See [Guest comments from preview links](#guest-comments-from-preview-links). Project comments are available on all plans. Yes. You can either mention `@Lovable` in a comment or press the **Send to chat** button on a comment thread. Both options send the thread as context to Lovable so it can act on the feedback. The comment pin will remain but display an indicator that the original element could not be found. You can still view and interact with the thread. Leaving comments does not use credits. However, when you send a comment thread to Lovable via `@Lovable` or **Send to chat**, the resulting response uses credits as with any other chat message. Yes. The comments sidebar shows all threads across all pages. Pins are only visible on the page where they were placed and only appear while you are in comment mode. # Project monitoring Source: https://docs.lovable.dev/features/project-monitoring Let Lovable check your app on a schedule, catch bugs and visitor errors early, alert you by email, and help you fix them in chat. Project monitoring checks your project in the background and alerts you when Lovable finds important issues. It looks at your project code and recent errors from visitors using your app, then shows findings in Lovable so you can review them and ask Lovable to fix them. Monitoring is most useful for published apps with real visitors, projects with several collaborators, and any project you want to keep healthy between editing sessions. It helps you catch problems before your users do. Project monitoring is in beta. It is available on Pro, Business, and Enterprise workspaces. ## What project monitoring scans Project monitoring checks two signals: * **Project code:** Lovable reviews the app code for broken functionality, broken app logic, and broken UI. * **Visitor errors:** Lovable checks recent errors that visitors to your app encountered and looks for underlying causes in the code. Examples of findings include: * Sign-in errors * Failing payments * Inputs that are not saved correctly * UI elements that do not work * Failing cron jobs * Broken integrations ## Turn project monitoring on You set up project monitoring separately for each project. Any project editor can turn it on or off. Open your project, then go to **Settings**. The toggle lives in [**Project settings → General → Project monitoring**](/features/projects/settings#project-monitoring). Find **Project monitoring** and turn on the switch. By default, checks run daily at 6:00 in your timezone, and only if the project was edited since the last check. The first check runs at the next scheduled time, not immediately. To change the schedule, select **Configure**, then select the schedule (for example, **Daily at 6:00**) to switch between daily and weekly checks, pick the day for weekly checks, and set the time. Times are shown in your timezone, and checks run around the selected time. Next to **Runs**, select the run condition to choose between **Every time** and **If edited since last check**. For the second option, set the number of edits under **Minimum edits made**, then select **Done**. Select **Save**. The **Project monitoring** section reflects the new schedule. Choose a daily schedule for published apps with regular visitors, and a weekly schedule for projects that change less often. **If edited since last check** avoids spending credits on checks when nothing has changed. When project monitoring is off, new scheduled checks stop running for that project. Scheduled checks also stop running if your workspace moves to a plan that does not include project monitoring, and resume when you upgrade again. ## How findings are shared Lovable shares project monitoring findings in two ways: * **Email:** The project owner receives emails for important or time-sensitive findings. Each email highlights the most important new finding and links directly to it in the editor. * **In the editor:** Project editors see summarized findings above the chat and can investigate, address, or ignore them. Members with view-only access do not see findings. ## Review and fix findings When Lovable finds issues, a summary appears above the project chat. Select **View issues** to expand the full list. You have three options: * **Try to fix:** Lovable works on the open findings in chat, like a regular request. You can review the changes in the chat when the fix completes. * **Skip:** Closes the list without making changes. Skipped findings stay open and reappear the next time you open the project. * **Ignore:** Removes a single finding from the list, for example when it is not relevant, already resolved, or not worth fixing. If you change your mind, select the undo button next to the ignored finding to reopen it. If you want to investigate a finding first, reference project monitoring and the concrete issue in a question to Lovable before starting a fix. For example: ```text wrap theme={null} Project monitoring found that the contact form fails to send messages. Before changing anything, explain what is causing this and how you would fix it. ``` ## Review monitoring history After the first check has run, the **Project monitoring** section in your project settings shows when the project was last checked. Select **View history** next to the last-checked date to see all previous checks, one row per check: | Column | What it shows | | ---------------- | ------------------------------------------------------------------------------------------------------------- | | **Date** | When the check ran | | **Credits used** | Credits the check used | | **Issues** | The number of issues found, **No issues** for clean checks, or **Check failed** if the check did not complete | Select **Load more** to see older checks. ## Cost and credits Project monitoring uses credits for each completed scheduled run. Cost varies with how much code and visitor activity Lovable checks, and each run's cost is shown in the monitoring history. Lovable always uses included daily grants before your credit balance. Scheduled checks are skipped when the project has not met the minimum edit threshold you configured or when the workspace is out of credits. Skipped checks do not use credits. ## Limitations * Project monitoring does not replace testing. Lovable can miss issues, especially when many issues exist in one scan. * Finding status updates only when you fix, ignore, or chat about a specific finding. Changes made before then can make a finding outdated. * Lovable can incorrectly flag working behavior as broken. Ignore false positives so they do not appear again. * Monitoring is configured per project, not once for an entire workspace. ## FAQ No. Project monitoring finds and explains issues. You decide whether to ask Lovable to fix a finding. The project owner receives email alerts for important findings. Each email highlights the most important new finding. All open findings appear in the editor, where project editors can review and act on them. Scheduled checks stop running for that project. Your monitoring history and past findings stay available under **View history** in project settings. Some findings come from recent visitor error logs. The issue may have been temporary or already addressed by another fix you made. Lovable checks whether an issue is still valid before attempting a fix. # Control project access Source: https://docs.lovable.dev/features/project-visibility Control who can view, remix, or collaborate on your projects. Choose whether projects are accessible to all workspace members, or restricted to invited users only. Project access (previously project visibility) controls who can view, edit, and remix **your project in the editor**. This includes access to your source code, chat history, work in progress, and changes that have not yet been published. Depending on your plan, you can keep a project restricted to invited users only or collaborate privately with your workspace. **Project access vs published website access (important difference)** Lovable uses two independent access settings: * **Project access (editor access)** controls who can view and edit your project in the editor, including your source code, chat history, work-in-progress, and any changes that have not been published yet. * **Website access (published URL access)** controls who can visit the published app at its live URL. These settings are independent. Publishing does not change who can access your project in the editor, and changing project access does not affect who can visit the published app. ## Workspace visibility by default As of December 2025, all workspaces have their **default project access** set to **workspace**. This means your projects are private to your workspace and can only be accessed by workspace members by default. ### Restrict project access On **Business and Enterprise plans**, you can choose to restrict projects to invited users only, both on **workspace level** and **project level**. * Workspace **admins and owners** can set the **default project access** for all new projects in **Settings → Privacy & security → Default project access**. * You can override the workspace default for individual projects at any time: * From the prompt input box on the dashboard **when creating new projects** * From the **Share** button in the top bar of any **existing project**. See [Share a project](/features/share-project) for more information. Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. ### Project access options | Default project access | Project-level access | Description | | ----------------------------------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Workspace**
(default for all plans) | Workspace can edit | All **workspace members and explicitly invited collaborators can view, remix, or edit the project based on their role.**
Ideal for team collaboration while keeping work private and secure.
*Note: On project level, you can update the workspace access to **Can view** from the [Share](/features/share-project) dialog.* | | **Restricted**
(available for Business and Enterprise) | Workspace has no access | **Only the owner and explicitly invited collaborators can view, remix, or edit** the project based on their role.
Use this for early exploration, prototyping, or personal experiments. You can give access to the workspace when you’re ready to share and collaborate with your team.
| ## Share a project with internal or external collaborators The **Share dialog** is where you open up a project to others: workspace members, external collaborators, or anyone with a link. It is accessible from the **Share** button in the top bar of any project. See [Share a project](/features/share-project) for more information. ## Enable public remixing When public remixing is enabled, anyone with the project link can copy and remix the project. You can disable this at any time. * People always **copy the latest version** when they remix. They can't edit your project, and the original stays unchanged. * People can **view your project's source code** when they remix it. Make sure it does not include passwords, API keys, or personal data. To let others copy and remix your project, go to **Project settings → Sharing** and turn on **Public remixing** (not available on Enterprise plans). **Important note:** * **Before November 6, 2025:** Projects were **public by default** for free plans, and only paid workspaces could change visibility. * **Starting November 6, 2025:** New projects default to **workspace visibility** for all plans, and all workspaces can update visibility of existing projects. * **As of December, 2025:** All workspaces have their **default project visibility** set to **workspace**. **Default project visibility** has been updated to **workspace** for all Lovable workspaces that previously had default project visibility set to public. * **Starting April 22, 2026**: You can no longer create public projects. Public project visibility has been completely removed. All public projects have been updated to **workspace** visibility. ## FAQ No. Publishing only makes the app available at the published URL. It does not grant anyone access to your project in the editor or your project code, and it does not make your project automatically remixable. Access to the editor, source code, chat history, and unpublished changes is always controlled by **project access**. Access to the published app is controlled separately through website access settings. For more information, see [Publish your app](/features/publish). No. Project access controls who can access your project in the editor. Access to the live app at its published URL is managed separately through website access settings. See [Publish your app](/features/publish) for more information. Project access and website access are **independent settings**. You can combine them in different ways depending on your needs. * **Project access** controls who can access the **project in the editor**, including source code, chat history, work in progress, and changes that have not yet been published. * **Website access** controls who can visit the **published app** at its live URL. Below are common configurations: 1. **Internal team app** * Project access: `Workspace` * Website access: `Workspace` **Result:** Only workspace members can view and edit the project in the editor and visit the published app. 2. **Private work-in-progress, public app** * Project access: `Restricted` * Website access: `Anyone` **Result:** Only you can view and edit the project in the editor, but anyone with the published URL link can visit the published app. Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. 3. **Team-built, publicly shared app** * Project access: `Workspace` * Website access: `Anyone` **Result:** Only workspace members can view and edit the project in the editor, but anyone with the published URL link can visit the published app. 5. **Private prototype shared internally** * Project access: `Restricted` * Website access: `Workspace` **Result:** Only you can view and edit the project in the editor, and only workspace members can visit the published app. Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. **Key reminder:** Publishing does not change who can access your project in the editor, and project access does not affect who can visit the published app. Yes, you can change the project access at any time from the **Share** button in the top bar of any project. See [Share a project](/features/share-project) for more information. Yes. Create the project with **Restricted** access. The project will only be visible to you. When you’re ready to share, click **Share** and invite specific people or [groups](/features/groups), assigning roles as needed. See [Share a project](/features/share-project) for more information. Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. # Chat with Lovable to build your app Source: https://docs.lovable.dev/features/projects/chat Everything you can do in Lovable's chat panel. Write or dictate prompts, attach files, queue messages, answer Lovable's questions, undo changes, and fix errors. The chat panel on the left side of the editor is where you tell Lovable what to build. You describe what you want in plain language, Lovable does the work, and each response shows what changed so you can review it, steer it, or undo it. Behind every message, Lovable's agent works in a loop: it gathers context from your conversation and project, takes action with tools, and checks the result before moving on. You'll see that loop reflected in everything below, from activity cards to the questions Lovable asks. You can ask Lovable anything, not just build requests. Ask how your app works, what a term means, or anything else on your mind, and Lovable answers in chat. ## The prompt box Type your message into the text field at the bottom of the chat panel, then press **Enter** or click the send button. You don't need any special phrasing. Describe the outcome you want rather than the implementation: ```text wrap theme={null} Add a sign-up form with email and password fields. ``` See [Prompting best practices](/prompting/prompting-one) for more guidance. Around the text field you'll find: * **The microphone**: Dictate your message instead of typing. Click it to start recording, or press **Option+V** (Mac) or **Alt+V** (Windows/Linux). When you finish, click the check, and Lovable transcribes your words into the prompt box for you to review and send. Click the X instead to discard the recording. * **The mode toggle**: Switch between [Build and Plan mode](#modes), or press **Option+P** (Mac) or **Alt+P** (Windows/Linux). * **The button**: Open the [Chat actions menu](#chat-actions) to attach files, add references, and reach common project tools. ## Modes The mode toggle next to the chat input switches how Lovable responds: * **Build**: Lovable makes changes directly in your project. This is the default, and the right choice for most requests, from small tweaks to whole features. Cost is usage-based, and many requests cost less than one credit. See [Build mode](/features/agent-mode). * **Plan**: Lovable discusses, investigates, and plans without touching your code. Use it to think through a bigger feature, debug an issue safely, or compare approaches before building. Each Plan mode message costs one credit. See [Plan mode](/features/plan-mode). You can switch modes at any time, and the conversation carries across both. ## Chat actions Click the **** button next to the chat input to open the **Chat actions** menu, the quickest route to attaching context and common project tools: * **Settings**: Open the settings dialog on your project's **General** tab, where you rename the project, manage publishing options, and more. See [Project settings](/features/projects/settings). * **History**: Open your project's [version history](/features/projects/history) to browse and restore earlier versions. * **Knowledge**: Write persistent instructions that Lovable follows in every request, such as your product context or design rules. See [Knowledge](/features/knowledge). * **GitHub**: Connect your project to a GitHub repository with two-way sync, so changes flow in both directions. See [GitHub](/integrations/github). * **GitLab**: Connect your project to a GitLab repository with two-way sync, so changes flow in both directions. See [GitLab](/integrations/gitlab). * **Project connectors**: See the services your project is connected to and the chat connectors available to it, and click any connection to manage it. See [Connectors](/integrations/introduction). * **Take a screenshot**: Capture the current preview and attach it to your message, useful for pointing at what you're discussing. * **Add reference**: Open the `@` picker to point Lovable at: * **[Code](/features/code-mode)**: Files in your project's codebase. * **[Files](/features/generate-files)**: Documents you uploaded or Lovable generated. * **[Connectors](/integrations/introduction)**: A selection of popular connectors to pull content from. * **[Projects](/features/cross-project-referencing)**: Other projects in your workspace. * **Add skill**: Browse your workspace's [skills](/features/skills), reusable instruction sets, and run one. Picking a skill types the `/` command for you. * **Attach**: Add files from your computer to your message. See [Attach files as context](#attach-files-as-context). ## Attach files as context Attachments show Lovable what you mean. Attach a design mockup to match, a screenshot of a bug to fix, or a document to build from, like a product brief, a spreadsheet of data, or an audio note. Attachments work the same when you [create a project](/features/projects/overview#ways-to-create-a-project) from the dashboard: attach files to your very first prompt. To add files, use **Attach** in the **Chat actions** menu, drag files into the chat, or paste them. Lovable reads what you attach: images, PDF, Word, Excel, and PowerPoint files, and even audio recordings. Ask questions about an attached document, or tell Lovable to use its content in your app. Each file can be up to **20 MB** on the Free plan, **256 MB** on paid plans, and **1 GB** on Enterprise. You can attach up to 10 files per message. Images can total up to 15 MB per message, and Lovable compresses large ones automatically. If an upload fails, try again with fewer or smaller files. After attaching an image, click it to open the preview and draw on it, for example to circle the part you want changed. Lovable receives the annotated image with your message. To put an image or video into your app itself rather than show it to Lovable, see the next section. ## Add images and videos to your app To place media in the app you're building, use whichever of these fits: * **Ask Lovable to generate it**: Lovable can generate images, edit existing ones (including making backgrounds transparent), and even generate short videos. Describe what you want: ```text wrap theme={null} Generate a hero image of a mountain at sunrise. ``` * **Attach the image in chat**: Upload the image and tell Lovable where it goes: ```text wrap theme={null} Replace the logo in the navbar with this image. ``` * **Point at an existing image**: In the preview, use **Select elements** in the [preview toolbar](/features/preview-toolbar) to select the image you want to change, attach the replacement or paste its URL, and describe the update. * **Reference a hosted URL**: If the image already lives somewhere online, paste its URL in chat and tell Lovable where to use it. Be mindful of copyright. * **Upload to your Git repository**: If your project is connected to [GitHub](/integrations/github) or [GitLab](/integrations/gitlab), upload media files to the repository's `public` folder, then reference them by path: ```text wrap theme={null} Add public/hero-image.jpg to the hero section. ``` * **Embed a video**: Link to a hosting service like YouTube and ask Lovable to embed it. For example: ```text wrap theme={null} Embed this video https://www.youtube.com/watch?v=your-video-id in the hero section. ``` Large files stored in your project make it slower to load and preview. Compress images to the size they're displayed at, and host videos on a service like YouTube instead of uploading the file to your repository. ## While Lovable works Lovable working on one request doesn't block you. Here is what you can do in the meantime. ### Queue your next prompts You don't have to wait for Lovable to finish before sending your next request. In both Build and Plan mode, new messages join a visible queue above the chat input and run one at a time, in order. You can pause and resume the queue, reorder prompts, edit, copy, or remove them, and repeat a queued prompt up to 50 times. Queued prompts keep the files, elements, and references you attached to them. ### Follow the work in activity cards Lovable's individual actions show up in chat as expandable activity cards: file edits, commands, web searches, browser tests, and the [subagents](/features/subagents) it delegates research to. Expand a card to inspect the details. On bigger Build mode requests, Lovable also shows the tasks it's working through. See [Build mode](/features/agent-mode#tasks-and-execution-visibility). ### Stop mid-task If you need to change course, click the **stop button** while Lovable is responding. Lovable keeps the work completed so far, and the message is charged for the work already done. You can then send a new message with better direction. ## Answer Lovable's questions When Lovable needs more direction, it can pause and show a question card instead of guessing. The card holds up to four questions, each with answer options, and you can pick an option or write your own answer. You stay in control of how much you answer: * Move between questions and change earlier answers before submitting. * Skip a single question, or skip them all. If you skip everything, Lovable picks reasonable defaults and continues. * Draft answers are kept in your browser, so refreshing the page doesn't lose them. For open-ended visual work, Lovable can also show design directions to choose from directly in chat, so you steer the look before it builds. See [Design guidance](/features/design-guidance#design-directions). ## Act on Lovable's responses When Lovable finishes a task, its response summarizes what it did and what changed, and a row of actions lets you react without typing: * **Undo latest edit** (latest response only): Reverse Lovable's most recent change in one click, with no confirmation. * **Revert to this version** (earlier responses): Restore your project to that point after you confirm. Works the same as reverting from [version history](/features/projects/history). * **Copy**: Copy the response text, for example to save an explanation Lovable gave you. * **Helpful** / **Not helpful**: Rate the response to give feedback on the result. The **More options** menu on a response shows: * **Copy message link**: Copy a direct link to that message, handy for pointing a collaborator or support to the exact step where something happened. * **Preview**: See your app as it was right after that message, without reverting anything. * How long Lovable worked and **Credits used**: What the message cost. See [Credits and usage](/introduction/credits-and-usage). On the activity card of a finished change, the **Bookmark in history** toggle saves that version to your bookmarks so it's easy to find and restore later. See [Version history](/features/projects/history). ## Edit a message and try again If an earlier request sent things the wrong way, hover over one of your own past messages and select **Edit message**. Rewrite the message and confirm with **Revert and resend**: your project returns to the state before that message, and Lovable runs the new version instead. This works on your own text-only messages. Learn more in [Version history](/features/projects/history). ## Fix errors and get unstuck When a build error appears while Lovable works, a **Try to fix** button appears on the activity card. Click it and Lovable scans the logs, finds the issue, and attempts a fix. Clicking **Try to fix** doesn't use credits. If the error keeps coming back, or your app runs without errors but doesn't behave as you intended, work through these steps instead of retrying the same prompt: Describe what you see and what you expected. Lovable can inspect errors, logs, and console output, and test your app in a browser. ```text wrap theme={null} The login form does nothing on mobile. Walk me through what's happening. ``` Roll back to the version just before the issue appeared using [version history](/features/projects/history), then try a clearer, more specific prompt. Switch to [Plan mode](/features/plan-mode) and ask Lovable to outline an approach first. Review the plan, adjust it, then build step by step. If you're on a paid plan and believe the issue is with Lovable itself, contact [Support](https://lovable.dev/support). With [Project monitoring](/features/project-monitoring), Lovable can also watch your project on a schedule and post a brief in chat when it detects an issue, with the option to fix or ignore it. Monitoring is off by default: turn it on in **Project settings → General → Project monitoring**. Available on Pro plans and above. ## Suggestions from Lovable After a response, Lovable may suggest features to build next as clickable chips near the chat input. Click one and it fills the prompt box, so you can adjust the wording before sending, or ignore the chips and write your own. Suggestions are based on your project and what you just built. You can turn them off with the **Chat suggestions** toggle in your [account settings](/introduction/lovable-account-settings). ## FAQ Yes. Messages in both Build and Plan mode consume credits. You can see what a specific message cost from its **More options** menu under **Credits used**. See [Credits and usage](/introduction/credits-and-usage). Yes. While Lovable is working, keep typing: new messages go into a queue and run one at a time, in order. You can pause, reorder, edit, or remove queued messages before they run. See [Build mode](/features/agent-mode#prompt-queue). Click **Undo latest edit** under Lovable's latest response to reverse its most recent change in one click. To go further back, revert from [version history](/features/projects/history), or use **Edit message** on your own message and choose **Revert and resend** to rewrite it and try again. Use **Attach** in the **Chat actions** menu, drag files into the chat, or paste them. You can also use **Take a screenshot** to capture the preview. See [Attach files as context](#attach-files-as-context). Yes. Open the **Code** tab in the project toolbar to read and edit your project's code by hand. See [Edit code](/features/code-mode). Single files larger than 10 MB cannot be saved into your project's code, usually after adding large images, videos, or other media. Ask Lovable in chat to migrate them, and it moves the files to Lovable's CDN and updates your code to load them from there: ```text wrap theme={null} Migrate large files to CDN assets. ``` Files pushed from your own computer through GitHub or GitLab can be larger, but Lovable cannot change them afterwards. Lovable keeps working. Your request runs on Lovable's servers, not in your browser, so you can close the tab and come back later to find the finished result in chat. Yes. On desktop, Lovable may offer to enable browser notifications so you know when it finishes a task or needs your input. You can dismiss the prompt and keep working without them. # Find your way around the Lovable editor Source: https://docs.lovable.dev/features/projects/editor A guided map of the Lovable editor: where every tool lives, from the chat panel and live preview to the project toolbar, More menu, and keyboard shortcuts. Opening a project takes you to the **editor**. This is where you build: you describe what you want in the chat panel on the left, and you watch your app take shape in the preview on the right. Everything else, from version history to publishing, is one or two clicks away in the top bar. This page is a map of the editor, so you always know where to find things. The layout described here is the desktop browser experience. On smaller windows some controls collapse into overflow menus, and the [Lovable mobile app](/integrations/lovable-mobile-app) arranges the same areas as swipeable views instead of a top bar. ## The two main areas * **Chat panel** (left): Where you tell Lovable what to build and follow its progress. Learn more in [Chat with Lovable](/features/projects/chat). * **Preview** (right): A live, interactive version of your app that updates as Lovable works. Learn more in [Preview your app](/features/projects/preview). The rest of the editor's controls sit in the top bar. ## Lovable logo The Lovable logo in the top corner opens the dashboard sidebar in place, so you can switch workspaces, jump to another project or folder, or reach any part of the [dashboard](/introduction/dashboard-overview) without leaving the editor. ## Project name menu Click your project's name in the top bar to open a menu with project-level and account actions. At the top it shows your workspace, plan, and current credit usage. Below that: * **Get free credits**: Earn additional credits through referrals. See [Share Lovable](/introduction/dashboard-overview#share-lovable). * **Settings**: Open the settings dialog, covering both [project settings](/features/projects/settings) and your [workspace settings](/features/workspace-admin-settings). * **Project connectors**: Manage the services your project connects to. See [Connectors](/integrations/introduction). * **Remix this project**: Create an independent copy to build on. See [Remix a project](/features/projects/remix). * **Design system**: Apply a shared design system to this project. Available on Enterprise plans. See [Design systems](/features/design-systems). * **Rename project**: Change the project's display name. * **Star project**: Pin the project to your **Starred** list on the dashboard. * **Move to folder**: Organize the project into a dashboard [folder](/introduction/project-folders). * **Details**: View project information such as its description, owner, and creation date. * **Appearance**: A small submenu to switch the editor between light and dark themes. * **Help**: Get support and helpful resources. You need edit access to the project to see most of these items, so viewers get a reduced menu. A few items also depend on your plan, like **Design system** on Enterprise. ## History The **History** toggle next to the project name opens your project's version history, where you can browse past versions, restore an earlier one, and manage bookmarks. Learn more in [Version history](/features/projects/history). ## Close sidebar The **Close sidebar** toggle collapses the chat panel to give the preview the full window, and brings it back when you click it again. You can also press **Cmd+B** (Mac) or **Ctrl+B** (Windows/Linux). ## Project toolbar The tabs in the project toolbar switch what the main area shows: * **Preview**: The home tab. Shows your app running live, so you can click through it exactly as your users would. See [Preview your app](/features/projects/preview). * **Files**: The files that live alongside your app: documents Lovable [generates for you](/features/generate-files) and files you upload, like reports, exports, and other deliverables. * **Code**: A full code editor where you can read your project's code, edit it directly on paid plans, and download it. See [the code editor](/features/code-mode). * **More**: Opens a panel with the rest of your project's tools, listed below. ### The More menu Click **More** to open a panel with tools for growing and running your app: | Section | What it's for | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Analytics** | Visitor counts, page views, and usage trends for your published app, without adding any tracking code. Learn more in [Analytics](/features/analytics). | | **Cloud** | Your app's backend in one place: the database and its records, user accounts, file storage, scheduled jobs, edge functions, secrets, logs, and usage. Learn more in [Lovable Cloud](/features/cloud). | | **Agent integrations** | Publish your app as an MCP server, so AI assistants like ChatGPT and Claude can use it. Learn more in [Agent integrations](/features/agent-integrations). | | **Payments** | Accept payments in your app through the built-in **Paddle** and **Stripe** integrations, with Lovable wiring up products and checkout. Learn more in [Payments](/features/payments). | | **Connectors** | See the services your project is connected to, with links to manage each connection. Learn more in [Connectors](/integrations/introduction). | | **Security** | Review security findings for your project and fix them with Lovable's help. Learn more in [Security](/features/security) and the [project security view](/features/security-view). | | **SEO & AI search** | Review how search engines and AI tools see your app, and fix metadata, indexing, and accessibility issues. Learn more in [SEO & AI search](/features/seo-aeo). | | **Sensitive data** | Appears when sensitive data scanning is enabled for your workspace, and shows what personal data your app handles. Learn more in [Sensitive data scanning](/features/sensitive-data-scanning). | A few tools you might expect as their own sections live inside **Cloud**: * **AI**: Monitor and manage the AI features inside your app, such as model usage and spend. Learn more in [AI](/features/ai). * **Emails**: Send transactional email, like sign-up confirmations and receipts, from your app's own address. Requires Lovable Cloud and a paid plan. Learn more in [Send emails](/features/custom-emails). * **Supabase**: Manage your external Supabase connection, when your project uses one. Learn more in [Supabase](/integrations/supabase). What you see in the More menu depends on your project and plan: sections tied to a feature appear once you use it. ## Top right controls These controls sit above the preview and are available while the **Preview** tab is active. From left to right: * **Preview toolbar button**: Brings back the [preview toolbar](/features/preview-toolbar) when it's hidden, so you can select elements, edit text inline, and draw on the preview. * **Comments**: Open your project's comments to catch up on feedback from collaborators. This button shows when the preview toolbar is hidden. When the toolbar is visible, comments live in the toolbar itself. See [Project comments](/features/project-comments). * **Collaborator avatars**: See who else is in the project right now, and invite others. * **Share**: Invite collaborators, control who can access the project, and create preview links. See [Share your project](/features/share-project). * **Publish**: Deploy your app to its live URL, or push an update to the published version. On Business and Enterprise plans you can publish to your workspace only, instead of the public web. You can also ask Lovable to publish in chat. See [Publish your project](/features/publish). ## Command palette Press **Cmd+K** (Mac) or **Ctrl+K** (Windows/Linux) anywhere in the editor to open the [command palette](/introduction/project-search-and-find#command-palette) and search for projects, folders, and settings from the keyboard. ## FAQ Open the **More** tab in the project toolbar and select **Cloud**. That's where your database, users, storage, and backend logs live. See [Lovable Cloud](/features/cloud). Open the **More** tab in the project toolbar and select **Analytics**. See [Analytics](/features/analytics). Click the **Code** tab in the project toolbar. See [the code editor](/features/code-mode). Click your project's name in the top bar, then select **Settings**. See [Project settings](/features/projects/settings). In the **Share** menu in the top right, not in project settings. Share is where you invite collaborators, set roles, and control the project's visibility. See [Share your project](/features/share-project). Click the Lovable logo in the top corner to open the dashboard sidebar and pick any project or folder, without leaving the editor. On smaller windows, some tabs collapse into an overflow menu at the end of the project toolbar, so try widening your browser window. Some tools also appear only when they're relevant to your project or included in your plan. # Revert and restore your project with version history Source: https://docs.lovable.dev/features/projects/history Lovable saves every change as a version automatically. Preview old versions of your project, revert to an earlier state, and bookmark stable versions. Every change Lovable makes to your project creates a version automatically. There is no save button: version history is always complete and up to date, and you can go back to any earlier version at any time. ## Why version history matters Version history is your safety net. If a change breaks something or takes the app in the wrong direction, you can preview an earlier version, revert to it, or go back to an earlier point and try a different instruction. Nothing gets lost along the way: all changes made after that point stay in the chat and can be reapplied anytime. ## Open version history Open the History panel in either of two ways: * Click the **History** toggle in the top bar of the editor. * Click the **** menu next to the message input and select **History**. The panel has two tabs: **History**, which lists every version, and **Bookmarks**, which lists the versions you bookmarked. ## Work with a version Click any version in the list to open it in a snapshot view, where you can look around that state of your app without changing anything. Use the **Back to latest** button in the top bar to return to your current version, or restore the snapshot from there. Each version also has a row of actions: * **More actions** menu: * **Open preview in new tab**: Look at that version full screen in its own browser tab. * **View code changes**: See exactly which files and lines that version changed, as a diff. * **Go to message in chat**: Jump to the conversation moment that produced the version, useful for remembering why a change happened. * **Revert** (tooltip: **Revert to this version**): Restore your project to that version. * **Bookmark** toggle: Save the version to the **Bookmarks** tab. The version your users currently see shows a **Published** badge, which makes it easy to find the exact state that is live right now. ## Revert to an earlier version Reverting restores your project to how it was at that version. It is not destructive to your chat: the conversation continues from where you are. Clicking **Revert** asks you to confirm first, with the date of the version you're returning to. Confirm with **Revert**, or click **View in chat** to jump to the matching message before you decide. Reverting restores your project's **code only**, and redeploys your app's edge functions to match. It does not restore or roll back your **database data**. If messages after that version added records, changed data, or ran migrations against your data, reverting the code does not undo those data changes. Your chat history is preserved, and the edits made after that point stay in the chat, so you can reapply them anytime. ### Go back and try something different If you want to return to an earlier point and take a different direction rather than just restore, edit a past message. Hover over one of your own messages, click **Edit message**, adjust the text, and confirm **Revert and resend**. Lovable reverts to that point and continues with your new instruction. ### When revert is unavailable The **Revert** button is disabled when: * You are already on that version. * The project was remixed from a [Lovable Cloud](/features/cloud) project: versions from before the remix can't be restored. * The version is very old. You can still open and preview it, but it can no longer be restored. The tooltip reads **Cannot revert this far back in history**. ## Bookmarks Bookmarks let you mark the versions you care about, like a stable release or a design you want to return to, so you don't have to scroll through the full history to find them. * Bookmark from chat: Select **Bookmark in history** on the activity card of a finished change. * Bookmark from the History panel: Click the bookmark toggle on any version. Bookmarks are kept per project and appear in the **Bookmarks** tab of the History panel. Bookmark a known-good version before starting a big change, like a redesign or a data model rework. If the change goes sideways, the version you want to return to is one click away instead of buried in history. ## FAQ No. Revert is all or nothing per version: it restores the entire project to that state. If you only want to undo one specific change, ask Lovable in chat to restore that specific part: ```text wrap theme={null} Bring back the pricing section from before the redesign. ``` No. Credits pay for the work Lovable performs, so messages you later revert still count. See [Credits and usage](/introduction/credits-and-usage). All versions are kept, and you can scroll back through your project's entire history. Very old versions can be opened and previewed but no longer restored. For those, the revert button shows **Cannot revert this far back in history**. Nothing. Reverting only restores your project's code. Your database data stays exactly as it is, which also means reverting cannot undo data changes made after that version. # Projects in Lovable Source: https://docs.lovable.dev/features/projects/overview What a project is in Lovable and how to work with one: create, organize, and publish projects, manage roles and ownership, and safely move or delete them. A project is one app in Lovable. Every project lives inside a [workspace](/features/workspace), has a single project owner, and holds everything that belongs to that app: * **[Chat](/features/projects/chat)**: The conversation where you tell Lovable what to build. * **[Preview](/features/projects/preview)**: The live version of your app that updates as you build. * **[Code](/features/code-mode)**: Your app's source code, which you can browse, edit, and download. * **[Version history](/features/projects/history)**: Every change, saved automatically. * **[Settings](/features/projects/settings)**: The project's name, URL, domains, knowledge, and more. Lovable saves its work automatically: every edit it makes becomes a version in your project's version history, so there is nothing for you to save as you build. Projects are the unit you build, share, and publish. Understanding how they work helps you keep work organized, collaborate with teammates, and make confident use of the few actions that are permanent, like deleting a project. ## Ways to create a project * **From the dashboard**: Describe what you want to build in the [prompt input](/introduction/dashboard-overview#the-prompt-input), by typing or dictating with the microphone, and send it. Attach files or drag and drop them for context, and use the **+** menu to start from a [template](/features/business/design-templates) or apply a [design system](/features/design-systems). You can also start from a Figma design, a sketch, or a website whose layout you want Lovable to recreate: see the start paths in [Quick start](/introduction/getting-started). * **By remixing**: Create your own independent copy of an existing project: one of your own, a project that allows remixing, or a template from the dashboard's **Resources** section. See [Remix a project](/features/projects/remix). * **With Build with URL**: Generate a project from a shareable link that contains a prompt, useful for embedding a "Build with Lovable" button or sharing predefined prompts. See [Build with URL](/integrations/build-with-url). Lovable also works beyond the browser: create and edit projects from the [desktop app](/integrations/desktop-app), the [mobile app](/integrations/lovable-mobile-app), the [ChatGPT app](/tips-tricks/chatgpt-app), the [Telegram bot](/tips-tricks/lovable-telegram-bot), or the [Lovable MCP server](/integrations/lovable-mcp-server) in your other AI tools. ## Draft and published states A new project starts as a draft: only you and the people you share it with can see it, through the editor or a [preview link](/features/share-project#share-preview-links). When you're ready, publishing deploys a snapshot of your app to its live URL. By default anyone with the link can visit it. On Business and Enterprise plans you can restrict website access to your workspace. Edits you make after publishing stay in your draft until you publish again, so visitors never see half-finished work. See [Publish your project](/features/publish) and [Preview your app](/features/projects/preview). ### Your project URL Every project gets a subdomain that forms its `lovable.app` web address after you publish. You can change it in **Project settings → URL subdomain**. Renaming a project changes only its display name, not its URL. On paid plans, you can also connect a [custom domain](/features/custom-domain) after you publish. ## Project roles Every project has one **owner**, usually the person who created it. Everyone else works in a project with one of three roles, managed from the **Share** menu in the editor: | Role | What they can do | Availability | | ---------- | -------------------------------------------------------------------------------------------------- | ----------------------------- | | **Owner** | Everything: edit, publish, manage settings, transfer, or delete the project | Every project has exactly one | | **Admin** | Full access to the project, including all project settings, integrations, and external connections | Paid plans | | **Editor** | Build, edit, and manage most project settings | All plans (the default role) | | **Viewer** | Read-only access to the project | Paid plans | Invite people from the **Share** menu, by email or with an invite link. You can invite members of your workspace, or external collaborators: people outside your workspace who get access to just this project. Workspace roles matter too. Workspace owners keep full access to all projects in the workspace regardless of who owns each project, and workspace admins have the same access except for projects with restricted access. See [Share a project](/features/share-project) for the full picture, including invite links and external collaborators. ### When ownership changes * **Transfer ownership**: The owner can hand a project to another workspace member from **Project settings → Transfer ownership**. * **When an owner leaves**: If a project owner leaves or is removed from the workspace, their projects are automatically transferred to the most senior remaining member (owners first, then admins, then editors). Projects with access set to **Restricted**, which only the owner and invited collaborators can open, are not transferred automatically. ## Organize and manage projects Everyday project management lives in three places, and you can use whichever is closest: the project card's menu on the [dashboard](/introduction/dashboard-overview#manage-projects-from-the-dashboard), the project name menu in the [editor](/features/projects/editor), and [Project settings](/features/projects/settings). * **Rename**: From the project name menu in the editor or **Project settings → Project name**. * **Star**: Pin the project to your **Starred** list, from the project card or the project name menu. * **Move to folder**: Organize projects into dashboard folders, from the project card or the project name menu. See [Project folders](/introduction/project-folders). * **Move to another workspace**: From the project card menu (**Transfer to workspace**) or **Project settings → Move workspace**. The project keeps its history and settings. People invited directly to the project only move with it if you opt in. See [Move a project to another workspace](/features/projects/settings#move-a-project-to-another-workspace). * **Transfer ownership**: From **Project settings → Transfer ownership**. * **Delete**: From **Project settings → Danger zone → Delete project**. To confirm, you type the project's name. Deleting a project is permanent. There is no way to restore a deleted project, its version history, or its chat history. If you might need the project later, [remix it](/features/projects/remix) first to keep a copy, or [download the code](/features/code-mode). ## FAQ Yes. Every change Lovable makes is saved automatically as a version in your project's [version history](/features/projects/history). There is no save button, and you can revert to any earlier version at any time. There is no project limit. Every workspace member can create and work on as many projects as they want. Plans are priced by credits, not by projects or seats. See [Lovable workspace](/features/workspace). No. A project lives in one workspace at a time. You can move it to another workspace from **Project settings → Move workspace**, or remix it into a different workspace to create an independent copy there. No. Deleting a project is permanent and there is no restore option. Remix the project or download its code before deleting it if you want to keep a copy. The project was most likely deleted, or you no longer have access to it. If neither should be true, contact [Support](https://lovable.dev/support). That depends on your project access setting, which you manage from the **Share** button in the editor. See [Project access](/features/project-visibility) and [Share a project](/features/share-project). # Preview and test your app in Lovable Source: https://docs.lovable.dev/features/projects/preview See your app running live while you build. Test phone, tablet, and desktop sizes, try complete flows before you publish, and share progress with a preview link. The **preview** is the live, interactive version of your app that runs on the right side of the editor. It updates as Lovable builds, so you can watch changes appear, click through your app, and test it exactly as your users would. Think of the preview as your app's staging environment: a private testing space that always runs your latest work. Your visitors see the published version instead, a snapshot that only changes when you [publish](/features/publish). That separation gives you room to iterate before visitors see the result. Keep in mind that the preview and your published app share the same backend and data, so changes to your database affect both. ## Why the preview matters The preview is where you check Lovable's work. Instead of guessing whether a change landed correctly, you click around your app, try the flow you asked for, and give feedback right away. Testing in the preview before you publish keeps unfinished work off your live site. ## Common ways to use the preview * **Check each change as it lands**: After you send a request, watch the preview update and confirm the result matches what you asked for. * **Test a flow end to end**: Sign up, fill in a form, or complete a checkout in the preview before your users do. * **Review on different screen sizes**: Use the device toggle above the preview to make sure your app works on a phone, not just on your laptop. * **Collect feedback**: Share a view-only preview link from the **Share** menu so a friend, client, or teammate can see your progress. See [Share a preview](#share-a-preview). ## Preview controls The bar above the preview holds the controls for moving around your app: * **Device toggle**: Switches the preview between **Desktop view**, **Tablet view**, and **Mobile view** so you can check your app at phone and tablet sizes before you share it. * **Page selector**: Shows the page you're viewing. Click it to see all of your app's pages, find one by typing in the **Find page or enter path** field, or enter a path directly to jump there. * **Refresh**: Reloads the preview. * **Open in new tab**: Opens your development preview in its own browser tab, so you can test it full screen or keep it visible while you chat. This URL requires signing in to Lovable with access to your project. To show your app to someone without access, use a [preview link](#share-a-preview) instead. If the preview looks wrong or won't load, click **Refresh** first. Hold **Shift** while clicking **Refresh** to also restart the preview environment, which resolves most loading issues. A hard browser refresh (**Cmd+Shift+R** on Mac, **Ctrl+Shift+R** on Windows/Linux) can help too. A few more controls sit in the top right corner, above the preview: * **Preview toolbar toggle**: Bring back the [preview toolbar](/features/preview-toolbar) if you've hidden it, so you can select elements, edit text, and draw on the preview. * **Comments**: Open your project's [comments](/features/project-comments) to catch up on feedback pinned to the preview. * **Collaborator avatars**: See who else is in the project right now. * **Share** and **Publish**: Invite people or create preview links, and put your app live. See [Share your project](/features/share-project) and [Publish your project](/features/publish). The [editor map](/features/projects/editor#top-right-controls) describes the full top bar. ## Preview pause Your preview runs in a temporary cloud environment that Lovable starts for your project while you work. When you're away from the project for a while, that environment pauses to save resources, and the preview shows a **Still building?** message noting that Lovable paused it. Click **Keep building** to resume. The environment starts again and the preview picks up exactly where you left off. Pausing is normal and changes nothing about your project. Your published site is never affected, and visitors can still access your live app while the preview is paused. ## Edit directly from the preview The [preview toolbar](/features/preview-toolbar), the floating toolbar inside the preview, turns the preview into an editing surface. Its four modes each change what clicking does: * **Select elements**: Point Lovable at a specific element and describe the change in plain language. * **Edit text inline**: Fix typos and copy directly on the page, without a prompt. * **Draw annotation**: Sketch on top of your app to show a layout change that's hard to describe. * **Add a comment**: Pin feedback to a specific element for you or your collaborators. When you know exactly which part of the page you want to change, pointing at it is usually faster and more precise than describing it in chat. See [Edit from the preview](/features/preview-toolbar) for the full guide. ## Test your app Test the important flows yourself in the preview: click every button, submit your forms, and try the paths your users will take. You can also ask Lovable to test for you. Lovable can open your app in a real browser, navigate pages, click buttons, fill forms, and report what it finds, and it can run automated tests for your app's logic. Ask in chat: ```text wrap theme={null} Test the sign-up flow and fix anything that's broken. ``` See [Test and verify your app](/features/testing) and [Browser testing](/features/browser-testing). ## Share a preview To let someone see your working version without giving them access to the project, create a **Share preview** link from the **Share** menu in the top right of the editor. Anyone with the link can open it while it's valid, with no Lovable account needed. Guests can't edit anything. By default they can leave comments on the preview, and you can turn guest comments off in the **Share** menu before copying the link. Links expire after 7 days, and Enterprise workspaces can disable share preview links entirely. Learn more in [Share your project](/features/share-project). ## FAQ Click **Refresh** above the preview first. If that doesn't help, hold **Shift** and click **Refresh** to restart the preview environment, or do a hard browser refresh (**Cmd+Shift+R** on Mac, **Ctrl+Shift+R** on Windows/Linux). A blank preview usually comes from an error in the app itself. Ask Lovable about it in chat: ```text wrap theme={null} The preview is white, investigate and fix it. ``` If the preview shows "Not found" or keeps spinning up, that's often temporary. Try again in a moment. No. The preview always shows your latest working version. Your published site is a snapshot that only changes when you publish. If you make changes in the editor, visitors won't see them until you publish an update. See [Publish your project](/features/publish). Only people you let in. Collaborators open the preview in the editor. Viewers see just the preview, while editors and admins see the full editor, including chat. To show your work to someone outside the project, send them a **Share preview** link. Anyone with the link can view your working version in their browser, with no Lovable account needed, until the link expires after 7 days. There is no permanent public URL for your preview. See [Share your project](/features/share-project). The preview pauses after you've been away for a while to save resources. Click **Keep building** to resume. This is normal and has no effect on your published site. Use the device toggle above the preview to switch between **Desktop view**, **Tablet view**, and **Mobile view**. You can also click **Open in new tab** and resize your browser window, or open a preview link on your phone. # Remix a project Source: https://docs.lovable.dev/features/projects/remix Remix a Lovable project to create your own independent copy. Learn what carries over to the copy, who can remix your project, and how to move projects between accounts. Remixing creates your own independent copy of a project. The copy is a new project that you own, and changes you make to it never affect the original. ## Why remix a project * **Duplicate your own work**: Keep a safe copy before a big change, or spin off a variation of an app you already built. * **Start from a public project**: Use someone else's remixable project or a template as a starting point instead of building from scratch. * **Move work between workspaces or accounts**: Remix a project into a different workspace, or use remixing to [move projects to another account](#move-a-project-to-another-account). ## Control who can remix your project The **Public remixing** toggle in **Project settings → Sharing** controls whether other people can remix your project via its link. It is off by default: until you turn it on, your project is a starting point for yourself and your collaborators only. Public remixing is not available in Enterprise workspaces. When public remixing is on, anyone with your project's link copies the **latest version** of the project. They can't edit your project, and the original stays unchanged. Because a copy contains your code, turning this on also lets people with the link view your project's source code. You can turn it off again at any time. Copies people already made stay theirs. See [Project access](/features/project-visibility). Projects connected to an external [Supabase](/integrations/supabase) project can only be remixed by people with edit access to the source project. ## How to remix You can start a remix from three places: * In the editor, click the project name in the top bar and select **Remix this project**. * In **Project settings → Project actions**, click **Remix**. * On the [dashboard](/introduction/dashboard-overview), open a project card's menu and select **Remix**. ### The Remix dialog The dialog shows these fields: * **Project name**: The name of the copy, pre-filled with the original name. * **Target workspace**: Which workspace the copy is created in. This field only appears when you have more than one workspace. In Enterprise workspaces, remixing into a different workspace requires transfer permission: workspace admins and owners always have it, and editors have it when the workspace's [**Editor project transfers**](/features/privacy-and-security-settings#editor-project-transfers) setting is on. * **Target folder**: Optionally place the copy in a [folder](/introduction/project-folders). Appears when the target workspace has folders. * **Include project history**: Copies the chat history into the copy so the conversation context is preserved. This option appears when you have edit access to the original. * **Include custom knowledge**: Copies the project's [knowledge](/features/knowledge). This option only appears when the project has custom knowledge. * **Region**: For projects on the built-in backend (Cloud), the dialog also asks which region hosts the copy's backend. The region is locked once chosen; see [Region selection](/features/cloud#region-selection). Some templates ask you to confirm a security acknowledgement before remixing. In that case, the button reads **Acknowledge and remix** instead of **Remix**. ## What carries over A remix copies what you need to keep building and leaves behind everything tied to the original's identity, like its live URL, its collaborators, its secrets, and its [app users](/features/authentication). **Carries over to the copy:** * Your project's code * Database structure (tables and schema, not the records in them) * Chat history, if **Include project history** is on * Custom knowledge, if **Include custom knowledge** is on **Does not carry over:** * Database data * Version history: the copy's History panel starts fresh * Secrets * Custom domains * Publish state: the copy starts unpublished * Collaborators * Service connections (Git sync and connectors) In practice this means the copy is your app's code with a clean slate around it: it gets its own new API keys, and it isn't connected to the original's secrets, domains, GitHub repository, or other services. If your app relies on external services, reconnect them and add their credentials again in the copy before it can use them. Remixed projects don't carry over subscription-level features unless the target workspace's plan also includes them. ## Move a project to another account Remixing is also the way to move a project between two Lovable accounts, for example when you want your projects under a new email address: 1. If the project is connected to an external [Supabase](/integrations/supabase) project, disconnect it first. The destination account has no edit access to the source project, so a connected project can't be remixed from there. You can reconnect Supabase after the move. 2. In the source account, turn on **Public remixing** in **Project settings → Sharing** and copy the project's link. 3. Sign in to the destination account and open the link. 4. Remix the project into the destination workspace. 5. Turn **Public remixing** off again in the source account if you want the original private. The copy in the new account follows the normal remix rules: [what carries over](#what-carries-over) is the same, and subscription-level features apply only if the new workspace's plan includes them. ## FAQ Remixing creates a second, independent copy and leaves the original untouched. Transferring moves the one existing project to a new owner (**Project settings → Transfer ownership**) or to another workspace (**Project settings → Move workspace**), so there is still only one project. Remix when you want a copy. Transfer when you want to hand over or relocate the original. No. A remix is a snapshot of the project at the moment you remix it. Changes to the original never flow into the copy, and changes to the copy never affect the original. No. Deleting a project is permanent, and there is no way to remix or otherwise recover it afterward. If you want a backup, remix the project before deleting it. The most common reasons are: * The project is connected to an external Supabase project, and you don't have edit access to the source project. * The owner turned off **Public remixing** in **Project settings → Sharing**, so it can't be remixed via its link. * The project is in an Enterprise workspace and you don't have permission to move projects out of it. # Project settings Source: https://docs.lovable.dev/features/projects/settings Every Lovable project setting in one reference: rename a project, change its URL, control publishing and sharing, connect Git, manage domains, or delete a project. **Project settings** is where you manage a single project: its name and URL, project type, monitoring, publishing options, sharing toggles, Git connection, domains, knowledge, and skills. This page walks through the settings tab by tab so you know exactly where each option lives. To open it, click the project name in the top bar of the editor and select **Settings**. From the chat, open the **Chat actions** menu with the plus button and choose **Settings**, or press **Cmd+.** (Mac) or **Ctrl+.** (Windows/Linux). You can also find any setting by name through the [command palette](/features/projects/editor#command-palette). Your project's tabs appear in the settings sidebar alongside your workspace and account settings. Access control does not live here. Who can access the project, collaborators, invite links, and share preview links all live in the **Share** menu in the top right of the editor. See [Share your project](/features/share-project). ## General tab The **General** tab opens by default and contains most settings, grouped into sections. ### Details * **Project name**: Rename your project. Lovable names new projects automatically, and the name is visible only inside your workspace, never to visitors of your published app. Renaming only changes the display name, not your project's URL. * **URL subdomain**: Change the subdomain of your published `lovable.app` address, which is where visitors find your app once you [publish](/features/publish). * **Owner**: Shows who owns the project, with a link to their profile. See [project roles](/features/projects/overview#project-roles). * **Messages count** and **AI edits count**: Read-only counters showing how much you've built in this project. * **Use as a template**: Turn your project into a template that others in your workspace can start from. Available on Business and Enterprise plans. See [Design templates](/features/business/design-templates). On Enterprise workspaces that use [design systems](/features/design-systems), this appears as a **Project type** selection instead, with **Design system** as a third option. * **Design system** (Enterprise): The design system Lovable builds this project with, so new UI matches your organization's components and styles. Click **Attach design system** to pick one, or **Manage design system** once attached. See [Design systems](/features/design-systems). ### Project monitoring * **Project monitoring**: Have Lovable review your project's code and recent visitor errors on a daily or weekly schedule, and alert you to important issues in the editor and by email. Off by default, available on Pro plans and above. See [Project monitoring](/features/project-monitoring). ### Publishing * **Project category**: Categorize what kind of app this is, which helps Lovable and directories present it correctly. * **Hide Lovable badge**: Removes the "Edit with Lovable" badge from your published app. Available on Pro plans and above. If your workspace later moves to a plan that doesn't include this, the badge comes back the next time you publish the project. Sites that are already live stay unchanged until you republish them. * **Visitor analytics**: Collect visitor data for your published app, which powers the [Analytics](/features/analytics) view in the editor. On by default. When you turn it off, Lovable stops collecting and the Analytics view shows no new data. * **AI app context**: Let Lovable use context from your app's AI calls to debug and improve its AI features. Secrets are removed from the logs automatically, and logs are kept for 90 days. See [AI features](/features/ai#let-lovable-debug-and-improve-your-ai-features). * **Auto-fix security issues**: Let Lovable automatically fix low-risk issues found by [security scans](/features/security), so simple findings don't wait on you. Workspace owners and admins can set a workspace-wide default in **Workspace settings → Privacy & security**, and when they lock it there, the project setting can't be changed here. * **Unpublish project**: Takes your published app offline. The button is available only while the project is published. See [Publish your project](/features/publish). ### Sharing * **Project access**: A shortcut only: the **Open share menu** button takes you to the **Share** menu, where you control who can view and edit the project. See [Share your project](/features/share-project). * **Public remixing**: Control whether anyone with your project's link can create their own copy of it. Off by default. See [Remix a project](/features/projects/remix). * **Cross-project sharing**: Controls whether your other projects can reference this one as context. Workspace admins can disable this workspace-wide. See [Cross-project referencing](/features/cross-project-referencing). ### Project actions * **Remix project**: Duplicate this app in a new project with the **Remix** button. See [Remix a project](/features/projects/remix). * **Move workspace**: Move this project to a different [workspace](/features/workspace) you belong to with the **Move** button. See [Move a project to another workspace](#move-a-project-to-another-workspace) below. * **Transfer ownership**: Make another member of your workspace the project owner. See [Transfer project ownership](#transfer-project-ownership) below. #### Transfer project ownership Click **Transfer ownership** and pick the new owner. The new owner must be a full member of the workspace: external collaborators and people with pending invites aren't eligible. After the transfer, the new owner has full control of the project, and what you can still do depends on your [workspace role](/features/people). If an owner leaves the workspace, their projects transfer automatically to the most senior remaining member. See [project roles](/features/projects/overview#project-roles). #### Move a project to another workspace Click **Move** on the **Move workspace** row and pick the destination workspace. You can also start a move from the dashboard: open a project card's menu and select **Transfer to workspace**, or select several projects to move them together. You can move projects you own, and workspace owners (plus workspace admins on paid plans) can move any project they can access. On Enterprise workspaces, project owners additionally need the [**Editor project transfers**](/features/privacy-and-security-settings#editor-project-transfers) setting turned on. The move dialog includes a **Transfer project collaborators** checkbox: * **Off (default)**: people invited directly to the project, and any pending project invites, are removed when the project moves. Access through workspace membership is not affected. * **On**: Lovable keeps direct collaborators and pending invites when the destination workspace allows their role and you have permission to grant it there. Some collaborators may still be removed, for example when the destination workspace's [**External project collaborators**](/features/privacy-and-security-settings#external-project-collaborators) policy doesn't allow their role. Two more things change during a move: the project leaves its dashboard [folder](/introduction/project-folders), and its access setting resets to the destination workspace's default, so check **Project access** after the move if the project should stay restricted. ### Danger zone * **Delete project**: Permanently deletes the project. To confirm, you type the project's name. Deleting a project is permanent. You cannot restore a deleted project, so [download your code](/features/code-mode) or [remix the project](/features/projects/remix) first if you might need it later. ## Git tab The **Git** tab is where you connect your project to a [GitHub](/integrations/github) or [GitLab](/integrations/gitlab) repository and manage the connection. The sync is two-way: Lovable pushes every change it makes to the repository, and commits you push to the synced branch flow back into Lovable. That gives you a full copy of your code outside Lovable and lets developers on your team work with their own tools. See [Git sync](/integrations/git-sync-overview) for how the sync works. ## Domains tab The **Domains** tab is where you manage the web addresses of your published app. You can connect a domain you already own, buy a new domain directly through Lovable, and choose a primary domain that all your project's other addresses redirect to. Custom domains are available on paid plans. See [Set up a custom domain](/features/custom-domain). ## Knowledge tab Open **Settings → Knowledge**, under **Customization** in the settings sidebar, or use the **Chat actions** menu in the editor. The Knowledge tab holds your project's instructions and guidelines. Lovable follows them in every request, so use this tab to describe your product, audience, and preferences once instead of repeating them in chat. Anyone with edit access can update project knowledge, and the same tab shows your workspace-wide knowledge. See [Knowledge](/features/knowledge). ## Skills tab Open **Settings → Skills**, also under **Customization** in the settings sidebar, to manage the reusable instruction sets available in this project, such as a launch checklist or a release notes format. Workspace owners and admins manage which skills exist. See [Skills](/features/skills). ## FAQ In the **Share** menu in the top right of the editor. That's where you manage project access, collaborators, invite links, and share preview links. The **Project access** row in settings is just a shortcut that opens the same menu. See [Share your project](/features/share-project). Open **Project settings → General** and edit **Project name**. You can also click the project name in the top bar of the editor and choose the rename option there. Renaming changes the display name only. To change your published address, edit **URL subdomain** instead. * **Move workspace** sends the project to another workspace you belong to. * **Transfer ownership** keeps the project in the same workspace but makes another workspace member the owner. * **Remix project** creates a separate copy of the project to build on, in this workspace or another one. See [Remix a project](/features/projects/remix). No. Deleting a project is permanent, which is why **Delete project** asks you to type the project's name to confirm. If you might need the project later, download the code or remix it before deleting. Your published app moves to the new `lovable.app` address, so anyone using the old link needs the new one. If you want a stable address you control, connect a custom domain from the **Domains** tab. See [Set up a custom domain](/features/custom-domain). # Publish your Lovable project Source: https://docs.lovable.dev/features/publish Deploy your project to a live URL, control who can access the published app, configure site metadata, and update or unpublish at any time. Publishing turns your Lovable project into a live web app by deploying a snapshot to a URL you can share. Only the current version is deployed, and depending on your plan, you can control who can access the published app. ## Quick start: publish your first project If you just want to get a project live, follow these three steps. The rest of this page covers plans, access control, metadata, security checks, and updating a published app. In your project, click the **Publish** button in the top-right corner of the editor, next to **Share**. On narrow windows it collapses to an icon without a label. Lovable auto-fills a URL (`[name].lovable.app`), site title, description, and icon. You can edit any of these now or later. A basic security scan runs automatically while the dialog is open. When the deploy finishes, Lovable shows the live link. To push later changes, open the same dialog and click **Update**. You can also publish from chat. Ask Lovable to **publish**, **deploy**, **ship**, or **go live**, and the agent handles the deploy while respecting your workspace settings. See [Publish from chat](#publish-from-chat). ## Who can publish projects? By default, **editors and above** can publish projects on all plans. On **Enterprise plans**, admins and owners can restrict who is allowed to publish externally to the web. Go to **Workspace settings → Privacy & security → Who can publish externally** and select: * Admins & owners * Owners only ## Internal and external publishing and website access control Publishing options and website access control depend on your plan. ### Free and Pro plans **Anyone with the link** can visit your published app. This means you publish externally to the web. **Website access** cannot be restricted on these plans, so make sure you’re ready to share before publishing. ### Business and Enterprise plans You can choose who can access your published app: * **Workspace**: Only authenticated workspace members can visit the published app, meaning you publish internally to the workspace. When selected, the publish button label changes to **Publish to workspace**. * **Anyone**: Anyone with the link can visit your published app, meaning you publish **externally to the web**. This allows you to: * Build and share internal apps that stay private to your workspace * Prevent accidental external publishing * Support governance and compliance for sensitive data Workspace admins and owners can also set a **default website access** policy for all published projects in **Workspace settings → Privacy & security → Default website access**. You can override the workspace default for individual projects in the **Publish modal** by choosing **who can see the website**. If unchanged, the project inherits the workspace default. ## Publish from the Publish dialog To publish, follow the steps below: In your project, click the **Publish** icon in the top-right corner. Review and configure the publish settings as explained below. When the publish dialog opens, Lovable automatically runs a [Basic security scan](/features/security) in the background while you configure the rest of the settings. This scan takes 10-15 seconds and checks your database for common security issues, including row-level security (RLS) policy mistakes and schema-level access control risks. * Enter your preferred website URL or leave the input field empty for Lovable to auto-generate a URL. By default, your app is published to `[published-url].lovable.app` On Business and Enterprise plans, you can publish apps under a workspace-branded URL pattern, such as `app-name.workspace-subdomain.lovable.app`. Branded app URLs create a consistent workspace-level URL structure across all published apps and are configured in **Workspace settings → Branded app URLs**. See [Publish apps with branded URLs](/features/branded-workspace-urls) to set this up. * When published, you can add a [custom domain](/features/custom-domain) (available on paid plans). Depending on your plan, you can control **who can see the website**: * **Public**: anyone with the URL can visit the published app (public website access) * **Workspace** (Business and Enterprise plans): only authenticated workspace members can visit the published app URL (private website access). You can choose to grant access to the whole workspace or specific people and [groups](/features/groups). Lovable provides **site metadata**, but you can customize how your site appears in browser tabs, search results, and link previews. Add the following info to help people find your site: * **Icon & title**: the site icon (**favicon**) and **site title** shown in browser tabs, search results, and link previews. * Click on the icon to upload a new one. * Click on the title text to update it. * **Description**: the **meta description** used in search results and link previews. * Click on the text to update it, or leave empty and Lovable will auto-generate a description. * **Social image**: the social sharing image (**OG image**) shown when your website link is shared, for example, on social media and messaging apps. * Click to upload an image or choose to generate one (title and description need to be filled out to generate). See [Optimize your app for SEO and AI search](/features/seo-aeo) for more information on optimizing your Lovable apps for search engines, social media previews, and AI systems. Review all info and optionally run an [SEO review](/features/seo-aeo). Click on any of the fields to update the settings. * URL * Published website visibility * Website info (icon & title, description, social image) Always review security findings before publishing to reduce the risk of data leaks, unauthorized access, and sensitive information exposure. Before you publish, review the outcome of the **Basic scan** that ran automatically in the background. * If the Basic scan finds issues, Lovable shows a warning with a summary of the findings. Click it to open the Security view, where you can review and fix them. Findings do not block publishing by default, but you should resolve critical issues before making your app available. * If the Basic scan passes, you can continue publishing. You can also run the optional **Deep scan** for additional coverage. The Deep scan is an optional agentic codebase review that usually takes around 4 minutes. It looks for application-code vulnerabilities such as exposed secrets, unsafe input handling, and authorization gaps. If you run the Deep scan, Lovable shows either a warning with any findings, or a `Basic & Deep security scans passed message` when both scans complete with no findings. In either case, you can continue publishing unless your workspace has stricter publishing controls enabled. See [Security overview](https://docs.lovable.dev/features/security) and [Project security view](https://docs.lovable.dev/features/security-view) for more information. **Publishing controls** Workspace admins and owners can enforce stricter publishing rules in **Workspace settings → Privacy & security** to help ensure insecure applications are never deployed. * **Block publishing with critical findings** prevents publishing while error-level findings are unresolved. * **Require security scan before first publish** prevents the first publish of a project until a security scan has completed. When ready, click **Publish**. When the deployment is complete, you'll receive a pop-up with the published link. After publishing your project, you can continue to iterate on it. To push updates later, click **Publish → Update**. When published, you can update your live app at any time, change the website address (published URL), or connect a [custom domain](/features/custom-domain) for a polished, on-brand experience. After publishing publicly, rerun your [SEO review](/features/seo-aeo) to unlock live checks for indexing, performance, accessibility, AI-search readiness, and Google Search Console setup. If you connect a custom domain, rerun the review again so Lovable can help verify your domain in Google Search Console and submit your sitemap. ## Publish from chat You can also ask the Lovable agent to publish for you instead of opening the Publish dialog. Try prompts like: ```text wrap theme={null} Publish my app ``` ```text wrap theme={null} Deploy this project ``` ```text wrap theme={null} Ship it ``` ```text wrap theme={null} Go live ``` To request a specific Lovable subdomain: ```text theme={null} Publish to my-todos.lovable.app ``` The agent respects all publish-related workspace settings and permissions. It checks your publish settings, confirms required page information (such as title, description, and social image), runs the same [security checks](/features/security) used by the Publish dialog, and schedules the deploy. Lovable asks for approval before publishing unless you have set the publish tool to auto-approve. For related settings such as changing visibility, connecting a [custom domain](/features/custom-domain), or unpublishing, the agent points you to the right place in the UI. Publishing from chat is treated as standard chat usage and consumes credits. ## How publishing works in Lovable Each time you publish, Lovable deploys a snapshot of your project to a live URL. Only the current version is deployed, and future changes are not automatically published. * Changes are not automatically published and pushed live. * To deploy new changes, click **Publish → Update**. If you don’t see recent changes on your live site, you need to republish. ### See when you have unpublished changes When your published project has changes that are newer than the live version, a small dot appears on the **Publish** button. It tells you at a glance that you have updates to deploy, without opening the dialog. The dot clears once you publish. It stays hidden when there is nothing new to publish, and when you do not have permission to publish. ## How to unpublish your project You can unpublish and remove your live app in two ways: * Go to **Project settings → Unpublish project → Unpublish** * Click **Publish → Edit settings → Unpublish** (top-right corner) Once unpublished: * The live URL becomes inaccessible * Your project remains in the editor ## FAQ Yes. Ask Lovable to publish, deploy, ship, or go live, and the agent handles the deploy for you while respecting all publish-related workspace settings and permissions. It checks your publish settings, confirms required page information, runs the same [security checks](/features/security) used by the Publish dialog, and schedules the deploy. You can also request a specific Lovable subdomain, such as `my-todos.lovable.app`. Lovable asks for approval before publishing unless you have set the publish tool to auto-approve. For related actions such as changing visibility, connecting a [custom domain](/features/custom-domain), or unpublishing, the agent points you to the right place in the UI. Publishing from chat is treated as standard chat usage and consumes credits. No. A published site stays live indefinitely. There is no expiry and no automatic unpublishing for inactivity. Only [share preview links](/features/share-project) expire, after 7 days. Apps that use Lovable Cloud or AI features do need available credits to serve requests. The **Publish** button sits in the top right of the editor. On narrow windows it collapses to an icon without a label, so look for it next to **Share**. You can also ask Lovable in chat to publish your app. No. Publishing from the **Publish** dialog is free and works even when your credit balance is zero. Hosting and running the published app with Lovable Cloud consumes Run credits as your app is used, and asking the agent to publish in chat counts as a standard chat message. Your published app stays live. Downgrading or canceling does not unpublish your project. * **Website access settings keep working.** If you restricted access to workspace members or selected people on a Business plan, the published app keeps requiring sign-in after a downgrade. The setting is enforced as stored. After a downgrade you can still change the setting to public access, which is available on all plans. Restricting access to workspace members or selected people requires a Business or Enterprise plan. * **Connected custom domains keep serving your app.** Connecting a new custom domain requires a paid plan, but domains that are already connected continue to work, and you can still disconnect them. Domains bought through Lovable are billed separately from your subscription, so their registration and renewal are not affected by a plan change. See [What happens to my custom domain if I downgrade or cancel my plan?](/features/custom-domain#what-happens-to-my-custom-domain-if-i-downgrade-or-cancel-my-plan) * **Apps that use the built-in backend (Cloud) or AI features still need available credits** to serve requests. See [Credits and usage](/introduction/credits-and-usage). No. Publishing only makes the app available at the published URL. It does not grant anyone access to your project in the editor or your project code, and it does not make your project automatically remixable. Access to the editor, source code, chat history, and unpublished changes is always controlled by [project access](/features/project-visibility). Project access and website access are **independent settings**. You can combine them in different ways depending on your needs. * **Project access** controls who can access the **project in the editor**, including source code, chat history, work in progress, and changes that have not yet been published. * **Website access** controls who can visit the **published app** at its live URL. Below are common configurations: 1. **Internal team app** * Project access: `Workspace` * Website access: `Workspace` **Result:** Only workspace members can view and edit the project in the editor and visit the published app. 2. **Private work-in-progress, public app** * Project access: `Restricted` * Website access: `Anyone` **Result:** Only you can view and edit the project in the editor, but anyone with the published URL link can visit the published app. Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. 3. **Team-built, publicly shared app** * Project access: `Workspace` * Website access: `Anyone` **Result:** Only workspace members can view and edit the project in the editor, but anyone with the published URL link can visit the published app. 4. **Private prototype shared internally** * Project access: `Restricted` * Website access: `Workspace` **Result:** Only you can view and edit the project in the editor, and only workspace members can visit the published app. Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. **Key reminder:** Publishing does not change who can access your project in the editor, and project access does not affect who can visit the published app. Yes, on Business and Enterprise plans you can restrict who can access your published app. You can choose to grant access to the whole workspace or specific people and [groups](/features/groups). This means you publish internally so **only authenticated workspace members** can visit the published app. Publishing deploys a snapshot. Changes aren't automatically pushed to your live app. To publish updates, click **Publish** and then **Update**. You can customize how your site appears in browser tabs, search results, and link previews. By default, Lovable generates site metadata, adds a Lovable logo as the favicon, and a screenshot of your app as the Open Graph (OG) image. To change this, click **Publish** and review and configure the **website info**, and optionally run an [SEO review](/features/seo-aeo): * **Icon & title**: the site icon (favicon) and page title shown in browser tabs, search results, and link previews. Click on the icon to upload a new one. Click on the page title text to update it. * **Description**: the meta description used in search results and link previews. Click on the text to update it. * **Share image**: the social sharing image (OG image) shown when your website link is shared, for example, on social media and messaging apps. Click to upload an image. See [Optimize your app for SEO and AI search](/features/seo-aeo) for more information on optimizing your Lovable apps for search engines, social media previews, and AI systems. You can change your project **URL subdomain**, which forms your [lovable.app](http://lovable.app) website address in two ways: 1. Click **Publish → Edit settings → URL**, edit your subdomain, save the change, and click **Done**. 2. Go to [**Project settings → URL subdomain**](/features/projects/settings#details), change the subdomain, and click **Update URL subdomain**. Note that renaming the project does not change the project URL, it only changes the project display name. On paid plans, you can also add a [custom domain](/features/custom-domain). When a publish fails, Lovable shows a **Publishing failed** message explaining what went wrong, along with the action to take: **Try again** for temporary issues, or **Try to fix** to have the agent investigate an error in your app. See [Troubleshooting](/features/publish#troubleshooting) for each failure type and how to resolve it. If the **Publish** button is disabled instead, your workspace admin or owner probably enabled a publishing control in **Workspace settings → Privacy & security**: * **Block publishing with critical findings** prevents publishing while error-level findings are unresolved. Open the Security view, fix them, and try again. * **Require security scan before first publish** prevents the first publish of a project until a security scan has completed. Wait for the scan that started when you opened the publish dialog to finish, or run a scan from the Security view. Yes, especially if your site is public. Some SEO checks only run against the live published site, including indexing, performance, accessibility, AI-search readiness, and Google Search Console setup. After publishing, run an [SEO review](/features/seo-aeo) to check your live site. If you connect a custom domain later, run the review again so Lovable can re-check the new host, verify Google Search Console, and submit your sitemap. Lovable builds **web apps** and publishing always deploys to a web URL (for example, `yourproject.lovable.app` or your [custom domain](/features/custom-domain)). There isn't a built-in flow that packages and submits your project to the App Store or Google Play, but you have two good options if you want an installable, store-ready experience: * **Progressive Web App (PWA)**: make your published app installable so users can "Add to Home Screen" and launch it like a native app, with offline support and a full-screen shell. This is the fastest path and works from any modern mobile browser. * **Capacitor wrapper**: wrap your published URL in a native shell with [Capacitor](https://capacitorjs.com/) outside of Lovable, then submit that shell to the App Store or Play Store. This is the right path when you need access to native device APIs (camera, push notifications, biometrics, etc.) or when a store requires a "real" native binary. The separate [Lovable mobile app](/integrations/lovable-mobile-app) is for **building** projects from your phone. It does not turn your project into a native app for end users. ## Troubleshooting When a publish fails, a **Publishing failed** banner appears in the Publish dialog with a message explaining what went wrong and how to resolve it. The agent is also notified about the failure, so you can ask it for help in chat. The publish hit a short-lived problem, such as a timeout or a rate limit on a connected service. **What to do:** Click **Try again** in the banner. Retries usually succeed. The publish failed because of something in your app's code, such as a build error or an edge function that couldn't be deployed. When the cause is a build error, the banner shows a short summary of the build error instead of this message. **What to do:** Click **Try to fix** in the banner. The agent investigates and applies a fix, and you can publish again when it's done. You can also describe the issue to the agent in chat. If the fix request can't be sent right away, for example because you hit a rate limit, the banner stays visible so you can try again. A configuration problem inside your project blocked the publish, for example a file that is too large to include. **What to do:** Click **Try to fix** in the banner. The agent resolves the configuration problem, and you can publish again when it's done. The publish failed because of a connection or setting outside your project that the agent can't change for you, such as an expired [Supabase](/integrations/supabase) connection or a connected service that reached its plan limits. **What to do:** Fix the underlying setting, for example reconnect the integration or update its plan or quota, then click **Try again**. A database change in this publish conflicts with data that already exists in your live app's database. **What to do:** Click **Ask the assistant to help** in the banner. Because the fix affects real data, the agent confirms with you before changing anything. The failure happened on Lovable's side and is not something you can resolve by changing your app or its configuration. **What to do:** Try publishing again after a few minutes. If the failure persists, [contact support](https://lovable.dev/support) and include your project link. Publish failure messages never include raw logs or output from connected services, so secrets and connection details stay out of the UI. Build errors are the exception: the banner shows a summary of the build failure so you can act on it. # Add SAML single sign-on to Lovable Cloud apps Source: https://docs.lovable.dev/features/saml-sso Let end users of your Lovable Cloud app sign in with their company identity provider, such as Okta, Microsoft Entra ID, Google Workspace, or any SAML 2.0 IdP. This page documents **SAML SSO for end users of your Lovable Cloud app**. It is configured **per project** under **Cloud → Users → Auth settings**. Looking for SSO for your **team's access to Lovable itself**? See [Set up workspace single sign-on (SSO)](/features/business/sso). Building an **internal tool for workspace members**? They may not need SAML at all: see [Reuse Lovable workspace identity in your app](/features/lovable-workspace-identity-reuse). ## Overview Lovable Cloud supports **SAML 2.0 single sign-on (SSO)** for your app's end users. When enabled, users whose email domain matches your configuration are redirected to your identity provider (IdP), authenticate there, and return to your app already signed in. It appears alongside your other sign-in methods under **Cloud → Users → Auth settings**. Setting up SAML is a **two-way exchange** between Lovable and your identity provider: * **Lovable → IdP:** Copy two service-provider values (ACS URL and Audience URI) from Lovable into your IdP's SAML application. * **IdP → Lovable:** Copy your IdP's metadata URL back into Lovable, along with the email domains that should use this IdP. **Service provider (SP)-initiated sign-in only.** Users must start sign-in from your app. IdP-initiated SSO (starting from a tile in the IdP's dashboard) is not supported for Cloud app end users. It is available for [workspace SSO](/features/business/sso#set-up-idp-initiated-sign-in-saml). ## Why use SAML SSO SAML SSO hands sign-in control to your customer's IT team: * Centralized access management: Provision and de-provision in your identity provider, your app inherits those decisions * Inherit your organization's MFA, conditional access, and device policies * Frequently required by enterprise customers during security and compliance reviews * Simpler sign-in for employees using their existing work accounts If you only need consumer logins (email, Google, Apple), you do not need SAML SSO. ## Common use cases SAML SSO fits apps whose users already have a work identity: * B2B SaaS products selling to enterprise customers * Internal tools where employees should sign in with their corporate identity * Apps shipped to a single customer who requires their identity provider for access ## Prerequisites You need the following before starting: * A [Lovable Cloud](/features/cloud) project (auth must be Lovable-managed) * SSO must be allowed by your workspace's [App login methods](/features/privacy-and-security-settings#app-login-methods) policy. The policy exists on Business and Enterprise workspaces; on other plans, all methods are allowed. * **Admin access to a SAML 2.0 identity provider** (Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud) that publishes a public metadata URL * The list of **email domains** to route to that identity provider, for example `acme.com, acme.co.uk` ## Set up SAML SSO Complete the following steps in order. You can do this in chat or in the Cloud tab. In your project chat, ask: ```text theme={null} Enable SAML SSO for this app ``` Lovable opens an interactive **Configure SAML SSO** form. The top of the form shows your project's **ACS URL** and **Audience URI (SP Entity ID)**. Leave the form open, you will fill in the metadata URL and domains in Step 3. * Open your project, then go to **Cloud → Users → Auth settings → SAML SSO**. * Toggle **Enable SAML 2.0 single sign-on** on. * Expand **Advanced** to see the **Single sign-on URL (ACS URL)** and **Audience URI (SP Entity ID)**. Copy both URLs. They look like: * **ACS URL:** `https://.supabase.co/auth/v1/sso/saml/acs` * **Audience URI:** `https://.supabase.co/auth/v1/sso/saml/metadata` If you already have your IdP's metadata URL when you start, include it in your prompt and Lovable will pre-fill the form so you only have to confirm: ```text wrap theme={null} Set up SAML SSO using https://acme.okta.com/app/xyz/sso/saml/metadata for the domain acme.com ``` In your identity provider, create a new **SAML 2.0** application. Exact steps and field names vary by provider, use this mapping: | Lovable value | Common IdP field names | What to enter | | :------------------------- | :----------------------------------------------------------------------------- | :--------------------------------------------------- | | ACS URL (from Step 1) | `Single Sign-On URL`, `SSO URL`, `Reply URL`, `Assertion Consumer Service URL` | Paste the ACS URL | | Audience URI (from Step 1) | `SP Entity ID`, `Audience URI`, `Identifier` | Paste the Audience URI | | Name ID format | `Name ID format`, `Name identifier format` | `EmailAddress` | | Email attribute | `Attribute Statements`, `Claims`, `User Attributes` | Map the user's primary email to an `email` attribute | Then: * Assign the users or groups who should be able to sign in. * Copy your IdP's **metadata URL**, you will need it in Step 3. For provider-specific instructions, refer to your identity provider's official documentation. Return to the form you opened in Step 1. * **SAML metadata URL:** Paste the metadata URL you copied from your identity provider. * **Domains**: comma-separated list of email domains to route to this identity provider, for example `acme.com, acme.co.uk`. Click **Submit** (chat) or **Save** (UI). Users at those domains can now sign in through your SAML provider. Enabling SAML configures authentication, but it does not automatically update your app's UI. Your sign-in screen still needs an entry point that starts the SSO flow. Ask Lovable to add it: ```text theme={null} Add a "Sign in with SSO" option to my sign-in page that prompts for an email and routes users to their SAML provider ``` Lovable will update the relevant components in your app. When that is done, you are ready to [test the flow](#test-the-sign-in-flow). ## Test the sign-in flow 1. Open your published app in an **incognito** window. 2. Go to the sign-in page. 3. Enter an email address at one of your configured domains (for example, `you@acme.com`). 4. You should be redirected to your identity provider, authenticate there, and return to your app signed in. If a user enters an email at a domain that is not in your SAML configuration, they will be offered the other sign-in methods you have enabled (for example, email, Google). ## Manage your SAML configuration After setup, these are the operations you may need: * **Disable SSO.** Toggle **Enable SAML 2.0 single sign-on** off. Existing users keep their accounts but can no longer sign in via SAML. They will need another enabled method. * **Certificate rotation.** If your identity provider rotates its signing certificate, the metadata URL usually stays the same and Lovable re-fetches it. If the URL itself changes, update it here. * **Edit the configuration.** Re-run the project chat flow or change the fields in the Cloud tab. Updates replace the existing connection. ## Limitations Keep these constraints in mind: * **One SAML provider per project.** You cannot connect two identity providers to the same project. * **SP-initiated only.** No IdP-initiated tile launches. * **Metadata URL only.** No XML upload or manual SP configuration. * **No attribute-mapping UI.** The user's email comes from the SAML assertion as-is. Make sure your identity provider sends a stable email value. * **No SCIM provisioning.** Users are created on first successful sign-in (just-in-time). Removing a user in your identity provider prevents future sign-ins, but stale rows may remain in your project's user table. * **Domains route, they do not enforce.** Configuring `acme.com` does not disable email or Google sign-in for `acme.com` users, it only routes them to your identity provider when they sign in using SSO. To enforce SSO-only, disable the other sign-in methods. ## Troubleshooting The metadata URL must return SAML metadata XML and be reachable from the public internet. The user's email domain is not in your **Domains** list, or they used a method (Google or email) that bypasses domain routing. Almost always one of two things: * Your app isn't reading the session after the redirect. Make sure you have an `onAuthStateChange` listener and that the SSO callback route is handled. * Your app's URL isn't in the redirect allow-list. If unsure, ask Lovable to: ```text theme={null} Wire up the SSO redirect handling on my sign-in page ``` The SAML assertion is missing an email, or the **ACS URL** / **Audience URI** in your IdP does not exactly match the values shown in Lovable's **Advanced** section. Re-check both. Clock skew between your IdP and Lovable, or signing certificate mismatch. Re-fetch the metadata URL or update your IdP's clock. Map `email` to `user.mail`. If `user.mail` is empty, use `user.userprincipalname`. ## FAQ Workspace-level SSO controls how **your team signs in to Lovable** (the product). The SAML SSO described on this page controls how **end users sign in to your Lovable Cloud app**. See [Set up single sign-on (SSO)](/features/business/sso) for the workspace-level feature. Any SAML 2.0-compliant IdP that publishes a metadata URL: Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, Auth0 (SAML mode), and others. For Cloud app end-user SSO, only SAML 2.0 is supported today. OIDC is available for workspace-level SSO. No. One SAML provider per Cloud project. No. Cloud app end-user SSO is SP-initiated only: users must start sign-in from your app. IdP-initiated SAML is available for workspace SSO (your team's sign-in to Lovable). See [Set up workspace single sign-on (SSO)](/features/business/sso#set-up-idp-initiated-sign-in-saml). Yes. Users are created the first time they successfully sign in via SAML. No. There is no SCIM provisioning surface for Cloud project SAML. Manage user lifecycle in your IdP. When you remove a user there, future sign-ins are blocked. Yes. Re-run the chat flow or change the fields in the UI. Updates replace the existing connection. No. Other methods stay enabled unless you turn them off explicitly. To enforce SSO-only sign-in, disable email, Google, and any other methods you do not want. # Secrets Source: https://docs.lovable.dev/features/secrets Store API keys and other sensitive values securely in Lovable Cloud, and understand the difference between secrets and VITE_ environment variables. Secrets store sensitive values such as API keys, tokens, and credentials without exposing them in code. They are encrypted, injected into your Edge Functions automatically, and never reach the browser. You usually don't add secrets by hand. When a feature needs one, Lovable prompts you to enter it through a secure input in chat. For example, a prompt like this leads Lovable to ask for the keys it needs: ```text wrap theme={null} Connect Stripe so clients can pay invoices online. Ask me for any API keys you need. ``` To manage secrets yourself, go to **Cloud tab → Secrets**. ## Manage secrets The Secrets view lists each secret's name and creation date. Values are never shown. * **Add secret** opens a dialog where you can enter one or more name and value pairs. * **Remove** deletes a secret. This cannot be undone; if a feature still needs the value, your app breaks until you add it again. * Secrets are **write-only**: after you save a secret, its value can never be viewed again in Lovable, only replaced or deleted. If you lose a key, generate a new one at the service that issued it. Secrets are not copied when a project is remixed. Some secrets carry a badge: * **Lovable**: managed by Lovable and required for the platform to work. These cannot be deleted. * **Manage**: added by a [connector](/integrations/introduction). The value is managed by the connection, and you delete it by removing the connection, not from the Secrets view. * **Not in use**: another secret with the same name takes precedence at runtime. The `LOVABLE_API_KEY` secret, used by built-in AI, has a **Rotate** action. If you suspect the key has been exposed, rotate it: Lovable issues a new key and updates your Edge Function environment automatically. Rotating requires editor access or above. ## Secrets vs. `VITE_` environment variables Lovable's Secrets manager is for **backend** values only: values used by Edge Functions and server-side integrations. Anything prefixed with `VITE_` is a **build-time, browser-exposed** value and must live in your project's `.env` file instead, not in Secrets. * **Backend secrets (use Secrets):** `STRIPE_SECRET_KEY`, `RESEND_API_KEY`, `OPENAI_API_KEY`, third-party service credentials, and anything that must never reach the browser. * **Frontend variables (use `.env`):** anything prefixed with `VITE_`, such as `VITE_SUPABASE_URL` and `VITE_SUPABASE_PUBLISHABLE_KEY`. These are embedded into the client bundle at build time and are safe to be public. You can find and edit them in the `.env` file in Lovable's code editor or in your synced GitHub repository. Do **not** add `.env` to `.gitignore` in a Lovable project. Lovable needs `.env` committed to the repository so build-time `VITE_*` values are available when generating previews and published builds. Gitignoring it will break the preview. If you try to add a `VITE_`-prefixed name in Secrets, Lovable rejects it with a message like *"`VITE_` prefixed variables are build-time browser values and should be defined in `.env` files, not in secrets."* ## Reserved secret name prefixes The following name prefixes are managed automatically by Lovable Cloud and cannot be created or overwritten in the Secrets UI: * `SUPABASE_`: for example `SUPABASE_URL`, `SUPABASE_ANON_KEY`, `SUPABASE_SERVICE_ROLE_KEY`, `SUPABASE_DB_URL`. These are populated by Lovable when Cloud (or a connected Supabase project) is enabled. * `LOVABLE_`: reserved for Lovable-managed values such as the Lovable API key used by built-in AI. You don't need to add these yourself. They already exist in your Edge Function environment, and your functions can reference them directly (for example, `Deno.env.get("SUPABASE_SERVICE_ROLE_KEY")`). If your project uses an **external** Supabase connection instead of Lovable Cloud, secrets are managed in Supabase: the backend view shows a **Manage secrets** button that opens your Supabase project's dashboard. ## FAQ No. Secrets are write-only: you can replace or delete a secret, but never read its value back. If you lose a key, generate a new one at the service that issued it. Lovable-generated keys are recreated fresh in the remixed project. Manually added secrets are not copied over, so re-enter them in the new project. Secrets are injected into your project's [Edge Functions](/features/edge-functions) and server-side integrations at runtime. They are never included in your frontend code or exposed to the browser. If the value must stay private (payment keys, AI provider keys, service credentials), use Secrets. If it's a `VITE_`-prefixed build-time value that is safe to be public, it belongs in `.env`. # Security overview Source: https://docs.lovable.dev/features/security Protect your apps with built-in security scans, API key protection, database access checks, dependency audits, and optional security integrations. Lovable helps reduce common application security risks during development and before publishing. It does this in two main ways: by preventing common security mistakes up front, and by identifying potential vulnerabilities through automated analysis. Lovable includes two built-in security scanners, **Basic scan** and **Deep scan**, plus optional connectors for additional coverage. These tools support secure application development, but they do not replace a thorough security review. You are responsible for ensuring that your app meets the security requirements appropriate for its use case, especially if it handles sensitive data or performs critical functions. These tools help identify common security issues, but they cannot guarantee complete security. For apps handling sensitive data or critical functionality, consider an additional professional security review. ## Built-in security scanners Lovable provides two built-in security scanners: **Basic scan** and **Deep scan**. ### Basic scan The built-in **Basic scan** is a fast configuration and dependency check. It covers multiple areas, including: * **RLS policy linting**: Checks row-level security policies for common mistakes * **Database schema review**: Reviews database schema and access control * **Dependency audit**: Detects known vulnerabilities in npm dependencies ### Deep scan The built-in **Deep scan** performs a thorough agentic review of your codebase. A Deep scan runs everything the Basic scan does, and adds areas such as: * **Access control review**: Detects overly permissive data-access rules and database functions that bypass row-level security * **Backend endpoint protection**: Flags edge functions and APIs that lack proper authentication or authorization * **Code-level vulnerabilities**: Identifies exposed secrets, unsafe input handling (such as SQL injection or XSS), insecure storage settings, and information leakage through errors or logs * **Project-specific issues**: Surfaces issues tied to context you've added in your [security memory](#improving-scan-accuracy-with-security-memory) **Schedule security scans (Enterprise only)** Workspace admins and owners on Enterprise plans can schedule deep security scans to run automatically across all projects. See [Schedule security scans](/features/security-center#schedule-security-scans-enterprise-only) for more information. ## Optional security app connectors Workspaces can also connect **optional security integrations** to extend coverage beyond Lovable’s built-in scanners. ### Wiz scanning Workspaces can connect **Wiz** to add enterprise-grade vulnerability and code-security detection to every project in the workspace. Wiz combines two analyses: * **Software composition analysis (SCA)**: Identifies vulnerable dependencies, including transitive ones, using Wiz's continuously updated security database * **Static application security testing (SAST)**: Scans your source code for risky patterns, hardcoded secrets, and unsafe API usage Once a Wiz connection is added at the workspace level, Wiz scanning runs as part of Lovable's standard security scan suite. Findings appear in each project's Security view alongside results from the other scanners, in a section attributed to your Wiz connection. See [Scan your projects for vulnerabilities with Wiz](/integrations/wiz) for setup and details. ### AI penetration testing with Aikido The built-in scanners and Wiz perform **static analysis** by reading your code and configuration to flag patterns that look risky. AI penetration testing complements this with **dynamic analysis**: AI agents interact with your running application, send real payloads, and attempt to exploit authentication, authorization, and API flows like a real attacker would. Workspaces can connect **Aikido** to run AI pentests on individual projects. Because pentests confirm each issue through a real attack scenario, every reported finding is exploitable rather than theoretical. Findings sync into the project's Security view in a dedicated **Agentic penetration test by Aikido** section, and Aikido also generates a shareable report structured for SOC 2, ISO 27001, and security questionnaires. The recommended order is: run the security scanners first, fix what they surface, then validate with a pentest before a major release. See [Run AI-powered penetration tests with Aikido](/integrations/aikido) for setup, prerequisites, and how to run pentests. ## When security scans run Lovable runs security scans at different points in your workflow to help catch issues early. Each scan runs only when it is relevant to your project and when changes have occurred since the last run. For example, database checks only run for projects with a connected database, and the dependency audit only runs when dependencies have changed. The **Deep scan** does not run automatically as you work. You can run it from the [project security view](/features/security-view), the [workspace security center](/features/security-center), or the [publish dialog](/features/publish) when the Basic scan passes. ### Before publishing When you open the [publish dialog](/features/publish), Lovable automatically runs the **basic security scan** in the background, including **RLS policy linting** and **database schema review**. You can also choose to run a **Deep scan** once the Basic scan has passed. If critical issues are found, you will be prompted to review them before proceeding. Resolve all critical issues before making your app publicly available. Publishing with unresolved critical issues is possible, but strongly discouraged, especially for production apps or apps handling sensitive user data. **Publishing controls** Workspace admins and owners can enforce stricter publishing rules in **Workspace settings → Privacy & security** to help ensure insecure applications are never deployed. * **Block publishing with critical findings** prevents publishing while error-level findings are unresolved. * **Require basic security scan before first publish** prevents the first publish of a project until a security scan has completed. ### On demand You can trigger a scan on demand from three places: * [Project Security view](/features/security-view): on the **Code analysis** tab, click **Basic scan** to refresh the database and dependency checks, or **Deep scan** to run the full agentic code review (which also re-runs any out-of-date basic checks). Each button is disabled when its results are already up to date. * [Workspace Security center](/features/security-center): click **Scan** on a project row. This runs every available scanner for that project (Basic and Deep together) in the background. * [Publish dialog](/features/publish): the Basic scan kicks off automatically when the dialog opens. Once it passes, a **Run scan** button appears for the Deep scan so you can run it before publishing. On-demand scans are useful after significant code changes, when investigating a specific finding, or when you want all results to reflect the current state of your project. ### Scheduled scans (Enterprise only) Workspace admins and owners on Enterprise plans can schedule Deep security scans to run automatically across selected projects. Scheduled scans help keep projects covered without requiring admins to trigger scans manually. See [Schedule security scans](/features/security-center#schedule-security-scans-enterprise-only) for setup details, available schedule options, and credit usage. ## How Lovable keeps your apps secure The sections below explain the main areas of risk in more detail and how Lovable helps you address them. For practical guidance on writing secure code and avoiding common security mistakes, see [Security best practices for Lovable apps](/tips-tricks/security-best-practices). ### Protecting API keys Lovable generates frontend code that runs in the browser, which means API keys and other secrets cannot be stored safely in client-side code. Exposing credentials can lead to data leaks or unauthorized access. To prevent sensitive credentials from being exposed, Lovable automatically detects API keys pasted into the chat and guides you to store them securely in **Secrets** instead of hardcoding them into your code. Rather than pasting credentials directly, describe what you want to build and Lovable will help you implement a secure setup using server-side functions and secret storage. **For example:** ```text wrap theme={null} I want to integrate service X API to generate text responses ``` Lovable will guide you to: 1. Store your API key securely in Secrets 2. Create an Edge Function to make the API call server-side 3. Call that Edge Function from your frontend code This approach keeps credentials secure and follows web security best practices. ### Protecting data access with row-level security (RLS) Row-level security (RLS) policies control which users can access or modify data in your database. Misconfigured RLS rules are a common cause of data leaks. You can review every policy in your project under **Cloud tab → Database → RLS policies**; see [RLS policies](/features/database#row-level-security-rls-policies). Lovable helps you review and reason about your RLS policies to ensure users only see and change the data they are authorized to access. The Basic scan's **RLS policy linting** highlights overly permissive rules or missing access checks that could expose sensitive data. A Deep scan includes this check as well. You should review RLS policies regularly, especially before publishing or after changes to authentication or database structure. ### Identifying database security risks Database schemas and access rules work together to determine how data is exposed. Unsafe combinations of schema design and access policies can introduce security risks even when individual rules appear correct. The Basic scan's **database schema review** examines your schema and RLS configuration together to identify patterns that could lead to unauthorized access or data exposure. This helps catch issues that may not be obvious when reviewing rules in isolation. The Deep scan includes this review and additionally performs an **access control review** that detects overly permissive data-access rules and database functions that bypass RLS. ### Identifying vulnerabilities in dependencies Third-party libraries are a common source of security risk. Even widely used packages can introduce vulnerabilities when new issues are discovered. The Basic scan's **dependency audit** checks your project's dependencies for known security vulnerabilities, identifies vulnerable packages, and provides information to help you assess and remediate the risk. Dependency vulnerability findings may appear: * In the project-level [Security view](/features/security-view), where you can review details and take action for a single project * In the workspace-level [Security center](/features/security-center), where workspace admins and owners can monitor vulnerabilities across multiple projects Findings include the affected package name and version, the type of vulnerability, and recommended remediation steps, such as updating to a secure version. Keeping dependencies up to date is an important part of maintaining a secure application. When critical vulnerabilities are disclosed, the Security center can help identify which projects are affected so issues can be addressed quickly. ### Identifying vulnerabilities in application code Application code can introduce security risks through patterns such as improper input handling, weak authorization checks, or exposed credentials. These are areas the Basic scan does not cover. The [**Deep scan**](#deep-scan) analyzes your application code and database schema (in addition to running every basic check) to identify common vulnerability patterns and provide recommendations for improving security. These checks help surface issues early, before they become exploitable in production. ## Acting on security findings After scans identify security findings, you can review and address them from the project-level Security view, through eligible automatic fixes, or through conversational security reviews. ### Review and fix findings in the project security view For project-level findings, use the [Project security view](/features/security-view). The Security view lets you inspect findings for a single project, understand severity, review suggested remediation steps, run scans, fix individual findings, use **Try to fix all**, ignore findings that do not apply, and review dependency vulnerabilities. This is the primary place to work through scan results during development, before publishing, and after launch. ### Let Lovable automatically fix eligible findings Lovable can automatically fix eligible security findings during regular agent work. When auto-fix is enabled, Lovable gets the latest **critical Basic scan findings**, marked as **error**, as part of its context whenever you chat with it. Lovable then attempts to resolve them as part of the next response. This is treated as standard chat usage and consumes credits. Auto-fix is designed for findings that are safe to remediate automatically, such as common row-level security (RLS) misconfigurations and database access patterns. It does not apply fixes for Deep scan findings. Auto-fix is checked each time you chat with Lovable in your project: 1. You send any message in the chat. 2. Lovable checks whether auto-fix is enabled for the project. 3. If enabled, Lovable gets the current list of eligible error-level Basic scan findings as additional knowledge. 4. Lovable attempts to fix those findings as part of what you asked for. Auto-fix can be configured at two levels: * **Workspace default**: Workspace admins and owners can set the default behavior across projects from **Workspace settings → Privacy & security → Security automation → Auto-fix security issues**. * **Project setting**: Anyone with project edit access can manage auto-fix for a specific project from **Project settings → Auto-fix security issues**, unless the workspace default requires auto-fix for that project. The available workspace options depend on your plan: | Option | What it means | | :-------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Selected project** | Auto-fix is disabled by default. You can enable or disable it for individual projects from **Project settings → Auto-fix security issues**. | | **Externally published projects** | Auto-fix runs automatically only after the project is published externally. After that, it runs each time you chat with Lovable on the project. You cannot disable it for externally published projects at the project level. You can still enable it manually for other projects. | | **All published projects** | Auto-fix runs automatically only after the project is published, internally or externally. After that, it runs each time you chat with Lovable on the project. You cannot disable it for published projects at the project level. You can still enable it manually for unpublished projects. | | **All projects** | Auto-fix runs automatically each time you chat with Lovable on any project in the workspace, whether or not it has been published. It cannot be disabled at the project level. | ### Ask Lovable to review your app’s security Separate from the automated security scanners, you can ask Lovable to perform a **conversational security review** at any time by prompting. This is an AI-driven review and consumes credits, just like regular chat messages. For example: ```wrap theme={null} Review my app's security ``` Lovable analyzes your project and responds with a detailed assessment. The review typically covers areas such as: * Potential vulnerabilities in your application code * Common issues like XSS risks, input handling, and authentication flaws * Database schema and row-level security (RLS) policies * Overall security posture with specific recommendations The scope and depth of the review depends on your project. You can also ask Lovable to focus on a specific area, for example: ```wrap theme={null} Review the authentication flow in my app. ``` or ```wrap theme={null} Check if my API routes are secure. ``` Conversational reviews are especially useful after significant changes or before major releases. Even if no warnings are currently shown, periodically requesting a review is a good practice for production applications. ## Where to manage security Lovable provides two security surfaces: one for securing individual projects and one for monitoring security across an entire workspace. ### Project security (Security view) Use the [**Security view**](/features/security-view) when you are building or maintaining a specific project. It brings together findings from Lovable’s Basic scan and Deep scan, plus optional integrations such as Wiz and Aikido, so you can understand and address security risks in one place. The Security view helps you: * Run Basic scan and Deep scan on demand * See whether scan results are up to date or need to be refreshed * Review project findings by severity, including errors, warnings, and info * Understand what each finding means, why it matters, and how to fix it * Use security memory to give the scanner project-specific context and reduce false positives * Fix individual findings, use **Try to fix all**, or make manual changes * Ignore findings that do not apply, with a recorded reason * Review project dependencies and known vulnerabilities * Filter vulnerable packages and trigger a fresh dependency audit * Download a JSON report of project dependencies and vulnerabilities * Verify that your project is ready to publish * Continue monitoring security after publishing as your project changes This is the primary place to work through security issues for a single project during development, before publishing, and after launch. ### Workspace security (Security center) Workspace admins and owners on Business and Enterprise plans can use the [**Security center**](/features/security-center) to monitor security across all projects in a workspace. The Security center helps you: * See which projects have errors, warnings, or outdated scan results * Monitor scan coverage across the workspace, including projects that have never been scanned * Run security scans for individual projects without opening them * Schedule recurring deep security scans across the workspace, on Enterprise plans * Review dependency vulnerabilities by project or by vulnerability * Identify vulnerable packages that affect multiple projects * View secrets across all projects without exposing secret values * Find stale or duplicated secrets that may need cleanup * Export security, dependency, and secrets data for audits or internal reporting * Track overall security posture at the workspace level The Security center also includes [**Workspace insights**](/features/workspace-insights), a portfolio-level view that combines security findings, ownership, lifecycle, publish status, and activity into a single **review priority** per project, so you can spot externally published projects, abandoned projects, projects with no owner, and projects with open security findings. On Enterprise plans, Workspace insights also incorporates sensitive data findings (PII), so you can also spot externally published projects that contain personal data. The Security center aggregates security information across the workspace, but fixes are still applied at the project level. ## Related security settings In addition to project and workspace security reviews, Lovable provides account-level and authentication-related security settings. These configurations are not tied to a specific project, but they play an important role in protecting user accounts and reducing the risk of compromised credentials. You should review these settings when setting up authentication or before launching an app that allows users to sign in. ### Leaked password protection If your app uses email and password authentication, you can prevent users from choosing known compromised passwords. This protection checks user passwords against the **HIBP (Have I Been Pwned) database** and rejects commonly leaked or easy-to-guess passwords. Enabling it helps reduce the risk of account takeovers caused by reused credentials. * **Using Lovable Cloud**: Enable **Password HIBP check** in **Cloud tab → Users → Auth settings → Email**. See [Password rules](/features/email-auth#password-rules). * **Using Supabase directly**: See the Supabase documentation on [Password strength and leaked password protection](https://supabase.com/docs/guides/auth/password-security#password-strength-and-leaked-password-protection) for detailed instructions. ## Costs and usage Lovable includes both automated and conversational security tools. Most security features are free to use, while some security actions consume credits. Automated and conversational security tools are designed to work together. Use automated security tools for continuous monitoring and targeted fixes during development and before publishing. Use conversational security reviews when you want a deeper, exploratory assessment of your app’s overall security posture. ### Automated security actions (free) The following automated security actions do not consume credits: * **Running security scans**\ Running **Basic scan** or **Deep scan** in the Security view, Security center, or publish dialog is free. * **Fixing detected issues**\ Fixing findings using **Try to fix all** in the Security view is free. These actions use Lovable's automated security scanners or security-specific remediation tools and do not count as regular chat usage. ### Conversational security actions (uses credits) The following conversational security actions consume credits, just like regular chat messages: * **Conversational security review**\ Asking Lovable to “review my app’s security” in chat runs a conversational, AI-driven review and consumes credits like a normal chat message. * **General security questions in chat**\ Asking security-related questions directly in the main chat, outside of automated security tools, is treated as standard chat usage and consumes credits. * **Referencing a finding in chat**\ Referencing a security finding in chat to ask Lovable to analyze or fix it is treated as standard chat usage and consumes credits. * **Letting Lovable fix eligible findings during regular agent work**\ [Letting Lovable fix eligible security findings during regular agent work](#let-lovable-automatically-fix-eligible-findings) is treated as standard chat usage and consumes credits. ### Third-party integrations (separate costs) Optional integrations involve third-party costs for scanning or testing. These costs are separate from Lovable credits. * [Wiz scanning](/integrations/wiz) runs as part of Lovable’s standard security scan suite and does not consume Lovable credits. However, Wiz usage is governed by your Wiz deployment, including any Wiz quotas, limits, or charges. * [AI pentests with Aikido](/integrations/aikido) are billed by Aikido and do not consume Lovable credits. Fixing or discussing findings in Lovable follows the same credit rules as other security actions: automated security actions are free, while general chat-based security actions consume credits like regular chat. # Workspace security center Source: https://docs.lovable.dev/features/security-center Monitor security findings, scan coverage, scheduled scans, secrets, and dependency risks across every project in your workspace. The **Security center** helps teams identify risks, prioritize project review, and track security coverage across every project at scale. * **Available on:** Business and Enterprise plans * **Access:** Workspace admins and owners * **Location:** [Security center](https://lovable.dev/settings/security-center) (**Settings → Security → Security center**) The Security center provides a **workspace-wide view of security status across all projects**. * To review, fix, or update findings for an individual project, open the [Project security view](/features/security-view). * For an overview of Lovable’s security model and scanning approach, see the [Security overview](/features/security). * For practical guidance on writing secure code and avoiding common security mistakes, see [Security best practices for Lovable apps](/tips-tricks/security-best-practices). ## What the Security center shows The Security center is organized into several sections, each focused on a different aspect of workspace security. Each tab that supports export shows an **Export** dropdown in the top-right corner. The dropdown offers options to export everything or export only the current filtered view. All exports are downloaded as CSV files. ### Workspace insights Get a portfolio-level view of every project in your workspace, combining security findings, ownership, lifecycle, cost, publish status, and activity signals into a single **review priority** for each project. On Enterprise plans, this also includes sensitive data findings (PII). Use it to quickly answer questions like which projects are published externally, which have open security findings, which are abandoned, and which have no owner. On Enterprise plans, you can also see which projects contain personal data. Workspace insights is available on Business and Enterprise plans. PII columns, PII quick filters, and PII scans are Enterprise-only. See [Workspace insights](/features/workspace-insights) for more information. ### Code analysis Review security findings from **the built-in security scans (Basic scan and Deep scan)** across all projects in your workspace. Summary cards provide an at-a-glance view of total projects, projects with findings, and scan coverage. For each project, you see: * **Publish status**: The project's publish status, whether it is not published, published internally to the workspace, or published externally to the public * **Auth providers**: Which auth providers are configured on the project (Email, Phone, Google, Apple, SAML SSO) * **Errors**: Critical security issues that require immediate attention * **Warnings**: Important security concerns that should be reviewed * **Info**: Informational findings that provide additional context * **Scan status**: When projects were **last scanned**, including **live scanning indicators** * **Last edited**: When projects were last edited * **CSV export**: Export the projects table as a CSV file. The export includes project name, project ID, publish status, error/warning/info counts, last scan date, and last edited date. * **Scan trigger**: Start a **Deep security scan** without opening individual projects * **View**: Open the project's [Security view](/features/security-view) You can search, filter, and sort projects by security status, publish status, auth providers, scan state, or name to quickly focus on what matters most. ### Supply chain security Monitor dependency vulnerabilities across your entire workspace. Summary cards highlight vulnerability counts by severity and overall scan coverage. * **Two views**: Review vulnerabilities **by project** or **by vulnerability** * **Vulnerabilities by severity**: Categorized as critical, high, or medium * **Affected projects**: Which projects use vulnerable dependencies * **Vulnerable packages**: Package names, affected versions, and fixed versions when available * **CSV export**: The **Export** dropdown offers multiple options depending on the active view: * **Export full dependency list**: Downloads a complete list of all packages across all projects (generated server-side) * **Export all projects** or **Export all vulnerabilities**: Downloads the full projects or vulnerabilities table * **Export current filter**: Downloads only the filtered results when filters are active You can filter and search vulnerabilities by severity, publish status, CVE, package name, or vulnerability title. ### Secrets overview View all secrets across every project in your workspace from a single table. The **Secrets overview** gives admins visibility into what secrets exist and which projects they belong to. You can group secrets **by project** or **by secret**. For each secret, you'll see: * **Secret name**: The name of the secret (for example, `OpenAI API Key`). Secret values are never shown. * **Associated project**: The project the secret belongs to * **Type**: The type of secret, whether it is user-created or Lovable-generated * **Publish status**: The associated project's publish status, whether it is not published, published internally to the workspace, or published externally to the public * **Creation date**: When the secret was added * **Security findings**: Project-level security findings and severity * **View**: Opens the project's secrets page, where you can update or remove individual secrets * **CSV export**: The **Export** dropdown offers multiple options: * **Export everything**: Downloads the full secrets table across all projects * **Export current filter**: Downloads only the filtered results when filters are active The export includes project name, project ID, publish status, secret name, secret type, integration, creation date, and project-level security findings. Secret values are never included. You can search by secret name across all projects, filter by publish status, secret type, and security findings. If you apply filters, the **Export current filter** option appears and includes the full filtered result set, not just the current page. Security findings shown alongside secrets are tied to the **project**, not the individual secret. ### Schedule security scans (Enterprise only) Workspace admins and owners on Enterprise plans can schedule **Deep security scans** to run automatically across selected projects. Scheduled scans help keep projects covered without requiring admins to trigger scans manually. Each workspace can have one scan schedule. The schedule has two configuration fields: * **Projects**: Choose which projects are included: * **No projects**: Turns the scheduled security scan off * **Published projects**: Scans only projects that have been published internally or externally * **All projects**: Scans every project in the workspace * **Cadence**: Choose how often the scheduled security scan runs: * **Weekly**: Runs every Monday at 08:00 in your workspace timezone * **Monthly**: Runs on the 1st of each month at 08:00 in your workspace timezone Changes are saved automatically. You can also manage and monitor the schedule with: * **Run now**: Trigger the scheduled scan immediately, without waiting for the next scheduled run * **Last run status**: See when the schedule last ran, whether it succeeded, and a relative timestamp Scheduled security scans consume credits. Each project included in a scheduled scan uses **1 credit** each time the schedule runs. For example, a weekly schedule covering 10 projects will use approximately 40 credits per month. If your workspace moves off the Enterprise plan, scheduled scans stop running and stop using credits. Your schedule is kept, so scans resume if you upgrade back to Enterprise. For details on how the **Deep scan** works, see [Security overview](/features/security). ## Why use the Security center The Security center helps teams stay on top of security issues by making risks visible, comparable, and actionable across projects. * **Centralized oversight**\ Review security findings across your entire workspace without opening projects individually. * **Portfolio-level prioritization**\ Use [Workspace insights](/features/workspace-insights) to combine security findings, ownership, lifecycle, and activity into a single review priority per project, so externally published apps, abandoned projects, and projects with no owner surface first. On Enterprise plans, this also includes PII signals, so externally published apps with personal data surface too. * **Clear prioritization**\ Focus on projects with critical errors, high-severity vulnerabilities, or outdated scans. * **Visibility into scan coverage**\ See which projects are up to date and which may need security reviews. * **Dependency risk awareness**\ Understand how vulnerable dependencies affect multiple projects and coordinate updates efficiently. * **Secrets visibility**\ See every secret across your workspace in one place, identify stale credentials, and manage secrets from a centralized view. ## Running security scans In addition to viewing results, you can trigger security scans from the Code analysis tab without opening individual projects. * **Run scans centrally**: Start a **Deep security scan** for any project from the Code analysis tab * **Last scan timestamps**: See when each project was last scanned so you can identify outdated results at a glance * **Risky project identification**: Spot projects that are public or recently changed but have outdated or missing scan results * **Never-scanned detection**: Flag projects that have never been scanned, catching cases where the scanning process may have been skipped entirely This is especially useful for maintaining consistent scan coverage across a large number of projects without having to visit each one individually. **Schedule Deep security scans (Enterprise)** If you'd rather have **Deep scans** run on a recurring cadence instead of triggering them manually, configure a schedule in [Schedule security scans](#schedule-security-scans-enterprise-only). Scheduled scans are billed at 1 credit per project per run; on-demand scans from the Code analysis tab remain free. ## Common use cases The Security center supports both routine reviews and time-sensitive security work, including: * **Release readiness and audits**\ Confirm projects meet security standards before shipping or compliance reviews. * **Project onboarding and handoffs**\ Ensure inherited or transferred projects have been scanned and don't introduce security risks. * **Critical vulnerability response**\ Quickly identify affected projects when new dependency issues are announced. * **Secret auditing**\ Search for a specific API key by name and see every project that uses it, making it easy to audit usage or coordinate key rotation. * **Stale secret cleanup**\ Sort secrets by creation date to find old credentials tied to unused projects, and remove them to reduce unnecessary exposure. * **Security reporting**\ Export dependency or secrets data as CSV files when you need a point-in-time snapshot for audits, reviews, or internal tracking. * **Ongoing monitoring**\ Regularly review findings and address new issues as part of a weekly or monthly cadence. ## Best practices for using the Security center The Security center is designed for ongoing review rather than a fixed workflow. The following best practices reflect how teams commonly use it. * **Start with the workspace overview**\ Review overall security status to understand how many projects have errors, warnings, or outdated scans. * **Prioritize projects that need attention**\ Use filters to focus on projects with critical errors, high-severity vulnerabilities, or recent warnings. * **Check scan freshness**\ Identify projects that haven’t been scanned recently and may need updated security reviews. * **Review dependency vulnerabilities**\ Inspect vulnerable packages by severity to see which issues affect multiple projects and require coordinated updates. * **Take action within individual projects**\ Use the **View** action on a project to open its security details, run new scans, update dependencies, and resolve findings in the [Project security view](/features/security-view). ## FAQ Workspace admins and owners on Business and Enterprise plans can access the **Security center** at **Settings → Workspace → Security center**. No. It displays the most recent scan results for each project. You can run a security scan for any project directly from the **Security center**, or run one from within the project itself. Enterprise workspaces can also schedule security scans to run automatically across selected projects. Scheduled scans consume credits, while on-demand scans remain free. * **Errors** are critical security issues that should be resolved before publishing. * **Warnings** are important concerns that may not be critical but should be reviewed. * **Info** findings provide additional context to help teams better understand their security posture. Projects appear as never scanned if a security scan has not yet been run for them. Run a security scan in the project to generate results. No. At the moment, the **Security center** shows only the latest scan results for each project. Yes. Use the **Export** dropdown in the top-right corner. Export is available on the **Workspace insights**, **Code analysis**, **Supply chain security**, and **Secrets overview** tabs. All exports are CSV files. Secret values are never included in any export. No. The **Secrets overview** only shows secret names (for example, `OpenAI API Key`), not the secret values themselves. Secret values are never included in exports. Not directly. You can click through from the **Secrets overview** to the specific project's secrets page, where you can update or remove individual secrets. Security findings are tied to the project, not the individual secret. They indicate the overall security posture of the project that holds that secret. Yes. You can trigger a security scan for any project directly from the Security center without having to open the project first. # Project security view Source: https://docs.lovable.dev/features/security-view Review scan results, fix vulnerabilities, and manage dependency risks for a single project before and after publishing. ## What is the Security view? The Security view shows security findings for a single project. It brings together results from Lovable's built-in security scanners and findings from optional security connectors, such as Wiz and Aikido, so that you can understand risks, take action, and verify that your project is ready to publish. For details on how each scan works and when scans run, see [Security overview](/features/security). You’ll find the **Security tab** inside any Lovable project by going to **More → Security** in the project toolbar. The Security view focuses on a single project. * To monitor security findings and dependency risks across multiple projects, use the [Security center](/features/security-center). * For a portfolio-level view that combines security findings, PII, ownership, lifecycle, and activity into a single review priority per project, see [Workspace insights](/features/workspace-insights) (Enterprise). * For practical guidance on writing secure code and avoiding common security mistakes, see [Security best practices for Lovable apps](/tips-tricks/security-best-practices). ## Why use the Security view? * **Review all project security sources in one place**\ Built-in scan results and optional connector findings appear together, so you do not need to check separate tools to understand a project’s security status. * **Catch issues early**\ Security issues are easier to fix during development than after deployment. The Security view helps identify common problems such as misconfigured database access, insecure code patterns, or vulnerable dependencies before your app goes live. * **Focus on what matters**\ Not all security findings carry the same risk. Findings are categorized by severity so you can prioritize critical issues first and review lower-risk recommendations later. * **Save time with guided fixes**\ Many findings include automated remediation options or clear guidance. You can ask Lovable to fix specific issues directly and review the resulting changes. * **Track security as your project evolves**\ As your project changes, previous scan results may become outdated. The Security view clearly shows when scans need to be refreshed so you always know your project’s current security state. ## Understanding scan status The scan status at the top of the Security view shows whether your security results reflect your latest changes. * **Up to date**: All scans reflect the current version of your project. * **Out of date**: One or more scans have not run since the project changed. * **Scanning**: Scans are currently running. Scan results are tied to a specific version of your code. When your project changes, earlier results may no longer be accurate and are marked as outdated. ## Run Basic and Deep scans Use the scan banner at the top of the Security view to run available scans and see the latest scan state. Depending on the current project state, you may see actions such as **Basic security scan** or **Deep security scan**. The Basic scan is a faster configuration and dependency check, while the Deep scan runs a more detailed agentic code review. Both actions are free and do not consume credits. The **Deep scan** does not run automatically as you work. You can run it from the [project security view](/features/security-view), the [workspace security center](/features/security-center), or the [publish dialog](/features/publish) when the Basic scan passes. You should run scans: * Before publishing * After significant code or database changes * When adding or updating dependencies * Periodically for production applications ## Included security findings The Security view brings together security findings for one project. Depending on your project setup and workspace integrations, it can include: * **Basic scan findings**: Database and dependency findings from row-level security (RLS) policy linting, database schema review, and dependency audits. * **Deep scan findings**: Agentic codebase review findings, including access control issues, unprotected backend endpoints, exposed secrets, unsafe input handling, and other code-level risks. * **Wiz findings**: Static analysis and software composition analysis results from a connected [Wiz integration](/integrations/wiz), including vulnerable dependencies and risky code patterns. * **Aikido findings**: Confirmed exploitable issues from AI penetration tests run through the [Aikido connector](/integrations/aikido). * **Project dependencies**: A list of project `npm` dependencies, known vulnerabilities, severity counts, fix actions, filters, and JSON export. Findings are grouped by scanner and severity so you can understand where each issue came from, prioritize what matters, and decide whether to fix, ignore, or investigate further. ## Review and fix security findings All findings appear under **Detected issues** and are grouped by **severity level**. If the latest scan does not find anything, Lovable shows a **No issues found** state. This means the latest scan did not surface findings, but it does not guarantee that the project has no security risk. If any errors exist, the view defaults to showing them first. * **Error**: Critical problems that need your attention right away * **Warning**: Issues you should review and fix if necessary * **Info**: Suggestions to consider implementing Click a finding to expand it and review full details, including: * Which scan produced the finding * A detailed explanation of the issue * Why the issue matters for security * Suggested remediation steps You can address findings in several ways: * **Fix a specific finding**\ Reference a finding in chat to ask Lovable to analyze or fix that issue. This is treated as standard chat usage and consumes credits. * **Fix multiple findings at once**\ Use **Try to fix all** to attempt automatic remediation for all findings in the current filter. It requires the **Deep scan** results to be up to date. This action is free and does not consume credits. Always review the changes Lovable makes and test them thoroughly. If a finding does not apply to your use case, you can **ignore** it by providing a reason. Ignored findings remain visible, are marked with an ignored label, and can be restored at any time. Ignoring findings should be a deliberate decision. If you are unsure whether a finding applies, ask Lovable for clarification before ignoring it. Running scans and using automated fix actions in the Security view are free. Conversational security reviews in chat, and referencing a finding in chat, consume credits. See [Security overview](/features/security) for details. **Let Lovable automatically fix eligible findings** Depending on your workspace and project settings, Lovable can automatically fix eligible **Basic scan** findings, such as common row-level security (RLS) and database access issues, during regular agent work. See [Let Lovable automatically fix eligible findings](/features/security#let-lovable-automatically-fix-eligible-findings) for how workspace and project settings interact, and which findings are eligible. ## Review project dependencies The Security view shows a **Project dependencies** section with a count of project `npm` packages and known vulnerabilities. Click **Review** to open the dependency list. From there, you can see: * Package name and version * Vulnerability counts by severity, including critical, high, and medium * A **Fix here** action for vulnerable packages You can also: * Search dependencies by package name * Filter to show only packages with vulnerabilities * Click **Scan dependencies** to refresh the dependency audit * Click **Download list** to download a JSON report of all dependencies and vulnerabilities for audits or compliance reviews Keeping dependencies up to date is one of the most effective ways to reduce security risk over time, especially as new vulnerabilities are disclosed. ## Improve scan accuracy with security memory Click **Edit security memory** to open the security memory document for your project. This document is shared with the security scanner and Lovable agent and guides how it evaluates your project. The document should cover the following: * A short description of how your app works from an access control perspective. For example, whether it has authenticated users, what roles exist, or whether it handles sensitive data. * What should never happen within your app's business logic. For example, users reading each other's private data, or unauthenticated access to admin actions. * What not to create vulnerabilities for. This section is also updated when the agent accepts a risk during a scan. Each entry is one line explaining what risk is accepted. Do not use this section to dismiss legitimate security issues. The security scanner reads this document before each scan and uses it to tailor recommendations and reduce false positives for your specific project. You do not need to fill in all sections immediately. Add context as you learn more about your app's security posture. Don't use the security memory to dismiss legitimate security issues. Focus on providing context about your app's purpose, users, and data sensitivity. ## Best practices for using the Security view The Security view is designed for ongoing use throughout development, not just a final check before publishing. The following best practices reflect how builders commonly use it. * **Keep security findings current**\ Review findings regularly and refresh scans when results become outdated, especially after adding features, changing database access, or updating dependencies. * **Prioritize critical issues**\ Address error-level findings before warnings or informational items. Critical findings often represent exploitable vulnerabilities. * **Use both scanning approaches**\ Use the built-in Basic and Deep scans in the Security view for structured checks and targeted fixes. Complement them by periodically asking Lovable to “review my app’s security” in chat for a narrative analysis that may catch issues the automated scans miss. If your workspace uses Wiz or Aikido, review those connector findings alongside Lovable’s built-in scan results. * **Manage dependency risk proactively**\ Regularly review the dependency section and address high-severity vulnerabilities promptly. * **Review and verify fixes**\ Automated fixes can save time, but always review the changes and test your app before continuing development. * **Be deliberate when ignoring findings**\ Ignore findings only when they clearly do not apply. Revisit ignored findings as your project evolves. * **Continue monitoring after publishing**\ Publishing is not the end of security work. Monitor new findings as your app changes over time. Automated scans help catch common issues, but they cannot guarantee complete security. For apps handling sensitive data or critical functionality, consider an additional professional security review. ## FAQ You’ll find the **Security tab** inside any Lovable project by going to **More → Security** in the project toolbar. A scan's results are outdated when your project has changed since the last run. Click **Basic scan** or **Deep scan** to refresh results. Actions on outdated findings are disabled to prevent acting on stale information. **Basic scan** is a faster configuration and dependency check. It looks for common database issues and vulnerabilities in dependencies. **Deep scan** runs a more detailed agentic code review and usually takes longer. Both actions are free and do not consume credits. **Asking Lovable to review your app's security** in chat triggers a separate AI-driven review that provides a narrative report and recommendations. It does not update scan results or scan status. Conversational security reviews in chat consume credits. These approaches are complementary. Yes. Continue monitoring security after publishing, especially when adding features or updating dependencies. Lovable warns you before publishing if critical issues exist. You can choose to publish anyway, but this is strongly discouraged since critical findings typically represent exploitable vulnerabilities. If your workspace has **Block publishing with critical findings** enabled, you need to resolve the critical issues before you can publish. # Sensitive data scanning Source: https://docs.lovable.dev/features/sensitive-data-scanning Detect and manage personally identifiable information across chat messages, file uploads, chat history, Lovable Cloud database, and Lovable Cloud storage. Sensitive data scanning helps teams find and manage personally identifiable information (PII) in Lovable projects. It covers both: * **New chat activity**, through **Chat send protection** for messages and attached files. * **Existing project data**, through **on-demand scans** of chat history, Lovable Cloud database, and Lovable Cloud storage. Use sensitive data scanning to identify personal or regulated data that flows through a Lovable workspace, so teams can review, redact, or remove it before it is used in generated apps or left behind in project data. ## Why use sensitive data scanning Teams that work with regulated, confidential, or customer data need visibility and control over where personal data appears. Sensitive data scanning helps you: * Meet internal compliance and data loss prevention (DLP) requirements. * Give users a chance to review and redact PII before sending chat messages. * Prevent detected PII from being sent in chat when stricter workspace controls are needed. * Audit stored project data before release, handoff, or review. * Keep an audit-ready record of detected PII and the actions taken on it. ## Prerequisites To use sensitive data scanning, you need: * An **Enterprise** plan * **Sensitive data scanning** enabled for your workspace in [Settings → Privacy & security](/features/privacy-and-security-settings#sensitive-data-scanning) * A **workspace owner** or **admin** role to enable sensitive data scanning and configure workspace-level settings * **Project edit access** to run on-demand scans, review findings, and act on findings in **Project → More → Sensitive data** ## How sensitive data detection works Every sensitive data scan in Lovable runs through the same detection engine, **Google Cloud DLP**, which recognizes well-known formats of personal information such as email addresses, credit card numbers, government IDs, and phone numbers from a range of countries. The engine returns potential matches, and Lovable records qualifying matches as findings in the project’s **Sensitive data** tab. For new chat messages, Lovable may also run an additional LLM-based review pass that checks the Google Cloud DLP results, filters likely false positives, and can catch sensitive content the pattern-based scan missed. This applies only to message text, not file attachments. If the review is unavailable, Lovable uses the original DLP results unchanged. Scans are read-only. They do not change, move, redact, or delete data by themselves. To remove or redact PII, take action on individual findings or ask Lovable in chat to fix the data. There are no additional charges to your workspace based on the volume of messages scanned or findings recorded. ### **What the engine looks for** Lovable scans for a fixed list of information types, grouped into these categories: | Category | Types | | :--------- | :----------------------------------------------------------------------------------- | | Identity | Person name, email address, phone number, street address, date of birth, age, gender | | Financial | Credit card data, financial account ID, US bank routing number, SWIFT code | | Government | Government-issued ID, passport | | Medical | Medical data, medical record ID | | Security | Passwords, API keys, and other authentication secrets | The list is international by design and covers patterns common in the EU, UK, India, Canada, and the US. ### How detection confidence works For every potential match, the detection engine returns a likelihood score. Likelihood reflects how confident the engine is that the value really is the type of PII it identified. It does not describe how serious the data is. Lovable records findings only at the **Likely** or **Very likely** level. Lower-confidence matches are filtered out before they reach the findings table, so the list stays focused on real issues. | Likelihood | Meaning | | :---------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | | Very likely | Strong evidence. The match has structural confirmation, such as a credit card number that passes the Luhn checksum or a well-formed email address. | | Likely | Solid evidence. The match fits the expected shape and surrounding context. | ### How findings are prioritized Each information type is mapped to a sensitivity tier that reflects how serious the match would be if real. | Sensitivity | Examples | | :---------- | :------------------------------------------------------------------------------------------ | | Low | Age, gender | | Mid | Email address, phone number, person name, street address | | High | Credit card data, government-issued ID, passport, medical record ID, authentication secrets | Likelihood and sensitivity are independent. A finding can be high-confidence and low-impact, or lower-confidence and high-impact. When you triage findings, address **High** sensitivity findings first. ### What gets scanned Sensitive data scanning covers different sources depending on whether the scan runs live through Chat send protection or on demand from the project's Sensitive data tab. | **Source** | **What is scanned** | **When it runs** | | :---------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------- | | Live chat message | The text in your message box | Every time a user sends a message (when **Chat send protection** is on) | | Live file upload | Files attached to a chat message, in supported formats. Files the scan can read:
  • Text files such as `.txt`, `.csv`, `.json`, `.xml`, `.yaml`, `.md`, `.html`, and log files
  • Spreadsheets and documents such as Excel, Word, PowerPoint, and PDF
  • Images such as JPG, PNG, BMP, and SVG, when text is visible in the image
| Every time a user sends a message with attachments (when **Chat send protection** is on) | | Chat history | Every message saved in the conversation, including user messages and Lovable replies | On demand, from Project → More → Sensitive data | | Cloud database | Sampled rows from Lovable Cloud database tables, where PII is most likely to appear, for example columns that hold text, identifiers, numbers, and dates | On demand, from Project → More → Sensitive data | | Cloud storage | Files in supported formats from the most recently used buckets and the most recently changed files in each. Files the scan can read:
  • Text files such as `.txt`, `.csv`, `.json`, `.xml`, `.yaml`, `.md`, `.html`, and log files
  • Spreadsheets and documents such as Excel, Word, PowerPoint, and PDF
  • Images such as JPG, PNG, BMP, and SVG, when text is visible in the image
| On demand, from Project → More → Sensitive data | ## Configure sensitive data detection Workspace admins and owners configure sensitive data scanning at Settings → Privacy & security. Sensitive data scanning has three related workspace settings: | Setting | What it controls | | :--------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------- | | [Sensitive data scanning](/features/privacy-and-security-settings#sensitive-data-scanning) | The main switch for PII detection. When enabled, Lovable can scan workspace content for PII and record findings. | | [Chat send protection](/features/privacy-and-security-settings#chat-send-protection) | What happens when PII is detected in new chat messages or attached files. | | [Block publishing with PII](/features/privacy-and-security-settings#block-publishing-with-pii) | Whether unresolved sensitive data findings prevent a project from being published or updated. | **Sensitive data scanning** must be enabled before the other controls are available. When enabled, it: * Makes **Chat send protection** available. * Makes **Block publishing with PII** available. * Adds the **Sensitive data** tab to projects. * Allows on-demand scans of existing project data. * Lets anyone with project edit access review and act on recorded findings. When disabled, no sensitive data scans run, no PII findings are recorded, related controls are hidden or inactive, and the Sensitive data tab is hidden on projects. ### Chat send protection **Chat send protection** becomes available only when **Sensitive data scanning** is on. It controls what happens when PII is detected in new chat messages or attached files. On-demand scans of chat history, Lovable Cloud database, or Lovable Cloud storage still work regardless of the chat send protection mode. It has four modes: | **Mode** | **Behavior** | | :----------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Off | No scanning. New chat messages and attached files send without inspection or logging. | | Log only | The scan runs. If PII is detected, a finding is recorded and available for review in the project's **Sensitive data** tab, but the message sends without interruption. This is the default mode when **Sensitive data scanning** is first enabled. | | Ask before sending | The scan runs. If PII is detected, the message is paused. For message text, the user can edit, send a redacted version, or send the original. For attached files with PII, the user can cancel or send the original. Detected PII is logged only if the user sends the original content. Otherwise, the original content is discarded.
You can bypass this on project level by disabling **PII detection warning** from the **Sensitive data** tab. | | Block original | The scan runs. If PII is detected, the user cannot send the original. For message text, they can edit the message or send a redacted version when available. For attached files with PII, they must cancel and replace the file. The original content is discarded and not logged. | ### Block publishing with PII **Block publishing with PII** controls whether unresolved sensitive data findings block publishing. This setting is available only when **Sensitive data scanning** is enabled. By default, **Block publishing with PII** is disabled. | Setting | Behavior | | :------- | :---------------------------------------------------------------------------------------------------------------------------------------- | | Disabled | PII findings do not block publishing. Projects can still be published or updated when they have unresolved sensitive data findings. | | Enabled | A project cannot be published or updated if it has unresolved sensitive data findings. Resolve or dismiss the findings before publishing. | Use this setting when your workspace requires projects to clear sensitive data findings before they go live or receive updates. ## PII detection warning When **Chat send protection** is set to **Ask before sending** or **Block original**, Lovable scans new chat messages and attached files before they are sent. If no PII is detected at the **Likely** threshold or above, the message sends. If PII is detected, the user sees a warning with: * The detected information types * A redacted preview of the message, when specific message text can be redacted. Detected segments are replaced by `[REDACTED:TYPE]` badges. Hovering over a badge reveals the original snippet that triggered the finding. * Matched snippets from attached files * The actions available for the current **Chat send protection** mode and content type The user chooses one of the available actions, depending on whether the finding is in message text or an attached file: | Action | Description | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Send original | Sends the message or attached file as written and records the detected PII as a finding.
This option is available in **Ask before sending** mode only, and not available in **Block original** mode. | | Edit | Returns the user to the message so they can rewrite it. The edited message is scanned again when sent. | | Send redacted | Replaces detected segments with `[REDACTED:TYPE]` placeholders before sending. Only the redacted text is saved to chat history. The original content is not stored anywhere.
Send redacted is unavailable when an attached file contains PII, or when the whole message is flagged as sensitive and there is no specific text segment to replace. If the button is disabled, hover it to see why, then edit the message to remove the sensitive content before sending. | | Cancel | Only for file uploads. Cancels the send so the user can replace the attachment. | If the user edits, cancels, or sends a redacted message, the original PII is discarded and not recorded as a finding. PII detection warning can be disabled for a project when **Chat send protection** is set to **Ask before sending.** ### Disable PII detection warning for a project When **Chat send protection** is set to **Ask before sending**, project members with edit access can disable **PII detection warning** from the project’s **Sensitive data** tab. Use this for projects where the warning adds unnecessary friction, such as internal tools where the team has already accepted the data flow. When **PII detection warning** is disabled: * Detected PII in new chat messages and attached files sends without showing the warning. * Findings are still recorded for audit and review in the project’s Sensitive data tab. Disabling **PII detection warning** is not available in **Off**, **Log only**, or **Block original** mode. ## Run an on-demand scan An on-demand scan inspects content as it currently exists: * Chat history as saved * Current rows in Lovable Cloud database tables * Current objects in Lovable Cloud storage Anyone with project edit access can run an on-demand scan across stored project data. To run an on-demand scan: 1. Open **Project → More → Sensitive data**. 2. Click **Run scan**. 3. Wait for the scan to finish. On-demand scans record every piece of PII found in the stored content they inspect, with no user choice involved. Because on-demand scans read stored content, PII that was already redacted or deleted is no longer present and is not recorded again. This makes it safe to re-run scans without losing review history. ## Review findings Detected sensitive data findings are recorded in each project's **Sensitive data** tab. The **Sensitive data** tab appears under **Project → More** whenever **Sensitive data scanning** is enabled for the workspace. If **Sensitive data scanning** is off, the tab is hidden and no findings are recorded. Above the findings table, you can see when the project was last scanned, for example *"Last scanned 8 hours ago"*, or *"This project has not been scanned yet"* for projects that have never been scanned. Use this view to review where PII was found, when it was recorded, and what action was taken. ### PII findings table Findings are **grouped by source**. Every finding tied to the same source appears together as one expandable row. The rows underneath represent a single finding within it. When you expand a group row, each nested row shows details for one finding. The PII findings table includes the following columns: | Column | Description | | :---------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Source | Where the finding came from:
  • **Chat**: A user message in the project's chat
  • **Upload**: A file attached to a chat message
  • **Cloud storage**: An object in the project's Lovable Cloud storage buckets
  • **Cloud database**: A row in a table in the project's Lovable Cloud database
| | Types | One or more [detected information types](#what-the-engine-looks-for), such as `PERSON_NAME` or `EMAIL_ADDRESS`. | | Sensitivity | The potential impact tier of the information type, assuming the match is real. The group row displays the highest sensitivity tier across the findings in the group.
  • **Low**: Age, gender
  • **Mid**: Email address, phone number, person name, street address
  • **High**: Credit card data, government-issued ID, passport, medical record ID, authentication secrets
Use this to prioritize which findings to address first. | | Found | When the finding was recorded. The group row displays the timestamp for the most recent finding in the group. | | Status | The status of the finding:
  • **Open:** Finding still requires review.
  • **Fixed:** The underlying content has been redacted, deleted, or otherwise resolved.
  • **False positive**: A user has marked the finding as **Not PII**. The underlying content is unchanged and the finding can be reopened.
  • **Mixed**: A group row badge that appears when the individual findings in that group have more than one status.
| | Reference | A link or location identifying the source.
  • Chat and upload findings show **View in chat**.
  • Cloud storage findings show the **object path**.
  • Cloud database findings show `schema.table`.
| ## Take action on findings The available action depends on the source of the finding. A single chat message, upload, or storage object can produce multiple findings. Actions either change review state or change the underlying content: * **Not PII** and **Reopen** change the review state of an individual finding. * **Redact** and **Delete** change the underlying content and resolve every finding on the referenced item together, so they always live on the group row. | Action | Applies to | What it does | | :---------- | :--------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Not PII** | Any finding | Marks the finding as a false positive. The underlying content is not changed, and the finding can be reopened later. | | **Reopen** | Any finding marked **Not PII** | Reopen a finding that was previously marked **Not PII** (false positive). | | **Redact** | Chat messages | Permanently replaces the detected segments in the original chat message with `[REDACTED:TYPE]` placeholders. The whole message is rewritten in the conversation history, and every finding on that message is resolved together. The status moves to **Fixed**. Refresh the page to see changes.
*Note: To dismiss an individual finding without changing the message, mark it as **Not PII** on the corresponding nested row instead.* | | **Delete** | File uploads (in chat and Cloud storage) | Permanently removes the underlying file. The finding moves to **Fixed**. | For Cloud database findings, you can mark a finding as **Not PII** to dismiss it, but the row must be removed from the database directly. Ask Lovable to fix it in the chat, then re-run the scan. Re-running the scan after removing the row updates the finding's status. Findings remain in the PII findings log after they are **Fixed** or marked as **Not PII**. The audit trail is preserved even when the underlying content is removed. If **Block publishing with PII** is enabled, unresolved findings must be fixed or marked as **Not PII** before the project can be published or updated. ## Best practices * **Start in Log only mode.** Use **Log only** to understand what surfaces in your workspace before moving to **Ask before sending** or **Block original**. * **Prioritize High sensitivity findings.** Address **High sensitivity** findings first, especially when they are **Likely** or **Very likely**. * **Treat Not PII as a real signal.** Mark a finding as **Not PII** only when the match is genuinely incorrect. * **Disable PII detection warning sparingly.** Disable it only for projects where the team has explicitly accepted the data flow. * **Re-scan after major data changes.** After importing data, restoring a backup, or making large schema changes, run an on-demand scan to catch anything new. * **Use Block publishing with PII for release control.** Enable it when projects should not be published or updated until unresolved sensitive data findings have been reviewed. ## **Limitations** Before relying on sensitive data scanning as the only line of defense, review the following limits. * **On-demand scans cover Lovable Cloud databases and storage.** External or self-hosted resources are not scanned. * **No direct fix for Cloud database findings.** Cloud database findings can be marked as Not PII from the project’s Sensitive data tab, but the underlying row must be removed from the database directly. To remove the underlying PII, ask Lovable to fix the data in chat, then re-run the scan. * **Only recognized file types are scanned.** Storage and upload scans read supported text files, spreadsheets, documents, PDFs, and images. Files in unsupported formats, or files uploaded without a recognizable content type, are skipped. * **Storage scans are sampled, not exhaustive.** Each storage scan checks the 10 most recently used buckets in the project, the 20 most recently changed files in each bucket, and roughly the first 450 KB of each text file or document, or 3.9 MB of each image. Older files, files beyond those counts, and content past the size limit are not inspected. * **Database scans are sampled, not exhaustive.** Each database scan reads roughly the first 200 rows from relevant tables and only the beginning of very large text values. A clean scan means no PII was found in the sampled data, not that the full database is guaranteed to be PII-free. * **File upload findings are capped.** For file uploads, Lovable records up to **10 findings per file**. If a file has more findings, redact or delete the file rather than addressing findings one at a time. * **Files with detected PII cannot be partially redacted.** When an attached file contains PII, the user must redact the file manually before sending, remove the attachment, or, in Ask before sending mode, send the original if your workspace policy allows it. * **In-chat form answers are not scanned.** Answers typed into in-chat forms are not scanned directly. If Lovable repeats the value back into chat, an on-demand chat history scan can still pick it up. * **Findings log cannot be exported.** Findings are viewable in the project’s Sensitive data tab, but there is no export option at the moment. ## FAQ No. There are no additional charges to your workspace based on the volume of messages scanned or findings recorded when using **Sensitive data scanning**. The default is **Log only**. Findings are recorded in the **Sensitive data** tab without interrupting users until you change the mode. Yes, but only when the workspace is in **Ask before sending** mode. From **Project → More → Sensitive data**, disable **PII detection warnings** for that project. Detected PII is then allowed in chat for that project, while findings are still recorded. In **Block original** mode, sending messages with detected PII is always blocked and cannot be bypassed at the project level. Findings appear in each project's **Sensitive data** tab. Go to **Project → More → Sensitive data**. In **Ask before sending** mode, the user can send the original content. For message text, they can also edit or send a redacted version. For attached files with PII, they can cancel or send the original. In **Block original** mode, the original content cannot be sent. For message text, the user can edit or send a redacted version when available. For attached files with PII, they must cancel and replace the file. No. Choosing **Send redacted** or editing the message discards the original PII, and nothing is written to the findings log.  No. Findings remain in the PII findings log to preserve the history of detected PII and the actions taken. When the underlying content is redacted or deleted, the status of the finding moves to **Fixed**. Findings are surfaced at the Likely confidence level or above. Possible, Unlikely, and Very unlikely matches are filtered out. Custom or proprietary identifiers that do not match a supported information type are also not detected. # Optimize your app for SEO and AI search Source: https://docs.lovable.dev/features/seo-aeo Run an SEO and AI search review, research keywords and competitors with live Semrush data, and connect a custom domain to help your Lovable app rank on Google, Bing, and AI search engines. **Search Engine Optimization (SEO)** helps your project show up in traditional search engines like Google or Bing. **Answer Engine Optimization (AEO)** helps your project show up in AI search engines like ChatGPT, Perplexity, Claude, or Gemini. Both depend on the same foundations: crawlable HTML, good metadata, clean content structure, fast loading, and links pointing to your site. Lovable helps handle those technical foundations, but strong SEO and AEO still require intentional review and iteration. The SEO & AI search tab helps you audit your project, surface issues, research opportunities, and improve search visibility through SEO & AI search reviews, Semrush-powered SEO research, Google Search Console integration, and AI-search-friendly publishing features. You'll find the SEO & AI search tab under **More → SEO & AI search** in the [project toolbar](/features/projects/editor#the-more-menu) at the top of the editor. The SEO & AI search tab brings together: * **SEO and AI search review**. Run on-demand audits for sitemap, `robots.txt`, metadata, semantic HTML, content structure, alt text, canonical tags, indexing, accessibility, mobile usability, and performance. Lovable surfaces clear recommendations and can apply most fixes in one click. * **Speed and Lighthouse checks**. Performance, accessibility, mobile usability, and indexing checks from the old standalone Speed tab **now live directly inside the SEO & AI search review**. The SEO & AI search review replaces the previous Speed dashboard. * **Google Search Console (GSC) setup**. If the [Google Search Console connector](/integrations/google-search-console) is enabled in your workspace, the SEO & AI search review can detect missing GSC setup and guide you through connecting GSC, verifying your site, and submitting your sitemap directly from chat. * **Semrush-powered SEO research**. Use **Research SEO with Lovable** to research keywords, competitors, backlinks, rankings, and SEO strategy using live Semrush data. * **Custom domains**. [**Buy or connect a custom domain**](/features/custom-domain) and build your search presence on a domain you control. ## Before you begin * SEO & AI search reviews are scoped to a single project at a time. * Running an SEO and AI search review is free on all plans. * Applying fixes with **Try to fix** uses regular message credits. * Semrush-powered SEO research has no additional cost through August 15, 2026. No Semrush account required and no separate billing. * You can run SEO and AI search reviews on unpublished projects. * Additional checks become available after your site is publicly published, including live indexing, AI markdown rendering, performance, and accessibility audits. * Only **publicly published** apps can be indexed by search engines. Private or unpublished projects, and [branded workspace URLs](/features/branded-workspace-urls) (`https://{app-name}.{workspace-subdomain}.lovable.app`), are never indexable. [Connect a custom domain](/features/custom-domain) to build search presence. The review still checks `robots.txt`, sitemap, and `llms.txt` on these so you can prepare before launch, but at lower priority. * Sitemaps, `robots.txt`, metadata, and other SEO elements are not always generated up front. The review surfaces missing or out-of-sync items, and Lovable can create, update, or repair most things in one click. * Google Search Console setup only appears after the [Google Search Console connector](/integrations/google-search-console) has been enabled in your workspace. * New Lovable apps created from May 13, 2026 use TanStack Start with server-side rendering (SSR). Older React + Vite apps use **on-request pre-rendering** on deployed public URLs, served only to verified search and AI crawlers (Google, Bing, social-preview bots, and AI engines like ChatGPT, Perplexity, Claude, Gemini). Pre-rendering runs at request time, so dynamically loaded content is included. Third-party SEO scanners and other unverified agents see the regular single-page app. SEO and AI search visibility are supported across both stacks. ## Quick start 1. Open **More → SEO & AI search** from the project toolbar. 2. Click **Scan project** (first time) or **Scan again** to run an SEO & AI search review. 3. Review failing findings at the top of the report. 4. Click **Try to fix** on individual findings, or **Try to fix all** to send multiple fixes to the agent at once. 5. Publish your project if you want published-site checks like performance, indexing, accessibility, AI readiness, and Google Search Console setup. 6. Run the review again after publishing to surface those checks. 7. If the review surfaces missing Google Search Console setup, click **Try to fix** to connect the [Google Search Console connector](/integrations/google-search-console), verify your site, and submit your sitemap directly from chat. Publish your latest changes before the sitemap step. Google fetches the sitemap from your live site, so unpublished routes won't be submitted. 8. [Connect a custom domain](/features/custom-domain) if you want to build search presence on your own domain. After connecting one, rerun the review so Lovable can verify and update Google Search Console for the new domain. 9. Use **Research SEO with Lovable** for strategy questions. Click a suggested question or type your own. For example: * “Which keywords should I target next?” * “What competitors rank for similar products?” * “What backlinks should I try to get?” ## SEO and AI search review SEO & AI search reviews run on demand and analyze your code, preview deployment, and, once publicly published, your live site. Lovable does not rerun reviews automatically when you publish. Use **Scan project** the first time you run a review, or **Scan again** to rerun it later. When a review is not actively running, a status badge at the top of the review shows whether the results reflect your latest code: * **Up to date**: the scan matches the current state of your project. * **Out of date**: you have made changes since the last scan. Run the review again before relying on the results. While a review is running, the header switches to **Scanning your project…** Findings reflect the most recent scan. If you make changes after a scan completes, run the review again before relying on the results. ### Understand findings Each finding includes an icon that shows its state and, when failing, how much it affects search visibility: * **Green check**: passing. Nothing to do. * **Blue lightbulb**: low-impact issue. Nice to fix. * **Amber warning triangle**: medium-impact issue. * **Red X**: high-impact issue. Reserved for problems that can effectively hide your site from search engines, such as a sitewide `noindex` tag, a homepage that will not load, `robots.txt` blocking crawlers on a live site, or an `X-Robots-Tag: noindex` header on a server-rendered published deployment. The review groups findings automatically: * **Failing** findings appear at the top of the list. * **Passing** findings appear below with a green check. * **Fixed** appears as a badge on findings the agent just resolved. The next scan confirms whether the issue is actually fixed and moves the finding back to failing if the issue still exists. * **Ignored** findings move into a collapsible **Ignored issues** section at the bottom of the review. Use **Restore** to move a finding back into the active list. ### What SEO & AI search review checks The review combines code analysis, preview checks, and published-site audits. * **Code-only checks** run on any project, including unpublished ones. These include page basics, metadata, Open Graph tags, structured data, indexing meta tags, and homepage content structure. * **Preview checks** require a reachable preview deployment. These include homepage reachability, `robots.txt`, `sitemap.xml`, and `llms.txt`. * **Published checks** run only against your live public site, not your preview deployment. These include Lighthouse performance audits, accessibility audits, mobile usability checks, indexing audits, and AI Markdown rendering checks. * **Google Search Console checks** only appear for live public sites when the [Google Search Console connector](/integrations/google-search-console) has been enabled in your workspace. Each check runs when you start a review, and Lovable can apply most fixes when you click **Try to fix**. | Category | Passing finding | Common issues | | :---------------- | :------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Page basics | Page basics are set | Missing viewport configuration or missing `lang` attribute on ``.
Appears as "Some basic page setup is missing" | | Indexing | Home page is reachable | A homepage that returns errors, a sitewide `noindex` meta tag, or (on server-rendered apps) an `X-Robots-Tag: noindex` header blocks search engines.
May appear as:
  • "Home page isn’t loading"
  • "Home page is blocked from search engines"
| | Indexing | Google Search Console is set up | Missing GSC connection, site verification, or sitemap submission. Only appears if the [Google Search Console connector](/integrations/google-search-console) has been enabled in your workspace.
Appears as "Google Search Console isn’t fully set up" | | robots.txt | Crawler rules look good | Missing `robots.txt`, blocked crawlers, missing `Sitemap:` directives, or invalid crawler rules.
May appear as:
  • "Crawler rules are missing"
  • "Crawler rules need attention"
| | Sitemap | Sitemap looks good | Missing sitemap, invalid XML, placeholder routes, relative URLs, host mismatches, or out-of-sync URLs between your routes and sitemap.
May appear as:
  • "Sitemap is missing"
  • "Sitemap needs attention"
| | Metadata | Page metadata describes the site clearly | Duplicate titles, placeholder text, weak descriptions, or incorrect canonical URLs.
May appear as:
  • "Page title and description are too generic"
  • "Search engines see placeholder text"
  • "Duplicate titles across routes"
  • "Canonical URLs point to the homepage"
| | Open Graph | Social link previews look good | Missing or generic Open Graph metadata and social previews per route.
May appear as:
  • "Shared links still show Lovable's branding"
  • "Social previews aren't customized for this site"
  • "Open Graph tags are missing on most pages"
| | Structured data | Structured data is set up for rich search results
or
Structured data is optional here (on utility apps and dashboards) | Missing or incorrect JSON-LD structured data.
May appear as:
  • "Search results won't show rich previews"
  • "Pages are missing schema for rich search results"
  • "JSON-LD type doesn't match the page"
| | Content structure | Homepage content and structure are well-optimized | Missing H1s, weak headings, missing alt text, poor link text, or accessibility labeling issues.
May appear as:
  • "H1 is missing or too generic"
  • "Some images lack alt text"
  • "Link text doesn't describe its destination"
  • "Heading levels skip from H1 to H3"
| | AI readiness | AI summary is in place | Missing or invalid `llms.txt`.
May appear as:
  • "AI summary is missing"
  • "AI summary needs attention"
| | AI readiness | AI assistants can see your site as Markdown | This is a positive-only check. It confirms Lovable is serving a clean Markdown version of your published site to AI crawlers. | | Performance | Page loads fast | Poor Lighthouse or PageSpeed performance metrics, including LCP, CLS, INP, render-blocking resources, image optimization, font loading, or JavaScript errors.
Appears as "Page loads slowly" | | Accessibility | Accessibility is good | Lighthouse accessibility issues such as low color contrast, missing ARIA labels, duplicate IDs, empty headings, or landmark/navigation problems.
Appears as "Has accessibility barriers" | | Mobile usability | Comfortable on phones | Mobile usability issues such as small tap targets, readability problems, spacing issues, or responsive layout problems.
Appears as "Awkward on phones" | ### Fix findings Failing findings appear at the top of the review. For each one you can: * **Try to fix**: sends the finding to the agent, which applies the changes across your project files. * **Ignore**: hides the finding from future scans until you restore it. The review header also includes: * **Try to fix all**: sends every failing finding to the agent in a single message. * **Scan again**: reruns the review. After the agent finishes, publish your project if needed and run the review again to confirm the fixes landed successfully. ### Google Search Console Connect Google Search Console directly from chat. Lovable can verify your site and submit your sitemap without leaving the SEO & AI search tab. If the [Google Search Console connector](/integrations/google-search-console) is enabled in your workspace, the review includes a GSC setup check for publicly published projects. The check verifies: * Google Search Console is connected * Your site is verified * A sitemap has been submitted If any step is incomplete, click **Try to fix** and Lovable handles the next setup step for you directly from chat. When all steps pass, the finding changes to “Google Search Console is set up.” Good to know: * Verification may take a few minutes after publishing. * Changing your [custom domain](/features/custom-domain) requires re-verification in GSC. * Make sure your latest changes are published before clicking **Try to fix** on the sitemap step. Google fetches the sitemap from your live site, so any pages that are only in your unpublished code won't be included. If you've added or renamed routes since your last publish, publish first, then submit. If the GSC connector has not been enabled for your workspace, this check does not appear. ## Research SEO with Lovable **Research SEO with Lovable** is powered by **live Semrush data**. It suggests SEO questions tailored to your project. Click a suggested question to send it to chat, or ask your own. Semrush-powered SEO research has no additional cost through **August 15, 2026**. No Semrush account required and no separate billing. You can use it for: * Keyword research * Competitor analysis * Content ideas * Search trends * Backlink opportunities * SEO strategy * Ranking analysis * Site audits * Landing page optimization Examples: * “What keywords should a site like mine target?” * “Which competitors rank for similar products?” * “Why is my homepage not ranking?” * “What pages drive the most traffic for sites like this?” * “What backlinks should I try to get?” * “Audit `/pricing` for SEO issues.” * “Suggest SEO improvements for my landing page copy.” Click **New questions** to rotate to a fresh set of suggestions. Lovable labels Semrush-powered responses directly in chat. The SEO & AI search review focuses on technical and indexing issues, while Semrush-powered SEO research helps with strategy, content, keywords, and competitive research. ## Custom domains **Get a custom domain** lets you buy or connect a custom domain without leaving the SEO & AI search tab. Using a custom domain helps consolidate your brand and search presence under a domain you control. Lovable supports both custom domains and subdomains, and lets you choose one primary domain so all other connected domains redirect to it automatically. After connecting a custom domain, use the [Google Search Console connector](/integrations/google-search-console) to verify your site and submit your sitemap directly from chat, so Google indexes the correct host. What you see depends on your project state: * **Project not published yet**: buy and connect actions are disabled until the project is publicly published. * **No custom domain yet**: Lovable suggests up to three domain ideas based on your project. Click a suggestion, or click **Search domains** to open the purchase dialog. * **Already own a domain?** Click **Manage domains** to open **Project settings → Domains** and finish connecting it. * **Already connected**: the section shows your live domain and links to **Project settings → Domains**. Buying a domain requires a paid plan and workspace admin or owner permission. For full setup details, see [Custom domains](/features/custom-domain). ## FAQ Yes. Lovable apps can rank like other modern web apps. New Lovable apps use TanStack Start with server-side rendering by default, and older React + Vite apps use **on-request pre-rendering** on deployed public URLs for **verified crawlers:** Google, Bing, social-preview bots, and AI engines like ChatGPT, Perplexity, Claude, and Gemini. Ranking still depends on factors outside Lovable's control, including content quality, search intent, backlinks, competition, performance, and search ranking algorithms. Lovable apps run on one of two stacks, both of which return crawlable HTML to search engines and AI crawlers. * **New apps** created from May 13, 2026 use **TanStack Start** with server-side rendering (SSR). Every request returns fully rendered HTML, for humans and crawlers. * **Older React + Vite apps** use **on-request pre-rendering** on deployed public URLs. Human visitors get the single-page app experience. When a verified crawler arrives, Lovable renders the page on the fly and returns the resulting HTML. Pre-rendering is only served to **verified crawlers:** Google, Bing, social-preview bots, and AI engines like ChatGPT, Perplexity, Claude, and Gemini. Third-party SEO scanners, link checkers, and other agents will see the regular SPA shell, not the pre-rendered HTML. If you want to verify the pre-rendered output yourself, use Google's URL Inspection tool, the Mobile-Friendly Test, or social-platform link debuggers. Because pre-rendering runs at request time, dynamically loaded content is included. Both stacks support SEO and AI search visibility without requiring external pre-rendering services. What still matters is the quality of each page: metadata, content structure, semantic HTML, alt text, structured data, internal links, performance, and backlinks. No. Lovable-hosted projects do not need an external pre-rendering service for search engines or AI crawlers. If your project is on React + Vite, Lovable handles pre-rendering for deployed public URLs, but only for **verified crawlers:** Google, Bing, social-preview bots, and AI engines like ChatGPT, Perplexity, Claude, and Gemini. Other automated agents, including third-party SEO scanners, will see the regular single-page app and not the pre-rendered HTML. If your project is on TanStack Start, server-side rendering returns crawlable HTML to every request, so every visitor (humans, crawlers, scanners) sees the same rendered output. Not right now. Existing React + Vite projects get pre-rendering automatically, which makes your content accessible to crawlers. Full SSR is currently only available for new projects built on TanStack Start. Yes. Lovable is designed to serve crawlable content to AI search engines such as ChatGPT, Perplexity, Claude, and Gemini. New TanStack Start apps return fully rendered HTML to AI crawlers. Older React + Vite apps use pre-rendering on deployed public URLs so AI crawlers can still access rendered content. For best results, make your content easy to understand and cite: * Use clear headings and semantic HTML. * Add structured data where it fits the page. * Keep important facts visible on the page. * Add `llms.txt` for key pages. * Write concise, factual answers to common questions. Social platforms such as LinkedIn, Slack, Facebook, X/Twitter, and WhatsApp usually read Open Graph metadata directly from the HTML response and often do not execute client-side JavaScript. Lovable apps are designed to serve crawlable metadata to social-preview bots, but previews still depend on properly configured Open Graph metadata for each page. For best results: * Use unique `og:title`, `og:description`, and `og:image` values per route. * Avoid generic fallback images across your site. * Publish changes before testing previews. * Use the platform preview/debugging tools to refresh cached previews. Indexing can take from a few hours to a few days, and sometimes longer depending on Google's crawl schedule and your site's authority. To help Google discover updates faster: * Submit your sitemap in Google Search Console. * Use **URL Inspection** for important pages. * **Request indexing** for new or updated priority pages. * Make sure important pages are linked from your site. Start by confirming that the page can be discovered and indexed: * Run an SEO & AI search review. * Check indexing in GSC through Coverage or URL Inspection. * Ensure your sitemap is submitted and confirm the page is in your sitemap. * Make sure it has a unique title and meta description. * Review headings, internal links, content quality, and search intent. * Confirm technical health: good performance scores, full mobile usability, and no blocked JavaScript or CSS. * Build relevant backlinks over time. Ranking also depends on competition and content quality, so passing technical checks does not guarantee high rankings. Yes. A custom domain helps you build search presence on a domain you control. It also lets you consolidate branding, backlinks, and canonical URLs under one primary domain. Lovable supports custom domains and subdomains. You can choose one primary domain, and other connected domains redirect to it. See [Custom domains](/features/custom-domain) for more information. After connecting a custom domain, use the [Google Search Console connector](/integrations/google-search-console) to verify your domain and submit your sitemap. A `lovable.app` subdomain works well for: * MVPs and demos * Temporary or experimental landing pages * Internal tools * Projects driven primarily by social or paid traffic The review focuses on technical SEO, crawlability, metadata, indexing, accessibility, mobile usability, and related issues that Lovable can detect automatically. It does not guarantee rankings or fully evaluate: * Content quality and originality * Search intent alignment * Competitor strength * Backlink quality and authority * Brand reputation and trust * Conversion quality or engagement * Whether a topic is worth targeting Use the SEO & AI search review to keep your technical foundations healthy, then use Semrush-powered SEO research and your own product knowledge to improve content strategy and authority over time. Strong SEO and AEO results come from combining good technical foundations, high-quality content, and ongoing iteration. Start with the SEO & AI search review to catch issues with metadata, indexing, structured data, accessibility, mobile usability, performance, and crawlability. Then use Semrush-powered SEO research to identify keywords, competitors, backlink opportunities, and content gaps over time. Focus on these fundamentals: **Content and structure** * Write unique, high-quality content. * Match real search intent and answer specific questions clearly. * Use descriptive headings and semantic HTML. * Add structured data where it fits the page. * Keep important facts visible in the page HTML. **Metadata and discoverability** * Use unique titles and descriptions for important pages. * Maintain accurate sitemaps and `robots.txt`. * Configure Open Graph metadata for social previews. * Add `llms.txt` for important AI-search-friendly content. * Use a custom domain, set it as the primary domain, and verify it in Google Search Console. **Performance and usability** * Optimize Core Web Vitals and PageSpeed performance. * Ensure strong mobile usability and accessibility. * Compress images and use efficient formats like WebP or SVG. **Authority and backlinks** * Create useful, link-worthy content. * Build relevant backlinks over time. * Partner with complementary businesses and communities. * Share updates, launches, tools, and research publicly. Strong rankings and AI visibility usually improve gradually over time as your site gains authority, backlinks, and useful content. Review SEO and AEO whenever you publish major changes, add or remove pages, change domains, or update routing. Use SEO & AI search review and Google Search Console regularly to monitor crawlability, indexing, metadata, performance, accessibility, and search visibility over time. As a baseline: * Weekly: check Google Search Console for indexing, coverage, and search performance issues. * Monthly: run an SEO & AI search review and review sitemap freshness, titles, descriptions, and Core Web Vitals/PageSpeed performance. * Quarterly: run an SEO & AI search review covering canonicals, `robots.txt`, structured data, indexing, performance, accessibility, and mobile usability. Review internal links, refresh declining content, and improve important landing pages as needed. * As needed: use Semrush-powered SEO research for keyword research, competitor analysis, backlink opportunities, and identifying new content opportunities. # Share a project with internal or external collaborators Source: https://docs.lovable.dev/features/share-project Manage project access and invite people to collaborate on a project. The **Share dialog** is where you open up a project to others: workspace members, external collaborators, or anyone with a link. It is accessible from the **Share** button in the top bar of any project. ## Add project collaborators Use **Invite people** at the top of the **Share** dialog to invite one or more workspace members, [workspace groups](/features/groups) (only on Business and Enterprise plans), or external collaborators to the project directly. Each person or group you add is granted access to the project based on the assigned role. 1. Open the project and click **Share** 2. Enter one or more email addresses or workspace groups in the **Add people** field 3. Choose the access level. * **Admin** (available on paid plans): Full access to the project, including all project settings, integrations, and external connections. * **Editor** (default on all plans): Can build, edit, and manage most project settings. Some advanced settings, like integrations and external connections, are reserved for admins. * **Viewer** (available on paid plans): Read-only access to the project editor. 4. Click **Invite** Each person receives an email with a link to join the project. If they already have a Lovable account, the project also appears in their **Shared with me** section. If they don't, they can create an account and join through the invitation. On **Business** and **Enterprise** plans: * Lovable warns you before inviting someone who isn't a member of your workspace. * Workspace admins and owners can control whether external collaborators are allowed and the highest project role they can have from **Settings → Privacy & security → External project collaborators**. When **SSO enforcement** is on, external collaborators are blocked by default until an admin or owner explicitly allows them. ## Control project access across your workspace The row showing your **workspace name** controls whether members of your workspace have access to the project by default. It sets the project's visibility across the whole workspace. | **Access level** | **Who can access the project** | Project visibility | | :--------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------- | | **Can edit** | **All workspace members and explicitly invited collaborators** can view, remix, or edit the project, based on their role.
On Free and Pro plans, projects are always visible to the workspace. You can only adjust the access level of individual collaborators. | **Workspace** | | **Can view** | **All workspace members** can view and remix the project. Workspace owners and explicitly invited collaborators with edit rights can still edit it.
Available on Business and Enterprise plans. | **Workspace** | | **No access** | **Only the owner and explicitly invited collaborators** can view, remix, or edit the project based on their role.
The project becomes personal (restricted). Available on Business and Enterprise plans.
*Note: Keep in mind that workspace owners have full access to all projects in the workspace and can view and edit them.* | **Restricted** | See [Project access](https://docs.lovable.dev/features/project-visibility) for more information. ## Share an invite link An invite link is a shareable URL. Anyone who opens it is automatically added to the project as a collaborator with the role you set. Invite links are useful for: * Onboarding a new teammate without looking up their email * Sharing a project in a chat channel or doc * Giving a contractor time-limited edit access On Business and Enterprise workspaces with **SSO enforcement** on, project invite links only work for users whose email is on a [verified workspace domain](/features/verified-domains) and the link's access level is within the workspace's just-in-time provisioning role. ### **Create an invite link** 1. In the **Share** dialog, set the **Invite link** access level: * **Edit access**: anyone with the link becomes an editor (available on all plans) * **View access**: anyone with the link becomes a viewer (requires a paid plan) 2. Click **Copy invite link** and share it Invite links expire automatically **5 days** after they are created. If a link stops working, create a new one. Only one active invite link can exist at a time. Changing the access level generates a new link and invalidates the previous one. ### **Change or disable an invite link** Open the **Share** dialog and use the access-level dropdown next to **Invite link**: * **Edit access** or **View access**: changes the link's access level. This generates a new link and the previous URL stops working. You need to share the link again. * **Disabled**: turns off the link entirely. The URL becomes invalid immediately. ## Manage who has access The **Project access** section of the **Share** dialog lists everyone who can currently access the project. You can see specific people, groups, and workspace-level access based on your plan. From this list you can: * **Change someone's role**: click the access-level dropdown next to their name * **Remove individuals or groups**: click **Remove** from the workspace member, external collaborator, or workspace group access-level dropdown * **Remove workspace access** (available only on Business and Enterprise plans): choose **Restricted** from the workspace dropdown * **Update workspace access**: choose **Can edit** or **Can view** (available only on Business and Enterprise plans) from the access-level dropdown * **Manage the invite link:** change the link's access level or disable the link entirely Available actions depend on your role. Editors can invite and remove others with the same role or lower; admins and owners can manage any collaborator. ## Share preview links A preview link is a public, **view-only URL** that anyone can open without logging in. It's designed for quickly showing a preview of your live app, even if not published. You can share it with clients, on social media, or in a bug report. A shared preview link does not create a collaborator, require an account, or grant any edit rights. Viewers see the app exactly as it runs; they do not see the Lovable editor, chat, or source code. 1. In the **Share** dialog, click **Share preview.** 2. Choose whether to allow guest viewers to leave comments on the preview. **Guest comments** is on by default; turn it off if you do not want to allow guests to comment. 3. Click **Copy preview link.** 4. Paste the link anywhere you want to share it. Preview links are valid for **7 days**. After that, create a new preview link. Sharing preview links is allowed by default on every plan. On **Enterprise** plans, workspace admins and owners can disable them across the entire workspace from **Settings → Privacy & security → Allow public preview links sharing**. When disabled, the **Share preview** button is hidden for all projects in the workspace. ### Collect feedback with guest comments When **Guest comments** is on, anyone who opens your preview link can leave comments directly on the preview without needing access to the project, even without a Lovable account. Disable **Guest comments** from the **Share dialog** before copying and sharing the preview link if you want to share a clean, comment-free preview. To leave a comment, a guest opens the preview link and: 1. Clicks **Comment** in the preview toolbar. 2. Clicks anywhere on the preview to pin a comment to that spot. 3. Guests signed in to Lovable comment under their Lovable account. Guests who aren't signed in are asked to enter a name the first time they comment. No account or email is required, and signing up is optional. 4. The guest can then start comment threads, reply to existing ones, and edit or delete their own comments. Comments appear in a panel alongside the preview. The project owner receives an inbox notification in Lovable when a guest comments on the preview. Anyone with access to the project can reply to guest comment threads. When the preview link expires after 7 days, commenting on it stops with it. Create a new link to keep collecting feedback. ## Publish project Deploy the project to a permanent public URL on `lovable.app` or your custom domain. See [Publish your project](/features/publish) and [Custom domains](/features/custom-domain) for more information. The publish project link in **Share** dialog only redirects you to the **Publish** dialog where you need to go through the whole publishing flow. ## FAQ An invite link turns the person who opens it into a project collaborator (editor or viewer) inside the Lovable editor. They must have a Lovable account. A shared preview link is a public, view-only URL to the preview of your live app. It does not create a collaborator, require an account, or grant any edit rights. Viewers do not see the Lovable editor, chat, or source code. Yes. **Guest comments** are on by default: anyone with the link can leave comments on the preview even without a Lovable account, and the project owner is notified in their Lovable inbox. Disable **Guest comments** from the **Share** dialog before copying and sharing the preview link if you want a comment-free preview. Shared preview link is a temporary (up to 7 days), public, view-only URL for quickly showing the preview of your live app to someone, and can be shared even before the app is published. Publishing deploys the app to a permanent URL on `lovable.app` or your custom domain, with its own access controls. Yes. Invite people by email or share an invite link. On Business and Enterprise plans, admins can restrict external collaborator roles or block external invites entirely using the **External project collaborators** setting in **Settings → Privacy & security**. The invite link can stop working for several reasons: * Invite links expire after 5 days. Create a new link and share it again. * Changing the link's access level generates a new link and the previous URL stops working. You need to share the link again. * The invite link is disabled. Yes. The project owner can hand the project to another workspace member from **Project settings → Transfer ownership**. To open it, click the project name in the top left of the editor, then click **Settings**. Your access after the transfer depends on your workspace role. See [Project access](/features/project-visibility) for how workspace roles map to project access. When a project owner is removed from the workspace or leaves it, ownership of their projects is auto-transferred to the most senior remaining member (owners first, then admins, then editors). Projects with access set to **Restricted** are not transferred automatically. If you're not the project owner and want a personal copy of a project, remix it into your own account. You'll be the owner of the new copy. Only if you opt in. The move dialog has a **Transfer project collaborators** checkbox, off by default. When it's off, people invited directly to the project and any pending invites are removed during the move. When it's on, Lovable keeps them when the destination workspace allows their role and you have permission to grant it there. See [Move a project to another workspace](/features/projects/settings#move-a-project-to-another-workspace). # Define reusable instructions with skills Source: https://docs.lovable.dev/features/skills Define reusable, on-demand workflows for Lovable using workspace skills. Package focused instructions, playbooks, and checklists that Lovable applies whenever a matching task comes up across every project in your workspace. Skills let you teach Lovable how to handle recurring tasks. Define a skill once at the workspace level, and Lovable can use it across every project in that workspace. Each skill is a short, named playbook with: * a name, * a description that tells Lovable when to use it, * and markdown instructions that Lovable follows when the skill applies. You can invoke the skill as a `/` command paired with your prompt, or let Lovable apply it automatically when the task matches. Skills are portable markdown-based files, so you can inspect exactly what Lovable is being told, share them with teammates, import them from GitHub or ZIP, and improve them over time. ## Skills vs. knowledge Skills and knowledge complement each other. * [Knowledge](/features/knowledge) is always included in context. Use it for rules and conventions that apply to everything Lovable does, such as coding standards, brand guidelines, or your project's domain terminology. * **Skills** are loaded on demand when the request matches. Use them for instructions that only matter for specific kinds of tasks, such as running a release checklist, drafting a customer reply, or producing a particular kind of content. If an instruction is relevant on every message, put it in workspace knowledge. If it is only relevant when a specific topic comes up, make it a skill. Skills are loaded only when relevant, so you can maintain many focused skills without loading them all into every conversation. ## Custom and built-in skills The Skills page is split into two sections: **Workspace skills** and **Skills built by Lovable**. **Workspace skills** are custom skills added by your team. They are shared with every project in the workspace and follow the [permission rules](#role-based-access-for-skills) below. Skills you build in chat, write manually, import from GitHub, or upload as a ZIP appear here. **Skills built by Lovable** are maintained by Lovable and available in every workspace without setup. They cover common tasks, such as accessibility checks, redesigns, SEO reviews, skill creation, and video creation. You can use them when relevant, but you cannot edit, delete, or download them. Workspace skills and Lovable-built skills appear in the slash menu, can be invoked directly, and can be applied automatically when your request matches the skill. ## What skills are for Skills work best for repeatable, task-specific workflows. Use them when you want Lovable to handle the same kind of task the same way each time. Common examples include: * **Launch checks**: pre-ship checklists, release readiness reviews, and go/no-go reviews * **Recurring content**: release notes, changelog entries, support replies, and marketing copy * **Review playbooks**: landing-page reviews, copy reviews, accessibility passes, and search engine optimization reviews * **Internal processes**: onboarding flow reviews, quality assurance passes, billing setup, and partner handoff steps * **Task-specific style guides**: tone of voice, brand persona, or formatting rules for a particular kind of content * **Reusable team workflows**: research routines, document templates, partner integrations, or other repeated team processes Because skills are shared across the workspace, they are especially useful when you want every project to follow the same process. ## Role-based access for skills Access to skills follows your workspace and project roles. | Role | Allowed action | | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workspace owner and admin only |
  • Create, edit, delete, and import custom workspace skills (from Skills page, chat, GitHub, or ZIP archive)
  • Enable or disable automatic use for a custom skill across the workspace
| |
  • Workspace owner, admin, or editor
  • Project owner, admin, or editor
|
  • View and invoke all skills available to the workspace
  • Download custom workspace skills
| On Enterprise plans, skill changes are recorded in your workspace audit log. ## Add a skill Workspace owners and admins can add custom skills in five ways. Four options are available from **Settings → Skills → Add**, and one starts from a project chat after Lovable does something you want to reuse. ### Build with Lovable Choose **Add → Build with Lovable** to start a guided skill-building conversation. Lovable opens the dashboard with a starter prompt: ```text wrap theme={null} Help me create a skill together using /skill-creator. First ask me what the skill should do. ``` Send the prompt, then answer Lovable’s questions about what the skill should do, when it should trigger, and what instructions it should follow. Lovable drafts the skill for you. When you approve the draft, the skill is published to your workspace. ### Write manually Choose **Add → Write manually** to write a skill from scratch. The form has three fields: * **Name**: a short, permanent ID like `launch-checklist` or `support-reply`. Use lowercase letters, numbers, and hyphens only. * **Description**: the trigger Lovable uses to decide when to load the skill. Start with “Use when...” and describe the skill’s scope and boundaries. * **Content**: the instructions Lovable follows once the skill is loaded, such as steps, constraints, examples, and the expected output. Click **Add skill** to publish it. The skill is available across the workspace immediately. For field requirements, naming rules, and description examples, see [Anatomy of a skill](#anatomy-of-a-skill). ### Import from GitHub Choose **Add → Import from GitHub**, and paste a public GitHub repository URL. Lovable supports two GitHub URL formats: * **Whole repository**: `https://github.com/owner/repo`\ Use this when the repository contains one skill. The `SKILL.md` file must be at the root of the repository. * **Subdirectory**: `https://github.com/owner/repo/tree//path/to/skill`\ Use this when a single repository contains multiple skills. The linked directory must contain `SKILL.md` directly. A direct file URL also works: ```text theme={null} https://github.com/owner/repo/blob//path/to/SKILL.md ``` When you use a `blob` URL, Lovable imports the parent folder that contains `SKILL.md`. Lovable downloads the repository, validates it, and adds the skill to your workspace. ### Upload a ZIP Choose **Add → Upload ZIP**, and drag in or browse for a `.zip` or `.skill` file. The archive must contain a `SKILL.md` file either at the root or inside one wrapping folder. Any bundled files referenced by the skill should sit alongside `SKILL.md` in the same directory. Uploaded archives can be up to **50 MB**. Each individual bundled file can be up to **1 MB**, and the full skill package can include up to **200 files** totaling **10 MB**. macOS metadata files, such as `__MACOSX/` and `.DS_Store`, are ignored at the root. **Example: importing a skill from Claude** Skills in Lovable use the same `SKILL.md` shape as Anthropic’s Claude and any other tool that follows the Agent Skills convention. If you already built a skill in Claude, export it as a `.skill` or `.zip` file, then upload it in Lovable from **Settings → Skills → Add → Upload ZIP**. Lovable validates the archive and publishes the skill to your workspace with its name, description, instructions, and bundled files intact. From there, it behaves like any other workspace skill. This works in the other direction too: download any custom skill from Lovable as a `.zip`, then upload it into another tool that supports the same `SKILL.md` shape. ### Save from a project chat You can turn a successful project chat interaction into a reusable skill without leaving the project. After Lovable completes a task the way you want, say “save that as a skill” and describe when the skill should apply. Lovable drafts the skill, including a name, description, and instructions, then shows it in chat for you to review. When you approve the draft, the skill is published to your workspace. ## Use a skill Lovable can use skills in two ways: automatically, or when you invoke one directly. ### Let Lovable choose automatically When your request matches a skill’s description, Lovable can apply that skill automatically. You do not need to do anything special. Just describe what you want. You can keep many skills in the same workspace. Lovable only loads the skills that seem relevant to the current request. A `launch-checklist` skill, for example, only applies when someone tells Lovable they are about to ship. It does not affect unrelated work. If a workspace admin has disabled automatic use for a skill, Lovable will not apply it automatically, even when the task matches. You can still invoke the skill manually with a slash command (`/skill-name`). See [Enable or disable automatic use](#enable-or-disable-automatic-use) for details. ### Invoke a skill directly Type `/` in chat, choose a skill from the menu, and then continue typing your request. The skill appears as a tag at the start of your message, telling Lovable which instructions to apply. Think of the skill as the **how** and your prompt as the **what**. For example, with a `launch-checklist` skill in your workspace, you could send: ```text theme={null} /launch-checklist Review the app for launch blockers before Friday’s release. ``` The slash menu filters as you type and shows each skill’s description on hover, so you can confirm you are choosing the right one. After you send the message, the skill appears as a tag in the chat. Hover over the tag to see its description, click it to open the full skill preview, or use the pencil icon in the preview to open that skill’s settings. Skills with automatic use disabled still appear in the slash menu and can be invoked directly with `/skill-name`. Disabling automatic use only prevents Lovable from applying the skill on its own; it does not hide the skill or block manual invocation. ## Manage your skills Use **Settings → Skills** to manage workspace skills. You can also open **Project settings → Skills** while working in a project. The available actions depend on your role. See [Role-based access for skills](#role-based-access-for-skills). ### Edit or delete a skill Go to **Settings → Skills** to see every skill in your workspace. Open a custom skill to edit its description or instructions, or delete it if you no longer need it. Deleting a skill removes it from the workspace and from every project in that workspace. ### Download a skill Open any custom skill in **Settings → Skills** and click **Download** to export the full skill package as a `.zip`. Use downloads to back up a skill, move it to another workspace, share it with a teammate to edit offline, or upload it into another tool that supports the same `SKILL.md` shape, such as Claude. ### Enable or disable automatic use Every custom workspace skill has **Automatic use** enabled by default. When automatic use is enabled, Lovable can apply the skill automatically whenever the task matches, and you can also invoke it manually with a slash command (`/skill-name`). When automatic use is disabled, Lovable does not apply the skill on its own in any project, even when the task matches. The skill stays available to the workspace. It appears in the slash menu, and you can invoke it manually with a slash command. Workspace owners and admins can enable or disable automatic use for a skill from **Settings → Skills**, or from **Project settings → Skills** while working in a project. The setting applies across the entire workspace. ## Anatomy of a skill Each skill has three required parts. * **Name**: a short, permanent identifier for the skill, between 1 and 64 characters. Use lowercase letters, numbers, and hyphens only, for example, `launch-checklist`, `release-notes`, or `support-reply`. Names cannot start or end with a hyphen, and cannot contain consecutive hyphens. The name cannot be changed after creation. To rename a skill, delete it and create a new one. * **Description**: a short sentence that tells Lovable when to use the skill. Start with “Use when...” and describe the trigger as concretely as possible. The description is the main signal Lovable uses to decide whether to load the skill for a message. * **Instructions**: the markdown body Lovable follows once the skill is loaded. Include the steps, constraints, examples, edge cases, and output format Lovable should follow. A good rule of thumb is to write the instructions you would give a new teammate doing the task for the first time: what to do, what to avoid, what to watch for, and what format to return. The full `SKILL.md` file can be up to **100,000 characters**. ### Bundled files A skill can also include bundled files. These are optional extra files that travel with the skill. Use bundled files for longer references, templates, or small scripts that the instructions point to, such as `reference.md`. Bundled files appear in the **Bundled files** list when you expand the skill, and they are included when you download or import the skill. Skills authored in chat usually do not need bundled files. They are most common for skills imported from GitHub or a ZIP. Each bundled file can be up to **1 MB**. A skill can include up to **200 files** and up to **10 MB** total across all files. ### Write clear skill descriptions A well-written description is the most important part of a skill. The description tells Lovable when to load the skill. If the description is vague, Lovable may not load the skill when you expect it to, or may load it for unrelated tasks. Good descriptions define both when the skill should apply and when it should not. Clear boundaries help Lovable load the right skill consistently without pulling it into unrelated tasks. **Too vague** ```text wrap theme={null} description: Helps with SEO. ``` This description does not clearly tell Lovable when to use the skill, what kind of SEO task it applies to, or what it should actually do. **Specific and scoped** ```text wrap theme={null} description: Use when auditing SEO health on an existing page: checking metadata, heading structure, and internal links. Not for writing new SEO copy from scratch. ``` This description names: * the trigger (auditing an existing page), * the scope (checking metadata, headings, internal links), * and the boundary (not for writing new copy). Well-scoped descriptions make skills load more consistently and reduce conflicts between similar skills. ### Example skill Here is a complete example of a pre-launch checklist skill that runs whenever you tell Lovable you are about to ship: **Name** ```text wrap theme={null} launch-checklist ``` **Description** ```text wrap theme={null} Use when I say I'm about to launch, ship, share, or release a project, or when I ask whether it is ready to go live. Run the checklist below before giving a go/no-go. ``` **Instructions** ```markdown wrap theme={null} Launch checklist Before approving the launch, walk through this checklist and report back on each item with pass, fail, or "needs manual check". Do not skip ahead. Account flows - Sign-up, sign-in, sign-out, and password reset are wired up end to end. - Signed-out users cannot reach pages that require an account. - Signed-in users land on the right page after login. Core surfaces - The home page and every primary route render without console errors. - Every list, table, or feed has a real empty state, not "No data". - Long-running actions show a loading state and surface errors with a retry path. - At mobile width (375px) there is no horizontal scroll and primary actions are reachable. Data and permissions - Database tables that hold user data have row level security enabled. - A user in one account cannot read or write another account's data. Flag this as "needs manual check". Ask me to verify with a second test account before launch. - Destructive actions (delete, cancel, refund) ask for confirmation. Content and trust - App name, favicon, social preview image, and meta description are set. - Footer links to a working privacy policy and terms page. - No placeholder copy left in the UI ("Lorem ipsum", "TODO", "Your headline here"). Environment - No dev URLs, localhost references, or test API keys (for example, Stripe `sk_test_*`) in production code. - Required production environment variables and secrets are set. - Analytics or product events fire on the actions you want to measure. Final step - Summarize anything that failed or needs a manual check, in priority order. - Do not say "ready to launch" unless every item above passes or has been explicitly waived. ``` This skill could also include [bundled reference files](#bundled-files) alongside `SKILL.md`. For example, the launch checklist could keep deeper search engine optimization and accessibility verification steps in separate bundled files instead of putting everything directly into `SKILL.md`. ```text theme={null} launch-checklist/ ├── SKILL.md ├── seo-checklist.md └── accessibility-checklist.md ``` ## Best practices * **Lead with the trigger.** Start the description with “Use when...” and describe the request as concretely as you can. The description is how Lovable decides whether to load the skill. * **Give each skill one job.** A skill that tries to cover too much may load in the wrong situations or fail to give Lovable clear guidance. Split broad guidance into focused skills, and let each one own a specific task. * **Include boundaries and “avoid” sections.** Telling Lovable what not to do is often as important as telling it what to do. Strong skills define both the intended behavior and the behaviors to avoid. * **Put always-on rules in knowledge instead.** If a rule should apply to every message, it belongs in workspace knowledge. Skills are for behavior that only matters in specific situations. * **Write the instructions like a short playbook.** Use short sections, bullet points, and direct instructions. Skills become part of the context Lovable reads, so shorter, focused instructions are easier to follow. * **Show, do not just tell.** Where helpful, include concrete values, example copy, or example outputs. Lovable follows specific instructions more reliably than abstract ones. * **Review and prune.** As your workspace grows, retire skills that are no longer needed. A skill with stale or incorrect instructions is worse than no skill at all. ## FAQ The full `SKILL.md`, including the description and instructions, can be up to 100,000 characters. Names are limited to 64 characters. A skill can also include bundled files alongside `SKILL.md`: each file can be up to 1 MB, and a skill can contain up to 200 files totaling 10 MB. No. The name is set when the skill is created. To rename a skill, delete it and create a new one with the desired name. The description and instructions can always be edited. Yes. Every skill defined in a workspace is available to every project in that workspace. Workspace owners and admins can disable automatic use for a skill across the workspace without deleting it, so Lovable will not apply it on its own but workspace members can still invoke it manually with a slash command (`/skill-name`). Yes. Open **Settings → Skills** or **Project settings → Skills**, expand the skill, and switch off the **Automatic use** toggle. This applies across the workspace. Lovable will not apply the skill on its own in any project, even when the task matches, but workspace members can still invoke it manually with a slash command (`/skill-name`). Re-enable automatic use at any time from the same place. Lovable reads the description of each skill and decides whether the skill is relevant to your current request. Clear, specific descriptions produce more reliable behavior. If a skill is not triggering when you expect, rewrite the description to be more explicit about the kind of request it applies to. [Knowledge](/features/knowledge) is always included as background context for Lovable. Skills are loaded on demand when the request matches the skill's description. Use knowledge for rules that apply to every message, and skills for instructions that only matter for specific kinds of tasks. Yes. Lovable can use more than one skill in a single message. Keep skills focused so that overlapping skills combine cleanly rather than contradicting each other. There is no additional skill-specific cost. Credits are tied to chat messages, not to skills themselves. * **Creating a skill from chat** (Build with Lovable or "save that as a skill"): costs standard credits, because it is a chat conversation. * **Adding a skill from Settings** (Write manually, Import from GitHub, or Upload ZIP): free. Settings actions do not consume credits. * **Using a skill**: no extra cost on top of the chat message. Standard credits apply to the message, based on its complexity. A skill may indirectly affect cost if the instructions it loads lead Lovable to do more work. Skills are stored in your workspace. On Enterprise plans, every edit and deletion is also recorded in the workspace audit log. Yes. Download the skill as a `.zip` from one workspace, then import the ZIP into another. The imported skill arrives with the same name, description, and contents. No. Only the skills you have added to the workspace can be downloaded. Lovable-built skills are read-only and managed by Lovable. # Storage Source: https://docs.lovable.dev/features/storage Store and manage your app's files in Lovable Cloud: create buckets, upload and organize files, and control public access. Lovable Cloud storage holds the files your app works with: profile photos, documents, videos, and other uploads. Describe what files should go where, and Lovable creates the buckets, wires up the upload flows, and controls access. For example, tell Lovable: ```text wrap theme={null} Add a contract upload field to each deal. Let clients have profile pictures and display them on the client detail page. Upload invoice PDFs and show a download link on the invoices table. ``` The **Storage** view lets you browse and manage those files directly. To open it, go to **Cloud tab → Storage**. ## Buckets Files are organized into buckets. Each bucket card shows its name, when it was last updated, and whether it is **Private** or **Public**: * **Private** (the default): files are only accessible by users with the correct permissions, controlled by [row level security policies](/features/database#row-level-security-rls-policies). * **Public**: files are accessible by anyone with the URL. **Public storage buckets are blocked by default on all plans.** This prevents users from creating publicly accessible storage buckets in Lovable Cloud. Workspace owners and admins on all plans can disable this in [Privacy & security](https://lovable.dev/settings/privacy-security). See [Block public storage buckets](/features/privacy-and-security-settings#block-public-storage-buckets) for details. To create a bucket yourself, click **New bucket**. Bucket names use lowercase letters, numbers, and hyphens only, must be 3 to 63 characters, and cannot be changed after creation. To delete a bucket, use the delete icon on its card. A bucket must be empty before it can be deleted, and deleting cannot be undone. ## Browse and manage files Open a bucket to browse its contents as folders and files, with each item's size, type, and last-modified date. * **Upload**: add one or more files, or drag and drop them into the bucket. * **Create folder**: folder names allow letters, numbers, dots, hyphens, and underscores. * **Rename** or **Delete** a file or folder from its row menu. Folders can only be deleted when they are empty, and deleting cannot be undone. * **Download**: select one or more items and download them. Multiple files download as a zip archive. Files in private buckets are downloaded through temporary signed links. Click a file to open its details, with a preview for images, video, and audio, its size and timestamps, and a **Copy URL** button. For public buckets this copies a permanent public URL. For private buckets it copies a temporary signed URL that expires after one hour. ## Limits Files up to **2 GB** are supported. ## FAQ Public buckets are blocked by default on all plans by the workspace setting **Block public storage buckets**. A workspace owner or admin can turn the block off in [Privacy & security](https://lovable.dev/settings/privacy-security). For most apps, keeping buckets private and letting your app serve files through signed URLs is the safer choice. Use **Copy URL** in the file's details to get a temporary signed URL, which expires after one hour. For permanent sharing, ask Lovable to build the sharing flow into your app, or store the file in a public bucket. No. Storage usage continues while a project is paused because your files stay in place. To stop storage usage entirely, download your files and [remove Lovable Cloud](/features/advanced-settings#remove-lovable-cloud) from the project. No. Database exports cover schema and table data only. Download storage files separately from the Storage view before migrating or removing Cloud. # Subagents Source: https://docs.lovable.dev/features/subagents Subagents help Lovable investigate complex tasks faster by splitting research, code exploration, and review into focused investigations. When a task needs more investigation, Lovable can start temporary, read-only subagents to research, inspect, or review focused parts of the work. Each subagent works independently and, when useful, Lovable can run several in parallel. Subagents report their findings back to the main Lovable agent. The main agent uses those findings to decide what to do next, continue building, or explain the result. Subagents can inform the work, but they cannot change your project. All file changes still come from the main Lovable agent. You do not need to configure subagents or choose when they run. Lovable decides when subagents are useful based on your request. ## Why subagents help Large requests often need a lot of investigation before Lovable can act confidently. This matters most on larger projects, where a change may depend on many files, features, and connected flows. The chat can quickly fill with file contents, search results, logs, stack traces, implementation notes, and abandoned paths. That extra material can make the important parts harder to track. Subagents keep that work contained. Instead of bringing every intermediate detail into the chat, Lovable can delegate focused investigations and return only the useful findings. This can make larger builds feel faster because Lovable can complete discovery work in parallel before deciding what to change. This helps in three ways: * **Cleaner context**: Requirements, decisions, and next steps stay easier to follow. * **Parallel progress**: Independent questions can be investigated at the same time instead of one after another. * **More focused results**: Each subagent works on a bounded question with fresh context, which helps it return sharper findings. ## Subagent types Lovable has two kinds of subagents you may see appear in the activity card in chat. Both investigate focused questions. The difference is the kind of result Lovable needs. * **Generic subagents** are useful when Lovable needs the findings in a specific shape, such as a comparison, checklist, summary, review, or recommendation. Their card title describes the task they are working on, such as `Check how notifications are implemented` * **Explore** is useful when the answer needs traceable evidence, such as when you ask how something works, where something is handled, or why something behaves a certain way. Explore uses the most capable model available and follows a structured research process. For example, its card title could be `Explore: How does the current authentication flow work?` ## How subagents work Subagents can search your project, inspect files, run read-only lookups, browse the web when needed, review work against your prompt, and return findings to Lovable. They cannot edit, create, delete files, or make any changes to your project. Subagents start with fresh context. They do not automatically see the full chat, previous messages, or everything Lovable has already read. Each subagent only knows what Lovable passes into its task briefing, such as the question to investigate, relevant project context, file paths, or constraints. When Lovable starts subagents, an activity card appears in the chat. You'll see subagent rows appear in the activity card showing what the subagents are investigating and their current status. Open the activity card to see more detail about what the subagents did, including files they inspected, searches they ran, tools they used, and findings they returned. This helps you understand where Lovable’s conclusions came from. When a subagent finishes, Lovable receives its findings automatically. Subagents do not coordinate directly with each other. Each one reports back to Lovable, and the main agent combines the findings before deciding what to do next. If you asked for research or investigation, Lovable will typically surface what the subagent found. If you asked Lovable to build something, it may use the findings quietly and continue building without a separate summary. ## Prompting Lovable to use subagents To encourage Lovable to delegate investigation work, mention subagents in your prompt and describe what you want investigated. This works best when the request has multiple parts, needs project exploration, or benefits from research before building. Lovable will still decide whether to use subagents based on the task. Use this when you want Lovable to inspect a project and explain how it works before making changes. For example: ```text wrap theme={null} Use subagents to explore my project and explain how it is structured. I have not touched this app in a while and want to understand the main pages, data flow, and important files before making changes. ``` Use this when you want Lovable to research best practices or implementation options before changing the app. For example: ```text wrap theme={null} Use subagents to help me redo my pricing page. Research what makes a strong pricing page, inspect my current page, and recommend what should change before building. ``` Use this when you want Lovable to inspect connected parts of the app and identify likely causes. For example: ```text wrap theme={null} Use subagents to investigate why my dashboard is sometimes slow. Look through the dashboard and anything connected to it, then tell me what might be causing the slowdown and how to improve it. ``` Use this when you want Lovable to assess the scope of a bigger feature before you commit to building it. For example: ```text wrap theme={null} Use subagents to help me plan adding comments and likes. Research how social features are usually built, inspect where they would fit in my app, and explain what I would be signing up for before I start. ``` ## FAQ No. Keep using Lovable the same way. Lovable decides when subagents can help. To encourage Lovable to use subagents, mention subagents in your prompt and describe what you want investigated. This does not guarantee subagents will be used, but it helps Lovable understand that you want the work split into focused investigations. No. Subagents are read-only at the moment. They can search, inspect, research, and review, but they cannot create, edit, or delete files. All project changes come from the main Lovable agent. Yes. When a request has several independent parts, Lovable can run multiple subagents in parallel. Subagents consume model usage like other agent work. Lovable routes routine research and lookups to lighter models where appropriate, which helps keep usage efficient. Yes. Subagents are part of how Lovable works and do not require any setup. # Test and verify your app Source: https://docs.lovable.dev/features/testing Lovable provides browser testing, frontend tests, and edge function verification to help understand system behavior, validate user workflows, and ensure backend logic works as expected. Lovable gives you several ways to check that your application behaves as expected. These tools help you reproduce issues, confirm fixes, and avoid regressions across frontend and backend behavior. **Choose the right test** If you are not sure which testing tool to use, start with the kind of behavior you want to verify. * If the issue is visible to users, use browser testing. * If UI behavior should stay correct over time, use frontend tests. * If the issue is in backend logic, call the edge function directly, then add an edge test. ## What Lovable can observe during verification Lovable collects information when the agent runs verification tools. This information is gathered automatically as part of those tools and is used to understand what is happening in your app. Lovable can capture: * browser console logs during browser testing * network requests made during browser testing * test failures and build errors from test runs * request and response data when calling backend functions directly These signals are available whenever the relevant tools are used and are often enough to diagnose issues without additional manual debugging. Lovable supports several testing approaches, each designed for a different kind of verification. Most tests fall into one of two categories: * checking complete user flows * checking specific rules or behaviors in isolation ## Browser testing [Browser testing](/features/browser-testing) checks real user behavior by interacting with your app in a browser. The agent can navigate pages, click buttons, fill forms, and submit requests. While doing so, it can capture screenshots, inspect UI elements, and observe console and network activity. Use browser testing when: * someone reports broken or unexpected UI behavior * you need to check a multi-step flow such as onboarding or checkout * the issue may depend on routing, authentication, timing, or state * you want to confirm changes from a user’s point of view Browser testing is slower than other methods, but it gives the clearest picture of what a user actually experiences. Browser testing may be started by the agent during investigation. You can also request it explicitly. **Example** ```text wrap theme={null} Use browser testing to verify the checkout flow. ``` ## Frontend tests Frontend tests verify UI behavior in isolation using clear assertions. They are useful for ensuring that specific UI logic continues to work as expected over time. Frontend tests run in a simulated browser environment, run quickly and give consistent results, and usually live next to components as `.test.tsx` files. **Test stack** * Vitest * React Testing Library * jsdom Use frontend tests when: * the issue can be described as a clear rule or expectation * you are fixing a UI regression and want to prevent it from coming back * you are working with conditional rendering or complex state such as forms, tables, and filters * you want fast feedback without running the full app Frontend tests run only when requested. **Example** ```text wrap theme={null} Write and run frontend tests for the login form. ``` ## Backend verification with edge functions Lovable provides two complementary ways to verify backend behavior in edge functions: direct calls and automated tests. These approaches are often used together. ### Direct edge function calls Direct calls let the agent run an edge function with specific inputs and inspect the result immediately. This avoids UI-related complexity and is useful for quick isolation. If you are logged in, authenticated calls can use your current session. Use direct calls when: * you suspect a backend issue and want to separate it from the UI * you need to check specific parameters or inputs * you want to compare behavior before and after a change * you are debugging authenticated behavior Direct edge function calls run only when requested. **Example** ```text wrap theme={null} Call the signup edge function directly with an invalid email. ``` ### Edge tests Edge tests are automated tests that check backend rules over time. They help ensure that important logic does not break silently. **Test stack** * Deno built-in test runner * Native TypeScript support Use edge tests when: * you change an edge function and want regression protection * you are validating business rules or permissions * the issue is subtle and hard to verify manually Edge tests run only when requested. **Example** ```text wrap theme={null} Write edge tests for the payment processing function. ``` ### How backend verification tools work together Direct calls and edge tests are often used together when debugging backend behavior. A common sequence looks like this: 1. Call the edge function directly to reproduce the issue with a specific input. 2. Apply the fix once the behavior is understood. 3. Call the function again with the same input to confirm the change. 4. Add an edge test to ensure the behavior does not regress over time. This approach keeps iteration fast while still providing long-term verification. ## FAQ No. Most issues can be understood and verified using a single tool. Browser testing is useful for user-visible problems, frontend tests help lock down specific UI behavior, and backend verification is best for business logic. Choose the tool that matches the type of issue you are investigating. When an issue does not resolve after a few attempts, you can ask Lovable to use multiple verification tools. Lovable runs these tools and uses their output to guide the next step. * Reviewing logs or test failures from earlier runs often helps narrow down the cause. * Backend issues are usually easiest to isolate by calling the edge function directly. * User-facing issues are best explored with browser testing. * Once the behavior is understood, adding automated tests helps keep it stable over time. If the issue still does not resolve, revert to the latest stable version. Most verification tools run only when you ask for them. In some cases, the agent may suggest or initiate a tool during investigation, but verification does not run silently in the background. # Transfer a domain to Lovable Source: https://docs.lovable.dev/features/transfer-domain Move a domain from another registrar to Lovable, so Lovable becomes your domain registrar. A domain transfer moves a domain you already own from another registrar into Lovable. After the transfer completes, **Lovable becomes the registrar for that domain**, so its renewals, registration details, DNS records, and connected Lovable projects all live in one place. The domain name stays the same, your website keeps working, and any email or other services tied to the domain continue to function as long as the underlying DNS records are carried over correctly. Lovable can automatically carry over common DNS records, keep existing Lovable subdomain connections intact, and handle annual renewal so your domain does not expire unexpectedly. Transfer a domain when you want an existing domain to live fully in Lovable. If you only want to point an existing domain to a Lovable project while keeping it with your current registrar, [connect a domain from another provider](/features/custom-domain#connect-a-domain-from-another-provider) instead. If you want a new domain you do not already own, [buy a domain through Lovable](/features/custom-domain#buy-a-domain-through-lovable). ## Prerequisites * You need to be on a **paid plan** to transfer a domain into Lovable. * You need to be a workspace **owner** or **admin** to transfer a domain into Lovable. * **You have a copy of your current DNS records.**\ Lovable tries to detect and carry over the DNS records your domain already uses, but the scan may not catch everything. Before you transfer, note your current records at your registrar so you can confirm they came across, or add anything missing, in **Workspace settings → Workspace domains** after the transfer completes. * Your domain must meet the following requirements. Lovable checks each one during setup and tells you what to fix if anything is blocking the transfer. * **The domain is at least 60 days old.**\ [ICANN](https://www.icann.org/) policy prevents transferring a domain that was registered or last transferred less than 60 days ago. Lovable shows the date the domain becomes transferable. * **The domain is unlocked.**\ Disable the transfer lock (sometimes called **domain lock** or **registrar lock**) at your current registrar. * **DNSSEC is disabled.**\ If DNSSEC is enabled at your current registrar, disable it before transferring and wait up to 24 hours for the change to propagate. DNSSEC still being active is one of the most common causes of transfer failures. * **You have the authorization code.**\ Also called an **EPP code** or **transfer code**, this is a one-time security code your current registrar issues to authorize the transfer. Get it from your current registrar's domain settings or their support. * **You're transferring the root domain.**\ Subdomains cannot be transferred. Enter the root domain (for example, `example.com`, not `blog.example.com`). ## How transfers work A domain transfer has three phases: 1. **Eligibility check.** Lovable checks whether the domain can be transferred. This includes confirming that the domain extension is supported, checking the domain’s age and lock status, looking for DNSSEC, and making sure another transfer is not already in progress for the same domain. 2. **Submission and waiting.** Lovable submits the transfer using the authorization code you provide. Your current registrar may take several days to release the domain. Lovable keeps checking the transfer status while the release is pending. 3. **Completion.** Once the transfer is approved, Lovable becomes the registrar for the domain. Lovable then updates the nameservers, applies the DNS records you chose to carry over, reconnects any existing Lovable projects already using subdomains of this domain, and saves the registrant contact details you provided. During the waiting phase, your domain keeps working as it did before. DNS records continue to resolve from your current registrar until the transfer is complete. Lovable only updates the nameservers at the end, once the transfer is finalized. ## Transfer a domain Go to **Workspace settings → Workspace domains** and click **Transfer in**. Enter the root domain you want to transfer (for example, `example.com`) and click **Check**. Wait while Lovable checks whether the domain can be transferred. If the domain is eligible, Lovable shows the transfer price, the renewal price, and whether the transfer is paid or free. * Most paid transfers include a one-time transfer fee that adds one year of registration to your domain, as required by ICANN. * The annual renewal price is shown separately and applies when the domain renews, not during the transfer. If something is blocking the transfer, Lovable tells you what to fix. Make the change at your current registrar, then click **Check** again to retry. Paste the **authorization code** (EPP code) you got from your current registrar. Fill in the registration contact details required for the domain. Some domain extensions require additional fields. [WHOIS privacy protection](https://en.wikipedia.org/wiki/Domain_privacy) is enabled automatically for domain extensions that support it.  Lovable shows the existing DNS records it found for your domain, including A, AAAA, CNAME, MX, TXT, CAA, and NS records. All auto-detected DNS records are selected by default. Deselect any you don't want to carry over. The selected records are saved to this transfer attempt and recreated in Lovable’s DNS once the transfer completes. Detection is best-effort, but you can add anything missing after the transfer. **Auto-renew** is enabled by default and recommended. When enabled, your domain renews automatically before it expires at the renewal price shown. This applies after the transfer completes. Click **Continue**. If there's a fee, complete the checkout to pay it. The domain then appears in your **Workspace domains** list with a **Transferring** status. Transfers from another registrar usually take **5 to 7 days**, because of registry and ICANN processing rules. Free transfers usually complete within minutes. You can follow the progress in your **Workspace domains** list. ## Transfer statuses While a transfer is in progress, the domain shows one of these statuses in **Workspace domains**. | Status | Description | User action | | :----------------------------- | :----------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------ | | **Transferring** | The transfer is in progress with the registry. | No action required. Wait for it to complete. If available, you can cancel from the domain details page. | | **Action needed** | The transfer is blocked and needs your attention. Lovable shows the specific reason. | See [Troubleshooting](#troubleshooting) for the reason shown and what to do. | | **Canceling transfer** | You requested to cancel the transfer. | No action required. This may take a few minutes. | | **Transfer canceled** | The transfer was canceled and your purchase was refunded. | None. You can start a new transfer if you want. | | **Transfer failed — refunded** | The transfer could not be completed and you've been refunded. | Click **Retry transfer** to try again with a fresh authorization code. | | **Transfer failed** | The transfer could not be completed and needs support to resolve. | [Contact Lovable support](https://lovable.dev/support). | | **DNS needs attention** | The domain transferred successfully, but its DNS setup didn't complete. | [Contact Lovable support](https://lovable.dev/support). | ## Cancel a transfer You can cancel a transfer while it's in progress. Open the domain from your **Workspace domains** list and click **Cancel transfer**. * If the transfer has not yet completed at the registry, the cancellation goes through and you'll receive a refund. * If the transfer has already completed at the registry, the domain stays in your account and cannot be refunded. * Free transfers complete in a single step and cannot be canceled. ## After the transfer completes When the transfer completes successfully, the domain becomes a registered Lovable domain in your workspace, the same as a [domain bought through Lovable](/features/custom-domain#manage-workspace-domains-bought-through-lovable). You can manage renewals, edit registration details, and update DNS records from **Workspace settings → Workspace domains**. At completion, Lovable updates the domain’s nameservers and applies the DNS records you chose to carry over. Because the setup scan can't catch everything, you should always check your records in **Workspace settings → Workspace domains** after the transfer and add anything that's missing. If any Lovable projects in your workspace were already published on subdomains of this domain, Lovable automatically reconnects them. If the domain was not connected to a Lovable project before the transfer, connect it from the project’s domain settings after the transfer completes. ### Connect a transferred domain to a project A transferred domain is not connected to a project automatically unless it was already connected to a Lovable project before the transfer. To use a newly transferred domain on a project, connect it from the project’s domain settings or from the publish dialog. * Open **Project settings → Domains**, then click **Connect domain**, or * Open the publish dialog and click **Add custom domain**. In the **Connect a domain** dialog, enter the domain you want to use, for example, `example.com` or `app.example.com` and click **Continue**. Lovable detects that the domain belongs to your workspace and shows a **Your domain** badge. In **Configure connection**, choose how to connect the domain: * Select **Root domain** to connect the domain itself, for example, `example.com`. Choose whether to redirect `www.example.com` to `example.com`. * Select **Subdomain** to connect a subdomain, for example, `app.example.com`. Review the **Will be connected as** summary. Click **Connect domain**. Because Lovable manages this domain, the DNS records are created for you automatically, so there's no manual DNS setup. ## Limitations * Domain extension (TLD) availability for transfer varies, and premium domains are not supported for transfer. * Up to 25 connected subdomain projects are automatically reconnected after the transfer. ## FAQ Transfers from another registrar usually take **5 to 7 days**, because of registry and ICANN processing rules. You can follow the progress in your **Workspace domains** list. Some registrars let you approve the transfer on their side, which can speed it up. Some domains can be transferred for free and complete within minutes. Usually, yes. After you enter your domain, Lovable shows the transfer price before you pay. Some domains can be transferred for free. For most domains, the transfer fee includes one additional year of registration, as required by ICANN. For example, if your domain currently expires on December 1, 2026, transferring it adds a year and the new expiry is December 1, 2027. The annual renewal price is shown separately and only applies when your domain renews. The authorization code (also called an **EPP code** or **transfer code**) is issued by your current registrar. Find it in your current registrar's domain settings, or request it from their support. It's a one-time security code that authorizes the transfer. **During the transfer**, nothing changes. Your domain keeps resolving through your current provider, so your site and email keep working until the transfer completes. **After the transfer completes**, Lovable moves your domain onto its own nameservers and recreates the DNS records you kept during setup. If your domain was already connected to a Lovable project, that connection carries over, so your site keeps serving. If it isn't connected to a project yet, [connect it to one](#connect-a-transferred-domain-to-a-project) to serve your site. When you start a transfer, Lovable checks your current DNS zone for the records most websites and email services rely on, including A, AAAA, CNAME, MX, TXT, CAA, and NS records. Before checkout, you choose which detected records to carry over. The records you keep are saved to that transfer attempt and applied to your new DNS zone once the transfer completes and Lovable updates the domain’s nameservers. Until then, your domain continues to use DNS from your current registrar, so your website, email, and other services can keep working during the waiting period. If any Lovable projects in your workspace are already published on subdomains of the domain being transferred, Lovable automatically adds records to keep them connected after the nameserver update. Up to 25 subdomains can be reconnected this way. DNS detection is best-effort. If your current DNS zone is slow to respond or your provider rate-limits requests, some records may be missed. After the transfer, check your records in **Workspace settings → Workspace domains** and add anything that's missing. You start each transfer individually. There is no bulk transfer flow. Yes, once the 60-day post-transfer lock expires. Contact your future registrar to request the transfer. Lovable will issue an authorization code from the domain detail page. See [transfer a domain to another registrar](/features/custom-domain#how-do-i-transfer-a-domain-bought-through-lovable-to-another-registrar) for more information. ## Troubleshooting Log in to your current registrar, find the domain in its dashboard, and disable the transfer lock (also called domain lock or registrar lock). The setting is sometimes under security or privacy settings. When unlocked, click **Check again** in the transfer flow in Lovable. The domain was registered or transferred less than 60 days ago. ICANN does not allow transfers during this period. Lovable shows the date when the domain becomes transferable. Wait until that date and try again. Disable DNSSEC at your current registrar. Wait up to 24 hours for the change to propagate, then click **Check again** in the transfer flow in Lovable. A transfer that needs attention shows one of these reasons: * **The transfer code was rejected.** Cancel this transfer and start a new one using the correct authorization code from your current registrar. * **Your current registrar has the domain locked.** Unlock it there and Lovable keeps retrying automatically. * **Your current registrar refused the transfer.** Check with them, or cancel and retry. * **The transfer is taking longer than usual.** Lovable keeps checking with the registry. [Contact Lovable support](https://lovable.dev/support) if it persists. Each domain can have only one transfer or registration in progress at a time. Open it from your **Workspace domains** list to see its status. If an attempt may still be in progress, check back in a few minutes. If you believe this is a mistake, [contact Lovable support](https://lovable.dev/support). # Usage and costs Source: https://docs.lovable.dev/features/usage-and-costs See what drives your Lovable Cloud project's run credit usage, category by category, and how monthly Cloud and AI grants work. Every Cloud project consumes **Run credits** while its deployed app runs: database work, AI calls, file storage, network traffic, and backend compute. The **Usage** view shows exactly what a project consumes, so you can see what drives spend before adjusting anything. To open it, go to **Cloud tab → Usage**. Access follows your workspace role, not your project role: workspace owners can always open the view, and workspace admins can on paid plans. On workspaces that haven't moved to unified billing yet, the view is visible to everyone who can open the project. ## The Usage view The Usage view shows the project's run credit usage: a chart of the credits its deployed app uses per day, with a total for the selected time range. It is the same breakdown you get from **Settings → Plans & credit usage → Usage details** by selecting **Run credits**, already filtered to the project. See [Cloud costs](/introduction/credits-and-usage#cloud-costs) for what drives this usage. The time range defaults to **Last 30 days**. You can switch to **Last 90 days** or pick a custom range of up to 90 days. Run credit usage may not appear immediately after your app is used. Below the chart, usage is broken down by category, sorted from highest to lowest: * **Database**: storing and working with your app's data, such as users, orders, and messages. Split into **Database server**, the work of reading and saving that data, and **Database storage**, the amount of data your database stores. Larger [instance sizes](/features/advanced-settings#upgrade-instance) support more traffic but use more credits. * **AI**: AI features in your app, such as chat or image generation, broken down by model. * **Compute**: your app's code running behind the scenes, such as processing payments or sending emails. * **Network**: data sent or received by your app, such as API responses, downloads, uploads, images, and media. * **Storage**: uploaded or generated files your app stores, such as images, documents, and videos. * **Realtime**: live updates sent through your app, such as chat messages, notifications, or collaborative updates. The number next to each category shows how many credits it used in the selected time range. For example, if **Compute** shows 1.6, then 1.6 credits of your Cloud spend in that period came from compute usage. Use the breakdown to see which resources drive the project's Cloud spend, for example before [resizing your instance](/features/advanced-settings#upgrade-instance) or [fixing slow queries](/features/database#find-and-fix-database-performance-problems). ## Monthly grants **Temporary offering, subject to change:** Free, Pro, and Business workspaces receive a **20-credit monthly Cloud grant** for Lovable Cloud usage and a **4-credit monthly AI grant** for AI gateway usage in deployed apps. On Free plans, monthly Cloud and AI grants reset on the 1st of each calendar month at **00:00 UTC** and do not roll over. On Pro and Business plans, the monthly Cloud and AI grants refresh with the subscription billing cycle and do not roll over. For details about Cloud and AI gateway usage costs, top-ups, auto top-up, alerts, and usage tracking, see [Credits and usage](/introduction/credits-and-usage). ## What drives Cloud usage Cloud usage usually increases when more people visit your app or when it stores more data and files. Larger uploads and downloads, more API responses and media, more background code, and more Realtime messages all add usage too. | Usage driver | What affects cost | | :--------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Database server | The instance size your database runs on, how long it stays active, and how much traffic or querying it handles. See [Upgrade instance](/features/advanced-settings#upgrade-instance). | | Database storage | The amount of data your database stores, such as users, orders, messages, and app records | | Network | Data sent or received by your app, such as API responses, downloads, uploads, images, and media | | Storage | The amount of uploaded or generated files your app stores, such as images, documents, and videos | | Compute | Your app's code running behind the scenes, such as processing payments or sending emails | | Realtime | Live updates sent through your app, such as chat messages, notifications, or collaborative updates | ## What drives AI usage AI gateway usage is measured when AI features inside your deployed app make model calls. These requests are separate from the Lovable agent that helps you plan, build, and edit your project. Each model call deducts credits based on the model used and the number of tokens processed. | Usage driver | What affects cost | | :------------ | :--------------------------------------------------------------------------------------------------------------------- | | Model choice | More capable models usually cost more than smaller or faster models | | Input tokens | Longer prompts, documents, chat history, or retrieved context increase usage | | Output tokens | Longer AI responses increase usage | | Call volume | More users or more frequent AI actions create more model calls | | Feature type | Chatbots, document question answering, image generation, embeddings, and automations can have different usage patterns | AI gateway usage rates are based on the underlying provider model costs. See [AI features for your app](/features/ai) and the [supported model list](/features/ai#supported-models-for-ai-features-in-your-app). ## Reduce a project's Cloud usage If a project uses more credits than it should, work through these in order of impact: * **Pause the project's Cloud backend** when it isn't actively used, from **Cloud tab → Overview → Advanced settings**. Lovable also pauses Cloud projects automatically after a period of inactivity, so manual pausing mainly helps for projects with scheduled jobs or other background activity. See [Pause Cloud](/features/advanced-settings#pause-cloud). * **Right-size your instance**. A larger instance uses more credits per hour while your app runs. On paid plans, review and change the instance size from **Cloud tab → Overview → Advanced settings**. See [Upgrade instance](/features/advanced-settings#upgrade-instance). * **Fix slow database queries** so your database does less work per request. Ask Lovable in chat to find and optimize the slowest queries. See [Find and fix database performance problems](/features/database#find-and-fix-database-performance-problems). * **Remove unused files** from [storage](/features/storage), since stored files continue to use credits, including while a project is paused. * **Review [Jobs](/features/jobs)**: frequent or long-running scheduled jobs add up. * **Remove Lovable Cloud** from projects that don't need a backend at all. This stops all Cloud usage for the project, but it permanently deletes the project's Cloud data, so export anything you need first. See [Remove Lovable Cloud](/features/advanced-settings#remove-lovable-cloud). Per-member credit limits apply to build credits only. Cloud and AI usage from deployed apps does not count against a member's monthly credit limit. See [Credits and usage](/introduction/credits-and-usage). ## FAQ Yes. Lovable uses one credit balance for building your app, hosting and running it with Lovable Cloud, and AI features in deployed apps. Cloud and AI gateway usage are shown as **Run credits** in **Settings → Plans & credit usage → Usage details**. * **Cloud usage** covers Lovable Cloud infrastructure resources used by deployed apps, such as database, network, storage, Edge Functions, and Realtime. * **AI gateway usage** covers AI features inside deployed apps, such as model calls made by your app. For more information, see [Credits and usage](/introduction/credits-and-usage). Yes. Lovable gives you several ways to control credit usage and top-up charges. * **Add credits manually:** On Pro and Business plans, workspace owners and admins can buy one-time top-ups when more credits are needed. * **Use auto top-up:** On Pro and Business plans, workspace owners and admins can enable auto top-up so Lovable automatically adds credits when the workspace balance reaches or falls below a threshold you set. You can also set a monthly spend limit to control how many credits auto top-up can add in a calendar month. To manage credits, top-ups, and auto top-up, go to **Settings → Plans & credit usage**. For more information, see [Credits and usage](/introduction/credits-and-usage). AI gateway usage rates are based on the underlying provider model costs. AI gateway usage is charged in credits based on the model used and the number of tokens processed. To estimate relative model costs, refer to the official provider pricing sources linked from the [supported model list](/features/ai#supported-models-for-ai-features-in-your-app). Go to **Settings → Plans & credit usage → Usage details**. You can filter by project across **All credits**, **Build credits**, and **Run credits**. Use **Run credits** to review Cloud and AI gateway usage by project. For more information, see [Tracking credit usage](/introduction/credits-and-usage#tracking-credit-usage). # Verify a domain for your workspace Source: https://docs.lovable.dev/features/verified-domains Prove ownership of your company's email domain with a DNS record to unlock SSO, automatic user provisioning, SCIM, and branded app URLs. Verified domains let you prove to Lovable that your organization owns an email domain, such as `acme.com`. Verification happens once, through a DNS record, and unlocks the identity and provisioning features that depend on knowing which users belong to your company. Once a domain is verified, Lovable can treat anyone signing in with an email on that domain (for example `jane@acme.com`) as a member of your organization, and apply your workspace's authentication and provisioning rules to them. * **Available on:** Business and Enterprise plans * **Access:** Workspace admins and owners * **Location:** [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity → Verified domains**) ## Why verify a domain You need at least one verified domain before you can use most workspace identity features: * **SSO**: connect a SAML or OIDC identity provider for your workspace. See [Set up workspace single sign-on (SSO)](/features/business/sso). * **Enforce SSO**: require all workspace members to sign in through your identity provider. * **Verified email sign-up**: automatically add users who sign up with an email on your verified domain to your workspace, with a default role you choose. No SSO needed. * **SSO sign-in provisioning**: automatically add users to your workspace the first time they sign in through your SSO provider. * **Add existing users**: a one-time action that adds existing Lovable users with verified-domain emails to your workspace. * **SCIM provisioning**: sync users and groups from your identity provider on the Enterprise plan. See [Set up SCIM user provisioning](/features/business/scim). * **Branded app URLs**: publish apps under a workspace subdomain derived from your verified domain. See [Publish apps with branded URLs](/features/branded-workspace-urls). The provisioning options above are configured on the same Identity tab. See [Manage workspace identity and user provisioning](/features/workspace-identity) for how they work and interact. ## Prerequisites * A workspace on the Business or Enterprise plan. * An owner or admin role in the workspace. * Access to your domain's DNS settings (through your DNS provider, such as Cloudflare, GoDaddy, or AWS Route 53). ## Verify a domain Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**), and under **Verified domains**, click **Add domain**. Enter your domain, for example `acme.com`. Wildcards are not supported. Lovable shows a DNS record to create. In your DNS provider, add a record with: | Setting | Value | | :-------- | :-------------------------------------------------------------------- | | Type | TXT | | Host/Name | `@` (some providers want this blank, or want the domain name itself) | | Value | The `lovable_verification=` token shown in the dialog, copied exactly | DNS changes can take anywhere from a few minutes to 72 hours, though most providers apply them within minutes. Back in Lovable, click **Verify domain**. When the check succeeds, you see a **Domain Verified!** confirmation, and the domain appears in your **Verified domains** list with a **Verified** badge. If this is the first domain you verify, Lovable automatically turns on **Verified email sign-up** with the default role set to editor, so colleagues who sign up with a company email join your workspace automatically. You can change the default role or turn this off under **User provisioning** on the same page. ## How domain verification works * **Verification is a one-time check.** Lovable checks the DNS record when you click **Verify domain**. Verified domains do not expire and are not re-checked later. * **You can verify multiple domains.** Add each domain your organization uses, for example `acme.com` and `acme.co.uk`. * **Verifying a domain does not reserve it.** Another workspace can verify the same domain. If your organization runs several workspaces, each one verifies the domain separately. * **Changes are audited.** Adding and removing verified domains is recorded in your workspace [audit logs](/features/audit-logs). ## Remove a verified domain 1. Go to [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**). 2. In the **Verified domains** list, click the trash icon next to the domain. 3. Confirm in the **Delete verified domain** dialog. Removing a domain disables SSO authentication for that domain. If you remove your **last** verified domain, Lovable also automatically turns off **Enforce SSO** and **Verified email sign-up**, since both depend on having a verified domain. To use the domain again, you must verify it again with a new DNS check. Removing a domain does not remove existing workspace members or end their sessions. Users who already joined through that domain keep their access. ## Troubleshooting The DNS record is not visible to Lovable yet. This usually means one of: * **The record has not propagated.** DNS changes can take up to 72 hours, though minutes is typical. Wait and try again. * **The record is on the wrong host.** The TXT record must be on the root of the domain (`@`), not on a subdomain like `www`. * **The value does not match.** The value must be the full `lovable_verification=` token exactly as shown, with no extra characters or quotes added by your DNS provider. Lovable could not query DNS for the domain at all. Check that the domain is spelled correctly and is a real, registered domain with active DNS. The domain is already in your workspace's verified list. You do not need to do anything. ## FAQ Yes. Verifying a domain is the first step of SSO setup, and the SSO configuration flow walks you through it if you have not done it yet. No. Lovable checks the DNS record once, when you click **Verify domain**. A verified domain stays verified until you remove it from your workspace. Verification is checked once, so removing the record does not un-verify the domain. Keeping the record in place is recommended so you can verify again easily if you ever remove and re-add the domain. Yes. Verification proves ownership to a workspace; it does not claim the domain exclusively. If your organization runs several workspaces, each one verifies the domain separately and configures its own identity settings. Nothing immediately. Existing members keep their access and their sessions stay active. The domain stops working for SSO sign-in, and if it was your last verified domain, **Enforce SSO** and **Verified email sign-up** turn off automatically. Workspaces with SSO can additionally restrict account creation on a verified domain so new users must start through the SSO flow instead of email/password or social login. Contact [Lovable support](https://lovable.dev/support) to enable this restriction for your domain. # Lovable workspace Source: https://docs.lovable.dev/features/workspace Manage your team's projects, members, billing, and settings in one central place. A **workspace** is the central place where you and your team build apps together in Lovable. Every project lives inside a workspace, and every member collaborating with you accesses projects through a workspace. Think of it as your team's home base. It holds your projects, your people, your billing, and your settings in one place. A workspace is also how you buy Lovable for a group of people: one subscription funds a shared pool of credits, and everyone you invite builds from that pool while working on their own projects. When you sign up for Lovable, your first personal workspace is created automatically on the **free plan** with a 5 daily credit allowance. From there you can: * Invite others to join * Create projects * Upgrade your plan as your needs grow You can also create additional workspaces from the **workspace switcher** in the top-left corner of the dashboard. ## Workspace basics These are the key rules that define how workspaces function in Lovable. * **Projects belong to a workspace**\ All projects exist inside a workspace. * **A workspace is shared by a group of people**\ Invite as many people as you need into a single workspace to collaborate. Membership is unlimited on all plans, and plans are priced by credits, not seats, so adding members doesn't increase your subscription cost. Everyone in the workspace works from the same plan, credits, and settings. * **One workspace holds many projects**\ Each member can create and work on as many of their own projects as they want inside the shared workspace. Projects stay separate, but they all live under the same workspace. * **Pricing plans are workspace-level**\ Each workspace has its **own plan and billing**, on a single invoice. A paid subscription applies to **one workspace only**. To buy credits for a group of people, upgrade one workspace to a plan with enough credits and invite everyone into it. See [Subscription plans](/introduction/subscription-plans) for more information. * **Credits are shared across the workspace**\ All projects in a workspace draw from the workspace's shared credits. This applies regardless of which member or external collaborator sends messages. * **You can cap how many credits each member uses**\ Workspace owners and admins can set a [default monthly credit limit](/features/workspace-admin-settings#general-workspace-settings) that applies to every member, plus [per-member overrides](/features/people#set-a-per-member-credit-limit), so no single person can use up the shared credits. * **You can belong to multiple workspaces**\ A single Lovable account can be a member of multiple workspaces. You can switch between them at any time. ## Create a workspace Any logged-in user can create a workspace. 1. Open the **workspace switcher** (top-left of the dashboard) 2. Click **Create workspace** 3. Enter a name (up to 50 characters) 4. Click **Create** and set up your pricing plan ## Workspace setup Workspace **owners and admins** can configure settings, billing, and security options for their workspace under **Settings → Workspace**. See [Workspace admin settings](/features/workspace-admin-settings) for more information. ## Invite people to your workspace Workspace members are the people you collaborate with on projects in a workspace. The **People** tab is the central place to manage the people in your workspace. Every workspace member appears here, whether they joined by invitation, through SSO, via SCIM, or as an external collaborator on a specific project. Open it from **Settings → People**. Workspace **owners and admins** can invite members, change roles, remove members, approve workspace and project access requests, and export the workspace member list as CSV. You can also track per-member credit usage and set individual credit limits that override workspace defaults. See [People](/features/people) for more information. ## Join a workspace Once you have a Lovable account, there are several ways to join a workspace. ### Email invitation or invite link A workspace owner, admin, or editor sends you an invitation by email or sends you an invite link. If **auto-accept invitations** is enabled in your personal account settings, you are added to the workspace without needing to manually accept the invites. ### Find your team's workspace If you signed up with a **work email address**, Lovable can automatically surface workspaces that belong to your organization. This helps you join the correct workspace without needing a direct invitation. The flow is driven by **Workspace discovery**, which is a **Business and Enterprise** feature. The feature is available to accounts using **non-public email domains** (such as `@yourcompany.com`). Public domains like `@gmail.com` or `@hotmail.com` are not supported. **How to find a workspace:** 1. Open the **workspace switcher** (top-left of the dashboard) 2. Click **Find workspaces** at the bottom of the dropdown and Lovable will search for workspaces associated with your email domain 3. Select the workspace you want to join 4. Choose the role you want to request 5. Submit your request Workspace admins and owners will be notified and can **approve or deny your access**. If you do not belong to any workspace yet, this option also appears in the **No workspace** dialog shown after sign-up. ## Switch workspaces Open the **workspace switcher** in the top-left corner of the dashboard and click a workspace name to switch to it. ## Leave a workspace Any workspace member can leave a workspace they no longer want access to. You can leave from either of these locations: * **Settings → Workspace → Leave workspace** * **Settings → People**, then click the **three dots menu next to your row** and click **Leave workspace**. This path is not available to external collaborators as they do not see the People tab. External collaborators can only leave from **Settings → Workspace → Leave workspace.** ### When you can't leave * **You're the only owner.** Workspaces must always have at least one owner. Promote another member to owner first, then try again. Owners can promote from **Settings → People** by changing another member's role to owner. See [People](/features/people) for more information. * **It's your only workspace.** Every Lovable account must belong to at least one workspace. Join or create another workspace before leaving. ### What happens when you leave * Your workspace membership is removed immediately. You lose access to all projects in the workspace, including projects shared with you directly. Your work is not deleted. * Projects you owned are auto-transferred to the most senior remaining member of the workspace (owners first, then admins, then editors). Projects with access set to **Restricted** are not transferred automatically. You cannot pick which member inherits your projects. If you want a specific person to take over, transfer ownership manually from each [project's settings](/features/projects/settings#transfer-project-ownership) before you leave. * Your real-time presence is removed from any projects you had open. * The leave event is recorded in [Audit logs](/features/audit-logs) on Enterprise plans. * Lovable switches you to another workspace you belong to and returns you to the dashboard. To rejoin, ask a workspace admin or owner to invite you again, or use the **Find workspaces** flow if **Workspace discovery** is enabled and your email matches a [verified domain](/features/verified-domains). ## FAQ Workspaces support **unlimited members** on all plans. For Enterprise workspaces, custom member limits can optionally be set. Email invitations are limited per workspace each day: **5** on Free, **20** on Pro, **100** on Business, and no limit on Enterprise. Joining through an invite link does not count toward these limits. Invites can also be blocked with an "Invite was blocked due to suspicious activity" message by automated fraud checks. If you believe the block is a mistake, contact [Lovable Support](https://lovable.dev/support). Upgrade a single workspace to a paid plan sized for your group, then invite everyone into that workspace. All members build from the workspace's shared credits, on one subscription and one invoice. Each member can work on as many of their own projects as they want. To keep any one person from using up the shared credits, set a [default monthly credit limit](/features/workspace-admin-settings#general-workspace-settings) in Workspace settings and [per-member overrides](/features/people#set-a-per-member-credit-limit) from the People tab. This works the same for companies, classrooms, and communities. For large organizations, the [Enterprise plan](https://lovable.dev/pricing) offers volume-based credits. Neither. Workspaces support unlimited members on all plans, and plans are priced by the credits they include, not by seats. Inviting more members doesn't change your subscription cost; what changes is how quickly the group uses the workspace's shared credits. Yes. However, each workspace requires its **own subscription**. Yes. Go to the main dashboard and click your workspace name in the top-left corner. In the dropdown you will see the other workspaces you have access to. Select one to switch. Yes. Owners can promote other members to **owner**. A workspace can have **multiple owners**. Yes. You can move a project to another workspace from three places: * **Project settings → Move workspace**: click **Move**. * The project card menu on the [dashboard](/introduction/dashboard-overview): click **Transfer to workspace**. * Select multiple projects on the dashboard and click **Transfer** in the actions bar. Who can move a project: * **Workspace owners and admins** can move any project in the workspace. * The **project owner** can move their own project. On Enterprise plans, this requires the [Editor project transfers](/features/privacy-and-security-settings#editor-project-transfers) setting to be enabled. To move a project into a workspace, you need to be a member of that workspace with permission to create projects there. Moves can also be blocked with a "This transfer was blocked due to suspicious activity" message by automated fraud checks. If you believe the block is a mistake, contact [Lovable Support](https://lovable.dev/support). See [Move a project to another workspace](/features/projects/settings#move-a-project-to-another-workspace) for what changes when you move one. You can leave from either of these locations: * **Settings → Workspace → Leave workspace** * **Settings → People**, then click the **three dots menu next to your row** and click **Leave workspace**. This path is not available to external collaborators as they do not see the People tab. External collaborators can only leave from **Settings → Workspace → Leave workspace.** You cannot leave if you are the only owner of the workspace, or if it's your only workspace. See [Leave a workspace](/features/workspace#leave-a-workspace) for the full flow, including what happens to projects you owned. Yes. Workspace owners can delete a workspace from **Settings → Workspace → Delete workspace**. Members lose access immediately, and the workspace is permanently deleted after a 60-day grace period during which Lovable support can restore it. See [Delete a workspace](/introduction/delete-workspace) for the full flow. # Workspace admin settings Source: https://docs.lovable.dev/features/workspace-admin-settings Overview of settings available to workspace owners and admins, including workspace details, access and organization, templates, billing and usage, workspace domains, security and compliance, and development settings. Workspace admin settings are the central place where **workspace owners and admins** manage the workspace and keep it organized, secure, and aligned with how your team works in Lovable. Settings configured here take effect immediately, apply across the entire workspace, and define defaults for all members unless overridden at the project or member level. Open settings from your workspace avatar or by navigating to `/settings`, then use the sidebar to move between sections. To find a setting quickly, start typing in the **Search settings** box at the top of the settings sidebar. It filters the sidebar to matching sections and understands common synonyms, so `env` finds build secrets and `sso` finds identity. You can also press `Cmd+K` (Mac) or `Ctrl+K` (Windows/Linux) to open the [command palette](/introduction/project-search-and-find#command-palette) and jump straight to a settings section. The available options depend on your pricing plan. Features that are plan-specific are noted in each section below. ## General workspace settings Manage the core identity of your workspace, default usage limits that apply to all members unless overridden, and workspace-level publishing options. | **Setting** | **Description** | | :--------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Avatar** | A workspace icon shown next to the workspace name across the app, including the workspace switcher. | | **Name** | Your workspace display name (maximum 50 characters) shown throughout the interface. Useful for distinguishing teams or business units. | | **Workspace handle** | A unique public identifier used in workspace-related URLs, such as profile pages and shared projects.
*Note: Changing the handle may break existing links.* | | **Default monthly member credit limit** | The maximum number of credits each member can use per calendar month (UTC). Defaults to no limit.
Use this field to set a default amount of credits members of your workspace can use per calendar month. Limits reset on the 1st of each month at 00:00 UTC, independent of your workspace billing cycle. Leave empty to use **no limit**. You can override this value by setting individual limits in **Settings → People**. | | **Enable branded app URLs**
(Business and Enterprise) | Publish apps under a workspace-branded subdomain derived from your verified domain. See [**Publish apps with branded URLs**](/features/branded-workspace-urls) for more information. | | **Leave workspace** | Removes your own access to the workspace. You cannot leave if you are the only owner or if this is your only workspace. See [Leave a workspace](/features/workspace#leave-a-workspace) for more information. | | **Delete workspace** | Permanently deletes the workspace, all its projects, all member access, and cancels the workspace subscription. Only workspace owners can delete a workspace. There is a 60-day grace period during which Lovable support can restore the workspace. See [Delete a workspace](/introduction/delete-workspace) for more information. | ## Billing and usage Manage your subscription, credits, billing settings, and workspace usage from **Settings → Plans & credit usage**. Lovable uses credits to measure and pay for credit-based usage across your workspace, including building your app, hosting and running it with Lovable Cloud, and powering AI features in deployed apps. Workspace owners and admins can upgrade or downgrade plans, switch billing cycles, change credit tiers, add credits with one-time top-ups, enable auto top-up, buy gift cards, and manage billing history and payment settings. All other roles can open **Plans & credit usage** to see the current plan, credit balance, and usage, but billing controls are disabled for them. They cannot initiate or approve charges against the workspace. For more information, see [Subscription plans](/introduction/subscription-plans) and [Credits and usage](/introduction/credits-and-usage). ## Access Manage who has access to your workspace and how members are structured for collaboration. ### People The main place to manage workspace members. Workspace owners and admins can invite members, change roles, remove members, approve workspace and project access requests, and export the workspace member list as CSV. You can also track per-member credit usage and set individual credit limits that override workspace defaults. See [People](/features/people). ### Groups Organize members into groups to simplify sharing and access control. Groups can be granted access to projects, folders, and published apps as a unit, reducing the need to manage permissions individually. Groups can also be synced from your identity provider using [SCIM](/features/business/scim), so externally managed groups appear alongside manually created ones. Group-level roles control who can manage the group itself. Available on **Business and Enterprise** plans. See [Groups](/features/groups). ### Identity Manage workspace identity and single sign-on (SSO). Configure SAML or OIDC providers, enforce SSO, set session duration, and control how users authenticate. You can also verify your organization’s email domains which are used for SSO and user provisioning. Users can join your workspace automatically in three ways, controlled from the **User provisioning** section: through their first **SSO sign-in**, by signing up with an email on one of your verified domains (**Verified email sign-up**), or through **Add existing users**, which brings existing Lovable accounts on your verified domains into the workspace in one step. SCIM-based sync from your identity provider is configured separately. Provisioned users appear in the People tab, where you manage their roles and access. SCIM provisioning is available on **Enterprise** plans. All other features are available on **Business and Enterprise** plans. See [Workspace identity](/features/workspace-identity), [Verified domains](/features/verified-domains), [SSO](/features/business/sso), and [SCIM](/features/business/scim). ## Customization Standardize how projects are created and ensure consistency across teams. ### Knowledge Define workspace-level instructions and context that Lovable uses across all projects. This is useful for coding standards, architecture rules, preferred libraries, and other conventions that should stay consistent. Only workspace owners and admins can manage workspace knowledge. Project knowledge can add project-specific context and override workspace-level guidance when needed. See [Workspace and project knowledge](/features/knowledge). ### Skills Define reusable, on-demand instructions that Lovable can apply across projects in your workspace. Skills help teams standardize repeatable workflows, such as launch checks, support replies, release notes, and review processes, without adding those instructions to every message. Use skills for task-specific guidance that should load only when relevant. Use workspace knowledge for rules and context that should apply broadly across all projects. See [Define reusable instructions with skills](/features/skills). ### Templates Create reusable design templates from existing projects. Templates copy the full project codebase, including structure, components, styles, and configuration, so new projects start from a consistent foundation. You can set a default template for the workspace so all new projects begin with a predefined setup, while still allowing customization. Available on **Business and Enterprise** plans. See [Design templates](/features/business/design-templates). ### Design systems Define reusable component libraries, styling guidelines, and setup instructions that apply across projects. Unlike templates, design systems provide ongoing guidance during project generation rather than copying files at the start. Design systems are managed as projects and can be connected to one or more projects in the workspace. Updates to a design system are applied to connected projects on future generations. Available on **Enterprise plans** (may require enablement). See [Design systems](/features/design-systems). ## Build & deploy Manage shared configuration used during development and integrations with built-in or external services. ### Git Manage workspace-level Git connections for GitHub and GitLab. Git connections let projects sync their code to an external repository for backup, developer collaboration, local editing, and deployment outside Lovable. Workspace owners and admins can manage Git providers and connections at the workspace level. Projects can then be linked to repositories for two-way sync. GitLab also supports GitLab.com and self-managed GitLab instances. See [GitHub](/integrations/github) and [GitLab](/integrations/gitlab). ### Build secrets Store and manage environment variables used during project builds. Secrets are encrypted and available in sandbox environments, but their values are never exposed after being set. Use build secrets for tasks like installing private npm packages, accessing external APIs, or configuring build-time dependencies. Secrets are managed at the workspace level and can be used across projects. Available on **Enterprise** plans. ### Private registry Provide your workspace with its own npm registry, hosted privately inside Lovable. You can publish npm packages directly to it without making them public, and any project in your workspace can install those packages. Available on **Enterprise** plans only. See [Private registry](/features/private-registry). ### MCP server Connect AI clients and developer tools, such as ChatGPT, Claude, and Cursor, to Lovable through the Lovable MCP server. The tab shows the server URL, setup steps for common clients, and a **Manage access** shortcut to the workspace's **Third-party MCP clients** setting in **Settings → Security → Privacy & security**. Available on all plans. See [Lovable MCP server](/integrations/lovable-mcp-server). ### Workspace domains View and manage domains purchased through Lovable for your workspace. See all domains in one place, including their status, renewal details, and connected projects. Domains are managed at the workspace level and can be connected to projects or subdomains, reused across the workspace, and configured with built-in DNS records and registration details. Available on all **paid plans**. See [Custom domain](/features/custom-domain). ## Security Configure workspace-wide security policies, authentication, and visibility, and monitor overall security posture. ### Privacy and security The main control panel for workspace-wide security and access settings. Configure default project and website access, publishing permissions, preview links, and sharing rules across the workspace. You can also control workspace invites, workspace discovery, and external collaborator access, as well as MCP (model context protocol) server access, data collection (including opt-out), auto-fix defaults for eligible security findings, and security scanning policies that gate when projects can be published. See [Privacy and security](/features/privacy-and-security-settings). ### Security center A workspace-wide security dashboard for monitoring risks across all projects. View security scan results, dependency vulnerabilities, secrets usage, authentication policies, and project-level risk signals in one place. Use the Security center to identify and prioritize issues, track scan coverage, compare security status across projects, filter and export data, and trigger security scans without opening individual projects. Security center includes: * **Code analysis**, **Supply chain security**, and **Secrets overview** for reviewing security findings, dependency vulnerabilities, and secrets across the workspace. * [Workspace insights](/features/workspace-insights) for a portfolio-level view of project risk, including review priority, publish status, ownership, activity, sensitive data findings, security findings, and credit usage. Available on Enterprise plans. * **Schedule security scans** for automatically running recurring Deep scans across workspace projects. Available on Enterprise plans. Security center is available on Business and Enterprise plans. Some tabs and features, including Workspace insights and Schedule security scans, are available only on Enterprise plans. See [Security center](/features/security-center). ### Audit logs View a searchable record of activity across your workspace, including who performed an action, when it occurred, what changed, and which resource was affected. Use audit logs to review membership and access changes, project activity, authentication events, and workspace configuration updates. You can filter logs by member, action, resource, and time range, and expand entries to inspect detailed event data. Available on **Enterprise** plans. See [Audit logs](/features/audit-logs). ## Connectors Manage how your workspace connects to external tools, services, and APIs. App connectors add capabilities to deployed apps, while chat connectors (MCP servers) provide context during app creation. App connectors are managed from **Connectors → App connectors** and are configured once at the workspace level. Who can create connections depends on your plan: * On Free and Pro plans, any workspace member with the editor role or higher can create connections. * On Business and Enterprise plans, workspace owners and admins can choose whether each connector is disabled, enabled for admins only, or enabled for editors and admins. On Business plans, connectors are enabled for admins only by default. On Enterprise plans, connectors are disabled by default. Access is also managed per connection. When creating a connection, you can keep it private, invite specific workspace members, or invite the entire workspace. Only workspace members with access to a connection can link it to a project, view or collaborate on projects that use it, and use the connection’s associated data. Connection access is enforced while building and collaborating in Lovable, but not after publishing. See [Lovable integrations: Connect tools, MCP servers, and APIs](/integrations/introduction). # Manage workspace identity and user provisioning Source: https://docs.lovable.dev/features/workspace-identity Control how your team authenticates and joins your workspace: verified domains, SSO, enforced sign-in, and automatic user provisioning. The **Identity** tab in workspace settings is where workspace owners and admins control how people authenticate to Lovable and how they join the workspace. It brings together domain verification, single sign-on (SSO), SSO enforcement, and automatic user provisioning in one place. * **Available on:** Business and Enterprise plans (SCIM provisioning is Enterprise only) * **Access:** Workspace admins and owners * **Location:** [Identity](https://lovable.dev/settings/identity) (**Settings → Access → Identity**) This page is about how your team signs in to **Lovable itself**. Apps your team builds can also recognize the signed-in workspace member automatically, so internal tools need no login page of their own. That is a separate feature: see [Reuse Lovable workspace identity in your app](/features/lovable-workspace-identity-reuse). ## What's on the Identity tab | Section | What it does | Details | | :-------------------- | :----------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------- | | **Verified domains** | Prove ownership of your company's email domains. Required for everything below. | [Verify a domain for your workspace](/features/verified-domains) | | **SSO providers** | Connect one SAML or OIDC identity provider, such as Okta, Auth0, or Microsoft Entra ID. | [Set up workspace single sign-on (SSO)](/features/business/sso) | | **Enforce SSO** | Require all workspace members to sign in through your identity provider, and set the session duration. | [Set up workspace single sign-on (SSO)](/features/business/sso) | | **User provisioning** | Control how users with verified-domain emails join the workspace automatically. | This page, below | | **SCIM provisioning** | Manage user lifecycle centrally from your identity provider (Enterprise plan). | [Set up SCIM user provisioning](/features/business/scim) | ## User provisioning The **User provisioning** section controls how users whose email is on one of your verified domains join the workspace without a manual invite. There are three options. ### SSO sign-in Automatically adds users to your workspace the first time they sign in through your SSO provider (also called just-in-time, or JIT, provisioning). Each provisioned user receives the provider's **JIT role**, which you set on the SSO provider. * On the **Enterprise plan**, use the **SSO Just-in-Time provisioning** toggle to turn this on or off yourself. * On the **Business plan**, this is enabled automatically when an SSO provider is configured, and the section shows a read-only **Enabled** or **Disabled** status. Contact Lovable support if you need it changed. * When no SSO provider is configured yet, the row shows an **Add SSO provider** button instead. ### Verified email sign-up Automatically adds users who sign up to Lovable with an email on one of your verified domains, whether or not they sign in through SSO. Set the **Default role** that these users receive when they join. Verified email sign-up turns on automatically when you verify your first domain, with the default role set to editor. Review the default role after verifying a domain. Verified email sign-up is unavailable while SCIM provisioning is active, since SCIM manages membership centrally from your identity provider. ### Add existing users A one-time action that adds people who already have Lovable accounts with verified-domain emails to your workspace. The section shows how many eligible users were found; click **Provision** to add them all. Use this after verifying a domain to bring existing colleagues into the workspace in one step, instead of waiting for them to sign in or sign up again. ### How provisioning methods interact * **SCIM takes precedence.** When SCIM provisioning is enabled, user creation and role assignment are managed from your identity provider, and verified email sign-up is disabled. * **Project invites respect provisioning.** When you invite someone to a project and their email matches a verified domain with verified email sign-up on, they join the workspace as a full member at your default role instead of becoming an external collaborator. * **Provisioned members are managed like any other member.** They appear in the [People tab](/features/people), where you can change roles, set credit limits, or remove them. ## Enforce SSO and session duration Once you have a verified domain and an SSO provider, you can turn on **Enforce SSO** to require all workspace members to sign in through your identity provider, and choose how long SSO sessions last (8 hours, 24 hours, 48 hours, or 7 days) before members must re-authenticate. For setup steps, the external-collaborator removal option, and troubleshooting, see [Set up workspace single sign-on (SSO)](/features/business/sso). ## Removal and cascade behavior Identity settings depend on each other, so removing one piece can turn others off: * Deleting your **last verified domain** automatically turns off **Enforce SSO** and **Verified email sign-up**. * Deleting your **SSO provider** automatically turns off **Enforce SSO** and removes **SCIM provisioning**. Lovable shows the effects in the confirmation dialog before you delete. Existing members keep their access in all cases. ## FAQ Both add verified-domain users automatically, but they trigger differently. **SSO sign-in** adds users when they first authenticate through your SSO provider and assigns the provider's JIT role. **Verified email sign-up** adds users when they sign up with a verified-domain email using any sign-in method, no SSO required, and assigns the default role you set. You can use both at once. The self-serve toggle is available on the Enterprise plan. On the Business plan, SSO sign-in provisioning is enabled automatically when an SSO provider is configured, and the status is shown read-only. Verified email sign-up is disabled while SCIM provisioning is active, because SCIM manages workspace membership centrally from your identity provider. Disable SCIM if you want to switch to domain-based provisioning. No. Turning off SSO sign-in, verified email sign-up, or SCIM only stops new automatic joins. Members who already joined keep their access until you remove them from the People tab. Users added through SSO sign-in get the JIT role set on your SSO provider. Users added through verified email sign-up get the default role set in the User provisioning section. Users provisioned through SCIM get roles from your group mappings, or the SCIM default role. You can change any member's role afterward from the People tab. # Workspace insights Source: https://docs.lovable.dev/features/workspace-insights Govern your Lovable workspace by identifying projects that need attention, with workspace-wide security, privacy, ownership, usage, and activity signals organized by review priority. Workspace insights helps workspace owners and admins govern and prioritize project review across a growing workspace. It combines security findings, ownership, lifecycle, cost, publish status, and activity signals so you can quickly find projects that may need security or ownership attention. On Enterprise plans, it also includes sensitive data findings (PII). Use it to answer governance questions such as: which projects are published to the internet, which have open security findings, which are abandoned, which have no owners, and which consume the most credits. On Enterprise plans, you can also see which projects contain personal data. Workspace insights complements the other [Security center](/features/security-center) tabs. **Code analysis**, **Supply chain security**, and **Secrets overview** focus on specific security areas, while Workspace insights adds portfolio and governance context across every project. * **Available on:** Business and Enterprise plans. PII columns, PII quick filters, and PII scans are Enterprise-only. * **Access:** Workspace admins and owners * **Location:** [Workspace insights](https://lovable.dev/settings/workspace-insights) (**Settings → Security → Security center → Workspace insights**) Viewing Workspace insights, exporting data, and running PII or security scans from Workspace insights do not consume credits. ## What you can do * See a workspace-wide summary of total projects, externally published projects, and projects with high review priority. * Jump to key risk themes with quick filters for abandoned projects, security scan findings, and projects with no owner. Enterprise workspaces also see a **Projects with PII** quick filter. * Search every project by project name, owner, or description. * Filter the project table by review priority, publishing status, and finding type. * Sort projects by review priority, activity, credits, scan status, and other table columns. * Show or hide columns to tailor the table to your workflow. * Expand any project row to review the findings and signals that explain why the project is flagged. * Click a project name to open the full project details page with description, Lovable Cloud setup, connectors, website details, PII status, activity metrics, and open findings. * Run a fresh security scan on a project. Enterprise workspaces can also run a fresh PII scan. * Export the table to a CSV file for audits, reporting, or leadership reviews. ## How Workspace insights works Workspace insights combines scan results and workspace signals, then turns them into **review priority** for each project. ### Where findings and signals come from Workspace insights brings together scan results and workspace signals to help you prioritize project review across the workspace. It uses: * **Security findings** from Lovable’s [Basic scan](/features/security#basic-scan), [Deep scan](/features/security#deep-scan), and related [Security center](/features/security-center) surfaces. * **Sensitive data findings** (Enterprise only) from [Sensitive data scanning](/features/sensitive-data-scanning), such as unresolved personally identifiable information (PII) in project data. * **Project and workspace signals** such as publish status, ownership, activity, credits, collaborators, connectors, secrets, and Lovable Cloud usage. These inputs contribute to each project’s **review priority**, shown as **High**, **Medium**, **Low**, or **Not scanned**. Review priority helps the projects that need the most attention rise to the top. | Source | What it contributes | | :----------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Sensitive data scanning](/features/sensitive-data-scanning) (Enterprise only) | Finds personally identifiable information (PII) in supported project data, including chat messages, file uploads, chat history, Lovable Cloud database data, and Lovable Cloud storage. | | [Basic scan](/features/security#basic-scan) | Runs fast configuration and dependency checks, including row-level security (RLS) policy linting, database schema review, and dependency audit. | | [Deep scan](/features/security#deep-scan) | Runs a more thorough agentic code review that includes Basic scan checks and adds access control review, backend endpoint protection, code-level vulnerability detection, and project-specific issues. | | Optional security connectors | Add coverage from connected tools, such as [Wiz](/integrations/wiz) or [Aikido](/integrations/aikido), when configured for the workspace. | | Workspace and project metadata | Adds project state and usage signals, such as publish status, ownership, activity, credits, collaborators, connectors, secrets, and Lovable Cloud configuration. | Each finding links to the relevant project view for review and action. ### Review priority Review priority indicates how urgently a project may need attention. It appears as **High**, **Medium**, **Low**, or **Not scanned**. Workspace insights assigns review priority based on the active findings and signals on a project. Signals that increase review priority include public exposure, open security findings, unresolved personal data findings, abandoned published projects, and projects with no active owner. Signals such as connectors, secrets, external collaborators, shared access, and edge functions can also contribute because they may require periodic review. A project with no scan data shows as **Not scanned**. ### Findings and signals The findings and signals below contribute to review priority. Projects with stronger or overlapping findings and signals are more likely to appear with higher review priority. | Finding | What it means | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | | Public app with security errors | The project is publicly exposed and has critical-level security findings. | | Public apps with PII and security findings (Enterprise only) | The project is published, contains personal data, and has warning-level or critical-level security findings. | | Security findings | The project has open security findings. | | Public apps with PII (Enterprise only) | The project is published and contains personal data. | | Abandoned published projects | The project is published and has no recent activity. | | Orphaned projects | The project owner is no longer an active workspace member. | | Open PII findings (Enterprise only) | The project has unresolved personal data findings. | | Secrets | The project has secrets configured. Review whether they are still needed and correctly scoped. | | Connectors | The project has external service connectors attached. Review how the app uses connected data. | | External collaborators | The project has collaborators outside the workspace. | | Shared with collaborators | The project is shared with additional users. | | Edge functions | The project has deployed edge functions. Run regular scans to keep backend code safe. | When a more specific finding applies, less specific overlapping findings can be hidden to avoid double-counting. For example, if **Public apps with PII and security findings** applies, Workspace insights suppresses overlapping PII-only findings for that project. ## Dashboard overview Workspace insights is organized from summary to detail: workspace-level metrics, quick filters, the project table, expanded findings rows, and per-project detail views. ### Summary cards The summary cards show the overall state of the workspace. | Card | What it shows | | -------------------- | --------------------------------------------- | | Total projects | Total number of projects in the workspace | | Externally published | Projects published to the public internet | | High review priority | Projects with signals that need urgent review | ### Quick filters The **Quick filters** row lets you jump directly to a filtered project table. | Quick filter | What it shows | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Projects with PII (Enterprise only) | Projects with open personal data findings | | Abandoned | Projects with no recent activity in the last 60 days. Includes edits, messages, sessions, and function calls. The abandoned-project threshold defaults to 60 days and can be configured per workspace to 30, 60, 120, or 180 days. | | Security scan findings | Projects with open security findings | | No owner | Projects whose owner is no longer an active workspace member, so the projects need a new accountable owner | ### Project table Every project in the workspace appears in a searchable, filterable, and sortable table. By default, each row shows the following columns: * **Project name** * **Review priority** * **Publish status** * **Owner** * **Last security scan** * **Last edit** * **Total credits** (all-time credits consumed by the project) ### Columns Use the column menu to show or hide columns. **Project name** and **Review priority** are always visible. Additional columns include: * **Project ID** and **Created** * **Edits (7d)** and **Visitors (7d)**, each with a tooltip showing when the activity data was last updated * **Security findings** * **Total vulnerabilities** * **PII findings** (Enterprise only) * **Auth providers** * **External access** * **Connectors**, **Lovable Cloud**, and **Edge functions** * **Secret names** Column preferences are stored in your browser for the current workspace. They do not sync across browsers or devices. ### Search Use the **Search projects...** field to search by project name, owner, or description. ### Filters The table can be filtered by review priority, publishing status, and findings. | Filter | Options | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Review priority | High, Medium, Low | | Publishing status | Externally published, Internally published, Not published | | Findings | Security findings, Project secrets, Connectors, External collaborators, Shared with collaborators, Edge functions, Abandoned, No owner. Enterprise workspaces also see **Open PII findings**. | You can combine filters. For example, selecting **High** review priority and **Externally published** shows only externally published projects with high review priority. ### Sorting Click a column header to sort by that column. Sort labels vary by column type: * Name columns use **A-Z** and **Z-A**. * Date columns use **Oldest first** and **Newest first**. * Review priority uses **Highest first**. * Count columns use **Fewest first** and **Most first**. ### Expanded findings row Expand a project row to see the findings and signals that explain why the project is flagged. Click **View** on a finding to open the relevant project view for investigation and action. You can also click **Run security scan** from the expanded row. Enterprise workspaces can also click **Run PII scan**. ### Project details Click the project name to open the full project details page. The project details page gives broader context about the project, including: * **Project description** * **Lovable Cloud** details, when the project uses Lovable Cloud, including **Status**, **Edge functions**, **Auth providers**, **Tables**, **Storage buckets**, and **Last synced**. * **Connectors** used by the project, such as Slack, Stripe, or Google Calendar, with links to connector settings. * **Website details**, including **Status**, published **URL**, **Project ID**, **Secrets**, **Edge functions**, and **Collaborators**. Enterprise workspaces also see **Handles PII**. * **Activity metrics**, including **Edits - 7d** and either **App visitors - 7d** for published projects or **Collaborators**. * **Security findings**, including open findings and links to the relevant project view for more detail. Enterprise workspaces also see **PII findings**. You can also start a new security scan from the project details page. Enterprise workspaces can also start a new PII scan. ## Export to CSV Use the export control in the **Security center** header to export the project table to CSV. You can choose: | Export option | What it includes | | ---------------------- | --------------------------------------------- | | Export visible columns | Only the columns currently shown in the table | | Export all columns | Every available column | Both options respect the current search query and filters. They export all matching rows, not just the current page. Exported files use a name like `workspace_insights_2026-06-23_15-30.csv`. Exports are capped at 100,000 rows. If the matching results exceed the cap, Lovable shows an **Export truncated** message and the file contains the rows included within the export limit. Narrow your filters to export the remaining projects. ## Important notes * Workspace insights reflects the latest workspace data Lovable has processed. Some values can lag behind recent changes. * Review priority updates asynchronously after scans, connector changes, ownership changes, and other relevant project changes. * Activity data, such as edits and visitors, can lag by up to 24 hours. * The project detail view and some table columns show when the underlying data was last updated. * Workspace insights helps identify projects that need attention, but changes still happen in the project itself. # Glossary Source: https://docs.lovable.dev/glossary Definitions of Lovable-specific terms, features, and the general web development concepts you'll encounter in the documentation. This glossary is split into two parts: * **Lovable terminology** covers terms specific to the Lovable platform, its features, and how it works. * **General development concepts** covers web, design, and backend terms that aren't Lovable-specific but show up often in the docs. ## Lovable terminology ### Modes and how Lovable works * [**Build mode**](/features/agent-mode): Lovable's execution mode for implementing changes directly in your project. The agent writes code, runs tools, applies changes across files, and verifies the result. Use Build mode when you're ready to ship a change. (Previously called *Agent mode*.) * [**Plan mode**](/features/plan-mode): Lovable's reasoning and brainstorming mode. Use it to explore ideas, compare approaches, investigate issues, and review or edit a plan before any code changes. Plan mode never modifies your project. * [**Subagents**](/features/subagents): Temporary, read-only agents that Lovable spins up to research, inspect, or review focused parts of a task in parallel. Subagents report findings back to the main agent but cannot change your project. * **Prompt**: A natural-language instruction you send to Lovable to create, modify, debug, or explain something in your app. * **Prompt queue**: A queue of prompts you can send while Lovable is already working. Queued prompts can be reordered, edited, paused, or removed before they run. * **Diff**: A side-by-side comparison of file changes Lovable made in a turn. * **[History](/features/projects/history)**: The chronological log of changes to your project. Lets you revert to a previous version or bookmark important checkpoints. * **Visible tasks**: The step-by-step progress view that shows what Lovable is doing during a Build mode run, including which files it's touching. ### Workspace, projects, and people * [**Workspace**](/features/workspace): The shared space where a group of people builds together. It holds your projects, members, billing, and settings, and everyone you invite builds from the workspace's shared plan and credits, each on as many of their own projects as they want. Every project lives inside a workspace. * [**Workspace admin settings**](/features/workspace-admin-settings): The central place where workspace owners and admins configure identity, access, templates, billing, domains, security, and developer settings for the workspace. * **[Project](/features/projects/overview)**: A single Lovable app, with its own code, chat history, integrations, and settings. Projects always belong to a workspace. * **External collaborator**: Someone outside your workspace who has been granted access to a specific project. External collaborators don't have a seat in the workspace itself. * [**Project access**](/features/project-visibility) (project visibility): Controls who can open and edit a project in the Lovable editor: **Workspace** or **Restricted** (Business and Enterprise). * **Restricted project**: A project visible only to people explicitly added to it, even within the workspace. Available on Business and Enterprise plans. * [**Share dialog**](/features/share-project): The dialog where you invite people or groups to a project, manage roles, and copy invite links. * [**Groups**](/features/groups): Named collections of workspace members used to grant access to projects, folders, and published apps in bulk. Groups can also sync from your identity provider via SCIM. Available on Business and Enterprise plans. * [**SSO (Single sign-on)**](/features/business/sso): Workspace-level authentication through your identity provider (Okta, Microsoft Entra ID, Auth0, Google Workspace) using OIDC or SAML. * [**SCIM provisioning**](/features/business/scim): Automatically create, update, and remove workspace users (and sync groups) from your identity provider. * [**Audit logs**](/features/audit-logs): A searchable trail of workspace activity showing who did what, when, and to which resource. Enterprise plans. ### Building and editing * **[Preview](/features/projects/preview)**: The live, interactive view of your app inside Lovable. The preview updates as Lovable builds, and you can interact with it the same way an end user would. * [**Preview toolbar**](/features/preview-toolbar): The toolbar on top of the preview that lets you select elements, edit text inline, draw annotations, and leave comments without leaving the preview. Replaces the older Visual edits panel. * [**Code editor**](/features/code-mode): The in-Lovable view for browsing and manually editing your project's source code. Editing is available on paid plans. See [the code editor](/features/code-mode). (Sometimes called *Code mode*.) * [**Knowledge**](/features/knowledge): Persistent instructions Lovable remembers across conversations. Split into **workspace knowledge** (rules and standards that apply to every project in the workspace) and **project knowledge** (project-specific context, personas, conventions, and design notes). * [**Skills**](/features/skills): Reusable, named playbooks defined at the workspace level. Each skill packages markdown instructions that Lovable applies whenever a matching task comes up, either invoked with a `/` command or triggered automatically. * [**Cross-project referencing**](/features/cross-project-referencing): Pull code, assets, files, or chat history from another project in your workspace using `@` mentions, so you can reuse implementations without rebuilding them. * [**File generation**](/features/generate-files): Ask Lovable to analyze data or generate downloadable files (CSV, PDF, Excel, charts) directly in the chat, without modifying your project's source code. * [**Browser testing**](/features/browser-testing): Lovable interacts with your app in a real browser, clicking, filling forms, and capturing screenshots, to verify user flows end to end. * [**Testing tools**](/features/testing): The umbrella feature covering browser testing, **frontend tests** (Vitest + React Testing Library), and **edge tests** (Deno test runner for edge functions). * [**Remix**](/features/projects/remix): Reuse the current state of a project as the starting point for a new one. Remixing creates a copy you can edit independently while preserving the original. You can remix one of your own projects, any project you have access to, or another user's project that has **public remixing** enabled. ### Design * [**Design guidance**](/features/design-guidance): The pre-build step where Lovable either shows three lightweight **design directions** to compare, asks **design questions** about typography, color, and layout, or builds directly when the visual intent is already clear. * **Design directions**: Three side-by-side HTML and Tailwind previews Lovable can generate before a build, so you can pick a visual direction before committing. * [**Design systems**](/features/design-systems): An Enterprise-only feature for defining a reusable React component library, styling guidelines, and setup instructions in a dedicated Lovable project. Other projects in the workspace can connect to that design system and receive updates. * [**Design templates**](/features/business/design-templates): Approved Lovable projects marked as reusable. Starting a new project from a template copies the full codebase, including structure, components, configuration, and styling. Available on Business and Enterprise plans. ### Publishing, hosting, and domains * [**Publish**](/features/publish): Deploy your project to a public URL. Publishing creates a snapshot; later edits require republishing to go live. * **Website access**: Controls who can visit your published app. Options include anyone (public) or workspace only (Business and above). * [**Custom domain**](/features/custom-domain): A domain you own (e.g. `yoursite.com`) connected to a published Lovable project. You can connect a domain from another registrar or buy one through Lovable. * [**Transfer a domain**](/features/transfer-domain): Move a domain you already own from another registrar into Lovable, so Lovable becomes the registrar. * [**Branded app URLs**](/features/branded-workspace-urls): A workspace-level subdomain that replaces the default `your-app.lovable.app` with `{app-name}.{workspace-subdomain}.lovable.app` for every app in the workspace. Available on Business and Enterprise plans. * [**Analytics**](/features/analytics): Built-in traffic and engagement metrics for published projects. * [**SEO and AI search (AEO)**](/features/seo-aeo): The combined tab for Search Engine Optimization and Answer Engine Optimization. Includes on-demand SEO reviews, sitemap/robots/llms.txt checks, Lighthouse performance, Semrush keyword research, and Google Search Console setup. ### Lovable Cloud * [**Lovable Cloud**](/features/cloud): Lovable's built-in full-stack platform with database, authentication, storage, edge functions, and AI for your app, all with no external setup. * [**Database**](/features/database): View tables, edit records, run SQL, and restore daily backups of your project's data. * [**Storage**](/features/storage): Buckets holding your app's uploaded files, private by default with signed URLs for sharing. * [**Jobs**](/features/jobs): Scheduled background tasks with run history, created by prompting Lovable. * [**Logs**](/features/logs): Searchable backend logs across functions, database, auth, and storage. * [**Usage and costs (Cloud)**](/features/usage-and-costs): Per-project run credit breakdown by category. * [**Advanced settings (Cloud)**](/features/advanced-settings): Instance size, disk space, data export, and pausing or removing Cloud. * [**Edge functions**](/features/edge-functions): Serverless TypeScript functions that run close to your users. Used for APIs, webhooks, scheduled jobs, and integrations with third-party services. * [**Secrets**](/features/secrets): Securely stored API keys, tokens, and credentials. Lovable Cloud automatically injects secrets into edge functions. * [**Email auth (Cloud apps)**](/features/email-auth): Sign in with email and password or one-time codes, with configurable confirmation and password rules. The default sign-in method for Cloud apps. * [**Phone auth (Cloud apps)**](/features/phone-auth): Sign in with a phone number and an SMS one-time code, using your own SMS provider. * [**Google auth (Cloud apps)**](/features/google-auth): Add Sign in with Google to a Lovable Cloud app using Lovable-managed OAuth or your own Google Cloud credentials. * [**Apple auth (Cloud apps)**](/features/apple-auth): Add Sign in with Apple to a Lovable Cloud app using Lovable-managed OAuth or your own Apple Developer credentials. * [**SAML SSO (Cloud apps)**](/features/saml-sso): Let end users of your Lovable Cloud app sign in with their company identity provider (Okta, Entra ID, Google Workspace, OneLogin, JumpCloud, or any SAML 2.0 IdP). Configured per project. Different from workspace SSO. * [**Lovable workspace identity reuse (apps)**](/features/lovable-workspace-identity-reuse): Let apps built in the workspace recognize the signed-in workspace member automatically, with no separate login flow. Business and Enterprise plans. Different from workspace SSO and from SAML SSO for Cloud apps. * [**Custom emails**](/features/custom-emails): Send authentication and app emails from your own domain with automatic SPF, DKIM, and DMARC setup to improve deliverability. * [**Payments**](/features/payments): Built-in subscriptions and one-time payments powered by Paddle or Stripe. ### Security * [**Security overview**](/features/security): The umbrella for Lovable's built-in security: Basic and Deep scans, API key protection, RLS checks, dependency audits, and optional security connectors. * **Basic scan**: A fast configuration and dependency check that runs locally inside Lovable. Free, doesn't consume credits. * **Deep scan**: A more detailed, agentic code review for harder-to-detect vulnerabilities. Free, doesn't consume credits. * [**Security view**](/features/security-view): Per-project tab showing scan results, dependency findings, and security recommendations. * [**Security center**](/features/security-center): Workspace-level dashboard that aggregates security findings, scan coverage, scheduled scans, secrets, and dependency risks across every project. Business and Enterprise plans. * [**Workspace insights**](/features/workspace-insights): Portfolio view in the Security center that combines security findings, PII, ownership, lifecycle, publish status, and activity into a single review priority per project. Enterprise plan. * [**Privacy & security settings**](/features/privacy-and-security-settings): Workspace-wide controls for default project access, publishing permissions, MCP access, sensitive data scanning, and data protection. * **Data opt-out** (training data and privacy): Enterprise option to exclude your workspace's data from being used for AI training. ### Integrations * [**Chat connectors (MCP servers)**](/integrations/mcp-servers): Connect Lovable to your personal accounts in tools like Notion, Linear, Jira, Confluence, or Miro using the Model Context Protocol. Pulls real context from those tools directly into chat. * [**Lovable MCP server**](/integrations/lovable-mcp-server): An MCP server that lets external AI agents and developer tools (ChatGPT, Claude Desktop, Cursor) build, iterate on, and deploy Lovable apps programmatically. * [**Lovable AI**](/features/ai): Built-in AI models you can use inside the apps you publish, for chatbots, summaries, sentiment detection, image generation, semantic search, and more. No API keys required. * [**Build with URL**](/integrations/build-with-url): Create Lovable apps from a URL by passing prompts and images as parameters. Useful for embedding "Build with Lovable" buttons or automating app generation. * [**Lovable desktop app**](/integrations/desktop-app): A native app for macOS and Windows with multi-tab project management, local MCP support (Figma, Paper), and keyboard shortcuts. * [**Lovable mobile app**](/integrations/lovable-mobile-app): The mobile companion app for building and reviewing Lovable projects on the go. * [**Supabase**](/integrations/supabase): Open-source backend-as-a-service. Can be connected to Lovable projects as an alternative to Lovable Cloud. * [**GitHub integration**](/integrations/github): Two-way sync between a Lovable project and a GitHub repository for version control, code review, and developer collaboration. ### Plans, credits, and billing * **Credits:** Units Lovable uses to measure and pay for credit-based usage across your workspace. Credits can be used for building your app, hosting and running it with Lovable Cloud, and powering AI features in deployed apps. * **Credit top-up:** An optional purchase of additional credits available on Pro and Business plans, separate from your monthly subscription. Top-ups can be purchased manually as a one-time top-up or automatically with auto top-up. * **Daily build credits:** Credits granted every day on Free, Pro, and Business plans for Build usage only. Free, Pro, and Business plans include 5 daily build credits that reset every day at 00:00 UTC and do not roll over. Free daily build credits are capped at 30 per calendar month. Pro and Business daily build credits do not have a monthly cap. * **Usage-specific grants:** Included credits that apply only to one type of usage, such as daily build credits, the monthly Cloud grant, or the monthly AI grant. Usage-specific grants are used before general credits and do not roll over. Daily build credits reset every day at 00:00 UTC. On Free plans, monthly Cloud and AI grants reset on the 1st of each calendar month at 00:00 UTC. On Pro and Business plans, monthly Cloud and AI grants refresh with the subscription billing cycle. * **General credits:** Credits that can be used after usage-specific grants run out to build your app, host and run your app with Lovable Cloud, and power AI features in deployed apps. General credits include monthly plan credits, top-up credits, and bonus credits. See [Credits and usage](/introduction/credits-and-usage) for more information. ## General development concepts These terms are not Lovable-specific. They come up across web, design, and backend development and are included here as a reference when you see them in the docs. ### Frontend and UI * **Frontend**: The part of an app users see and interact with in the browser. * **React**: The JavaScript library Lovable uses to build user interfaces. * **Tailwind CSS**: The utility-first CSS framework used to style Lovable projects. * **Component**: A reusable piece of UI (button, card, form, navbar) that combines to build pages. * **Responsive design**: Layouts that adapt to different screen sizes such as mobile, tablet, and desktop. * **Hero section**: The prominent area at the top of a landing page, typically containing a headline, subheading, and call to action. * **CTA (Call to action)**: A button or link prompting users to take an action, such as "Sign up", "Get started", or "Buy now". * **Modal / Dialog**: An overlay window that interrupts the main flow to capture attention or input. * **Toast**: A brief, non-intrusive notification that appears temporarily. * **Tooltip**: A small popup that appears on hover or focus to provide extra information. * **Skeleton loader**: A placeholder UI that mimics the final layout while real content is loading. * **Above the fold**: The portion of a page visible without scrolling. * **Breadcrumb**: A navigational element showing a user's location within the site hierarchy. * **Favicon**: The small icon shown in browser tabs and bookmarks. ### Design language and styles Use these terms in prompts to steer Lovable toward a specific aesthetic. * **Glassmorphism**: Translucent, frosted glass elements with blur and subtle borders. * **Neobrutalism**: Bold, raw, high-contrast design with unpolished edges and chunky typography. * **Minimal**: Clean layouts, lots of whitespace, restrained color and type. * **Premium**: Refined, sophisticated, attention-to-detail aesthetic. * **Retro**: Visual styles borrowed from past decades, such as neon, pixel, or vintage. ### Backend, databases, and APIs * **Backend**: The server-side of an app, including data, business logic, authentication, and integrations. * **API (Application Programming Interface)**: A contract that lets two software systems exchange data. APIs define what requests one system can make to another and what responses to expect. * **REST API**: An API style that uses HTTP verbs (GET, POST, PUT, DELETE) over predictable URL endpoints. * **Endpoint**: A specific URL on an API where a client sends or receives data. * **Webhook**: An HTTP callback that notifies your app when an event happens in an external service. * **CRUD (Create, Read, Update, Delete)**: The four basic database operations. * **SQL (Structured Query Language)**: The query language for relational databases. Lovable writes SQL for you, but you can run custom queries in the Cloud SQL editor. * **PostgreSQL**: The open-source relational database that powers Lovable Cloud and Supabase. * **Edge function**: A serverless function that runs on a globally distributed network close to your users. (Used in both Lovable Cloud and Supabase.) * **RLS (Row-level security)**: Postgres feature that restricts which rows a user can read or modify based on policies. Critical for multi-user apps. * **Bucket**: A storage container for files (images, video, documents) in object storage. ### Authentication and security * **OAuth**: A protocol that lets users log in to your app using a third-party account (Google, GitHub, etc.) without sharing their password. * **SAML 2.0**: An XML-based standard for enterprise single sign-on between an identity provider and a service provider. * **OIDC (OpenID Connect)**: A modern authentication layer on top of OAuth 2.0, commonly used for SSO. * **IdP (Identity provider)**: A service that authenticates users, such as Okta, Microsoft Entra ID, Google Workspace, Auth0, JumpCloud, or OneLogin. * **2FA (Two-factor authentication)**: A second verification step in addition to a password. * **CORS (Cross-Origin Resource Sharing)**: A browser security policy that controls which origins can call your API. ### SEO and discoverability * **SEO (Search Engine Optimization)**: Optimizing a site to rank in traditional search engines like Google or Bing. * **AEO (Answer Engine Optimization)**: Optimizing a site so AI search engines like ChatGPT, Perplexity, Claude, or Gemini surface it as an answer. * **Meta title / Meta description**: The page title and short summary shown in search results. * **Canonical URL**: The preferred URL for a page, used to avoid duplicate-content issues. * **Sitemap**: An XML file listing a site's pages to help search engines crawl them. * **robots.txt**: A file telling crawlers which paths they can or can't access. * **llms.txt**: A newer convention for guiding AI crawlers about a site's content and policies. * **Open Graph**: Meta tags that control how a page is previewed when shared on social platforms. * **Lighthouse**: Google's open-source auditing tool for performance, accessibility, SEO, and best practices. ### Design and asset resources External tools and libraries commonly used with Lovable. * [**21st.dev**](https://21st.dev/): Open-source React UI components powered by Tailwind CSS and Radix UI. * [**Google Fonts**](https://fonts.google.com/): Free, web-optimized font library. * [**SVG Repo**](https://www.svgrepo.com/): Open-licensed SVG icons and graphics. * [**Dribbble**](https://dribbble.com/): Designer community for visual inspiration. * [**Noun Project**](https://thenounproject.com/): Library of free icons and stock imagery. * [**Typewolf**](https://www.typewolf.com/): Curated font pairings and typography inspiration. # Run AI-powered penetration tests with Aikido Source: https://docs.lovable.dev/integrations/aikido Run AI-powered penetration tests on your Lovable projects with Aikido to identify real exploitable vulnerabilities and generate shareable security reports. ## What is AI pentesting [Aikido](https://www.aikido.dev/) brings AI-powered penetration testing to Lovable. It lets you test your projects for real, exploitable vulnerabilities at any point in your project lifecycle. AI pentesting is automated penetration testing performed by AI agents that simulate real attackers. It performs **dynamic analysis** by interacting with your application to identify vulnerabilities that can be exploited. This includes sending real payloads, testing authentication and authorization flows, attempting privilege escalation, and probing APIs for unexpected behavior. This differs from Lovable's [built-in basic and deep security scans](/features/security), which perform **static analysis**. The built-in security scans read your code to flag known patterns such as exposed secrets, missing row-level security, and common misconfigurations. The two approaches are complementary. * Static analysis tells you what *could* go wrong based on your code. * Dynamic analysis tells you what *actually* breaks when someone tries. The recommended order is to run the basic and deep security scans first, fix those issues, then validate with a pentest. Because AI pentesting validates issues through real attack scenarios, all findings are confirmed before being reported. This means you only see exploitable vulnerabilities, not theoretical risks. After a pentest completes, you can sync findings into your project's [Security view](/features/security-view) in a dedicated section called **Agentic penetration test by Aikido**. Aikido also generates a report and certificate that you can share with customers, investors, enterprise prospects, and external auditors, structured for SOC 2, ISO 27001, and vendor security questionnaire requirements. ## When to use AI pentesting * **Before a major release**\ Run a pentest after feature work is complete to catch vulnerabilities before going live. * **After significant changes** \ Re-run after changes to authentication, database schema, or APIs to check for regressions. * **For compliance or client requirements** \ Use the generated report to satisfy SOC 2, ISO 27001, or enterprise security questionnaires. * **As an ongoing practice**\ Run regular pentests on active projects that handle real user data. ## How Aikido tests your application Aikido uses two testing approaches: * **Blackbox testing**\ Attacks the application with no prior knowledge of the code, scanning to discover features, endpoints, and APIs * **Whitebox testing**\ Uses full access to the source code to reason about application logic, roles, and data flows, catching logic flaws and access control issues that surface testing alone would miss Because Lovable sends your project repository to Aikido when you create a pentest, whitebox testing is always included. ## Prerequisites * A paid [Aikido](https://www.aikido.dev/) account. Pentests are billed through Aikido. Until the end of June 2026, each pentest costs 100 Aikido credits. * Lovable workspace **admin** or **owner** role to connect Aikido. * Lovable project **editor** or higher to run pentests and sync findings. * A dedicated test user account in your Lovable project with username and password that Aikido can use to log in and test authenticated flows. ## How to connect Aikido A workspace admin or owner connects the Lovable workspace to Aikido via OAuth. Only one Aikido connection can be added per workspace. When a connection is created, it is shared with all workspace members and AI pentesting is available across all projects in the workspace. Open **Connectors** → **App connectors** and select **Aikido.** * Click **Add connection.** * Enter a name for the connection, for example, `Aikido`. * Click **Connect**. The Aikido authorization window opens - make sure your browser doesn't block pop-ups. * Select the Aikido workspace you want to connect, review the requested permissions, and click **Authorize**. You'll be redirected back to Lovable with a confirmation. ## How to run pentests and fix findings Each pentest is scoped to a specific project. * Open your project, then go to **Security view → Agentic penetration test by Aikido.** * Click **Prepare Aikido pentest** (first time) or **Launch new pentest** (if you've run one before). * Click **Acknowledge and proceed** to acknowledge the warning about database changes. Lovable uploads your repository and opens a pre-configured assessment in Aikido for you to review and launch. Most configuration is already pre-filled. In most cases, you only need to: * **Add test users**\ Add at least one test user and provide the username and password in the **Authentication instructions** field. Click **Save and Test** to verify credentials. Without credentials, testing is limited to unauthenticated flows. * **Review the remaining configuration in Aikido** \ Test scope, allowed domains, code & documentation, safety settings, and pricing are already set. You can adjust them if needed, but no changes are required to proceed. * **Run the assessment**\ When preflight completes, click **Run Assessment**. The **Confirm AI Pentest** confirmation dialog appears. Read the checklist, tick the confirmation checkbox, and click **Run Assessment** to launch. See [official Aikido documentation](https://help.aikido.dev/pentests/aikido-pentest) for more information. The pentest runs for several hours, and issues appear in Aikido in real time as they are discovered. Findings are not synced automatically. When the pentest completes: * Go to the **Security view** in your project. * Click **Sync findings** to pull results in. Findings appear in the **Agentic penetration test by Aikido** section. Severity maps as follows: * Critical and high → Error * Medium → Warning * Low → Info Each finding includes technical details, an attack analysis, reproduction steps, and AI-generated remediation guidance. Each sync reflects the current state of open issues in Aikido. If you close or resolve an issue in Aikido and then sync, it will no longer appear in the Security view. * To fix an issue, copy the attack analysis from Aikido and send it in the chat, or click **Try to fix all** and Lovable will attempt the fix. * To verify a fix, use the **Retest issue** option in Aikido, then sync again. When the pentest completes, Aikido automatically generates a report combining an executive overview with actionable findings. The report is structured for SOC 2, ISO 27001, client security questionnaires, and investor due diligence. You can access and download it from Aikido. In Lovable, you can find past pentests under **Pentest history** in the Security view, with status badges (Draft, Pending, Running, Completed, Cancelled, Failed) and a **View in Aikido** link per assessment. ## **Manage the Aikido connection** Workspace admins and owners can manage the Aikido connection from **Connectors** → **App connectors** → **Aikido**. * **Reconnect**: re-runs the OAuth flow to get updated credentials. A new window will open - make sure your browser allows pop-ups. * **Delete**: permanently removes the workspace connection and its credentials. This cannot be undone. Workspace members will no longer be able to run AI pentests with Aikido. Existing synced findings remain visible in each project's Security view. # Connect your app to Airtable Source: https://docs.lovable.dev/integrations/airtable Connect your app to Airtable, a spreadsheet-database hybrid, to read and write bases, tables, and records, and turn an Airtable base into a custom app interface. [Airtable](https://airtable.com/) lets your Lovable app read from and write to bases, tables, and records managed by your team in the Airtable app. It's designed for apps where the source of truth lives in Airtable and you want a custom interface (internal tool, customer-facing portal, or workflow) on top of it. With Airtable, your app can: * List bases, tables, fields, and views using the Metadata API * Create, read, update, and delete records in any base * Filter, sort, and paginate records using Airtable formulas and views * Build internal tools and customer-facing apps backed by Airtable data * Keep a single source of truth in Airtable while exposing a tailored UI to users Each Airtable connection uses a single **Airtable Personal Access Token (PAT)**. The PAT determines which bases and which operations the connection can perform. Lovable inherits whatever scopes you grant the token. ## Common use cases and example apps | Example app | Example prompt | Description | | :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Internal CRM on top of Airtable | *Use Airtable and build a CRM that reads contacts and deals from my Airtable base and lets the team update statuses inline.* | **Turn an Airtable base into a custom CRM.**
The app reads contacts and deals, lets users update fields, and writes changes back so Airtable stays the source of truth. | | Customer-facing portal | *Use Airtable and build a customer portal where each customer sees only their own orders from my Airtable Orders table.* | **Expose a filtered view of an Airtable table to customers.**
The app filters records by customer, renders a tailored UI, and hides the rest of the base. | | Inventory or asset tracker | *Use Airtable and build an inventory app where staff can scan items, view stock, and update quantities in Airtable.* | **Replace manual Airtable editing with a focused operational UI.**
The app reads inventory records, supports search and barcode scan, and pushes quantity updates back to the base. | | Submission form that writes to Airtable | *Use Airtable and build a job application form. When someone submits it, create a new record in my Applications table.* | **Capture user input and create Airtable records.**
The app validates submissions, formats the payload, and creates a row in the chosen table. | | Event RSVP and attendee dashboard | *Use Airtable and build an RSVP page that writes responses to Airtable and shows a live attendee count to admins.* | **Run events end-to-end on Airtable.**
The app collects RSVPs, writes them to a table, and renders a dashboard for organizers from the same data. | | Directory or catalog | *Use Airtable and build a directory where each row in my Airtable base becomes a detail page, with filters by category and tag.* | **Render an Airtable table as a browsable directory.**
The app lists items with filters, links to detail pages by record ID or slug, and reads all fields from Airtable. | | Content calendar or workflow board | *Use Airtable and build a content calendar that reads my Editorial base and lets editors move pieces between status columns.* | **Give a team a focused workflow UI on top of Airtable.**
The app reads records grouped by status, supports drag-and-drop, and updates the status field in Airtable. | ## How to connect Airtable Workspace **admins** and **owners** can connect Airtable. You can create multiple Airtable connections using different Personal Access Tokens. This is useful for separating environments (for example, development and production), scoping connections to different bases, or limiting which operations a given app can perform. When the connection is created, Airtable can be linked to any project in the workspace. Multiple projects can use the same connection. ### Prerequisites Before connecting Airtable, make sure you have: * An Airtable account with access to the bases you want to connect * An Airtable Personal Access Token (PAT) with the right scopes and base access * Lovable workspace owner or admin role All API requests made through this connector use your Personal Access Token. API usage counts toward your Airtable plan's rate limits and record limits, and billing is handled directly by Airtable, not Lovable. ### Step 1: Create an Airtable Personal Access Token A **Personal Access Token (PAT)** lets your Lovable app authenticate with the Airtable Web API. PATs are scoped, so you choose which bases the token can access and which operations it can perform. To create a PAT: Sign in to Airtable and go to [airtable.com/create/tokens](https://airtable.com/create/tokens). Click **Create new token** and give it a descriptive name, for example `Lovable integration`. Add the scopes your app needs. Common scopes: * `data.records:read`: read records from tables * `data.records:write`: create, update, and delete records * `schema.bases:read`: list bases, tables, and fields (Metadata API) * `schema.bases:write`: create or modify tables and fields Most Lovable apps only need `data.records:read`, `data.records:write`, and `schema.bases:read`. Grant only the scopes your app actually needs. Under **Access**, choose which bases this token can use. You can grant access to specific bases or to all bases in a workspace. Limit access to the smallest set of bases your app needs. Click **Create token** and copy the value. Your Personal Access Token functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See Airtable docs for detailed instructions: [Personal access tokens](https://airtable.com/developers/web/guides/personal-access-tokens). ### Step 2: Connect Airtable to Lovable You can create multiple connections using different Personal Access Tokens. To connect Airtable: Go to **Connectors** → **App connectors** and select **Airtable**. Click **Add connection**. 1. **Display name**: Name the connection, for example `Airtable Prod`. 2. **Personal access token**: Paste your Airtable PAT. 3. **Who can access this connection**: Keep access limited to specific people or invite the entire workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable verifies the token with Airtable. If the token is invalid or has been revoked, the connection will fail and you can paste a new one. When connected, your Lovable apps can start reading from and writing to your Airtable bases. ## Working with bases, tables, and records The Airtable Web API exposes two surfaces, and both are available through the connector: * **Metadata API**: list bases, tables, fields, and views. Useful when you want Lovable to discover the schema of a base without hardcoding IDs. * **Record API**: create, read, update, and delete records in a specific table. When prompting Lovable, it helps to mention the **base name** and **table name** you want to use, and which fields to read or write. ## Limitations The Airtable connector wraps the Airtable Web API. The Airtable connector cannot: * Receive Airtable webhooks or change events (apps must poll Airtable for updates) * Use Airtable Automations or scripting block features from your app * Support per-end-user authentication * Exceed Airtable's per-base API rate limits. Heavy traffic should batch requests If a request fails because the Personal Access Token has been revoked, rotated, or no longer has access to a base, you'll need to create a new token in Airtable and reconnect. There is no automatic refresh for PATs. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Algolia Source: https://docs.lovable.dev/integrations/algolia Connect your app to Algolia to add full-text search, faceted filtering, and indexing to your Lovable app. [Algolia](https://www.algolia.com/) is a hosted search and indexing engine that lets your Lovable app add fast, typo-tolerant search across product catalogs, content libraries, marketplaces, and directories. It's designed for apps where database queries aren't enough and you need faceted filtering, ranking, recommendations, and search analytics. With Algolia, your app can: * Index records using the Algolia API * Run full-text search with typo tolerance and ranking * Build faceted filtering, sorting, and category navigation on top of indexed data * Use Algolia's recommendation and AI features to surface related results * Expose a restricted public search key so the frontend can query Algolia directly Algolia is a search engine, not a database. Use it alongside your primary data store, not as a replacement, and reindex when records change. For simple search (filtering a small list, basic text matching), keep it in your database or frontend. Reach for the Algolia connector when you need typo tolerance, faceted filters, ranking, or search analytics across larger record sets. ## Common use cases and example apps | Example app | Example prompt | Description | | :----------------------------- | :----------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **E-commerce product search** | *Use Algolia and build a product catalog with instant search and faceted filters for price, category, and availability.* | **Power product discovery with instant search.**
The app indexes products and renders a search experience with facets and ranking tuned for relevance. | | **Documentation site search** | *Use Algolia and add a search bar to my docs site with autocomplete and keyboard shortcuts.* | **Add fast in-page search to a docs site.**
The app indexes pages and headings so readers can find content with autocomplete and typo tolerance. | | **Marketplace listings** | *Use Algolia and build a marketplace where buyers filter listings by location, price, and condition.* | **Run faceted search across marketplace listings.**
The app indexes listings and exposes filters and sorting so users narrow results quickly. | | **Blog or editorial search** | *Use Algolia and add search to my blog with tag and author filters.* | **Surface relevant articles through search and filtering.**
The app indexes posts and metadata, then renders ranked results filtered by tag, author, or date. | | **Internal directory** | *Use Algolia and build an employee directory where people search by name, team, or skill.* | **Find people fast across an internal directory.**
The app indexes employee records and renders typo-tolerant search with team and skill filters. | | **Location finder** | *Use Algolia and build a restaurant finder with geo search and cuisine filters.* | **Search nearby places with geo and category filters.**
The app uses Algolia's geo search and filters to render a finder UI with map results. | | **Search analytics dashboard** | *Use Algolia and build a dashboard that surfaces top searches, no-result queries, and click-through data.* | **Monitor what users search for and where results fall short.**
The app reads Algolia search analytics so the team can tune indexes and improve relevance. | ## How to connect Algolia Workspace **admins** and **owners** can connect Algolia. You can create multiple Algolia connections using different application IDs and keys, which is useful for separating environments (for example, development and production), targeting different Algolia applications, or scoping keys to specific indexes. When the connection is created, Algolia becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Algolia, make sure you have: * An Algolia account and application * Your Algolia Application ID * A backend API key with the ACLs your app needs (for example, `search`, `addObject`, `deleteObject`, `settings`) * (Optional) A public API key restricted to the `search` ACL, if you want the frontend to query Algolia directly * Lovable workspace **owner** or **admin** role All search and indexing operations made through this connector count toward your Algolia plan limits. Billing and quotas are handled directly by Algolia, not Lovable. ### Step 1: Get your Algolia application ID and API keys Your Lovable app authenticates to Algolia with an **Application ID** and a **backend API key**. You can also provide an optional **public API key** that the frontend uses for search. Sign in to the [Algolia dashboard](https://dashboard.algolia.com/) and select the application you want to connect. Go to **Settings → API Keys**. Your Application ID is shown at the top of this page. Click **New API key** and create a key for backend use. Give it a descriptive name, for example `Lovable backend`, restrict it to the indexes your app uses, and grant only the ACLs the app needs (typically `search`, `addObject`, `deleteObject`, and `settings` for an app that indexes and searches). Do not use your Algolia admin API key. Create a dedicated key with the minimum ACLs required, so the credential can be rotated or revoked without affecting other integrations. If you want the frontend to call Algolia directly, create a second key with only the `search` ACL, restricted to the indexes the frontend can query. Lovable validates this key on save and rejects it if it carries any ACL other than `search`. Restrict the key to specific indexes (and, if possible, domains) in Algolia for defense in depth. Your secret backend API key functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See Algolia documentation for details: [API keys guide](https://www.algolia.com/doc/guides/security/api-keys/). ### Step 2: Connect Algolia to Lovable You can create multiple connections using different application IDs and keys. Go to **Connectors → App connectors** and select **Algolia**. Click **Add connection**. 1. **Display name**: name the connection, for example `Algolia Prod`. This name is only used inside Lovable to identify the connection. 2. **Application ID**: paste your 10-character Algolia application ID. This value is publicly visible in your published app. 3. **Secret API key**: paste your backend API key. This stays on the server and is proxied through the Lovable gateway. 4. **Public API key** (optional): paste a public, `search`-only API key if you want the frontend to query Algolia directly. This value is publicly visible in your published app. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable verifies both keys against Algolia before saving the connection. When connected, anyone building in a project can ask Lovable in chat to link their project to Algolia (based on configured connection-level access). Your Lovable apps can then index records and run search through the connector. ## Public and secret API keys The connector accepts two keys with different roles: * The **secret backend API key** is used for server-side calls (indexing, settings, search). It's proxied through Lovable's connector gateway, so the raw key never reaches the published app. * The **public API key** is optional. When provided, it's exposed to the frontend so the app can call Algolia's search endpoint directly. Lovable enforces a strict `search`-only ACL on this key, and rejects any key with broader permissions. If you skip the public key, the frontend can still search by going through your backend (which calls Algolia through the gateway). Direct frontend search is faster and lighter on your backend, but requires a search-only public key. ## Limitations The Algolia connector cannot: * Replace your primary database. Algolia is a search engine, so records must be indexed from your source of truth and kept in sync when they change. * Automatically delete Algolia indexes when a Lovable project, workspace, or connection is removed. You must delete unused indexes in the Algolia dashboard. * Refresh or rotate API keys for you. To rotate, create a new key in Algolia and update the Lovable connection. * Support per-end-user Algolia authentication. Each connection represents a single Algolia application shared across all projects linked to it. * Accept a public API key with any ACL other than `search`. Keys with broader permissions are rejected on save. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Apollo.io Source: https://docs.lovable.dev/integrations/apollo Connect your app to Apollo.io to search its B2B database of people and companies, enrich contact and organization data, and manage contacts, accounts, and deals from your Lovable app. [Apollo.io](https://www.apollo.io/) is a B2B sales intelligence and engagement platform with a database of people and companies. The Apollo.io connector lets your Lovable app search that database, enrich contacts and organizations, and manage contacts, accounts, and deals. With Apollo.io, your app can: * Search Apollo's B2B database for people and companies * Enrich contacts and organizations with profile and firmographic data * Create and manage contacts, accounts, and deals * Build prospecting and outreach workflows on live sales data It's a good fit for prospecting dashboards, lead-enrichment forms, and internal sales tools built on live Apollo data. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------- | :------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- | | **Company research page** | *Use Apollo.io and build a company research page that searches Apollo by company name and shows firmographic details.* | **Turn a company name into a research profile.**
The app searches Apollo for matching companies and displays their size, industry, and location. | | **Lead enrichment form** | *Use Apollo.io and build a form where I enter a company domain and get back enriched firmographic data.* | **Enrich records from a single input.**
The app calls Apollo's organization enrichment and fills in company details automatically. | | **Prospecting list builder** | *Use Apollo.io and build a prospecting tool that searches for people by title and industry and saves them to a list.* | **Find and shortlist prospects from live data.**
The app searches Apollo's people database and lets you save matches for outreach. | | **Contact enrichment on signup** | *Use Apollo.io and enrich each new signup with their company data when they register.* | **Add context to new users automatically.**
The app enriches the signup's email or domain with Apollo firmographics and stores the result. | | **Sales pipeline dashboard** | *Use Apollo.io and build a dashboard that creates and tracks accounts and deals from prospect research.* | **Manage accounts and deals alongside research.**
The app creates Apollo contacts, accounts, and deals and shows their status in one view. | | **ICP account finder** | *Use Apollo.io and build a tool that finds companies matching our ideal customer profile by size, industry, and location.* | **Surface accounts that match your ICP.**
The app queries Apollo with firmographic filters and lists companies that fit. | ## How to connect Apollo.io Who can create Apollo.io connections depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections). You can create multiple Apollo.io connections using different API keys, which is useful for separating environments (for example, development and production) or using different Apollo accounts. When the connection is created, you can link it to the projects where you want to use it. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Apollo.io, make sure you have: * An Apollo.io account * An Apollo.io API key * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) All search and enrichment requests through this connector consume Apollo credits and count toward your Apollo plan's rate limits. Billing and quota are handled directly by Apollo.io, not Lovable. ### Step 1: Get an Apollo.io API key An API key lets your Lovable app authenticate with the Apollo.io API. Apollo scopes each key to the endpoints you grant it, so create the key with access to the endpoints your app needs. To create an Apollo.io API key: Sign in to [Apollo.io](https://app.apollo.io/). Go to [Settings → Integrations → API Keys](https://app.apollo.io/#/settings/integrations/api). Click **Create new key**, give it a descriptive name, for example `Lovable integration`, grant access to the API endpoints your app needs, then click **Create API key** to finish. Some endpoints, such as people search, require a master API key. Copy the key and store it securely. You'll paste it into Lovable in the next step. Your API key functions like a password. Keep it secure and never share it publicly. See the [Apollo API documentation](https://docs.apollo.io/) for details. ### Step 2: Connect Apollo.io to Lovable You can create multiple connections using different API keys. Go to **Connectors → App connectors** and select **Apollo.io**. Click **Add connection**. 1. **Display name**: name the connection, for example `Apollo.io Prod`. This name is only used inside Lovable to identify the connection. 2. **API key**: paste your Apollo.io API key. Under **Who can use this connection**, decide who in your workspace can use the connection. You start as the only person with access: * **Only you** (default): leave the access list as is; only you can use the connection and its associated data. * **Invite specific people**: add workspace members by email; only you and the people you add can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable validates the key against Apollo before saving the connection. When connected, anyone building in a project can ask Lovable in chat to link their project to Apollo.io (based on configured connection-level access). Your Lovable apps can then search, enrich, and manage Apollo data through Lovable's connector gateway. ## Endpoint access and credits Apollo scopes API keys per endpoint, so a key can call some endpoints and not others. If a request returns a 403 with `error_code: API_INACCESSIBLE`, the connected key does not have access to that endpoint. Some endpoints, such as people search, require a master API key. Enable the endpoints your app needs (or use a master key) under **Settings → Integrations → API Keys** in Apollo, then update the Lovable connection if you created a new key. Search and enrichment requests consume Apollo credits and count toward Apollo's per-minute, hourly, and daily rate limits. Cache results and fetch on demand rather than on every page load, so your app stays within Apollo's quota. Lovable routes your app's server-side Apollo calls through its [connector gateway](/integrations/introduction#gateway-based-connectors); if you edit backend code yourself, call the gateway rather than `https://api.apollo.io` directly. ## Limitations The Apollo.io connector cannot: * Refresh or rotate API keys automatically. To rotate, create a new key in Apollo and update the Lovable connection * Support per-end-user Apollo authentication. Each connection represents a single Apollo account shared across all projects linked to it If an API key is revoked or deleted in Apollo, reconnect the integration in Lovable with a valid key before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # App user connectors: let your users connect their own accounts Source: https://docs.lovable.dev/integrations/app-user-connectors App user connectors let each end user of your published Lovable app connect their own third-party account, so your app acts on their behalf with their own permissions. Authentication is handled securely through Lovable's connector gateway. **App user connectors** let **each end user of your published app** connect **their own** third-party account. Your app then acts **on their behalf**, with their own permissions and only their data. Authentication runs through Lovable's [connector gateway](/integrations/security#gateway-connectors), so user tokens are stored securely and never exposed in your project. Use an app user connector when the app is multi-tenant by nature: a signed-in user should see **their** inbox, **their** calendar, or **their** CRM records, not a single shared account. ## Standard connector vs. App user connector Both are [app connectors](/integrations/introduction#app-connectors-add-capabilities-to-your-published-app) and both route through the gateway. The difference is **whose account** the app uses. | | **Standard app connector** | **App user connector** | | :-------------------- | :-------------------------------------------------------------------------- | :------------------------------------------------------------------- | | **Whose account** | One account you connect once | Each end user's own account | | **Who authorizes** | The builder (or a workspace admin) | Every user, the first time they use it | | **Data the app sees** | The single connected account's data, shared by all visitors | Only the signed-in user's data, per their granted scopes | | **Typical use** | Send from a company inbox, post to one Slack workspace, query one warehouse | "Connect your Gmail", "Connect your Salesforce", per-user dashboards | | **Credentials** | Stored once, reused for every request | Stored per user, isolated from other users | **When to reach for which.** If every visitor should act as the *same* account (for example, notifications from one company Slack), use a standard connector. If every visitor should act as *themselves* (for example, viewing their own calendar events or their own CRM records), use an **app user connector**. ## How it works An **app user connector** has two parts: a **client** you configure once as the builder, and the **individual sign-ins** your end users complete when they use the app. ### 1. You configure the client once As the builder, you set up a client for the connector once for your workspace. Depending on the provider, this means registering an OAuth application with that provider (for example a Salesforce External Client App, a Databricks OAuth app, or a Snowflake OAuth security integration) and adding its details to the client. This configuration is stored securely and reused for every user who connects, and it never contains any individual user's data. ### 2. Each user connects their own account The first time one of your users needs the integration, your published app sends them through the provider's standard **OAuth consent screen**. The user signs in with their own account and approves the requested permissions (scopes). Lovable exchanges the authorization for tokens and stores them **encrypted in the connector gateway**, linked to that individual user. ### 3. Your app calls the provider through the gateway When your app makes a request, it goes to the **connector gateway** rather than directly to the provider. The gateway: * **Resolves the right user's account** for the request and confirms it belongs to that user, in this workspace and project. * **Refreshes expiring tokens automatically** in the background, so users don't have to re-authorize on every session. If a refresh token is no longer valid, the gateway returns a clear "reconnect" signal so your app can prompt the user to authorize again. * **Injects the credentials** and forwards the request to the provider. The third-party tokens never touch your app code. * **Keeps users isolated**: one user's access can never be used to act as another user. Because tokens live in the gateway and not in your project, they are not visible in project settings, to workspace admins, or to the Lovable Agent. See [Integration security](/integrations/security#credentials) for how credentials are stored, rotated, and deleted. ## Available app user connectors The following providers are available as **app user connectors**. For Google and Microsoft, each product is its own connector but shares the same sign-in. The **OAuth app setup** column links to each provider's own documentation for creating the OAuth application you configure the client with. | Provider | App user connectors | OAuth app setup | | :------------- | :------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Google** | Gmail, Google Calendar, Google Drive, Google Docs, Google Sheets, Google Slides | [Create OAuth credentials](https://developers.google.com/workspace/guides/create-credentials) | | **Microsoft** | Outlook, OneDrive, SharePoint, Teams, OneNote, Word, Excel, PowerPoint | [Register an application](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) | | **Slack** | Slack | [Installing with OAuth](https://api.slack.com/authentication/oauth-v2) | | **Salesforce** | Salesforce | [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm) | | **HubSpot** | HubSpot | [Working with OAuth](https://developers.hubspot.com/docs/apps/developer-platform/build-apps/authentication/oauth/working-with-oauth) | | **Linear** | Linear | [OAuth 2.0 authentication](https://linear.app/developers/oauth-2-0-authentication) | | **Databricks** | Databricks | [Authorize user access with OAuth](https://docs.databricks.com/aws/en/dev-tools/auth/oauth-u2m) | | **Snowflake** | Snowflake | [OAuth for custom clients](https://docs.snowflake.com/en/user-guide/oauth-custom) | | **Workday** | Workday | [OAuth 2.0 API clients](https://doc.workday.com/admin-guide/en-us/authentication-and-security/authentication/oauth/dan1370797830693.html) (Workday sign-in required) | The list of app user connectors grows over time. Open **Connectors** in your workspace to see what's currently available. ## Set up an app user connector Setup happens in two steps: configure the client in the workspace, then wire the connect experience into your app. ### Register and approve your OAuth app with the provider Before you can configure the client, you (or your organization's admin) register an **OAuth application** on the provider's side and get it approved for use. **This process differs from provider to provider**, and each has its own requirements. For example, you might create a Salesforce External Client App, a Databricks OAuth app, a Snowflake security integration, a Google OAuth consent screen, or a Microsoft app registration. Approval can also involve extra steps such as **admin consent** for a tenant, **app verification** for sensitive scopes, or **installation approval** in a workspace. Because the exact steps and any review process are owned by the provider, the authoritative instructions live in **that provider's own documentation**. The OAuth app setup links in [Available app user connectors](#available-app-user-connectors) point you to each provider's guide. When you register the OAuth app, add Lovable's **connector gateway callback URL** to the app's allowed redirect URIs so authorization can complete: ```text theme={null} https://connector-gateway.lovable.dev/api/v1/app-users/oauth2/callback ``` Lovable also shows this value in the connector setup screen so you can copy it directly. ### Configure the client 1. Open **Connectors** in your workspace and select the provider you want (for example **Salesforce** or **Gmail**). 2. Add a client and provide the provider's OAuth application details for App User access (for example client ID and secret, and any account or workspace URL the provider requires). 3. Link the client to the project that should use it. Who can configure a connector follows the standard [app connector access rules](/integrations/introduction#who-can-create-connections): on Free and Pro plans any editor can, and on Business and Enterprise plans workspace admins and owners govern availability. ### Offline access When you set up a client, **Allow offline access** is on by default. It lets the gateway refresh each user's tokens in the background so they stay connected without reauthorizing every session. Turning **Allow offline access** on or off is available on **Business and Enterprise** plans. On Free and Pro plans it stays on. The setting is fixed once the client is linked to a project, so choose it before linking. To change it later, unlink the client from all projects first. Control over **Allow offline access** is rolling out gradually, so it may not be available in every workspace yet. ### Add the connect experience to your app Once the client is configured and linked, tell the Lovable Agent what you want, and it builds the in-app "Connect" flow for you. For example: ```text wrap theme={null} Let my users connect their own Gmail so the dashboard shows their inbox. ``` ```text wrap theme={null} Add a "Connect Salesforce" button so each signed-in user links their own account, then show their own open opportunities and let them log a call. ``` There are multiple entry points. You can start from the UI or drive the whole thing from chat, but the pattern is the same: **configure the client in the UI, then ask the agent to connect it** in your app. From there, each of your users connects their own account the first time they use the feature. App user connectors need to know **who** the current user is, so each sign-in can be tied to that person. Use [Lovable Cloud authentication](/features/authentication) (or your own auth) so each visitor is signed in before they connect. For enterprise accounts that publish a project to their own workspace, Lovable derives the signed-in user's identity automatically through Lovable Auth, so you don't need to add your own authentication. ## Managing clients * **Users can disconnect** their own account at any time, which revokes the stored tokens for that user. * **Deleting the client** removes access for every user of that connector in the linked projects. See [Integration security](/integrations/security) for credential storage, rotation, outbound IP ranges, and data retention that apply to all gateway connectors. ## FAQ An **app user connector** lets **each end user** of your published app connect **their own** third-party account, so your app acts on their behalf with their own permissions. It differs from a standard app connector, where you connect a single account once and every visitor shares it. Yes. Each user's access is isolated. The gateway forwards requests using that user's credentials and their granted scopes, so one user's access can never be used to act as another user. Usually yes. Each sign-in is tied to a specific user, so your app needs to know who the current user is. Use [Lovable Cloud authentication](/features/authentication) or your own auth before prompting a user to connect. The exception is enterprise accounts that publish a project to their own workspace: Lovable derives the user's identity through Lovable Auth, so no extra authentication is needed. No. Tokens are stored encrypted in the connector gateway and are never visible in your project, to workspace admins, or to the Lovable Agent. Your app calls the connector through the gateway, which injects credentials behind the scenes and refreshes them automatically. # Connect your app to Asana Source: https://docs.lovable.dev/integrations/asana Connect your app to Asana with a personal access token (PAT) to create and update tasks, read project and team data, and automate work tracking workflows in your Lovable apps. [Asana](https://asana.com/) is a work management platform for tasks, projects, and team planning. It lets your Lovable app work with tasks, projects, teams, sections, and assignees so you can build internal tools and automations that interact directly with your team's Asana workspace. With Asana, your app can: * Create and update tasks * Read team, project, and section data * Track assignees, due dates, and task status * Automate intake, reporting, and planning workflows Asana is a good fit when your app needs to work with project management, task tracking, or team planning directly from your app interface. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------ | :--------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Request intake to Asana | *Build an intake form. When someone submits, create an Asana task in the Operations project and assign it to the on-call manager.* | **Turn form submissions into trackable Asana tasks automatically.**
The app captures the submission and creates a properly formatted Asana task in the right project, with no manual copy-paste required. | | Project status dashboard | *Build a dashboard that reads tasks from our Launch project, groups by section, and highlights overdue items.* | **Give teams a live project view without leaving your app.**
The app reads current project data from Asana and displays tasks by section, assignee, or status. | | Automated task follow-ups | *Every weekday, find incomplete tasks due in 2 days and post a reminder summary in the app.* | **Reduce missed deadlines with automated follow-up logic.**
The app reads upcoming due dates from Asana and surfaces reminders directly in your app. | | Team workload view | *Show open tasks by assignee from Asana and flag teammates with more than 10 active tasks.* | **Surface workload imbalance for planning and staffing decisions.**
The app reads task assignments from Asana and organizes them into a focused workload view. | | Bug-to-task workflow | *When a bug report is submitted, create an Asana task with severity, reporter, and reproduction steps.* | **Standardize triage by routing bug reports into Asana with structure.**
The app turns incoming bug reports into properly formatted Asana tasks so nothing falls through the cracks. | ## How Asana connections work Each Asana connection is authenticated with a personal access token (PAT) issued by an Asana account. When you connect Asana, you authorize Lovable to call Asana on behalf of the account that issued the PAT. Within your Lovable workspace: * You can create multiple Asana connections. * Each connection uses a separate PAT. * Each connection can: * Be tied to a different Asana account * Access different Asana workspaces or projects, depending on the PAT's permissions * Multiple projects within a single workspace can use the same connection. This makes it easy to separate environments (for example, development and production) or manage multiple Asana accounts. The connection can only access data that the Asana account behind the PAT can access. If you revoke or rotate the PAT in Asana, the connection stops working until you update the token and reconnect. ## How to connect Asana Workspace **admins** and **owners** can connect Asana. ### Prerequisites Before connecting Asana, make sure you have: * An Asana account * An Asana personal access token (PAT) * Lovable workspace admin or owner role ### Set up your Asana connection Open **Connectors** → **App connectors** and select **Asana**. Click **Add connection**. In **Display name**, enter a name for the connection, for example `Asana (Prod)`. In **Personal access token**, paste your Asana PAT (for example, `1/xxxxxxxx...`), or click **Get value** to open Asana and generate one. The PAT inherits the permissions of the Asana account that issued it. Make sure that account has access to the workspaces and projects your app needs. Under **Who can access this connection**, keep access limited to specific people, or choose **Invite entire workspace**. Click **Connect**. The connection appears as enabled in **Connectors** → **App connectors** → **Asana**. When connected, your Lovable apps can start using Asana data. ## Limitations The Asana connector does not support: * Receiving incoming Asana webhooks or real-time event subscriptions. * Per-user Asana login where each end user connects their own Asana account. * Access to Asana data outside the permissions of the account that issued the PAT. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Ashby Source: https://docs.lovable.dev/integrations/ashby Connect Ashby to your Lovable app to work with jobs, candidates, applications, and hiring workflows through the Ashby API and Lovable’s connector gateway. [Ashby](https://www.ashbyhq.com/) is an **applicant tracking** and **recruiting operations** platform. The **Ashby** app connector lets your Lovable app call the [Ashby HTTP API](https://developers.ashbyhq.com/reference) through Lovable’s **connector gateway** using an **API key**, so secrets are not hard-coded in your repository. With Ashby connected, your app can: * List and manage **job postings** and **openings** * Search and view **candidates** and **applications** * Create and update **candidates** and **applications** programmatically (within API and permission limits) * Work with **interview** and **pipeline** data where exposed by the API Ashby is a strong fit when recruiting is centralized in Ashby and you want internal or candidate-facing tools that stay in sync with your ATS. ## Common use cases and example apps | Example app | Example prompt | Description | | :-------------------- | :-------------------------------------------------------------------------------------------- | :---------------------------------------------------------------- | | **Open roles page** | *Build a careers page that lists live Ashby jobs with title, location, and apply link.* | **Public job board** driven by Ashby as the source of truth. | | **Referral form** | *When an employee submits a referral, create or update a candidate in Ashby with their note.* | **Internal referrals** flow into the ATS without manual retyping. | | **Recruiter console** | *Build a small app that searches candidates by email and shows their current stage.* | **Fast lookup** for coordinators and recruiters. | | **Interview prep** | *For a given application ID, show upcoming interviews from Ashby.* | **Scheduling context** in one place for hiring managers. | | **Pipeline snapshot** | *Show counts of applications by stage for our flagship role.* | **Lightweight analytics** on top of Ashby data. | ## How Ashby connections work * **API key**: You create an API key in Ashby and paste it into Lovable as **API key**. The gateway attaches it to outbound requests; it is not exposed in client-side bundles as plain project text. * **Gateway**: Traffic goes through Lovable’s **connector gateway**. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for token handling and **per-project request limits**. **Ashby subscription** limits, API quotas, and feature availability are governed by **Ashby**, not Lovable. ## How to connect Ashby Workspace **admins** and **owners** can connect Ashby. When a connection is created, link it to the **projects** that should use Ashby. ### Prerequisites * An **Ashby** account with permission to create **API keys** * **Lovable workspace admin or owner** role ### Step 1: Create an Ashby API key 1. Sign in to Ashby and open **Admin** (or your organization’s settings area for integrations). 2. Go to **API keys** and create a key with the **minimum scopes** your app needs. Ashby’s UI entry point: [API keys](https://app.ashbyhq.com/admin/api-keys). For request shapes and endpoints, use [Ashby API reference](https://developers.ashbyhq.com/reference). ### Step 2: Connect Ashby in Lovable 1. Open **Connectors** → **App connectors** and select **Ashby**. 2. Click **Add connection**. 3. Enter a **Display name** (for example `Ashby Production`). 4. Paste the **API key**. 5. Click **Create** / **Save**. Lovable verifies the key against Ashby. ## Limitations * The connector represents **one** Ashby workspace API key per connection—not each candidate’s or employee’s personal Ashby login. * **Field-level and workflow rules** inside Ashby still apply; the API cannot bypass Ashby permissions you have not granted to the key. * **Gateway limits** apply as described in [Gateway-based connectors](/integrations/introduction#gateway-based-connectors). ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Attention Source: https://docs.lovable.dev/integrations/attention Connect your app to Attention, a sales conversation intelligence platform, to read meeting transcripts and scorecards, write back snippets and QA results, and ask natural-language questions across your sales conversations. [Attention](https://www.attention.com/) is a sales conversation intelligence and coaching platform that records, transcribes, and analyzes customer-facing meetings. The Attention connector lets your Lovable app read conversations, transcripts, and scorecards from Attention, and write back snippets, scorecard results, and conversation updates, so you can build dashboards, briefings, coaching tools, and QA workflows on top of your sales motion. With Attention, your app can: * List and retrieve sales conversations and meeting metadata * Read full meeting transcripts, participants, and timing details * Surface scorecards, insights, and coaching signals from the Attention API * Update, archive, or import conversations, and create snippets and scorecard results * Ask natural-language questions across your conversation history with Attention's semantic AI endpoint * Pull and manage organization, team, and user data * Combine conversation data with the rest of your app's content (CRM views, internal tools, AI summaries) The Attention connector is a good fit when your sales team already runs on Attention and you want to give the rest of the company a tailored window into the conversations happening there. ## Common use cases and example apps | Example app | Example prompt | Description | | :---------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Deal-room conversation viewer** | *Use Attention and build a deal-room view that lists recent conversations for an account, with transcripts, participants, and durations.* | **Bring meeting context next to the deal.**
The app fetches conversations from Attention, filters by account or owner, and renders transcripts and participant lists alongside whatever deal info your team already tracks. | | **Weekly sales briefing app** | *Use Attention and build a weekly briefing that summarizes last week's customer calls and emails it to the team.* | **Turn raw conversations into a leadership-ready digest.**
The app pulls the last seven days of conversations, summarizes themes and risks, and produces a recurring digest the team can scan in minutes. | | **Coaching and scorecard dashboard** | *Use Attention and build a coaching dashboard that shows scorecard results and trends per rep.* | **Make coaching signals legible across the team.**
The app reads scorecards and conversation metadata from Attention and presents trends per rep, so managers can spot what to coach on next. | | **Ask-your-calls chatbot** | *Use Attention and build a chatbot that answers questions about our sales calls, like "what objections came up about pricing last month?"* | **Query meetings in plain English**
The app uses Attention's Ask Attention endpoint to run semantic queries across conversations and returns grounded answers with source calls. | | **Auto-tagging and QA tool** | *Use Attention and build a tool that submits scorecard results and updates conversations after an external QA review.* | **Push structured QA back into Attention.**
The app reads conversations, lets reviewers score them in a custom UI, then writes scorecard results and updates conversation metadata back via the Attention API. | | **Onboarding library for new reps** | *Use Attention and build an onboarding library of best-of calls grouped by deal stage.* | **Curate calls into a learning experience.**
The app pulls selected conversations from Attention and organizes them by stage or topic so new reps can ramp by listening to real customer calls. | | **Risk and pipeline review app** | *Use Attention and build a pipeline review that flags deals where recent calls mention risk language.* | **Surface risk signals from conversations.**
The app combines conversation transcripts and scorecards to highlight deals that need attention before the next forecast call. | | **Internal "voice of the customer" feed** | *Use Attention and build an internal feed of customer quotes pulled from recent meetings.* | **Distribute the voice of the customer across the company.**
The app surfaces highlights from Attention conversations as a feed product, support, and design teams can browse. | ## How to connect Attention Workspace **admins** and **owners** can connect Attention. You can create multiple Attention connections using different API keys. This is useful for separating environments (for example, development and production), isolating access for specific apps, or managing usage limits independently. When the connection is created, Attention can be linked to any project in the workspace. Multiple projects can use the same connection. ### Prerequisites Before connecting Attention, make sure you have: * An Attention account with admin role permissions in your organization * An Attention API key * Lovable workspace owner or admin role All API requests made through this connector use your Attention API key. Usage counts toward your Attention plan limits and billing is handled directly by Attention, not Lovable. ### Step 1: Create an Attention API key An **Attention API key** is an organization-level Bearer token that lets your Lovable app authenticate against Attention's v2 API. You must have **Admin** role permissions in Attention to create and manage organization-level API keys. To create an Attention API key: Go to [app.attention.tech](https://app.attention.tech) and sign in with Google, SSO, or your email and password. Click your profile avatar in the top-left corner and select **Settings** from the dropdown menu. In the sidebar, under the **Organization** section, select **API Keys**. Click **+ Create API Key** in the top-right corner and give the key a descriptive name, for example `Lovable integration`. After creation, an **API Key Created** modal will appear showing your key once. Copy the key and store it securely. Attention will not show it again. Your API key functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See Attention's docs for detailed instructions: [API authentication](https://docs.attention.com/api-authentication). ### Step 2: Connect Attention to Lovable You can create multiple connections using different API keys. To connect Attention: Go to **Connectors → App connectors** and select **Attention**. Click **Add connection**. 1. **Display name**: Name the connection, for example `Attention Prod`. 2. **API key**: Paste your Attention API key. 3. **Who can access this connection**: Keep access limited to specific people or invite the entire workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable validates the key against Attention before saving the connection. If the key is invalid or has been revoked, the connection will fail and you can paste a new one. When connected, your Lovable apps can start reading from and writing to conversations, transcripts, and related data from Attention. Attention API keys inherit the permissions of the Admin who creates them, there is no per-key scope picker. Any Lovable app linked to a connection can read **and write** any data the key has access to in Attention, including updating or archiving conversations, creating or deleting users, and managing teams. Only link the connection to projects that should have that level of access. ## Working with conversation data The Attention API returns rich conversation objects that include metadata, participants, and full transcripts, and supports updating, archiving, and importing conversations. When prompting Lovable, be specific about what you want. Conversations include sensitive customer information. Plan how the data is displayed in your app and who can see it before sharing the app broadly inside your company. ## Limitations The Attention connector cannot: * Receive Attention webhooks or real-time conversation events (poll the API on a schedule instead) * Support per-end-user Attention login (each end user connecting their own Attention account). All requests use the workspace API key, so every end user of your Lovable app sees the same Attention data. Attention enforces rate limits on its API. If you build apps that paginate through many conversations or run frequent background jobs, expect occasional `429 Too Many Requests` responses and add retry-with-backoff in your edge functions. If a request fails because the API key has been revoked or rotated in Attention, you'll need to generate a new key and reconnect. There is no automatic refresh for API keys. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to AWS Athena Source: https://docs.lovable.dev/integrations/aws-athena Connect your app to AWS Athena, the serverless SQL query service for data in Amazon S3, to run queries and power dashboards from your data lake. [Amazon Athena](https://aws.amazon.com/athena/) is a serverless query service that runs SQL directly against data stored in Amazon S3. The AWS Athena connector lets your Lovable app submit queries and read the results, so you can build dashboards, reports, and internal tools on top of your data lake without managing database servers. With AWS Athena, your app can: * Run SQL queries against data stored in S3 * Browse data catalogs, databases, and table schemas * Fetch query results as paginated rows * Power dashboards and reports with data lake queries * Reuse your existing Athena workgroups and result locations Athena queries are asynchronous: the app starts a query, Athena processes it, and the app fetches the results when the query finishes (typically within a few seconds). Lovable generates this flow for you. ## Common use cases and example apps | Example app | Example prompt | Description | | :-------------------- | :----------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- | | Analytics dashboard | *Use AWS Athena and build a dashboard that shows daily revenue and active users from our events table.* | **Turn data lake tables into live dashboards.**
The app runs aggregate queries against your S3 data and renders the results as charts. | | Log explorer | *Use AWS Athena and build a log search tool that filters our access logs by status code and date range.* | **Search large log archives with SQL.**
The app queries partitioned log tables in S3 and shows matching rows in a filterable table. | | SQL query console | *Use AWS Athena and build an internal tool where my team can run queries and download the results as CSV.* | **Give your team a lightweight query console.**
The app submits queries, polls until they finish, and renders the results with CSV export. | | Data catalog browser | *Use AWS Athena and build a browser that lists our databases, tables, and column schemas.* | **Make your data catalog explorable.**
The app lists databases and table metadata so anyone can see what data exists and how it's structured. | | KPI report | *Use AWS Athena and build a weekly report page that compares this week's signups and orders to last week's.* | **Publish recurring reports from data lake queries.**
The app runs comparison queries on demand and presents the results as a readable report. | | Customer usage portal | *Use AWS Athena and build a page where each customer sees their monthly usage from our billing exports.* | **Expose per-customer analytics from S3 exports.**
The app filters query results by customer and renders usage summaries. | ## How AWS Athena connections work Each AWS Athena connection is tied to a single AWS region, with an optional workgroup and query result location. When you connect AWS Athena, you provide IAM credentials, and Lovable's connector gateway signs every request with them. The credentials stay on the server and never reach your published app. Within your Lovable workspace: * You can create multiple AWS Athena connections. * Each connection targets a specific region, and optionally a workgroup and result location. * Each connection uses its own IAM credentials. * Multiple projects within a single workspace can use the same connection. This makes it easy to separate environments (for example, production and staging workgroups) or scope access per team. AWS Athena uses Lovable's gateway architecture for secure credential handling and automatic request signing. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. ## How to connect AWS Athena Workspace **admins** and **owners** can connect AWS Athena. When the connection is created, AWS Athena becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting AWS Athena, make sure you have: * An AWS account with data in S3 and tables defined in the Glue Data Catalog * An IAM user with the Athena, Glue, and S3 permissions listed below * Lovable workspace **owner** or **admin** role All queries made through this connector run in your AWS account. Athena charges based on the amount of data each query scans, and AWS bills you directly, not Lovable. ### Step 1: Create an IAM user with Athena access Before setting up the connection in Lovable, create an IAM user in AWS with the minimum permissions needed. Athena needs three kinds of access: the Athena API itself, the Glue Data Catalog (where table definitions live), and the S3 buckets holding your data and query results. Go to the [AWS IAM console](https://console.aws.amazon.com/iam/) and create a new IAM user, or use an existing one, for Lovable to use. Create and attach an inline policy, or managed policy, with the following permissions. Replace `YOUR-REGION`, `YOUR-ACCOUNT-ID`, `YOUR-WORKGROUP`, `YOUR-DATABASE`, `YOUR-DATA-BUCKET`, and `YOUR-RESULTS-BUCKET` with your actual values. ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "AthenaQueries", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:StopQueryExecution", "athena:GetQueryExecution", "athena:GetQueryResults", "athena:GetWorkGroup", "athena:ListDatabases", "athena:ListTableMetadata" ], "Resource": [ "arn:aws:athena:YOUR-REGION:YOUR-ACCOUNT-ID:workgroup/YOUR-WORKGROUP", "arn:aws:athena:YOUR-REGION:YOUR-ACCOUNT-ID:datacatalog/AwsDataCatalog" ] }, { "Sid": "GlueCatalog", "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions" ], "Resource": [ "arn:aws:glue:YOUR-REGION:YOUR-ACCOUNT-ID:catalog", "arn:aws:glue:YOUR-REGION:YOUR-ACCOUNT-ID:database/YOUR-DATABASE", "arn:aws:glue:YOUR-REGION:YOUR-ACCOUNT-ID:table/YOUR-DATABASE/*" ] }, { "Sid": "ReadData", "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::YOUR-DATA-BUCKET", "arn:aws:s3:::YOUR-DATA-BUCKET/*" ] }, { "Sid": "ResultLocation", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:GetBucketLocation", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::YOUR-RESULTS-BUCKET", "arn:aws:s3:::YOUR-RESULTS-BUCKET/*" ] } ] } ``` Keep the policy scoped to the workgroup, database, and buckets your app actually uses. Avoid wildcard (`*`) resources beyond the table and object paths shown above. The Glue permissions are required because Athena resolves table definitions through the Glue Data Catalog. A missing Glue permission is the most common cause of failing queries after the connection itself verifies successfully. This policy scopes Glue access to a single database, which is enough to run queries against it. If your app needs to list every database in the catalog (for example, to browse your data catalog), grant `glue:GetDatabase` and `glue:GetDatabases` on `arn:aws:glue:YOUR-REGION:YOUR-ACCOUNT-ID:database/*` instead. In the IAM user's **Security credentials** tab, create an access key. Save both the **Access key ID** and **Secret access key**, since you'll need them in the next step. The secret access key is shown only once and functions like a password. Store it securely and never commit it to a repository or share it publicly. If you lose it, create a new access key pair. For more detail, see [Identity and access management in Athena](https://docs.aws.amazon.com/athena/latest/ug/security-iam-athena.html) in the AWS documentation. ### Step 2: Connect AWS Athena to Lovable You can create multiple connections using different IAM credentials. Go to **Connectors → App connectors** and select **AWS Athena**. Click **Add connection**. 1. **Display name**: name the connection, for example `Athena Prod`. This name is only used inside Lovable to identify the connection. 2. **AWS region**: select the region where your Athena workgroup lives. The default is **US East (N. Virginia)**. 3. **Access key ID**: paste the IAM access key ID from the previous step. 4. **Secret access key**: paste the IAM secret access key paired with the access key ID. 5. **Workgroup** (optional): the Athena workgroup queries run in. Defaults to `primary`. 6. **Query result location** (optional): the S3 path where Athena writes query results, for example `s3://my-bucket/athena-results/`. Leave it empty if the workgroup enforces its own result location. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable verifies the credentials by looking up the configured workgroup in your region. If verification fails, check that the keys are correct and that the IAM policy includes `athena:GetWorkGroup` on the workgroup. When connected, anyone building in a project can ask Lovable in chat to link their project to AWS Athena (based on configured connection-level access). Your Lovable apps can then run SQL queries against your data in S3 and use the results. ## Limitations The AWS Athena connector cannot: * Call AWS services other than Athena. The gateway only forwards Athena API operations, so your app cannot read S3 objects or manage Glue resources directly through this connection. * Exceed the permissions of the IAM policy you attach. Queries fail if the credentials lack access to the data, the Glue Data Catalog, or the result location. * Run queries synchronously. Results are available only after Athena finishes processing the query. * Refresh or rotate access keys automatically. To rotate, create a new access key in IAM and update the Lovable connection. * Support per-end-user AWS login. Each connection represents a single set of IAM credentials shared across all projects linked to it. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to AWS S3 Source: https://docs.lovable.dev/integrations/aws-s3 Connect your app to AWS S3 to read and write CSV, JSON, Parquet, and other data files in S3 buckets from your Lovable apps. [Amazon S3](https://aws.amazon.com/s3/) is a cloud object storage service. It lets your Lovable app read and write data files such as CSV, JSON, Parquet, and more directly in your S3 buckets, so you can build apps that work with external datasets, batch exports, file uploads, and file-based data sources. With AWS S3, your app can: * Read CSV, JSON, and other data files from S3 buckets * Upload files to S3 buckets (when write access is enabled) * List and browse objects in a bucket with prefix filtering * Integrate external data sources into your Lovable app * Access batch data exports from enterprise data pipelines AWS S3 is a good fit when your app needs to read or write files in S3, such as analytics exports, data pipeline outputs, user uploads, or shared datasets. ## Common use cases and example apps | Example app | Example prompt | Description | | :-------------------- | :--------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Data explorer | *Build a data explorer that lists files in my S3 bucket and lets me preview CSV and JSON files.* | **Browse and preview files stored in S3 without leaving your app.**
The app lists objects in the bucket and renders previews of supported file formats inline. | | Analytics dashboard | *Build a dashboard that reads a daily export CSV from S3 and shows charts for revenue and user signups.* | **Turn S3 data exports into live dashboards.**
The app reads the latest export file from your bucket and visualizes key metrics automatically. | | Report viewer | *Build an internal report viewer that loads JSON reports from S3 and displays them in a searchable table.* | **Give your team a clean interface to browse reports.**
The app pulls JSON files from a specific S3 prefix and renders them as filterable, sortable tables. | | File download portal | *Build a file download portal where users can browse and download files from our shared S3 bucket.* | **Create a simple self-service file access layer on top of S3.**
The app lists available files and lets users download them directly, without needing AWS console access. | | File upload app | *Build an app where users can upload CSV files to our S3 bucket for processing.* | **Accept file uploads directly into S3.**
The app uploads files via signed URLs, letting users submit data without needing AWS credentials. | | Data pipeline monitor | *Build a tool that checks my S3 bucket for new data files and shows when each pipeline last wrote output.* | **Monitor data pipeline health by tracking file freshness.**
The app lists objects by prefix and surfaces the last-modified timestamps so you can spot stale or missing exports. | ## How AWS S3 connections work Each AWS S3 connection is tied to a single S3 bucket. When you connect AWS S3, you provide IAM credentials with access to that bucket. By default, connections are read-only, but you can enable read-write access to allow file uploads. Within your Lovable workspace: * You can create multiple AWS S3 connections. * Each connection targets a specific bucket and AWS region. * Each connection uses its own IAM credentials. * Multiple projects within a single workspace can use the same connection. This makes it easy to connect different buckets (for example, production data and staging data) or separate access by team. AWS S3 uses Lovable's gateway architecture for secure credential handling and automatic request signing. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. By default, each AWS S3 connection has **read-only** access. To enable file uploads, set the **Access type** to **Read & write** when creating or editing the connection. Even with write access enabled, the connector does not support deleting objects. ## How to connect AWS S3 Workspace **admins** and **owners** can connect AWS S3. When a connection is created, the S3 bucket becomes available across all projects in the workspace. ### Prerequisites Before connecting AWS S3, make sure you have: * An AWS account with access to the S3 bucket you want to connect * An IAM user with the appropriate S3 permissions (see below) * The bucket name and AWS region * Lovable workspace admin or owner role ### Step 1: Create an IAM user with S3 access Before setting up the connection in Lovable, create an IAM user in AWS with the minimum permissions needed. Go to the [AWS IAM console](https://console.aws.amazon.com/iam/) and create a new IAM user, or use an existing one, for Lovable to use. Create and attach an inline policy, or managed policy, with the following permissions. Replace `YOUR-BUCKET-NAME` with your actual bucket name. For **read-only** access: ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "ListBucket", "Effect": "Allow", "Action": ["s3:ListBucket", "s3:GetBucketLocation"], "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME" }, { "Sid": "ReadObjects", "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*" } ] } ``` For **read and write** access (includes upload): ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "ListBucket", "Effect": "Allow", "Action": ["s3:ListBucket", "s3:GetBucketLocation"], "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME" }, { "Sid": "ReadWriteObjects", "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*" } ] } ``` Keep the policy scoped to only the bucket you want to connect. Avoid using wildcard (`*`) resources. In the IAM user's **Security credentials** tab, create an access key. Save both the **Access Key ID** and **Secret Access Key**, since you'll need them in the next step. The secret access key is shown only once. Store it securely. If you lose it, you'll need to create a new access key pair. ### Step 2: Connect AWS S3 to Lovable When you connect AWS S3, the bucket's contents will be accessible to all users in your workspace. Open **Connectors** → **App connectors** and select **AWS S3**. Click **Add connection**. In **Display name**, enter a name for the connection, for example `S3 (Production Data)`. Fill in the required fields: * **Bucket name**: the name of the S3 bucket (for example, `my-data-bucket`) * **AWS region**: the region where the bucket is located (for example, `us-east-1`) * **Access key ID**: the IAM access key ID from the previous step * **Secret access key**: the IAM secret access key from the previous step Optionally, expand **Advanced settings** to configure: * **Access type**: choose **Read only** (default) or **Read & write**. Read & write enables file uploads via signed URLs. Make sure the IAM policy includes `s3:PutObject` if you enable this. Click **Connect**. Lovable verifies the credentials by checking access to the bucket. If verification succeeds, the connection is ready to use. When connected, your Lovable apps can start reading data from the S3 bucket. ## CORS configuration for signed URLs File downloads and uploads use signed URLs, where the browser accesses S3 directly. For this to work, your S3 bucket must have a CORS (Cross-Origin Resource Sharing) policy that allows requests from your app's origin. Without it, the browser will block the request. To configure CORS on your bucket: 1. Open the [S3 console](https://console.aws.amazon.com/s3/) and select your bucket. 2. Go to **Permissions → Cross-origin resource sharing (CORS)**. 3. Add a CORS configuration. Replace `https://your-app-id.lovable.app` with your app's actual URL: ```json theme={null} [ { "AllowedHeaders": ["*"], "AllowedMethods": ["GET", "PUT"], "AllowedOrigins": ["https://your-app-id.lovable.app"], "ExposeHeaders": ["ETag"], "MaxAgeSeconds": 3600 } ] ``` If you only need downloads, you can restrict `AllowedMethods` to `["GET"]`. Add `"PUT"` only if you have write access enabled. You can find your app's origin URL in the browser address bar when previewing your Lovable app. Avoid using `"*"` for `AllowedOrigins` in production. Restrict it to your app's specific origin to follow the principle of least privilege. ## Limitations The AWS S3 connector does not support: * Deleting objects in the bucket * Connecting to S3-compatible services other than AWS S3, such as MinIO or DigitalOcean Spaces * Per-user AWS login where each end user connects their own AWS account * Real-time event notifications or S3 event triggers ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to BigQuery Source: https://docs.lovable.dev/integrations/bigquery Connect Google BigQuery to your Lovable app by signing in with Google (OAuth) or using Workload Identity Federation. Run SQL, explore datasets and schemas, and build analytics features without storing long-lived GCP keys in your project. [Google BigQuery](https://cloud.google.com/bigquery) is a serverless data warehouse for analytics at scale. The **BigQuery** app connector lets your Lovable app call the BigQuery API through Lovable’s secure gateway. You can connect by **signing in with your Google account** or with **Workload Identity Federation (WIF)**, so you never paste long-lived service account keys into Lovable. With BigQuery connected, your app can: * Query datasets and tables using **standard SQL** * Explore **schema metadata** (projects, datasets, tables, columns) * Run **parameterized queries** with cost guardrails in mind * Read from **views** and **materialized views** BigQuery fits when your data already lives in GCP, or when you want warehouse-scale analytics, reporting, and dashboards backed by SQL. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------ | :------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Executive metrics dashboard** | *Build a dashboard that shows weekly revenue and signups from your BigQuery `marts` tables, with filters by region.* | **Turn warehouse tables into charts in your app.**
The app runs SQL against BigQuery and renders KPIs and trends for stakeholders. | | **Internal reporting tool** | *Build an internal app where your team can run approved SQL reports against dataset `analytics` and export CSV.* | **Self-serve reporting on curated datasets.**
The app submits parameterized queries and returns result sets without giving users direct GCP console access. | | **Dataset explorer** | *Build a tool that lists datasets and tables I can access and shows column types and row counts.* | **Browse what’s in the warehouse.**
The app uses metadata APIs and lightweight queries to describe tables and schemas. | | **Customer health view** | *Join your CRM export in BigQuery with product usage and show a health score per account.* | **Combine modeled data for operational workflows.**
The app queries pre-joined or curated tables your data team maintains in BigQuery. | | **Scheduled insight page** | *Build a page that shows yesterday’s funnel metrics from BigQuery materialized views.* | **Surface daily or hourly aggregates.**
The app reads from views or summary tables that your pipelines refresh on a schedule. | | **Data validation UI** | *Build a small app that runs row counts and null checks on key columns after your pipeline runs.* | **Lightweight quality checks on top of SQL.**
The app runs targeted queries to confirm expectations after loads complete. | Exact behavior depends on **your datasets**, **IAM permissions** of the connected identity, and **what you ask Lovable to build**. ## How BigQuery connections work * **Authentication**: Connections authenticate in one of two ways. **Connect with Google** signs in with your Google account (OAuth). **Workload Identity Federation** exchanges identity tokens for short-lived service account credentials through Google’s security token service. In both modes, short-lived access tokens are obtained and refreshed through Lovable’s **connector gateway**, and no long-lived JSON keys are stored in your repo. * **Gateway**: Requests to the BigQuery API are proxied through the gateway. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for token handling and **per-project request limits**. * **Scopes**: Connections use the `https://www.googleapis.com/auth/bigquery` scope. What you can read or run still depends on **IAM and dataset permissions** in Google Cloud: your Google account’s permissions for Connect with Google, or the **service account’s** for Workload Identity Federation. * **Identity**: With **Connect with Google**, the connection acts as the Google account that authorized it and runs queries in the Google Cloud project you configure. With **Workload Identity Federation**, you configure Google Cloud to trust identity tokens for a **workspace-specific audience** and Lovable impersonates the **service account** you specify. BigQuery **query and storage costs** are billed by **Google Cloud** to your GCP billing account, based on bytes processed, slots, and related usage. Lovable does not bill you for BigQuery usage. ## How to connect BigQuery Who can create BigQuery connections depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections). When a connection is created, it can be **linked to projects** like other app connectors so deployed apps use it where allowed. ### Choose how to connect * **Connect with Google** is the fastest way to connect. You sign in with your Google account and pick the Google Cloud project that runs and is billed for your queries. The connection is tied to that Google account, which makes it a good fit for individuals, prototypes, and teams that already work through personal Google accounts. The connection stops working if that account loses access (see [Limitations](#limitations)). * **Workload Identity Federation** fits production and org-managed data access. The connection is not tied to any individual account: you grant access to a service account through your own Google Cloud IAM, access is auditable, and no long-lived keys are involved. The connection keeps working when people leave the team. Follow the setup steps below based on how you want to connect BigQuery. Sign in with your Google account and run queries in a Google Cloud project you choose. No Workload Identity Federation setup is required. **Prerequisites** Before connecting BigQuery, make sure you have: * A **Google account** with access to the BigQuery datasets you want to query * The **BigQuery Job User** role (`roles/bigquery.jobUser`) on the Google Cloud project that will run your queries * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) **Connect BigQuery in Lovable** Go to **Connectors → App connectors** and select **BigQuery**. Click **Add connection**. In **Display name**, enter a clear name (for example `BigQuery Analytics`). Under **Authentication**, select **Connect with Google**. In **Google Cloud project ID**, enter the project that runs and is billed for your queries. The connected Google account needs the **BigQuery Job User** role on this project. The project that runs your queries can be different from the project that stores the data. To read data stored in another project, keep the project that runs your queries in this field and fully qualify table names in your queries, for example `data-project.dataset.table`. Under **Who can use this connection**, decide who in your workspace can use the connection. You start as the only person with access: * **Only you** (default): leave the access list as is; only you can use the connection and its associated data. * **Invite specific people**: add workspace members by email; only you and the people you add can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. The Google sign-in window opens, so make sure your browser doesn’t block pop-ups. Sign in and approve the requested access. The flow requests one scope: **View and manage your data in Google BigQuery** (`https://www.googleapis.com/auth/bigquery`). The scope is an upper bound, not a grant. What the connection can actually do is decided by the IAM roles of the account you sign in with. Grant roles to match what you’re building: * **Read-only apps** (dashboards, reporting, data explorers): grant **BigQuery Data Viewer** on your datasets plus **BigQuery Job User** on the project. IAM blocks all writes, so the connection stays read-only even though the scope allows more. * **Read-write apps** (data entry, writebacks, table management): additionally grant **BigQuery Data Editor** on the datasets your app should change. Lovable requests this scope instead of Google’s read-only scope (`bigquery.readonly`) because the read-only scope doesn’t support the full BigQuery jobs API. Grant access to a service account through your own Google Cloud IAM. The connection is not tied to any individual account and uses no long-lived keys. In the connection form, this option is labeled **Bring Your Own Key**. **Prerequisites** Before connecting BigQuery, make sure you have: * A **Google Cloud project** with the **BigQuery API** enabled and the datasets you want to query * Permission to configure **IAM** and **Workload Identity Federation** in that project (or a dedicated admin project for identity pools) * A **Google Cloud service account** that has the BigQuery roles your use case needs (for example, **BigQuery Data Viewer** plus **BigQuery Job User** for read-only apps, adding **BigQuery Data Editor** on datasets your app should change) * Your **Lovable workspace ID** (you will need it for the OIDC **audience** in Google Cloud) * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) **Step 1: Configure Workload Identity Federation in Google Cloud** You need a **Workload Identity Pool** and an **OIDC provider** that trusts **Google-issued ID tokens** whose audience is Lovable’s connector gateway for **your workspace**. In the [Google Cloud console](https://console.cloud.google.com/), open **IAM & Admin → Workload Identity Federation** and create a **Workload Identity Pool** (or use an existing one). Add an **OIDC provider** to the pool with: * **Issuer URL**: `https://accounts.google.com` * **Allowed audiences**: `https://connector-gateway.lovable.dev/workspaces/`. Replace `` with your **Lovable workspace ID** (the same value Lovable uses for your workspace in URLs and settings). Grant `roles/iam.workloadIdentityUser` (or the appropriate role for your organization’s policy) so principals from this pool can impersonate the service account that will call BigQuery. Follow Google’s documentation for binding **workload identity pool principals** to a service account. It looks like `//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID`. This string is the **WIF audience** value Lovable expects. For detailed steps and IAM conditions, see Google Cloud documentation on [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation) and configuring **OIDC** providers. **Step 2: Connect BigQuery in Lovable** Go to **Connectors → App connectors** and select **BigQuery**. Click **Add connection**. In **Display name**, enter a clear name (for example `BigQuery Production` or `Analytics reporting`). Under **Authentication**, select **Bring Your Own Key**. This is the Workload Identity Federation option. In **WIF audience**, paste the **Workload Identity Provider** resource name from Google Cloud (the full `//iam.googleapis.com/projects/.../providers/...` string). In **Service account email**, enter the service account to impersonate for BigQuery access (for example `bq-reader@your-project.iam.gserviceaccount.com`). Under **Who can use this connection**, decide who in your workspace can use the connection. You start as the only person with access. Add specific workspace members by email, or click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Complete the flow to **create** or **verify** the connection. Lovable validates the federation setup through the gateway. When connected, anyone building in a project can ask Lovable in chat to link their project to BigQuery (based on configured connection-level access). Your Lovable apps can then run SQL queries against your datasets through the connector while you build and after you publish. ## Cost and safety practices BigQuery charges for **data scanned** by queries (and other usage). When implementing features in chat, prefer patterns that: * Use **`maximumBytesBilled`** (or equivalent) on query jobs so large scans fail **before** running when they would exceed your limit. * Filter **partitioned** tables on the partition column, avoid `SELECT *` during exploration, and use **`LIMIT`** while iterating. * Use **INFORMATION\_SCHEMA** and metadata APIs to discover schemas and partitions before heavy scans. See [BigQuery pricing](https://cloud.google.com/bigquery/pricing) and [best practices for controlling costs](https://cloud.google.com/bigquery/docs/best-practices-costs) in Google’s documentation. ## Limitations * **One identity per connection**: end users of your app do not sign in with their own Google accounts. A **Connect with Google** connection acts as the single Google account that authorized it, and a **Workload Identity Federation** connection acts as the configured service account. * **Connect with Google connections depend on that Google account**: if the account loses access to the project, or the authorization is revoked on the Google side (for example, from the account’s third-party access settings), the connection stops working until someone reconnects it in Lovable. * **Gateway limits** apply as described in [Gateway-based connectors](/integrations/introduction#gateway-based-connectors). * **IAM and dataset access** are entirely under your control in GCP; Lovable cannot grant access to tables the connected account or service account is not permitted to read. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Brevo Source: https://docs.lovable.dev/integrations/brevo Connect your app to Brevo to send transactional and marketing emails, manage contacts and lists, and trigger communication workflows from your Lovable app. [Brevo](https://www.brevo.com/) is a customer communication platform for email, SMS, contacts, and marketing automation. It's designed for apps that need transactional or marketing messaging, contact management, and multi-channel outreach as part of the product experience. With Brevo, your app can: * Send transactional and marketing email * Manage contacts, lists, and segmentation * Trigger SMS and WhatsApp campaigns when supported by your Brevo account * Track delivery and campaign performance events in Brevo Brevo is a good fit when your app needs branded, high-volume, or multi-channel messaging beyond what Lovable's built-in email provides, or when you already manage contacts and campaigns in Brevo. For standard transactional emails (signup confirmations, password resets, receipts, internal notifications), use the built-in [Lovable Emails](/features/custom-emails). Reach for the Brevo connector when you need marketing campaigns, contact lists, SMS/WhatsApp, lifecycle automation, or you already manage your messaging in Brevo. ## Common use cases and example apps | Example app | Example prompt | Description | | ----------------------------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Order confirmations and updates** | *Use Brevo to send order confirmation emails and shipping updates after checkout.* | **Send transactional notifications from app events.**
The app triggers Brevo email sends whenever order status changes. | | **CRM-driven outreach app** | *Use Brevo and build a dashboard that syncs leads into Brevo lists and sends targeted campaigns.* | **Keep contacts and campaigns connected to product actions.**
The app updates contact attributes and list membership before launching campaigns. | | **Onboarding lifecycle app** | *Use Brevo to send a welcome sequence over email and SMS when users sign up.* | **Automate onboarding communication across channels.**
The app enrolls users in Brevo workflows based on signup and activation milestones. | | **SMS reminders and alerts** | *Use Brevo to send SMS reminders 24 hours before each booking and one-time codes on login.* | **Deliver time-sensitive messages over SMS.**
The app sends scheduled or event-driven SMS through Brevo (where SMS is enabled on the account). | | **Internal alerts app** | *Use Brevo to send internal alert emails for failed payments or account risk events.* | **Deliver operational alerts quickly to internal teams.**
The app formats event data and sends notifications through Brevo. | | **Newsletter and announcements** | *Use Brevo to collect subscribers and send weekly product updates from my app.* | **Run recurring communication from one workflow.**
The app captures opt-ins, stores segmentation fields, and triggers campaign sends. | ## How to connect Brevo Workspace **admins** and **owners** can connect Brevo. You can create multiple Brevo connections using different API keys, which is useful for separating environments (for example, development and production), enforcing different feature scopes, or managing rate limits. When the connection is created, Brevo becomes available across all projects in the workspace. ### Prerequisites Before connecting Brevo, make sure you have: * A Brevo account * A Brevo REST API key that starts with `xkeysib-` * Lovable workspace owner or admin role Requests made through this connector are billed by Brevo based on your Brevo plan and usage. Billing is handled by Brevo, not Lovable. ### Step 1: Create a Brevo API key A Brevo REST API key lets your Lovable app authenticate with the Brevo API. You can create multiple keys with different permissions. To create an API key in Brevo: Sign in to [Brevo](https://app.brevo.com/) and open **Settings → SMTP & API → API keys**. Click **Generate a new API key**. * Give the key a descriptive name, for example `Lovable integration`. * Choose the permissions or scopes the key should have based on what your app needs (for example transactional email, contacts, SMS). * Click **Generate**. Copy the key and store it securely. Brevo API keys start with `xkeysib-`. Your API key functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See Brevo documentation for detailed instructions: [Brevo API reference](https://developers.brevo.com/reference). ### Step 2: Connect Brevo to Lovable You can create multiple connections using different API keys. Go to **Connectors → App connectors** and select **Brevo**. Click **Add connection**. 1. **Display name**: name the connection, for example `Brevo Prod`. 2. **API key**: paste your Brevo API key (`xkeysib-`). 3. **Who can access this connection**: keep access limited to specific people or invite the entire workspace. See [**Who can manage connections**](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. When connected, your Lovable apps can start sending email and SMS, managing contacts, and using Brevo's other API features. ## Limitations The Brevo connector cannot: * Receive incoming Brevo webhooks or delivery events directly through the connector (you can poll Brevo's events APIs instead, or configure webhooks to a Brevo-side endpoint outside Lovable) * Support per-end-user Brevo authentication (each connection uses a single shared API key, scoped to the workspace) * Refresh or revoke credentials automatically. To rotate, generate a new API key in Brevo and update the Lovable connection before app workflows can send requests again * Send SMS or WhatsApp messages on accounts where those channels are not enabled or have no available credits. Feature availability depends on your Brevo account, plan, and enabled channels. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Lovable API: Build with URL Source: https://docs.lovable.dev/integrations/build-with-url The Lovable API Build with URL feature is in open beta. Build and share Lovable apps from simple URLs, now with reference images and web pages. The Lovable API **Build with URL** feature lets you create applications by passing a prompt, and optionally reference images or web pages, through URL parameters. Embed it in a website, an internal tool, or an automation, and users generate a Lovable app with a single click. Each link tells Lovable *what* to build and optionally *what to reference*, such as images to work from or a live web page to draw layout and content from. Example: ```text wrap theme={null} https://lovable.dev/?autosubmit=true#prompt=Create%20a%20todo%20app ``` Clicking this link opens Lovable and begins building a to-do app. ## Use cases You can do the following with the Build with URL API: * Embed a **Build with Lovable** button on your website or application. When the user clicks it, Lovable opens and builds the app automatically. * Recreate or iterate on an existing web page by passing its URL as a reference. * Share predefined prompts via URLs with friends, colleagues, or social media. * Automate app generation as part of internal workflows. You can construct the URL yourself, or use the [Lovable Link Generator](https://lovable.dev/links). See below for more information. ## Base URL ```text wrap theme={null} https://lovable.dev/?autosubmit=true# ``` `autosubmit` (boolean): Set this to `true` to process the request automatically on load. ## URL with parameters Parameters go in the URL hash fragment (after `#`), not the query string: ```text wrap theme={null} https://lovable.dev/?autosubmit=true#prompt=YOUR_PROMPT&images=IMAGE_URL&html=PAGE_URL ``` ### Parameters | Parameter | Type | Description | Required/Optional | | --------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | | `prompt` | string | Text describing the application to build. Maximum 50,000 characters. Use URL encoding (for example, `%20` for spaces). Very long URLs might fail due to browser or parsing limits. | Required | | `images` | string | A publicly accessible image URL used as a visual reference. Repeat the key for several (`images=URL1&images=URL2`). Raster formats only: JPEG, PNG, and WebP. | Optional | | `html` | string | A publicly accessible web page URL. Lovable fetches the page and uses it as a reference for layout, content, and styling. Repeat the key for several. | Optional | ### Attachment limits * `images` and `html` share a combined limit of 10 reference attachments per link. * Every `images` and `html` URL must be reachable over public `http` or `https`, because Lovable's servers fetch them. Lovable skips private, authenticated, or `localhost` URLs. * Lovable ignores non-raster image URLs (such as SVG and GIF) and malformed or non-`http(s)` URLs. The rest of the link still builds. ## Lovable Link Generator Use the [Lovable Link Generator](https://lovable.dev/links) to build shareable URLs that generate apps with your chosen prompt, images, and web pages. It also handles URL encoding so links stay valid. 1. Enter your prompt, which describes the application to build (up to 50,000 characters). 2. Add reference images. The generator uploads each image to your Lovable account and references it in the link, so the image does not need to stay publicly hosted. 3. Add reference web pages by URL. Each page must be publicly reachable, because Lovable fetches it server-side. 4. Copy the generated Lovable URL and share it. Generating a link requires you to sign in to Lovable, because uploads are tied to your account. Images and web pages share a limit of 10 references per link. ## Build with URL examples **Basic app generation** ```text wrap theme={null} https://lovable.dev/?autosubmit=true#prompt=Create%20a%20todo%20app ``` **Reference image** ```text wrap theme={null} https://lovable.dev/?autosubmit=true#prompt=Build%20a%20landing%20page%20with%20this%20logo&images=https://img.com/logo.png ``` **Reference an existing web page** ```text wrap theme={null} https://lovable.dev/?autosubmit=true#prompt=Recreate%20this%20page&html=https://example.com/index.html ``` **Web page and image together** ```text wrap theme={null} https://lovable.dev/?autosubmit=true#prompt=Rebuild%20this%20page%20with%20our%20logo&html=https://example.com/index.html&images=https://img.com/logo.png ``` ## Best practices * Keep prompts concise and focused on core features. * For `html`, point at a standard web page served as a normal HTML document. Lovable may skip pages without a recognizable HTML structure. * Make sure every image and page URL is publicly reachable. * Use clear, descriptive language for the best generation results. * URL-encode special characters in the prompt and in URLs to avoid parsing issues. ## App creation and authentication flow for shared URLs When you click a **Build with URL** link: * If you are signed in, you select a workspace and Lovable starts building the app automatically. * If you are signed out, you sign up or log in first. After you authenticate, you select a workspace and Lovable builds the app automatically, preserving the original prompt and references. ## Error handling * Lovable silently drops reference URLs that are non-public, non-raster (for `images`), or not valid `http(s)`. The app still builds from the prompt and the remaining attachments. * Very long or malformed URLs can cause browser "URL too long" errors, incomplete parameter parsing, or failed autosubmission. Keep prompts within the 50,000-character limit, and prefer the Link Generator for long inputs. ## FAQ **Which image formats can I reference?** JPEG, PNG, and WebP. Lovable ignores other formats, such as SVG and GIF. **Do my image and page URLs need to be public?** Yes. Lovable fetches them server-side, so it skips private, authenticated, or `localhost` URLs. The Link Generator works around this for images by uploading them to your account. **How many references can I add to one link?** Up to 10 in total, combining images and web pages. **Can the Link Generator reference a web page?** Yes. Add the web page URL in the generator, alongside any images. Each page must be publicly reachable, because Lovable fetches it server-side. **What happens when a signed-out user clicks a link?** They sign up or log in first. After they authenticate, they select a workspace, and the app builds automatically with the original prompt and references preserved. # Connect your app to Calendly Source: https://docs.lovable.dev/integrations/calendly Connect your app to Calendly, a scheduling automation platform, to build booking flows, event dashboards, and meeting workflows. [Calendly](https://calendly.com/) is a scheduling automation platform for booking meetings and managing appointment workflows. The Calendly connector lets your Lovable app read scheduled events, list event types, fetch invitee details, create single-use scheduling links, and cancel scheduled events from a connected Calendly account. With Calendly, your app can: * Read the connected user and organization profile * List event types and scheduled events with filters and pagination * Fetch invitee details for scheduled events * Create single-use scheduling links for embedded booking flows * Cancel scheduled events on behalf of the connected user The Calendly connector is a good fit for booking portals, sales handoff tools, customer success dashboards, recruiting workflows, and internal scheduling apps that need to use Calendly account data inside a custom product. ## Common use cases and example apps | Example app | Example prompt | Description | | :----------------------- | :--------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Booking portal | *Use Calendly and build a booking portal that creates a single-use scheduling link when a visitor chooses an event type.* | **Create a custom booking entry point backed by Calendly.**
The app lists available event types, creates a single-use scheduling link, and sends the visitor into the right Calendly booking flow. | | Meeting dashboard | *Use Calendly and build a dashboard that shows upcoming scheduled events for our team.* | **Track scheduled meetings from a connected Calendly account.**
The app reads the connected user, lists scheduled events, and displays upcoming meetings with invitee details. | | Sales handoff tracker | *Use Calendly and build a sales handoff tool that shows booked demos and lets our team mark follow-up status.* | **Turn Calendly demos into a structured sales workflow.**
The app pulls scheduled events and invitees, links them to internal follow-up records, and helps the team track next steps. | | Recruiting scheduler | *Use Calendly and build a recruiting dashboard that lists candidate interviews by event type and date.* | **Organize candidate interviews from Calendly.**
The app filters scheduled events by event type, shows interview details, and gives recruiters a focused view of upcoming conversations. | | Customer success planner | *Use Calendly and build a customer success planner that shows renewal calls, kickoff meetings, and invitee contact details.* | **Give account teams one place to review customer meetings.**
The app fetches scheduled events and invitees, groups meetings by account, and keeps customer touchpoints visible. | | Cancellation workflow | *Use Calendly and build an admin tool that lets our operations team cancel selected scheduled events with a reason.* | **Manage selected Calendly events from an internal tool.**
The app lists scheduled events, lets approved teammates choose an event, and sends a cancellation request through Calendly. | ## How to connect Calendly Workspace **admins** and **owners** can connect Calendly. You can create multiple Calendly connections using different accounts, which is useful for separating environments or managing different teams. When the connection is created, Calendly becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Calendly, make sure you have: * A Calendly account * Lovable workspace **owner** or **admin** role All API requests made through this connector count against Calendly API limits according to your Calendly plan. Billing and quota are handled directly by Calendly, not Lovable. ### Set up your Calendly connection Go to **Connectors**, then **App connectors**, and select **Calendly**. Click **Add connection**. In **Display name**, name the connection (for example, `Calendly Prod`). This name is only used inside Lovable to identify the connection. Expand **Advanced settings** to choose the permissions your app requests. Lovable pre-selects default scopes that cover common scheduling, booking, and event management use cases. You can enable additional scopes for more advanced workflows or turn off defaults you don't need. The `users:read` scope is required and cannot be disabled. Only the scopes you select are sent to Calendly during authorization, and Lovable exposes the approved scopes to the agent so it knows which Calendly capabilities your app can use. **Default scopes (pre-selected):** | Scope | Description | | :------------------------------------------------- | :----------------------------------------------------------- | | Users: read (`users:read`) | Read the connected Calendly user profile. *(Required)* | | Organizations: read (`organizations:read`) | Read organization details, memberships, and invitations. | | Event types: read (`event_types:read`) | Read event type details and available times. | | Scheduled events: read (`scheduled_events:read`) | Read scheduled events, invitees, and no-show data. | | Availability: read (`availability:read`) | Read user and event-type availability. | | Scheduling links: write (`scheduling_links:write`) | Create single-use scheduling links from event types. | | Shares: write (`shares:write`) | Create and customize single-use scheduling links. | | Scheduled events: write (`scheduled_events:write`) | Create invitees, cancel events, and manage invitee no-shows. | **Additional scopes (off by default):** | Scope | Description | | :------------------------------------------------------------- | :----------------------------------------------------- | | Event types: write (`event_types:write`) | Create or update event types. | | Availability: write (`availability:write`) | Update event type availability. | | Locations: read (`locations:read`) | Read configured meeting locations. | | Routing forms: read (`routing_forms:read`) | Read routing forms and submissions. | | Groups: read (`groups:read`) | Read group details and relationships. | | Organizations: write (`organizations:write`) | Invite or remove organization users. | | Webhooks: read (`webhooks:read`) | Read webhook subscriptions and sample payloads. | | Webhooks: write (`webhooks:write`) | Create or delete webhook subscriptions. | | Activity log: read (`activity_log:read`) | Read organization activity logs. | | Data compliance: write (`data_compliance:write`) | Delete invitee or event data for compliance workflows. | | Outgoing communications: read (`outgoing_communications:read`) | Read outgoing SMS and email communications. | | Contacts: read (`contacts:read`) | Read Calendly contacts. | | Contacts: write (`contacts:write`) | Create, update, and delete Calendly contacts. | **Pick scopes for common use cases:** * **Booking portals and meeting dashboards**: the defaults are enough. They cover reading event types, scheduled events, and invitees, and creating single-use scheduling links. * **Managing event types or availability from your app**: add `event_types:write` and `availability:write`. * **Routing form integrations**: add `routing_forms:read` to read form submissions and route invitees. * **Webhook automation**: add `webhooks:read` and `webhooks:write` to manage Calendly webhook subscriptions from your app. * **CRM-style contact sync**: add `contacts:read` and `contacts:write` to read or update Calendly contacts. * **Admin and compliance tooling**: add `organizations:write`, `activity_log:read`, and `data_compliance:write` for user management, audit views, or GDPR-style data deletion flows. For full scope documentation, see [Calendly's scope reference](https://developer.calendly.com/scopes). Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. The Calendly authorization window opens, so make sure your browser does not block pop-ups. If it does, Lovable redirects you instead. Sign in to Calendly if prompted, review the requested permissions, and click **Allow**. Lovable redirects you back with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to Calendly (based on configured connection-level access). Your Lovable apps can then read Calendly data and perform Calendly actions allowed by the scopes you approved. ## Limitations The Calendly connector cannot: * Access Calendly resources that are outside the scopes approved for the connection. * Use a Calendly endpoint that is unavailable on the connected Calendly plan. * Call Calendly directly from browser code. Apps should use server-side requests through the Lovable connector gateway. * Support per-end-user Calendly login. Each connection represents a single Calendly account shared across all projects linked to it. If Calendly authorization is revoked from the Calendly side, you need to reconnect the integration in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Chargebee Source: https://docs.lovable.dev/integrations/chargebee Connect your app to Chargebee, a subscription billing and revenue management platform, to manage customers, subscriptions, invoices, checkout, and billing workflows. [Chargebee](https://www.chargebee.com/) is a subscription billing and revenue management platform for managing customers, subscriptions, invoices, payments, product catalog data, hosted checkout, and billing portal flows. The Chargebee connector lets your Lovable app call the Chargebee API through a workspace-level connection. With Chargebee, your app can: * List and manage customers and subscriptions * Read invoices, credit notes, payments, and orders * Build billing workflows around products and item prices * Create hosted checkout pages and billing portal flows The Chargebee connector is a good fit when your app needs subscription billing data, customer billing workflows, or internal tools backed by your Chargebee account. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------- | :----------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Customer billing portal | *Use Chargebee and build a customer billing portal where customers can view their subscription, invoices, and payment status.* | **Give customers access to billing information from Chargebee.**
The app reads customer, subscription, invoice, and payment data from Chargebee and presents it in a self-service portal. | | Subscription admin dashboard | *Use Chargebee and build an admin dashboard for searching customers, viewing subscriptions, and checking invoice status.* | **Help operators manage subscription accounts in one place.**
The app lists Chargebee customers and subscriptions so support or finance teams can investigate account status. | | Checkout flow | *Use Chargebee and build a checkout flow that creates hosted checkout pages for subscription plans.* | **Start subscription checkout from your app.**
The app creates Chargebee hosted checkout pages and redirects customers to complete subscription signup. | | Revenue reporting app | *Use Chargebee and build a revenue dashboard showing recent invoices, payments, credit notes, and orders.* | **Turn billing activity into operational reporting.**
The app reads Chargebee billing records and summarizes recent revenue activity for your team. | | Plan management tool | *Use Chargebee and build an internal tool for reviewing products, item prices, and subscription plan details.* | **Surface product catalog data from Chargebee.**
The app reads Chargebee product and price data so teams can inspect plans without leaving the app. | | Renewal workflow tracker | *Use Chargebee and build a workflow tracker for upcoming subscription renewals and failed payments.* | **Track billing events that need follow-up.**
The app uses Chargebee subscription and payment data to highlight accounts that need attention. | ## How to connect Chargebee Workspace **admins** and **owners** can connect Chargebee. You can create multiple Chargebee connections using different API keys, which is useful for separating environments (for example, test and production) or connecting different Chargebee sites. When the connection is created, Chargebee becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Chargebee, make sure you have: * A Chargebee account * Your Chargebee site name, for example `acme-test` from `https://acme-test.chargebee.com` * A Chargebee API key * Lovable workspace owner or admin role All API requests made through this connector use your Chargebee account. API usage, limits, and billing are handled directly by Chargebee, not Lovable. ### Step 1: Get your Chargebee site name and API key A Chargebee API key lets your Lovable app authenticate with the Chargebee API for your connected site. You can create separate keys for different environments or apps. To find your site name and create a Chargebee API key: Sign in to [Chargebee](https://app.chargebee.com/login) with the account for the site you want to connect. Copy the site name from your Chargebee URL. For example, if your Chargebee URL is `https://acme-test.chargebee.com`, enter `acme-test` in Lovable. Follow Chargebee's API key instructions to open the API keys area for your site. Create a key for Lovable or copy an existing key with permissions for the Chargebee API actions your app needs. Use a descriptive name, for example `Lovable integration`. Copy the API key and store it securely. Your API key functions like a password. Keep it secure and never share it publicly. You need it in the next step. See Chargebee documentation for more: [Chargebee API getting started](https://apidocs.chargebee.com/docs/api/getting-started#get-your-api-key). ### Step 2: Connect Chargebee to Lovable You can create multiple connections using different API keys. Go to **Connectors → App connectors** and select **Chargebee**. Click **Add connection**. * **Display name**: name the connection, for example `Chargebee Prod` or `Chargebee Test`. * **Site name**: enter your Chargebee site name without `.chargebee.com`, for example `acme-test`. * **API key**: paste your Chargebee API key. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to Chargebee (based on configured connection-level access). Your Lovable apps can then manage customers, subscriptions, invoices, checkout, and billing workflows through Chargebee. ## Limitations The Chargebee connector cannot: * Create or manage your Chargebee account or site configuration * Receive Chargebee webhooks directly through the connector * Rotate API keys automatically. To rotate a key, create a new key in Chargebee and update the Lovable connection * Support per-end-user Chargebee login. Each connection represents a single Chargebee account shared across all projects linked to it * Bypass Chargebee API permissions, limits, or billing rules for your account ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to ClickHouse Source: https://docs.lovable.dev/integrations/clickhouse Connect a ClickHouse database to your Lovable app over the HTTP interface. Run SQL queries, explore schemas, and build analytics features against self-hosted or ClickHouse Cloud databases. The **ClickHouse** app connector lets your Lovable app **run SQL queries** against your [ClickHouse](https://clickhouse.com/) database over the [HTTP interface](https://clickhouse.com/docs/interfaces/http). It works with both **self-hosted ClickHouse** and **ClickHouse Cloud**. With ClickHouse connected, your app can: * Run **SQL queries** over the ClickHouse HTTP interface * Explore **schema and table metadata** via system tables * Paginate large result sets with **`LIMIT`** and **`OFFSET`** * Enforce **per-query time limits** to keep requests bounded ## Common use cases and example apps | Example app | Example prompt | Description | | :-------------------------------- | :---------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | | **Real-time analytics dashboard** | *Build a dashboard that shows event counts and trends from my ClickHouse `events` table, refreshed every minute.* | **Turn high-volume event data into live charts.** The app runs SQL against ClickHouse and renders metrics that stay current. | | **Log explorer** | *Build a tool to search and filter our application logs stored in ClickHouse by service, level, and time range.* | **Self-serve search over large log tables.** The app submits filtered queries and returns results without console access. | | **Schema explorer** | *Build a tool that lists databases and tables and shows column types and row counts.* | **Browse what's in the database.** The app reads system tables to describe schemas. | | **Usage metering view** | *Show per-customer usage aggregated from our ClickHouse `usage` table, with date filters.* | **Surface aggregates from curated tables.** The app queries summary tables your pipelines maintain. | Exact behavior depends on **your tables**, the **permissions of the ClickHouse user** you connect with, and **what you ask Lovable to build**. ## How ClickHouse connections work * **HTTP interface**: The connector talks to the [ClickHouse HTTP interface](https://clickhouse.com/docs/interfaces/http) over HTTPS. You provide the full HTTPS URL of the interface, including the port (for example `https://abc123.eu-central-1.aws.clickhouse.cloud:8443`). * **Authentication**: ClickHouse uses HTTP basic auth. Provide the username and password of the database user you want to connect with. Credentials are stored securely in Lovable's gateway and are never exposed to the browser or your app's frontend code. * **Gateway**: Queries are proxied through Lovable's **connector gateway**, which injects the host and credentials so your app never sends them. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for token handling and per-project request limits. * **Data access**: What you can read or run depends entirely on the permissions of the ClickHouse user you connect with. **Use a read-only ClickHouse user.** Create a dedicated user with read-only access to only the databases and tables your app needs. The user's permissions determine what every app using the connection can query, so scoping it down limits what a query can reach. ## How to connect ClickHouse Who can connect ClickHouse depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections) for details. ### Prerequisites Before connecting in Lovable, make sure you have: * A **ClickHouse database** (self-hosted or ClickHouse Cloud) with the HTTP interface reachable over HTTPS * The **HTTPS URL** of your HTTP interface, including the port * A **ClickHouse user** (a read-only user is recommended) with access to the data your app needs * Permission to create connections in your Lovable workspace ### Set up your ClickHouse connection Open **Connectors** → **App connectors** and select **ClickHouse**. Click **Add connection**. In **Display name**, name the connection (for example, `ClickHouse Production` or `ClickHouse read-only`). * **HTTP Interface URL**: the full HTTPS URL of your ClickHouse HTTP interface, including the port (e.g. `https://abc123.eu-central-1.aws.clickhouse.cloud:8443`). * **Username**: the ClickHouse user for HTTP basic authentication. * **Password**: that user's password. To connect **without authentication**, leave both **Username** and **Password** empty. No auth header is sent and ClickHouse uses its `default` user. See the [HTTP interface docs](https://clickhouse.com/docs/interfaces/http) for details. Under **Who can use this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable verifies the connection through the gateway with a `SELECT 1` query. When connected, you can link the connection to projects and start building apps that query your ClickHouse data. ## Limitations * **No per-user data scoping.** Everyone using a connection queries with the same ClickHouse user. Use a read-only user scoped to the right databases, and restrict who can use the connection. * **Queries are synchronous.** There is no polling or server-side cursor. Paginate with SQL `LIMIT` / `OFFSET`, and raise the per-query time limit for long queries. * **No default database.** Qualify table names with the database (e.g. `mydb.users`). * **Gateway limits** apply as described in [Gateway-based connectors](/integrations/introduction#gateway-based-connectors). ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Contentful Source: https://docs.lovable.dev/integrations/contentful Connect your app to Contentful to fetch and display published content from your headless CMS, including entries, assets, and rich text. [Contentful](https://www.contentful.com/) is a headless CMS that separates content management from how content is presented. The Contentful connector lets your Lovable app fetch published content from your Contentful space using the Content Delivery API (CDA). Your app can then render content driven pages, product catalogs, blogs, or documentation powered by the content stored in Contentful. With Contentful, your app can: * Fetch published entries, assets, and content types from your space * Deliver content through Contentful's CDN backed Content Delivery API * Build dynamic pages and layouts powered by your CMS content * Filter and paginate entries by content type, locale, or field values * Render rich text fields in your app UI The Contentful connector is **read only**. It does not support creating, updating, or deleting content. All content management happens in the Contentful web app or through the Contentful Management API. ## Common use cases and example apps | Example app | Example prompt | Description | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Marketing and landing page sites** | *Use Contentful and build a marketing site where the homepage and feature pages are loaded from Contentful.* | **Build marketing pages powered by CMS content.**
The app fetches page entries from Contentful and renders them as components so editors can update text and images without changing code. | | **Product catalog apps** | *Use Contentful and build a product catalog that shows products stored in my Contentful space with category filters.* | **Display product listings managed in Contentful.**
The app fetches product entries, renders product cards, and supports filtering and pagination based on fields stored in the CMS. | | **Blog and editorial platforms** | *Use Contentful and build a blog that loads articles from Contentful and renders rich text and images.* | **Create a blog backed by Contentful content.**
The app fetches article entries, resolves linked assets, and renders rich text fields as formatted content. | | **Documentation sites** | *Use Contentful and build a documentation site where each doc page is stored as an entry in Contentful.* | **Build documentation driven by CMS content.**
The app fetches documentation entries and generates navigation and pages from the content structure in Contentful. | | **Multilingual content apps** | *Use Contentful and build an app that loads content in the user's language using Contentful locales.* | **Serve localized content from Contentful.**
The app fetches entries in the requested locale and renders translated content based on the user's language. | | **Event and announcement pages** | *Use Contentful and build an event listing page that loads upcoming events from Contentful and sorts them by date.* | **Display event listings managed in Contentful.**
The app fetches event entries, sorts them by date fields, and renders upcoming events that editors maintain in the CMS. | ## How to connect Contentful Workspace **admins** and **owners** can connect Contentful. You can create multiple Contentful connections using different API keys or different spaces. This can be useful for separating development and production environments or connecting multiple Contentful spaces. When the connection is created, Contentful becomes available across all projects in the workspace. ### Prerequisites Before connecting Contentful, make sure you have: * A Contentful account with a space that contains published content * A **Content Delivery API (CDA) access token** for that space * Your **Space ID** * Lovable workspace owner or admin role All API requests made through this connector use your Content Delivery API access token. API usage counts toward your Contentful plan limits and billing is handled directly by Contentful, not Lovable. ### Step 1: Find your space ID and create a CDA access token Your Space ID and CDA access token are both available in the Contentful web app. **To find your Space ID:** 1. Log in to [app.contentful.com](https://app.contentful.com). 2. Open the space you want to connect. 3. Go to **Settings → General settings**. 4. Copy the **Space ID**. See Contentful documentation for detailed instructions: [Find space ID ](https://www.contentful.com/help/spaces/find-space-id) **To create a Content Delivery API access token:** 1. In the same space, go to **Settings → API keys**. 2. Click **Add API key** or open an existing key. 3. Give the key a name such as `Lovable integration`. 4. Copy the **Content Delivery API access token**. See Contentful documentation for detailed instructions: [Authentication](https://www.contentful.com/developers/docs/references/authentication/) Your access token functions like a password. Keep it secure and never share it publicly. You'll need both the Space ID and the access token in the next step. ### Step 2: Connect Contentful to Lovable 1. Open **Connectors** → **App connectors** and select **Contentful**. 2. Click **Add connection**. 3. Enter a **Display name**, for example `Contentful Prod`. 4. Enter your **Space ID**. 5. Enter your **Content Delivery API access token**. 6. Click **Connect**. When connected, your Lovable apps can start fetching content from your Contentful space. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Databricks Source: https://docs.lovable.dev/integrations/databricks Connect your app to Databricks to query warehouse data, build live dashboards, and power data-driven tools using your existing tables and views. [Databricks](https://www.databricks.com/) is a data intelligence platform that lets your Lovable app work with warehouse data, SQL queries, and cluster resources. The Databricks connector lets you build apps and dashboards on top of your existing Databricks data without exporting CSVs or waiting for engineering tickets. With Databricks, your app can: * Run SQL queries against your warehouse data * List and manage SQL warehouses * List clusters in your Databricks workspace * Build live dashboards that query data in real time Authentication uses a Databricks service principal. Your credentials are stored securely in Lovable's gateway and are never exposed to the browser or your app's frontend code. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Live KPI dashboard** | *Build a dashboard that queries our Databricks warehouse and shows MRR, DAU, and churn rate. Auto-refresh every 5 minutes.* | **Replace static slides with a live dashboard on your warehouse data.** The app queries Databricks directly and displays key metrics that stay up to date without manual exports. | | **Revenue pipeline tracker** | *Build a pipeline tracker that pulls revenue and deal data from our Databricks tables and shows a funnel view with filters by region and quarter.* | **Give RevOps a self-serve view of pipeline data that lives in the warehouse.** The app queries Databricks tables where your CRM data lands and presents it in a structured, filterable view. | | **Team metrics explorer** | *Build a metrics explorer where users pick a team and date range, then see charts for their key metrics pulled from Databricks.* | **Let teams explore their own metrics without filing data requests.** The app runs parameterized SQL queries and renders results as charts, scoped to each team's data. | | **Data quality monitor** | *Build an internal tool that runs data quality checks against our warehouse tables and flags anomalies.* | **Catch data issues before they reach downstream consumers.** The app runs validation queries on a schedule and surfaces failures in a clean internal view. | | **Executive summary bot** | *Build a Slack bot that answers natural language data questions by querying our Databricks warehouse.* | **Turn your warehouse into a conversational interface for leadership.** The app translates questions into SQL, queries Databricks, and posts formatted answers to Slack. | ## How Databricks connections work The Databricks connector uses **service principal authentication** (M2M OAuth). Instead of connecting as an individual user, you create a service principal in Databricks with access to specific tables and views, then provide its credentials to Lovable. ### What this means for data access The service principal's permissions determine what data is available to everyone who uses that connection. Lovable does not filter results based on the individual user's Databricks permissions. For example, if you create a service principal with access to HR tables, everyone with access to that connection in Lovable can query HR data. **Recommended approach: one service principal per access role.** Create separate service principals scoped to different data: * `databricks-engineering`: full warehouse access, only engineers get this connection in Lovable * `databricks-sales`: pipeline and revenue tables only, sales team gets this connection * `databricks-company`: company-wide safe metrics, everyone gets this connection Lovable controls who can use each connection. Databricks controls what each service principal can query. Together, they provide role-based data access without requiring per-user OAuth. You can create multiple Databricks connections in a workspace, each with a different service principal and different access settings. Databricks uses Lovable's gateway architecture for secure OAuth handling and automatic token refresh. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. ## How to connect Databricks Workspace **admins** and **owners** can connect Databricks. ### Prerequisites Before connecting, make sure you have: * A Databricks workspace with at least one SQL warehouse * A service principal configured in Databricks with an OAuth secret (see [Databricks M2M OAuth setup](https://docs.databricks.com/en/dev-tools/auth/oauth-m2m.html)) * The service principal's client ID and client secret * Your Databricks workspace URL (e.g. `https://dbc-abc123.cloud.databricks.com`) * Lovable workspace admin or owner role ### Set up your Databricks connection Open **Connectors** → **App connectors** and select **Databricks**. Click **Add connection**. In **Display name**, name the connection (for example, `Databricks Engineering` or `Databricks Sales`). Use a name that reflects the access level of the service principal. * **Workspace URL**: your Databricks workspace URL (e.g. `https://dbc-abc123.cloud.databricks.com`) * **Client ID**: the service principal's OAuth client ID * **Client secret**: the service principal's OAuth client secret Click **Create**. Lovable verifies the credentials and connects to your Databricks workspace. When connected, you can link the connection to projects and start building apps that query your Databricks data. ### Configure who has access After creating a connection, you can choose who in your workspace can use it. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for details. This is especially important for Databricks, since the service principal's access level determines what data is visible. Restricting connection access to the right team ensures that only authorized people can build with that data. ## Building a semantic layer Every Databricks use case benefits from a semantic layer: a shared definition of what your key metrics mean, which tables to use, and what assumptions they carry. What counts as a "daily active user"? How is MRR calculated? Which view should be used for churn, and does it exclude trials? Without this shared context, each app or dashboard risks computing the same metric differently. ### If you already have a semantic layer If your Databricks workspace already has a semantic layer (for example, dbt metrics, Unity Catalog tags, or a YAML definitions file), point Lovable to it: ```text wrap theme={null} Use our semantic layer at catalog.schema.metrics_definitions when computing any KPIs. MRR is defined there as monthly_recurring_revenue. ``` ### If you don't have one yet You can build a semantic layer quickly in Lovable using a dedicated project. Create a new project, connect it to Databricks, and ask the agent to explore your warehouse and draft definitions: ```text wrap theme={null} Let's build a full semantic layer for our Databricks warehouse. Please start by exploring the tables and forming your own understanding of the data. Create a sample dashboard that showcases your analysis of the key metrics, the tables they use, and the assumptions behind each query. We will walk through them together and correct anything that is wrong. Use these tables as the main starting point: [table names] ``` Drop in any existing context you have (prior dashboards, a data dictionary, a dbt schema file) and Lovable will incorporate it. Ask the agent to save the output as Markdown or YAML files in its project directory: ```text wrap theme={null} Save the finalized metric definitions as YAML files in this project. Other projects will reference them. ``` Once saved, other Lovable projects in the same Lovable workspace can reference that project's knowledge to get consistent metric definitions out of the box. ## Limitations * **No per-user data scoping with this connector.** With service principal authentication, everyone using a connection sees the same data (the service principal's data). Create separate service principals per access role, or use the Databricks **[app user connector](/integrations/app-user-connectors)** so each end user queries under their own Databricks login and permissions. * **No automatic caching.** Query results are not cached by default. You can ask Lovable to add caching logic to your app at your chosen interval. * **Published apps are publicly accessible.** Connection-level access controls who can build and edit, not who can use the published app. If your app surfaces sensitive data, add your own authentication layer before publishing. * **Customer-managed cost controls.** Lovable does not impose query cost caps. Use Databricks-side controls like warehouse auto-stop, query timeouts, and per-warehouse budgets to manage costs. See [Databricks usage and cost monitoring](https://docs.databricks.com/aws/en/admin/usage/) for details. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. ## FAQ No. Lovable enforces who on your team can **use** a connection. The service principal's access level determines what data is queryable. If the service principal can see HR tables, everyone with access to that connection can query HR tables. Create separate service principals per access role to scope data. Lovable does not impose query cost caps. Use Databricks-side controls to manage costs: warehouse auto-stop, query timeouts, and per-warehouse budgets. We recommend starting with a small warehouse and scaling up as needed. See [Databricks usage and cost monitoring](https://docs.databricks.com/aws/en/admin/usage/) for details. Not by default. Lovable queries Databricks at runtime with no automatic data replication or caching. Caching is opt-in: you can ask Lovable to add caching logic to your app at an interval you choose. The published app uses the service principal to query Databricks. Anyone with the app URL can see the results. Connection-level access only controls who can build and edit the project, not who can use the published app. If the data is sensitive, add your own authentication layer in the app before publishing. No. The service principal credentials are stored server-side in Lovable's gateway and are never exposed to the browser or your app's frontend code. # Connect your app to the dbt Semantic Layer Source: https://docs.lovable.dev/integrations/dbt-semantic-layer Connect your app to the dbt Semantic Layer to query governed metrics defined in dbt, sliced by dimensions and time, without writing warehouse SQL. The [dbt Semantic Layer](https://www.getdbt.com/product/semantic-layer) is dbt Cloud's API for governed metrics: definitions your data team maintains in dbt with MetricFlow, computed consistently wherever they are queried. The connector lets your Lovable app query those metrics directly instead of writing SQL against your warehouse. With the dbt Semantic Layer, your app can: * Query governed metrics sliced by dimensions and time grains * Discover the metrics and dimensions defined in your dbt project with metadata queries * Filter, order, and limit results * Read the same metric definitions used across your BI stack * Power dashboards, embedded analytics, and metric explorers The connector is **read-only**: your app reads metric values, while your data team continues to define and maintain the metrics in dbt. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Company KPI dashboard** | *Use the dbt Semantic Layer and build a KPI dashboard that shows monthly revenue and active customers with filters by region.* | **Turn governed metrics into charts in your app.**
The app queries metric values by month and region and renders trends everyone can trust. | | **Embedded analytics** | *Use the dbt Semantic Layer and build a customer-facing usage page that shows each account's key metrics over time.* | **Show customers metrics from your own data stack.**
The app slices metrics by account dimensions and presents them inside your product. | | **Metric explorer** | *Use the dbt Semantic Layer and build a metric explorer where I pick a metric, slice it by any dimension, and chart the result.* | **Self-serve exploration on top of defined metrics.**
The app discovers available metrics and dimensions with metadata queries and lets users combine them. | | **Natural-language metric questions** | *Use the dbt Semantic Layer and build a chat interface that answers questions like "what was revenue by region last quarter?"* | **Answer questions with governed numbers.**
The app maps each question to a metric query, so answers come from your dbt definitions rather than generated SQL. | | **Board and executive reporting** | *Use the dbt Semantic Layer and build an executive report page with quarterly trends for our core metrics.* | **Recurring reporting from a single source of truth.**
The app queries quarterly grains for the metrics leadership follows and lays them out as a report. | | **Team scorecard** | *Use the dbt Semantic Layer and build a team scorecard that compares this week's metrics against the previous week.* | **Track performance with consistent definitions.**
The app queries the same metrics at weekly grains and highlights week-over-week changes. | ## How dbt Semantic Layer connections work * **Queries**: Your app queries metrics through the GraphQL API at your Semantic Layer's `/api/graphql` endpoint. dbt's MetricFlow generates the warehouse SQL from your metric definitions. * **Gateway**: Requests are proxied through Lovable's [connector gateway](/integrations/introduction#gateway-based-connectors), which injects your dbt service token. The token is never exposed in app code. * **Environment**: Every Semantic Layer query includes an `environmentId` argument. Lovable syncs the environment ID from the connection to linked projects so app code can use it. Semantic Layer queries run through your dbt Cloud account and your data warehouse. Usage counts toward your dbt Cloud plan, and warehouse compute is billed by your warehouse provider, not by Lovable. ## How to connect the dbt Semantic Layer Who can connect the dbt Semantic Layer depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections) for details. Each connection queries one dbt environment. You can create multiple connections with different environment IDs or service tokens, for example to separate staging and production environments. ### Prerequisites Before connecting the dbt Semantic Layer, make sure you have: * A dbt Cloud account on a plan that includes the dbt Semantic Layer (Starter, Enterprise, or Enterprise+) * The dbt Semantic Layer configured for the environment you want to query, with MetricFlow metrics defined in your dbt project * Permission to create connections in your Lovable workspace ### Step 1: Get your credentials in dbt Cloud You need three values from dbt Cloud: the Semantic Layer host, the environment ID, and a service token. Sign in to dbt Cloud, open **Account settings**, select your project, and open its **Semantic Layer** settings. Copy the GraphQL API host shown in the Semantic Layer settings, for example `semantic-layer.cloud.getdbt.com`. Hosts are region-specific, so copy the exact value dbt shows for your account. Copy the numeric ID of the environment the Semantic Layer is configured for. This is the environment whose metrics your app queries. Go to **Account settings → API tokens → Service tokens** and create a token with the **Semantic Layer Only** and **Metadata Only** permission sets. Copy the token; it starts with `dbtc_`. Your service token functions like a password. Store it securely and never share it publicly. You'll need it in the next step. See dbt's documentation for detailed instructions: [Set up the dbt Semantic Layer](https://docs.getdbt.com/docs/use-dbt-semantic-layer/setup-sl). ### Step 2: Connect the dbt Semantic Layer to Lovable Go to **Connectors → App connectors** and select **dbt Semantic Layer**. Click **Add connection**. 1. **Display name**: name the connection, for example `dbt Semantic Layer Prod`. 2. **Semantic Layer host**: enter the GraphQL API host from your Semantic Layer settings, for example `semantic-layer.cloud.getdbt.com`. Enter the bare hostname only, without `https://` or a path. 3. **Environment ID**: enter the numeric dbt environment ID from the Semantic Layer settings. 4. **Service token**: paste your dbt service token (it starts with `dbtc_`). Under **Who can use this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable validates the credentials against your dbt environment, so the connection fails if the host, environment ID, or service token is wrong. When connected, anyone building in a project can ask Lovable in chat to link their project to the dbt Semantic Layer (based on configured connection-level access). Your Lovable apps can then query the metrics and dimensions defined in your dbt project. ## Limitations The dbt Semantic Layer connector is **read-only**. It cannot: * Create or modify dbt models, metrics, or jobs, or trigger dbt runs * Query data outside the metrics and dimensions defined in your dbt project * Connect to dbt Core alone (it requires dbt Cloud with the Semantic Layer enabled) * Query more than one dbt environment per connection (create a separate connection for each environment) * Support per-end-user dbt authentication (each connection uses a single service token shared by its linked projects) ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Lovable desktop app Source: https://docs.lovable.dev/integrations/desktop-app Use Lovable as a native desktop application. Connect local tools, manage multiple projects in tabs, and move faster with keyboard shortcuts. Lovable is available as a native desktop application for macOS and Windows. You get everything in the web app plus local MCP server support, multi-project tabs, and keyboard shortcuts. When using Lovable desktop, any processing that occurs locally on your device is your responsibility. Your use of Lovable desktop is subject to our [Lovable desktop terms](https://lovable.dev/desktop-app-terms). ## Requirements * **macOS** (Apple Silicon or Intel) or **Windows** * A Lovable account. The desktop app is available on **all plans, including Free**, at no extra cost. ## Download Download the latest version of Lovable Desktop for macOS. Download the latest version of Lovable Desktop for Windows. ## Keyboard shortcuts | Action | macOS | Windows | | ---------------------------- | ----------------------- | ------------------------- | | Open option menu | `Cmd+K` | `Ctrl+K` | | New project tab | `Cmd+T` | `Ctrl+T` | | Close current tab | `Cmd+W` | — | | Switch to tab 1–9 | `Cmd+1` through `Cmd+9` | `Ctrl+1` through `Ctrl+9` | | Open current page in browser | `Cmd+Shift+O` | `Ctrl+Shift+O` | | Find in page | `Cmd+F` | `Ctrl+F` | | Find next | `Cmd+G` | `Ctrl+G` | | Find previous | `Cmd+Shift+G` | `Ctrl+Shift+G` | | Zoom in | `Cmd+=` | `Ctrl+=` | | Zoom out | `Cmd+-` | `Ctrl+-` | | Reset zoom | `Cmd+0` | `Ctrl+0` | | Preferences | `Cmd+,` | `Ctrl+,` | ## Preview permissions When you preview an app in the desktop app, some browser features ask for your permission the first time an app uses them. Each prompt is scoped to that specific app. You can allow or deny the request, and you can select **always allow** so that app does not ask again. * **Clipboard**: an app can copy to your clipboard without asking. The first time an app tries to read from your clipboard, Lovable asks you to allow or deny it. * **Location**: the first time an app requests your location, Lovable asks you to allow or deny it. ## MCP servers The desktop app supports both **remote MCP servers** and **local MCP servers**. **Remote MCP servers** work the same as in the web app. Go to **Connectors** → **Chat connectors** to connect cloud-based tools like Notion, Linear, or Jira. See [Chat connectors](/integrations/mcp-servers) for the full list and setup instructions. For quick access to connectors from any location, use the [**command palette**](https://docs.lovable.dev/introduction/project-search-and-find#command-palette) (Cmd+K on Mac, Ctrl+K on Windows/Linux) and search for connectors. **Local MCP servers** connect to tools running directly on your machine. The most common examples are **Figma Desktop** and **Paper**, which expose a local MCP server when running on your computer. Connecting them lets the Lovable agent read your design files, inspect components, and use that context while building your app. ### Connect Figma Open the Figma desktop app and open any Design file. Switch to **Dev Mode** (`` toggle in the bottom toolbar, or press `Shift+D`), then click **Enable desktop MCP server**. In the Lovable desktop app, open **Connectors** → **Local MCP servers**. Figma appears in the list. Click **Enable**, then approve when prompted. ### Connect Paper Make sure Paper is installed and running on your machine. Open **Connectors** → **Local MCP servers**. Paper appears in the list. Click **Enable**, then approve when prompted. When connected, you can reference your local designs directly in chat. For example: ```text wrap theme={null} Build the onboarding flow based on the designs in my Figma file, matching the colors, typography, and component layout exactly. ``` ### Add a custom local MCP server You can connect any MCP server running locally on your machine, such as a custom internal tool or a locally hosted service. Open **Connectors** → **Local MCP servers** and click **Custom MCP**. Give the server a name and enter the connection details: a command and arguments for a local process, or a URL for a local HTTP server. Click **Add server**, then approve the connection when prompted. ### Security and approvals When a local MCP server requests access for the first time, the desktop app prompts you to approve it. You can review and remove connected local servers at any time in **Connectors** → **Local MCP servers**. ## FAQ Yes. The desktop app is free to download and uses your existing Lovable account and plan. All plans, credits, and workspace settings carry over. The Lovable agent requires an internet connection to run. If you lose connectivity, the app shows an offline message and resumes normally once your connection is restored. The desktop app checks for updates automatically. When a new version is available, it downloads in the background and installs the next time you quit the app. For critical updates, you may be prompted to update before continuing. Chat connectors (available in both the web app and desktop app) connect to remote cloud services like Notion, Linear, or Jira. Local MCP servers (desktop app only) connect to tools running directly on your machine, such as Figma Desktop or Paper. Local servers are only reachable from your computer, which is why they require the desktop app. For **Figma**, make sure you have a Design file open in Dev Mode and that you clicked **Enable desktop MCP server** inside Figma. For **Paper**, make sure the app is running. If the connector still does not appear in Lovable, restart the Lovable desktop app. You can also add the server manually under **Connectors** → **Local MCP servers** → **Custom MCP**. Yes. Your Lovable account works across desktop and web simultaneously. Projects, credits, and settings are shared. # Connect ElevenLabs to enable voice AI in your app Source: https://docs.lovable.dev/integrations/eleven-labs Connect your app to ElevenLabs, an AI audio platform, to generate high-quality speech and audio content. [ElevenLabs](https://elevenlabs.io/) is an AI audio platform that lets your Lovable app generate **spoken audio and voice-driven experiences**. It’s designed for apps that need realistic text-to-speech, character voices, or audio output as a core part of the product experience. With ElevenLabs, your app can: * Convert text into high-quality synthesized speech * Use character voices or branded narrators * Generate podcasts, audio summaries, or spoken content * Power real-time conversational or voice-based interactions * Support accessibility through screen-free or hands-free experiences ElevenLabs is a good fit when your app depends on **spoken output or audio-first interaction** rather than text-only interfaces. ## Common use cases and example apps | Example app | Example prompt | Description | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Voice-enabled assistants** | *Build a voice-enabled assistant. Users ask questions and the app responds aloud using ElevenLabs voices.* | **Create voice-enabled assistants that deliver spoken responses instead of text-only replies**.
The app accepts user input, generates a response, converts that response into spoken audio using a selected voice, and delivers audio as the primary output. | | **Daily briefing apps** | *Use ElevenLabs and build a daily briefing app that reads out metrics or summaries every morning.* | **Deliver daily briefings as audio so users can listen while multitasking**.
The app compiles a briefing from selected sources (for example metrics, dashboards, or summaries), generates a spoken version, and provides playback in-app. | | **Podcast and narrated content generators** | *Use ElevenLabs and build an app that turns articles or story prompts into narrated audio episodes.* | **Turn written content into narrated audio episodes users can listen to on demand**.
The app transforms articles or prompts into scripts, generates narration (optionally using multiple voices), and outputs complete audio episodes for on-demand listening.. | | **Children’s story and storytelling apps** | *Use ElevenLabs and build a story app that generates narrated stories with character voices.* | **Generate narrated stories with expressive character voices for immersive storytelling experiences**.
The app creates stories based on user-defined inputs, assigns voices to characters, and produces fully narrated audio as the primary output. | | **Learning and instructional apps** | *Use ElevenLabs and build a learning app that reads lessons or exercises aloud.* | **Support learning through spoken instruction and narrated educational content**.
The app converts lessons, exercises, or explanations into spoken audio and delivers narration as a core part of the learning experience. | | **Fitness, wellness, and guided experience apps** | *Use ElevenLabs and build a fitness or wellness app that delivers spoken guidance.* | **Provide guided experiences through audio-first instructions and prompts**.
The app generates spoken guidance for routines, sessions, or exercises and delivers audio continuously throughout the experience. | | **Accessibility features** | *Use ElevenLabs and build an app that reads content aloud for users who prefer or require audio output.* | **Enable audio-first access to app content so it can be consumed without relying on the screen**.
The app automatically generates spoken audio for relevant content and delivers audio as the primary way users consume information, supporting screen-free or hands-free use. | ## How to connect ElevenLabs Workspace **admins** and **owners** can connect ElevenLabs. You can create multiple ElevenLabs connections using different API keys, and with different access levels, which is useful for separating environments (for example, development and production) or managing rate limits. When the connection is created, ElevenLabs becomes available across all projects in the workspace. ### Prerequisites Before connecting ElevenLabs, make sure you have: * An ElevenLabs account and API key All audio generation or processing performed through this connector consumes ElevenLabs credits (based on the selected model and input length), and billing is handled directly by ElevenLabs, not Lovable. * Lovable workspace owner or admin role ### Step 1: Create an ElevenLabs account and API key An API key lets you connect to ElevenLabs API and use its features. You can create multiple keys with different access levels. To create an ElevenLabs API key: 1. Go to [ElevenLabs](https://elevenlabs.io/app/developers/api-keys?source=lovable) and set up your account. 2. In **Developers → API keys**, click **Create Key**. 3. Give the key a descriptive name, for example, `Lovable integration`. 4. Turn on **Restrict Key**. 5. Set a monthly **Credit Limit**. 6. Choose which feature endpoints this key can use, depending on what your app needs. 7. Copy the generated API key and store it securely. Your API key functions like a password. Keep it secure and never share it publicly. You’ll need it in the next step. ### Step 2: Connect ElevenLabs to Lovable You can create multiple connections using different API keys. To connect ElevenLabs: 1. Open **Connectors** → **App connectors** and select **ElevenLabs**. 2. Click **Add connection**. 3. **Display name**: name the connection, for example `ElevenLabs Prod`. 4. Under **Authentication**, enter your ElevenLabs API key (`sk_xxxxxxxx…`). 5. Click **Create**. When connected, your Lovable apps can start generating speech and audio using ElevenLabs. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect Firecrawl to scrape web data for your app Source: https://docs.lovable.dev/integrations/firecrawl Connect your app to Firecrawl, an AI-powered scraper and crawler, to extract structured data from websites. [Firecrawl](https://www.firecrawl.dev/) is a web scraping and crawling platform that lets your Lovable app work with **live website data**. It’s designed for apps that need to continuously fetch, update, and structure information from websites, rather than relying on one-time imports or static datasets. With Firecrawl, your app can: * Scrape URLs into structured JSON * Crawl entire websites, including sitemaps, subpages, and navigation * Extract clean text, metadata, product details, tables, and more * Handle JavaScript-heavy sites, lazy loading, and cookie modals * Re-fetch live data on a schedule to keep results up to date Firecrawl is a good fit when your app depends on **real-time or frequently changing website content**. ## Common use cases and example apps | Example app | Example prompt | Description | | ----------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Competitor trackers** | *Build a competitor tracker. Users add competitor URLs. Scrape each URL with Firecrawl, store snapshots, re-check on a schedule, and show what changed.* | **Monitor and analyze competitors in your space by tracking changes on their websites.**
User adds competitor URLs to track, and the app re-scrapes those URLs over time to highlight what changed, such as pricing pages, product updates, documentation revisions, or feature announcements. | | **Jobs aggregators** | *Build a jobs aggregator. Users pick companies from a preset list. Use Firecrawl to pull listings from each company’s careers page, structure the results, keep them updated, and highlight new roles.* | **Pull job listings from multiple sources (for example, Greenhouse, Lever, or Workday) and present them in one unified interface.**
User selects companies from a preset list, and the app scrapes listings into structured results and keeps the feed updated as new roles appear. | | **Lead enrichment tools** | *Build a lead enrichment tool. Users enter company domains. Crawl key pages with Firecrawl (about, team, careers, contact) and extract publicly available company details into a structured profile.* | **Enrich company profiles using publicly available information from company websites.**
User pastes a company domain (or uploads a list), and the app scans key pages to extract people and company information, tech stack signals, locations, careers, and contact details, saving the extracted fields for each company. | | **E-commerce price monitors** | *Build a price monitor. Users save product URLs. Use Firecrawl to extract price and availability, check on a schedule, store history, and alert on changes.* | **Track product availability and pricing across e-commerce sites.**
User saves product URLs, and the app checks them on a schedule, records snapshots, flags changes, and alerts users when prices drop or products come back in stock. | | **Brand asset extractors** | *Build a brand kit extractor. Users enter a website URL. Use Firecrawl to extract colors, fonts, and logos, and output a simple brand kit.* | **Generate lightweight brand kits from any website.**
User enters a company URL, and the app scrapes brand-related pages to extract fonts, colors, logos, and style tokens. | | **Knowledge extractors** | *Build a knowledge extractor. Users paste a URL. Use Firecrawl to return clean markdown + metadata, save it, and allow re-sync.* | **Turn any webpage into clean, reusable content**.
User pastes a URL, and the app converts the page into clean markdown, structured metadata, readable text, and useful structured elements like tables, making it ready for search, summarization, or reuse. | ## How to connect Firecrawl Who can create Firecrawl connections depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections). When adding a connection, you can choose between: * **Managed by Lovable** (no Firecrawl account or API key required) * **Your own credentials** (bring your own Firecrawl API key; labeled **Bring Your Own Key** in the connection form) When a connection is created, it can be **linked to projects** like other app connectors so deployed apps use it where allowed. Follow the setup steps below based on how you want to connect Firecrawl. Choose this option if you want the fastest setup. You don’t need to create a Firecrawl account or API key. Lovable provides and manages the credentials for you. You can create only one managed Firecrawl connection per workspace. Go to **Connectors → App connectors** and select **Firecrawl**. Click **Add connection**. In **Display name**, name the connection (for example, `Firecrawl Prod`). Under **Authentication**, select **Managed by Lovable**. Managed connections are shared with the **entire workspace** by default. To limit who can use the connection, click **Restrict to specific people** under **Who can use this connection**. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Bring your own credentials if you want to use your own Firecrawl account, manage billing directly, or control rate limits and environments with your own API keys. In the connection form, this option is labeled **Bring Your Own Key**. All scraping and crawling performed through this connector consumes your Firecrawl usage, and billing is handled directly by Firecrawl, not Lovable. You can create multiple Firecrawl connections using different API keys, which is useful for separating environments (for example, development and production) or managing rate limits. ### Prerequisites Before connecting Firecrawl, make sure you have: * A Firecrawl account and API key * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) ### Step 1: Create a Firecrawl account and API key You can create multiple API keys in Firecrawl. This is useful for different environments or rate limits. Go to [Firecrawl](https://www.firecrawl.dev/) and set up your account. Go to your Firecrawl dashboard and navigate to the [API Keys page](https://www.firecrawl.dev/app/api-keys). Click **Create** and give your key a descriptive name, for example, `Lovable integration`. Copy the generated API key and store it securely. Your API key functions like a password. Keep it secure and never share it publicly. You’ll need it in the next step. Firecrawl provides free credits when you sign up, which is enough to test your connection and complete this setup. ### Step 2: Connect Firecrawl to Lovable Go to **Connectors → App connectors** and select **Firecrawl**. Click **Add connection**. In **Display name**, name the connection (for example, `Firecrawl Prod`). Under **Authentication**, select **Bring Your Own Key**. In **API key**, paste your Firecrawl API key (`fc-xxxxxxxx…`). Under **Who can use this connection**, decide who in your workspace can use the connection. You start as the only person with access: * **Only you** (default): leave the access list as is; only you can use the connection and its associated data. * **Invite specific people**: add workspace members by email; only you and the people you add can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to Firecrawl (based on configured connection-level access). Your Lovable apps can then use Firecrawl to scrape, crawl, and keep website data up to date. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Fireflies Source: https://docs.lovable.dev/integrations/fireflies Connect your app to Fireflies to access meeting transcripts, summaries, and conversation insights. [Fireflies.ai](https://fireflies.ai/) records, transcribes, and summarizes meetings across Zoom, Google Meet, Microsoft Teams, and other platforms. The Fireflies connector enables meeting data integration for your app, allowing you to surface transcripts, search conversations, and display action items directly in your app. With Fireflies, your app can: * Retrieve meeting transcripts, AI summaries, and speaker-attributed content * Search and analyze conversations across your organization * Build workflows on top of meeting intelligence * Sync notes and action items into your product Fireflies is a good fit when your app needs access to meeting content, conversation history, or spoken interaction data rather than manually entered notes. ## Common use cases and example apps | **Example app** | **Example prompt** | **Description** | | :---------------------------- | :---------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Meeting dashboard | *Build a dashboard that shows my recent meetings from Fireflies with titles, dates, participants, and durations.* | **Display meeting activity in a central view.**
The app pulls recent transcripts, shows key metadata, and lets users browse meeting history without leaving the app. | | Sales call intelligence | *Build a sales call review tool. Show a list of recent calls with AI summaries, key topics, and action items from Fireflies.* | **Surface conversation insights from sales calls.**
The app retrieves transcripts and summaries, highlights keywords and action items, and helps sales teams review calls efficiently. | | CRM enrichment | *After a call, pull the Fireflies summary and next steps into our CRM notes.* | **Turn conversations into structured follow-ups.**
The app retrieves AI summaries and action items from recent calls and writes them into a CRM-style view. | | Action item tracker | *Build a task board that pulls action items from Fireflies meeting summaries and lets users mark them as done.* | **Turn meeting outcomes into trackable tasks.**
The app extracts action items from AI summaries and displays them in a structured format so teams can follow up. | | Team meeting digest | *Build a weekly digest that summarizes all team meetings from Fireflies and displays them in a feed.* | **Compile meeting summaries into a recurring digest.**
The app aggregates recent transcripts, extracts highlights and decisions, and presents them in a scannable format. | | Searchable transcript archive | *Build a search interface where users can search across all Fireflies transcripts by keyword, date, or participant.* | **Create a structured search experience for meeting transcripts.**
The app lets users find past discussions, filter by speaker or date, and jump to relevant sections. | | Support handoff | *Given a ticket, find related meeting context from Fireflies.* | **Speed up resolution when calls explain the issue.**
The app matches tickets to relevant transcripts so support agents can see what was discussed. | ## How to connect Fireflies Workspace **admins** and **owners** can connect Fireflies. You can create multiple Fireflies connections using different API keys, which is useful for separating environments (for example, development and production) or managing rate limits. When the connection is created, Fireflies can be linked to any project in the workspace. ### Prerequisites * A [Fireflies.ai](http://Fireflies.ai) account and API key All API usage consumes Fireflies API quota based on your Fireflies plan, and billing is handled directly by Fireflies, not Lovable. * Lovable workspace admin or owner role ### Step 1: Create a Fireflies API key An API key lets you connect to the Fireflies API and access your organization's meeting data. 1. Sign in to [Fireflies](https://app.fireflies.ai/). 2. Open [Developer settings (Fireflies API)](https://app.fireflies.ai/settings/developer-settings). 3. Copy the generated API key and store it securely. Your API key functions like a password. Keep it secure and never share it publicly. You’ll need it in the next step. ### Step 2: Connect Fireflies in Lovable You can create multiple connections using different API keys. 1. Open **Connectors** → **App connectors** and select **Fireflies**. 2. Click **Add connection**. 3. Enter a **Display name** (for example `Fireflies Production`). 4. Paste the **API key**. 5. Click **Connect**. Lovable will verify your API key by making a test request to the Fireflies API. If the key is valid, the connection is saved. When connected, your Lovable apps can start accessing meeting transcripts and conversation data from Fireflies. ## Available data Through the Fireflies connector, your app can access the following meeting data: | **Data** | **Description** | | :--------------- | :--------------------------------------------------------------------- | | Transcripts | Full meeting transcripts with sentence-level detail | | AI summaries | Keywords, action items, outlines, and overviews generated by Fireflies | | Participants | List of meeting participant emails | | Speakers | Speaker identification and attribution within transcripts | | Meeting metadata | Title, duration, date, calendar type, and conferencing link | | Transcript URL | Direct link to view the meeting in the Fireflies dashboard | For the full list of available queries and fields, see the [Fireflies GraphQL API documentation](https://docs.fireflies.ai/graphql-api) and the [API quickstart](https://docs.fireflies.ai/getting-started/quickstart). Fireflies returns transcripts and summaries in markdown format. Use a React markdown rendering library (such as `react-markdown`) for proper display instead of rendering raw markdown strings. ## Limitations The Fireflies connector cannot: * Create, modify, or delete meetings or transcripts (read-only access) * Receive incoming events or webhooks from Fireflies * Access data beyond your Fireflies organization's scope * Support per-user Fireflies login (each end user connecting their own Fireflies account) Each connection represents one Fireflies API key. The API returns data that your Fireflies workspace and key are allowed to access. Keep this in mind when building user-facing features. Fireflies enforces API rate limits that vary by plan. Free and pro plans allow approximately 50 requests per day. If your app makes frequent calls, consider caching responses to stay within these limits. Lovable gateway limits also apply. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to GatewayAPI Source: https://docs.lovable.dev/integrations/gatewayapi Connect your app to GatewayAPI, an SMS and RCS messaging API, to send mobile messages, track delivery status, and handle inbound replies from your Lovable app. [GatewayAPI](https://gatewayapi.com/) is an SMS and RCS messaging platform for sending mobile messages through an API. The GatewayAPI connector lets your Lovable app send SMS and RCS messages, batch-send notifications, and connect delivery events back to app workflows. With GatewayAPI, your app can: * Send SMS and RCS messages to phone numbers * Batch-send mobile messages for notifications and campaigns * Add labels and references so messages can be matched to orders, bookings, or other app records * Receive delivery status callbacks through a public webhook endpoint you configure in GatewayAPI * Receive inbound SMS and RCS replies when your GatewayAPI account supports them GatewayAPI is a good fit for apps that need transactional alerts, operational notifications, customer messaging, or campaign workflows backed by your GatewayAPI account. ## Common use cases and example apps | Example app | Example prompt | Description | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Appointment reminders** | *Use GatewayAPI and build an appointment reminder app that sends SMS reminders before each booking.* | **Reduce missed appointments with scheduled SMS reminders.**
The app stores bookings, sends GatewayAPI messages before each appointment, and records delivery status for each reminder. | | **Order status notifications** | *Use GatewayAPI and build an order tracking app that texts customers when their order is packed, shipped, and delivered.* | **Keep customers updated from order events.**
The app sends SMS or RCS updates when order status changes and uses message references to connect callbacks to the right order. | | **Incident alerting** | *Use GatewayAPI and build an incident alert tool that texts on-call staff when a critical event is created.* | **Send high-priority alerts outside email and chat.**
The app detects critical incidents, sends mobile alerts through GatewayAPI, and stores delivery results for audit trails. | | **Two-way support inbox** | *Use GatewayAPI and build a support inbox that receives inbound SMS replies from customers.* | **Turn inbound customer replies into support records.**
The app exposes a public webhook endpoint, verifies GatewayAPI signatures, and stores replies for the support team. | | **Campaign sender** | *Use GatewayAPI and build a campaign tool that sends approved SMS updates to a customer list.* | **Send segmented mobile campaigns from app data.**
The app batches recipients, sends messages through GatewayAPI, and tracks callback events for each campaign. | | **Delivery status dashboard** | *Use GatewayAPI and build a dashboard showing sent, delivered, and failed SMS messages from GatewayAPI webhooks.* | **Monitor message delivery inside your app.**
The app saves webhook events, groups them by message reference, and shows delivery trends over time. | ## How to connect GatewayAPI Workspace **admins** and **owners** can connect GatewayAPI. App connectors are enabled by default on Free, Pro, and Business plans. On Enterprise plans, workspace admins and owners can enable app connectors in **Connectors → Admin settings → App connectors**. You can create multiple GatewayAPI connections using different API tokens, which is useful for separating environments (for example, development and production), targeting different GatewayAPI accounts, or using separate GatewayAPI domains. When the connection is created, GatewayAPI becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting GatewayAPI, make sure you have: * A GatewayAPI account * A GatewayAPI API token * The GatewayAPI domain where your API token is valid, either **Global (gatewayapi.com)** or **EU (gatewayapi.eu)** * Lovable workspace owner or admin role All SMS, RCS, webhook, and API usage through this connector uses your GatewayAPI account. Messaging costs, quotas, and billing are handled directly by GatewayAPI, not Lovable. ### Step 1: Get a GatewayAPI API token A GatewayAPI API token lets your Lovable app authenticate with the GatewayAPI messaging APIs. You can create separate tokens for different environments or apps. To create or copy a GatewayAPI API token: Sign in to the [GatewayAPI dashboard](https://app.gatewayapi.com/) with the account you want Lovable to use. In GatewayAPI, open the section where API tokens are managed for your account. Create a new API token for Lovable or copy an existing token. Use a descriptive name, for example `Lovable integration`, if GatewayAPI asks for one. Note whether the token belongs to the global GatewayAPI domain (`gatewayapi.com`) or the EU domain (`gatewayapi.eu`). You need to select the matching domain in Lovable. Your API token functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See GatewayAPI documentation for more information: [GatewayAPI authentication](https://gatewayapi.com/docs/authentication/). ### Step 2: Connect GatewayAPI to Lovable You can create multiple connections using different API tokens. Go to **Connectors → App connectors** and select **GatewayAPI**. Click **Add connection**. * **Display name**: name the connection, for example `GatewayAPI Prod`. * **API domain**: select the GatewayAPI domain where your token is valid. The default is **Global (gatewayapi.com)**. Select **EU (gatewayapi.eu)** for tokens issued for the EU domain. * **API token**: paste your GatewayAPI API token. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to GatewayAPI (based on configured connection-level access). Your Lovable apps can then send SMS and RCS messages through GatewayAPI. ## Receiving delivery status and inbound replies GatewayAPI sends delivery status updates and inbound SMS or RCS messages to webhook endpoints that you configure in the GatewayAPI dashboard. These webhook events do not go through the Lovable connector gateway. When prompting Lovable to build webhook handling, ask it to: * Create a public endpoint for GatewayAPI webhook events * Store a separate `GATEWAYAPI_WEBHOOK_SECRET` backend secret for webhook signature verification * Verify the `Signature` header before trusting webhook data * Save each event before responding with a 2xx status * Respond within 5 seconds so GatewayAPI does not treat the event as failed * Use GatewayAPI message references to match status callbacks to app records After Lovable creates the webhook endpoint, register that endpoint and webhook secret in the GatewayAPI dashboard for the matching domain. Inbound SMS requires a short code or keyword leased from GatewayAPI and assigned to the webhook in GatewayAPI. Availability and pricing are handled by GatewayAPI. ## Limitations The GatewayAPI connector cannot: * Create, update, or delete GatewayAPI webhooks for you. Configure webhooks in the GatewayAPI dashboard * Route delivery status or inbound message webhook events through the connector gateway * Lease short codes, keywords, or other inbound messaging resources for you * Support per-end-customer GatewayAPI authentication. Each connection represents one GatewayAPI API token shared across all projects linked to it * Use more than one GatewayAPI domain per connection. A single connection authenticates against either the global domain or the EU domain ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Gemini Enterprise Source: https://docs.lovable.dev/integrations/gemini-enterprise Connect your app to Gemini Enterprise to search and summarize connected enterprise data, show grounded answers with citations, and build search or chat experiences on top of your existing Gemini Enterprise engine. [Gemini Enterprise](https://cloud.google.com/enterprise-search) is Google Cloud's search and grounded-answer platform for enterprise data. The Gemini Enterprise connector lets your Lovable app use the Gemini Enterprise engine you already configured in Google Cloud, so you can build search pages, Q\&A assistants, and internal tools on top of connected company data. With Gemini Enterprise, your app can: * Search connected data stores using natural language queries * Return grounded answers with citations from your indexed content * Support follow-up questions with multi-turn conversations * Build search-first interfaces with ranked results, filters, and facets * Inspect which data stores are connected to your Gemini Enterprise setup What your app can do depends on the Gemini Enterprise engine you connect, the data stores attached to it, and the Google account used to authorize the connection. ## Why and when to use it Use Gemini Enterprise when your organization already uses Gemini Enterprise or Vertex AI Search as the layer that unifies internal data sources. This connector is a good fit when you want Lovable to build on top of that existing search layer instead of calling each source system directly. Gemini Enterprise works best for search and answer experiences such as internal knowledge search, support assistants, and research tools. It is not the right choice when you need direct write access to the source systems themselves, such as sending email, creating Jira issues, or modifying files in external tools. ## Common use cases and example apps | Example app | Example prompt | Description | | :---------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Internal knowledge assistant** | *Build a chat interface that answers employee questions using our Gemini Enterprise engine and always shows citations.* | **Create a grounded Q\&A experience on top of your indexed company content.**
The app asks Gemini Enterprise for grounded answers and displays source-backed responses with follow-up questions. | | **Enterprise search portal** | *Build a search page for our Gemini Enterprise engine with filters, result cards, and a document preview panel.* | **Turn Gemini Enterprise into a structured search UI.**
The app returns ranked search results from connected data stores and lets users browse sources directly. | | **Support knowledge tool** | *Build a support workspace where agents can search our help content and get a cited answer before replying to customers.* | **Help teams find trusted answers faster.**
The app combines search and grounded answer generation so agents can verify what the source documents actually say. | | **Cross-source research assistant** | *Build a research assistant that searches across the data stores connected to our Gemini Enterprise app and summarizes the findings with citations.* | **Search across blended enterprise sources from one interface.**
The app uses your existing Gemini Enterprise setup to retrieve and summarize results across multiple connected data stores. | | **Source explorer** | *Build an admin page that shows which data stores are connected to our Gemini Enterprise engine and lets users search within specific sources.* | **Make the search configuration visible inside your app.**
The app can list connected data stores, show their types, and target search experiences to selected sources. | ## Requirements and billing Workspace **admins** and **owners** can create Gemini Enterprise connections. Before connecting Gemini Enterprise, make sure you have: * A Google Cloud project with a Gemini Enterprise or Vertex AI Search engine * Data stores already connected to that engine in Google Cloud * A Google account that can access the Gemini Enterprise engine and the connected content you want the app to use * Your **GCP project ID** * Your **Engine ID** * Your **Location** (`global`, `us`, or `eu`) * Lovable workspace admin or owner role Gemini Enterprise usage, quotas, and billing are managed by Google Cloud. Requests made through this connector count toward your Google Cloud project, not Lovable. ### How Gemini Enterprise connections work * Each connection stores the **GCP project ID**, **Location**, and **Engine ID** for one Gemini Enterprise engine. * You authorize the connection with a Google account, and Lovable stores that access securely in the connector gateway with automatic refresh. * Your app can use the connection across linked projects in the workspace. * You can create multiple Gemini Enterprise connections if you need different engines, environments, or Google accounts. * For Google Workspace and supported third-party sources connected through Gemini Enterprise, retrieval respects the access of the Google account used for the connection. * Search results and grounded answers depend on both your Gemini Enterprise engine configuration and the access of the Google account used for the connection. Gemini Enterprise can search data from Google and third-party sources that your Google Cloud admin has already connected to the engine. See Google's list of [supported data sources and connectors](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/introduction-to-connectors-and-data-stores). ## Setup and configuration Go to **Connectors → App connectors** and select **Gemini Enterprise**. Click **Add connection**. Enter a **Display name** such as `Gemini Enterprise Prod` or `Internal Search`. Fill in the connection fields: * **GCP project ID**: the Google Cloud project where your Gemini Enterprise engine lives * **Location**: `global`, `us`, or `eu` * **Engine ID**: the Gemini Enterprise engine identifier If you open **Advanced settings**, you can review the Google permissions requested for the connection. The default selection is appropriate for most Gemini Enterprise setups. Click **Connect**, sign in with Google, and approve the requested access. Lovable verifies that the project, location, engine, and account access are valid before creating the connection. When connected, your Lovable apps can build both search-first and answer-first experiences on top of the same Gemini Enterprise engine. ### What to ask Lovable after connecting Use prompts that make the intended experience clear. Gemini Enterprise supports both classic search interfaces and grounded chat-style answers. ```text wrap theme={null} Build a search page for our Gemini Enterprise connection with a search bar, result cards, filters, and a detail panel for the selected document. ``` ```text wrap theme={null} Build a grounded Q&A assistant on top of our Gemini Enterprise connection. Show citations for every answer and support follow-up questions in the same conversation. ``` ## Limitations and troubleshooting * Each connection is tied to the Google account that authorized it. What your app can retrieve depends on that account's access. * This connector supports Gemini Enterprise search and grounded answers. It does not expose raw APIs for systems behind Gemini Enterprise, such as Jira REST or Microsoft Graph. * Gemini Enterprise actions that are only available in the Google Cloud console are not available through this connector. * Website data stores are not supported for Gemini Enterprise search and assistant apps. * If you see a **403** error, confirm the Google account can access the engine and the relevant data sources. * If you see a **404** error, confirm the **GCP project ID**, **Location**, and **Engine ID** exactly match the engine in Google Cloud. * If you see a **429** error, review quotas and rate limits in your Google Cloud project. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Sync your Lovable project code with GitHub or GitLab Source: https://docs.lovable.dev/integrations/git-sync-overview Git sync keeps your Lovable project code in your own GitHub or GitLab repository with automatic two-way sync, so you can back up code, collaborate with developers, work in your IDE, and deploy anywhere. When you build with Lovable, your project code is stored and managed inside the Lovable platform. Git sync connects a Lovable project to a repository you own on GitHub or GitLab, and keeps the two in sync automatically: changes you make in Lovable are committed to your repository, and commits pushed to the synced branch appear back in your Lovable project. You don't need Git to use Lovable. Many users build and launch entirely within Lovable. If you only need a copy of your code, open the [Code editor](/features/code-mode) and click **Download codebase** at the bottom of the file tree sidebar (paid plans). This page explains how Git sync works across providers. In a project, the connection lives in [**Project settings → Git**](/features/projects/settings#git-tab). For setup steps, see the provider pages: * [GitHub](/integrations/github) (github.com, GitHub Enterprise Cloud with data residency, or GitHub Enterprise Server) * [GitLab](/integrations/gitlab) (GitLab.com or a self-managed GitLab instance) Want your app to call the GitHub REST API to read repositories, issues, and pull requests instead? Use the [GitHub API connector](/integrations/github-api). ## Why sync your project to a Git repository * **Back up your code.** Store your project safely outside Lovable, in an account you control. * **Collaborate with developers.** Use branches, pull or merge requests, and code reviews alongside building in Lovable. * **Work locally in your IDE.** Clone the repository, edit and commit locally, and push. Your changes sync back into Lovable. * **Deploy outside Lovable.** Self-host or deploy to other platforms. See [Deployment, hosting, and ownership options](/tips-tricks/deployment-hosting-ownership). * **Keep a copy of your code within your own infrastructure.** Sync to GitHub Enterprise Cloud with data residency, GitHub Enterprise Server (both Enterprise plan), or a self-managed GitLab instance. ## How Git sync works Git sync has two layers, for both GitHub and GitLab: 1. **A workspace connection** authorizes Lovable to access a Git account, organization, group, or instance. Connections belong to the workspace and can be reused by any project in it. A workspace can hold multiple connections, including connections to both GitHub and GitLab at the same time. 2. **A project repository link** connects one Lovable project to one repository under one of those connections. Linking a project creates a new repository and starts two-way sync automatically. Once linked: * Edits made in Lovable are committed and pushed to your repository. * Commits pushed to the synced branch flow back into your Lovable project. * Lovable edits and syncs **one branch at a time**. Commits on other branches don't appear in Lovable until you merge them into the synced branch or switch the synced branch. You can switch branches and create new branches from Lovable on both providers. ### Who can do what * **Workspace owners and admins** add, update, and delete workspace connections. * **Workspace or project owners and admins** connect and disconnect projects. * **Editors and above** view sync status and work with the synced repository. The provider pages list the exact role requirements for each action. ## Choose a provider Each project links to one repository on one provider. Both providers support the same core two-way sync. | | GitHub | GitLab | | ----------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------ | | Hosted service | github.com (all plans) | GitLab.com (all plans) | | Your own infrastructure | GitHub Enterprise Cloud with data residency, or GitHub Enterprise Server (both Enterprise plan) | Self-managed GitLab instance (all plans) | | Connection method | Lovable GitHub App (or your own copy of it on Enterprise Server) | OAuth with your GitLab account | | Synced branch | Active branch: switch and create branches from Lovable | Active branch: switch and create branches from Lovable | | Repository renames | Followed automatically | Break the sync | If your team already uses one of these platforms, use that one. ## Disconnecting and reconnecting Disconnecting a project stops the sync, nothing more: * Your repository stays on GitHub or GitLab, intact with all history and files. * Your project and its code stay in Lovable. Future changes are stored only in Lovable. If you reconnect a project later, Lovable creates a **new repository** with the current version of your project. The original repository stays in your account but is no longer linked. ## Limitations These apply to both providers: * **Export only.** You can't import an existing repository into Lovable. Connecting a project always creates a new repository. * **One repository per project.** Each Lovable project links to exactly one repository. * **One branch at a time.** Only the synced branch flows back into Lovable. * **Keep the repository where it is.** Don't rename, move, or delete a connected repository (or the account, organization, or group it lives in). Doing so breaks the sync. * **Reconnecting creates a new repository.** You can't re-link a previously disconnected repository. ## FAQ No. Set up the connection once and your code is safely stored in your repository. You only need Git knowledge for advanced workflows like branching, pull or merge requests, or CI/CD. No. On paid plans you can download your code directly: open the [Code editor](/features/code-mode) and click **Download codebase**. Git sync is for ongoing two-way sync and collaboration. A workspace can hold GitHub and GitLab connections side by side, and different projects can sync to different providers. A single project links to one repository on one provider. No. Pushing commits syncs your code into Lovable and updates the preview in the editor, but it never publishes. Your live site only changes when you publish from Lovable. See [Publish your project](/features/publish). No. The repository contains your project's code, including the database migration files that define its structure, but never the data inside your database. To export data, see [Export Lovable Cloud data](/features/advanced-settings#export-lovable-cloud-data). No. Git sync only exports from Lovable. Connecting a project creates a new repository. Yes. Your project remains fully editable in Lovable; the repository is a synced copy that you own. Disconnecting never deletes code on either side. # Sync your Lovable project with GitHub Source: https://docs.lovable.dev/integrations/github Export and two-way sync your Lovable project code with github.com, GitHub Enterprise Cloud, or GitHub Enterprise Server for code backup, collaboration, and deployment. When you build with Lovable, your project code is stored and managed inside the Lovable platform. [GitHub](https://github.com/) is a platform for hosting, managing, and collaborating on code, with version control, pull requests and code reviews, and CI/CD through GitHub Actions. If you want your own copy, plan to collaborate with developers, or move your project elsewhere, you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable. On the Enterprise plan, you can also keep a copy of your code within your own infrastructure with GitHub Enterprise. For the full picture of what Git sync is, how the two-way sync model works across providers, and how to choose between GitHub and GitLab, see the [Git sync overview](/integrations/git-sync-overview). This is a Git sync integration for Lovable projects. You can export and two-way sync your Lovable project code with github.com, GitHub Enterprise Cloud, or GitHub Enterprise Server. Want your app to call the GitHub REST API to read or update repositories, issues, and pull requests instead? Use the [GitHub API connector](/integrations/github-api). You don't need GitHub to use Lovable. Many users build and launch entirely within Lovable. If you only need a copy of your code, you can download your code directly from Lovable. Open the [Code editor](/features/code-mode) and click **Download codebase** at the bottom of the file tree sidebar (paid plans). ## How GitHub Git sync works Like all [Git sync](/integrations/git-sync-overview), the GitHub integration has two layers: 1. A **workspace connection** 2. A **project repository link** ### Workspace connection A workspace connection authorizes Lovable to access a GitHub account or organization through the Lovable GitHub app. This grants Lovable permission to create and update repositories in your chosen account or organization. Workspace connections are shared across the workspace and can be reused by multiple projects. A workspace can contain: * Multiple GitHub connections * Multiple GitHub accounts and organizations * Multiple GitHub connection types This is useful if your team works across personal accounts, client accounts, or multiple organizations. ### Project repository link A project repository link connects one Lovable project to one GitHub repository. When connected: * Changes made in Lovable sync to GitHub * Changes pushed to the active GitHub branch sync back into Lovable * Lovable only edits and syncs one branch at a time ### GitHub Git sync connection types Lovable supports three GitHub connection types: * **github.com** (available on all plans)\ The standard hosted GitHub platform used by most teams. Lovable manages the GitHub app installation for you. * **GitHub Enterprise Cloud - Data residency** (available on the Enterprise plan)\ GitHub Enterprise Cloud using a `*.ghe.com` hostname so repository data stays in a specific region. Lovable manages the GitHub app installation for you. * **GitHub Enterprise Server** (available on the Enterprise plan)\ Self-hosted GitHub running on infrastructure your organization controls. With this setup, you create your own copy of the Lovable GitHub app inside your GitHub organization, so credentials remain under your control. When you add a new connection, you choose which type to set up. All three types support the same two-way sync, branch operations, and pull request creation between Lovable and your GitHub repository. ### Role-based access for GitHub integration | Role | Allowed action | | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workspace owner or admin only |
  • Install the Lovable GitHub app on a new account or organization
  • Add a workspace connection
  • Update a workspace connection
  • Reconnect a workspace connection (re-authorize the GitHub app for the workspace connection)
  • Delete a workspace connection
| |
  • Workspace owner or admin
  • Project owner or admin
|
  • Connect a project to a repository
  • Disconnect a project from a repository
  • Reconnect a project to a repository
| |
  • Workspace editor or higher
  • Project editor or higher
|
  • View sync status
  • Switch branches
  • Create branches
| | Any workspace member, including external collaborators | View the connection in Workspace settings → Git → GitHub (read-only mode) | ## Create a workspace GitHub connection **Workspace admins and owners** can create workspace connections from: * **Workspace settings → Git → GitHub → Add connection** * [**Project settings → Git**](/features/projects/settings#git-tab) **→ GitHub → Add connection** (if a project has not been connected yet). To use an **existing GitHub installation**, click **Connect** next to the account or organization you want to use. The list shows installations on accounts and organizations you have access to on your GitHub identity. If someone else installed the Lovable GitHub app on an organization you're not a member of, you won't see that installation. Ask them to add you to the GitHub organization, or to set up the Lovable workspace connection themselves. To set up a new connection, follow the steps for your connection type: * github.com * GitHub Enterprise Cloud (data residency) * GitHub Enterprise Server github.com is the standard hosted GitHub service used by most teams. Available on all plans. You need to have a GitHub account. You can create one for free at [github.com](https://github.com/). Click **Add account**. * On Free, Pro, and Business plans, you'll go straight to the **github.com** installation flow. * On Enterprise plan, Lovable shows three connection types. Select **github.com.** A GitHub popup opens. * Choose the account or organization. * Choose **All repositories** or **Only select repositories**. * Click **Install & Authorize**. Lovable automatically detects the installation and adds it as a reusable workspace connection. You can now link projects to repositories under this account or organization. Use this option if your organization runs GitHub Enterprise Cloud on a `*.ghe.com` hostname to keep repository data in a specific region. This setup requires a Lovable Enterprise plan. Click **Add account**. On the host selection step that appears, choose **Data residency**. If your GitHub organization enforces an **IP allow list**, copy the IP ranges shown in the setup wizard and add them under **GitHub organization → Settings → Security → IP allow list**. * **Instance URL**: Enter your data residency hostname, for example `acme.ghe.com`. The hostname must end with `.ghe.com` and must be reachable over HTTPS. * Click **Connect**. A popup opens to your data residency instance. * Choose the account or organization. * Choose **All repositories** or **Only select repositories**. * Click **Install & Authorize**. Lovable automatically detects the installation and adds it as a reusable workspace connection. You can now link projects to repositories under this account or organization. Use this option if your organization runs GitHub Enterprise Server on its own infrastructure. With this setup, **you create your own copy of the Lovable GitHub app** inside your GitHub organization, so credentials stay under your control. This setup requires: * A Lovable Enterprise plan * Organization admin access on your GitHub Enterprise Server to register and install the GitHub app * Network access from Lovable's public IP ranges Click **Add account**. On the host selection step that appears, choose **Server**. Lovable must be able to reach your GitHub Enterprise Server to push code, verify repositories, and receive webhook events. Add the IP ranges shown in the setup wizard to: * Your network firewall * Or your GitHub organization IP allow list under **Settings → Security → IP allow list** * **Instance URL:** Your GitHub Enterprise Server hostname (for example, `github.example.com`). Lovable connects over HTTPS. The hostname cannot be `github.com` or a `*.ghe.com` host. * **Organization name:** The GitHub organization where the Lovable App should be created. You must be an **admin** of this organization. * Click **Connect**. Lovable opens GitHub's “Create a GitHub app” popup pre-filled with the required manifest. * **Permissions include:** * Contents (write) * Metadata (read) * Pull requests (write) * Workflows (write) * Administration (write) * **Event subscriptions** include: * push * pull\_request * repository * delete * **Webhook URL:** Lovable's webhook endpoint, pre-filled. Confirm to create the app. When the app is created, the popup closes and Lovable shows an **Install app on GitHub** button. * Click **Install app on GitHub** to install the app on your organization. A pop-up opens. * Choose **All repositories** or **Only select repositories**. * Complete the install. Lovable validates the installation and adds it as a reusable workspace connection. You can now link projects to repositories under this organization. The app's private key is transferred securely and stored encrypted on Lovable's side. You do not need to download or manage the key manually. Deleting a GitHub Enterprise Server connection schedules secure destruction of the stored signing key. ## Link a project to a GitHub repository When there is an active workspace GitHub connection, **workspace or project admins and owners** can connect a Lovable project to a GitHub repository. * Connecting a project creates a new GitHub repository. The repository is **private by default**, so nobody can see your code unless you change its visibility on GitHub. * Each Lovable project can connect to one repository. You can access project GitHub settings from: * **Project settings → Git → GitHub** * The `+` **(plus) menu** in the chat Existing workspace connections appear under **Accounts.** Click **Connect** next to the workspace connection where the new repository should be created. Lovable creates a new GitHub repository and starts two-way sync automatically. Don't delete your GitHub repository, rename your GitHub account or organization, or transfer the repository to an account this workspace has no connection for. Doing so breaks the sync, and Lovable won't be able to update your project. Renaming the repository itself is safe: Lovable tracks repository renames automatically. ## Manage a project's repository sync After connecting a project to a GitHub repository, you see the following in the project's GitHub settings: * Repository status as **Connected** * Branch picker with active branch name (GitHub branch synced with Lovable) * Clone URLs (HTTPS, SSH, GitHub CLI) * Option to **View on GitHub** (available from the dropdown) * Option to **Disconnect** (available from the dropdown) Lovable only edits and syncs one branch at a time. By default, this is the repository's default branch (usually `main`). Changes pushed to the currently active branch sync back into Lovable. ### Switch branches 1. Click the branch picker. 2. Search or select a branch. 3. Click the branch to switch. Lovable immediately starts editing and syncing the branch you switched to. You can switch back to the default branch at any time. ### Create a new branch 1. Click the branch picker. 2. Click **+ Create branch** at the bottom of the list. 3. Enter a branch name. Lovable validates it against empty names, invalid characters, and duplicates. Branch names must follow Git naming rules (no spaces, .., leading or trailing dots or dashes, and special characters like \~ ^ : ? \* \[ ] \\). The new branch is created from the **currently active branch** as its source (shown as `Source: ` in the dialog). Lovable automatically switches to the new branch and starts editing and syncing it. The source is your **currently active branch**, not the repository's default branch. If you want to start a new feature branch from `main`, switch to `main` first, then create the new branch. You can't switch branches or create new branches while Lovable is editing the project. ### Clone the repository locally After connecting a project, Lovable provides clone URLs for: * HTTPS * SSH * GitHub CLI You can clone the repository locally and continue working in your preferred IDE. ### View the repository on GitHub You can quickly access the synced repository directly in GitHub from **Project settings → Git → GitHub.** Use **View on GitHub** from the repository connection dropdown. This opens GitHub in a new tab. ### Commit attribution Commits made by Lovable are authored by the Lovable GitHub app identity: * `lovable-dev[bot]` for github.com and GitHub Enterprise Cloud * `[bot]` for GitHub Enterprise Server Commits are also co-attributed to the Lovable user who triggered them using GitHub's `noreply` email format. ### Disconnect a project from a GitHub repository Disconnecting removes the sync relationship between a Lovable project and a GitHub repository. When you disconnect: * **Sync stops.** The two-way connection between Lovable and GitHub ends. * **Your repository stays on GitHub.** It remains intact with all history and files. * **Your project and its code stay in Lovable.** Future changes are stored only inside Lovable. Disconnecting a project does not remove the workspace connection itself. There are two ways to disconnect a repository connection. * Disconnect from the project GitHub settings * Disconnect from the workspace GitHub settings **Workspace or project admins and owners** can disconnect from the project's GitHub settings. You can access project GitHub settings from: * **Project settings → Git → GitHub** * The `+` **(plus) menu** in the chat In the active repository connection, open the dropdown and select **Disconnect**. * Type the required info * Click **Disconnect** to confirm **Workspace owners and admins** can disconnect from the workspace GitHub settings. Open **Workspace settings → Git → GitHub**. Select the connection from the list. Under **Linked projects**, select the projects you want to unlink. * Click **Unlink N projects** (where `N` is the number of projects you selected) * Click **Unlink** to confirm If a project needs GitHub again, you can link it to any available connection. If you reconnect later: * Lovable creates a new repository with the current version of your project. * The original repository stays unchanged on GitHub and is no longer linked to Lovable. ## Delete a workspace GitHub Git sync connection **Workspace admins and owners** can delete GitHub connections. Deleting a workspace GitHub connection: * Removes the connection for all projects * Stops syncing for linked projects * Does not delete repositories on GitHub * Deletes stored credentials * For GitHub Enterprise Server, deleting a connection also schedules destruction of the stored GitHub app signing key. Go to **Workspace settings → Git → GitHub**. Select the connection from the list. Review the list of linked projects carefully before deleting the connection to avoid unintentionally removing GitHub sync. Under **Delete this connection**: * Click **Delete** * Type the required info * Click **Delete** to confirm the deletion ## Limitations The GitHub Git sync integration currently does not support: * Importing existing GitHub repositories into Lovable. You can only export from Lovable to GitHub. * Reconnecting to the same repository after disconnecting. A new repository is created on reconnect. * Installing the Lovable GitHub app multiple times on the same account or organization. ## Troubleshooting When something goes wrong, Lovable shows a **Reconnect** prompt in the affected project's GitHub settings. ### Workspace connection issues These problems affect the workspace-level GitHub connection itself, so the fix usually applies to **every project linked to that connection**. A workspace owner or admin only needs to perform the fix once from any affected project, and the other projects on the same connection resume automatically. The GitHub app installation is currently suspended in your GitHub account or organization. 1. Open the project's GitHub settings. 2. Click **Reconnect**. Lovable opens your GitHub App installation settings in a new tab. 3. Unsuspend the Lovable GitHub App in GitHub, then return to Lovable. When the GitHub app is unsuspended, sync resumes for every project on this connection. Someone uninstalled the Lovable GitHub app from your GitHub account or organization. As a result, Lovable disconnected every project that was using that connection, and the workspace connection was removed. The original repositories stay on GitHub untouched, but they are no longer linked to Lovable. To restore syncing: 1. Open **Workspace settings → Git → GitHub** and click **Add connection**. 2. Reinstall the Lovable GitHub App on the same account or organization. This creates a new workspace connection. 3. For each project that was previously synced, open the project's GitHub settings and click **Connect** to link it to the new workspace connection. Lovable creates a **new GitHub repository** for the project. Your original repositories stay on GitHub for reference. If you have history in the old repository that needs to be preserved, copy or merge it into the new one yourself. The Lovable GitHub app is installed but no longer has access to one or more repositories (for example, an admin changed the installation from **All repositories** to **Only select repositories** and excluded this one). 1. Open the project's GitHub settings. 2. Click **Reconnect**. Lovable opens your GitHub App installation settings in a new tab. 3. Under **Repository access**, either select **All repositories** or add the missing repository to **Only select repositories**. Sync resumes for all affected projects when access is restored. Your project still references a GitHub installation that this workspace no longer has a connection record for. This typically happens after a workspace transfer, or after the previous workspace connection was removed. 1. Open the project's GitHub settings. 2. Click **Reconnect**. 3. Reinstall the Lovable GitHub App on the account or organization shown when the GitHub popup opens. Lovable creates the workspace connection record and re-links the project automatically. This affects the **GitHub install and authorize popup** that opens during workspace connection setup. Your browser probably blocked the GitHub login popup. Allow popups for Lovable and try again. This applies to data residency and Enterprise Server connections. Add Lovable's IP ranges (shown in the setup wizard) to **GitHub organization → Settings → Security → IP allow list**. Confirm that your GitHub Enterprise Server is reachable from Lovable's public IP ranges over HTTPS. ### Project repository issues These problems affect a single project's link to its repository. Workspace or project admins and owners can resolve them from the **project's GitHub settings**. The repository was deleted on GitHub, or transferred to an account or organization this workspace has no connection for. You can either: * **Restore the repository on GitHub.** Transfer it back to its original owner, or [restore a deleted repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/restoring-a-deleted-repository). Sync resumes automatically. * **Move on with a new repository.** Open the project's GitHub settings, disconnect the project, then connect it again. Lovable creates a new GitHub repository with your current code. Lovable only syncs **one branch at a time,** and that is the branch the project is currently set to in its GitHub repository connection settings. By default this is the repository's default branch (usually `main`). If you pushed commits to a different branch in GitHub, you have two options: * **Merge your changes into the synced branch**. For example, open a pull request from your feature branch into `main` and merge it. Lovable then picks up those commits. * **Switch the synced branch in Lovable**. In your project's GitHub settings, select the branch where your commits live. Lovable starts editing and syncing that branch instead, and your commits will appear. The branch your project was synced to was deleted on GitHub. Lovable automatically switched the project to a new branch called `lovable-fallback` so you can keep editing without errors. Your repository is otherwise untouched. Pick another branch or recreate the original branch. You can leave or delete `lovable-fallback` in GitHub once you've moved on. GitHub rejects pushes that contain files larger than **100 MB**. When this happens, your project's GitHub settings show the error "Your project contains files that exceed the maximum file size limit (100 MB)" together with a list of the affected files, after a few failed sync attempts. To fix it, delete the listed files from your project (or ask Lovable to remove them) and let the sync retry. If the push keeps failing after the files are gone, an oversized file is stuck in the repository's history, and history cleanup requires help from [Lovable Support](https://lovable.dev/support). Separately, Lovable itself cannot save files larger than **10 MB** into your project. Files you push from your own computer can be larger (up to GitHub's limits) and sync into Lovable, but Lovable cannot edit those files afterwards: any Lovable change that touches a file over 10 MB fails. For large media, ask Lovable to "Migrate large files to CDN assets". See the [chat page FAQ](/features/projects/chat) for details. Your synced branch rejected the push, most often because of branch protection rules or because someone pushed a conflicting change you couldn't be rebased onto. To avoid losing your work, Lovable pushed it to a new `lovable-sync-` branch instead. Open that branch on GitHub, review the changes, and merge them into your protected branch through your usual review process. ## FAQ No. Set up Git sync once, and GitHub safely stores your code. You only need to learn GitHub's features if you want to do more advanced things like branching, pull requests, or CI/CD. Repositories created by Lovable are **private by default**, on every plan. Nobody can see your code on GitHub unless you change the repository's visibility yourself in GitHub's settings. No. On paid plans you can download your code directly from Lovable. Open the [Code editor](/features/code-mode) and click **Download codebase** at the bottom of the file tree sidebar. GitHub is for ongoing two-way sync and collaboration, not just for getting a copy of your code. * **github.com** is the standard hosted GitHub service and is available on all plans. * **GitHub Enterprise Cloud (data residency)** uses a `*.ghe.com` hostname so your data stays in a specific region. It uses the Lovable-managed GitHub app. Available on the **Enterprise** plan. * **GitHub Enterprise Server** is GitHub running on your own infrastructure. You register your own copy of the Lovable GitHub app inside your organization. Available on the **Enterprise** plan. The Lovable GitHub app requests: * **Contents** (write): Read and write code in your repositories. * **Metadata** (read): Basic repository information. * **Pull requests** (write): Open and update pull requests. * **Workflows** (write): Manage GitHub Actions workflow files. * **Administration** (write): Create new repositories under your account or organization. The app subscribes to **push**, **pull\_request**, **repository**, and **delete** events to keep Lovable in sync with GitHub. It depends on the change: * **Rename the repository**: Sync continues. Lovable detects the rename and updates the connection automatically. * **Transfer the repository to another account or organization**: Sync continues only if this workspace also has a connection for the new owner. Otherwise the connection breaks and the project stops syncing. * **Delete the repository**: The connection breaks and the project stops syncing. You can [restore the deleted repository on GitHub](https://docs.github.com/en/repositories/creating-and-managing-repositories/restoring-a-deleted-repository) to resume syncing, or disconnect and reconnect the project to create a new repository. The GitHub connection breaks. Your project stops syncing, and you are not able to edit it in Lovable. To fix this, revert to the original GitHub user or organization name. The GitHub connection breaks during the transfer. Lovable shows a warning before you confirm. After the transfer, your repository stays on GitHub but is no longer linked to Lovable. To resume syncing, set up a GitHub connection in the destination workspace and reconnect the project. A new repository is created on reconnect. You can't change the linked GitHub account on an existing project. As a workaround: 1. Disconnect the project from GitHub in the project's GitHub settings. 2. Reconnect the project and choose a different installation during setup. A new repository is created. The original repository stays on GitHub but is no longer linked to Lovable. Yes. A workspace can have multiple GitHub connections, each pointing to a different personal account or organization, and these can be on github.com, your data residency instance, or your GitHub Enterprise Server. Each Lovable project is then linked to one repository within one of those installations. Yes. Workspace or project admins and owners can [disconnect a project from a GitHub repository](#disconnect-a-project-from-a-github-repository) at any time in the project's GitHub settings. Your repository stays on GitHub, but syncing stops. If you reconnect later, a new repository is created. No. You can only export from Lovable to GitHub, not the other way around. Yes. The branch picker in your project's GitHub repository connection lets you [switch to any branch](#switch-branches) in your repository. You can also [create a new branch](#create-a-new-branch) directly from the picker. Lovable forks from the branch you're currently editing, so switch to your intended starting point (usually `main`) first. Commits made by Lovable are authored by the Lovable GitHub app identity: * `lovable-dev[bot]` for github.com and GitHub Enterprise Cloud * `[bot]` for GitHub Enterprise Server Commits are also co-attributed to the Lovable user who triggered them using GitHub's `noreply` email format. Only if Lovable's public IP ranges can reach your instance. Lovable needs network access to your GitHub Enterprise Server to push code and receive webhook events. With data residency, repository data and webhook traffic stay within the GitHub region tied to your `*.ghe.com` hostname. Lovable's backend connects to that hostname from the IP ranges shown in the setup wizard. If your organization enforces an IP allow list on GitHub, add those ranges to the allow list. # Connect your app to GitHub API Source: https://docs.lovable.dev/integrations/github-api Connect your app to GitHub with a personal access token to read repositories, manage issues and pull requests, and build automations with the GitHub REST API. [GitHub](https://github.com/) hosts repositories, issues, pull requests, and CI workflows for engineering teams. The GitHub connector lets your Lovable app call the [GitHub REST API](https://docs.github.com/en/rest) using a personal access token from your GitHub account. It is designed for apps that read or update GitHub data from server code, such as issue dashboards, PR trackers, and automation workflows. With GitHub, your app can: * List and read repositories, branches, and file contents * Create and update issues and pull requests * Read commits, releases, and workflow runs * Build internal tools and automations on top of GitHub data This is a connector for apps you build with Lovable. Your app can call the GitHub REST API to read and update repositories, issues, pull requests, and other GitHub data. Want to export or two-way sync your Lovable project code to GitHub instead? Use [GitHub Git sync](/integrations/github). ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------- | :------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issue triage board | *Use GitHub and build a dashboard that lists open issues across my repositories, grouped by label.* | **Surface open work without leaving your app.**
The app reads issues from GitHub and presents them in a filterable board. | | PR status hub | *Use GitHub and build a page that shows open pull requests with review status and age.* | **Give managers a live view of in-flight code review.**
The app fetches pull requests and highlights stale or blocked reviews. | | Release tracker | *Use GitHub and build a tool that lists recent releases and workflow results for our main repos.* | **Track shipping activity from GitHub data.**
The app combines release and Actions metadata in one view. | | Repo health dashboard | *Use GitHub and build an admin page that shows repository stats and open issue counts.* | **Monitor repository health at a glance.**
The app aggregates GitHub API responses into summary cards. | | Automation webhook companion | *Use GitHub and build a server endpoint that creates an issue when a form is submitted.* | **Turn app events into GitHub issues automatically.**
The app validates input and calls the GitHub REST API through the connector gateway. | | Contributor activity feed | *Use GitHub and build a page that shows recent commits and pull requests across our team repositories.* | **Give stakeholders a single view of recent engineering activity.**
The app fetches commits and pull requests and groups them by repository or author. | ## How to connect GitHub Workspace **admins** and **owners** can connect GitHub. You can create multiple GitHub connections using different personal access tokens, which is useful for separating environments (for example, development and production) or using tokens with different permission scopes. When the connection is created, GitHub becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting GitHub, make sure you have: * A GitHub account * A [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) with permissions that match the endpoints your app will call * Lovable workspace **owner** or **admin** role API requests made through this connector count toward your GitHub account rate limits. Quotas and billing are handled by GitHub, not Lovable. ### Step 1: Create a GitHub personal access token A personal access token lets your Lovable app authenticate with the GitHub REST API on your behalf. To create a GitHub personal access token: Sign in to [GitHub](https://github.com/) and open [Settings → Developer settings → Personal access tokens](https://github.com/settings/tokens). Create a **fine-grained** or **classic** token. Fine-grained tokens can be limited to specific repositories. Classic tokens use scope lists such as `repo` or `public_repo`. Grant only the permissions your app needs. For private repositories, include repository read or write access. For public data only, `public_repo` may be enough on classic tokens. Copy the token when GitHub shows it. You will not be able to view it again. Your personal access token functions like a password. Keep it secure and never share it publicly. You will need it in the next step. See GitHub documentation for more: [Managing personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). ### Step 2: Connect GitHub to Lovable You can create multiple connections using different personal access tokens. Go to **Connectors → App connectors** and select **GitHub**. Click **Add connection**. 1. **Display name**: name the connection, for example `GitHub Prod`. 2. **Personal access token**: paste the token you created in step 1. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. Lovable verifies the token against the GitHub API before saving the connection. When connected, anyone building in a project can ask Lovable in chat to link their project to GitHub (based on configured connection-level access). Your Lovable apps can then read and update repositories, issues, pull requests, and other GitHub resources through the connector gateway. ## Limitations The GitHub connector cannot: * Use OAuth app or GitHub App installation flows. Use a personal access token instead. * Replace [GitHub Git sync](/integrations/github) for backing up or syncing your Lovable project codebase. * Support per-end-user GitHub login. Each connection represents a single GitHub account shared across all projects linked to it. * Call endpoints your token permissions do not cover. If a call returns `403`, update the token permissions or create a new token with broader scopes. If you revoke the personal access token on GitHub, update the connection with a new token or create a new connection before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Sync your Lovable project with GitLab Source: https://docs.lovable.dev/integrations/gitlab Export and two-way sync your Lovable project code with GitLab.com or a self-managed GitLab instance for code backup, collaboration, and deployment. When you build with Lovable, your project code is stored and managed inside the Lovable platform. [GitLab](https://gitlab.com/) is a platform for storing, managing, and sharing code, with version control, merge requests and code reviews, and CI/CD pipelines. If you want your own copy, plan to collaborate with developers, or move your project elsewhere, you can export and sync your project to GitLab: back up your code, review changes in merge requests, work locally in your IDE, test features on branches, and deploy outside Lovable. With GitLab Self-Managed, you can also keep a copy of your code within your own infrastructure. For the full picture of what Git sync is, how the two-way sync model works across providers, and how to choose between GitHub and GitLab, see the [Git sync overview](/integrations/git-sync-overview). You don't need GitLab to use Lovable. Many users build and launch entirely within Lovable. If you only need a copy of your code, you can download your code directly from Lovable. Open the [Code editor](/features/code-mode) and click **Download codebase** at the bottom of the file tree sidebar (paid plans). ## How GitLab Git sync works Like all [Git sync](/integrations/git-sync-overview), the GitLab integration has two layers: 1. A **workspace connection** 2. A **project repository link** ### Workspace connection A workspace connection authorizes Lovable to access a GitLab namespace (your personal account or a group) through OAuth. Lovable requests the `api` scope, which it needs to create projects, configure webhooks, manage branches, and open merge requests. Workspace connections are shared across the workspace and can be reused by multiple projects. A workspace can contain: * Multiple GitLab connections * Multiple group namespaces from the same GitLab account or instance * One personal-account namespace (a workspace can hold only one personal GitLab account, alongside any number of groups) * Both GitLab connection types (GitLab.com and Self-Managed) ### Project repository link A project repository link connects one Lovable project to one GitLab repository. When connected: * Changes made in Lovable sync to GitLab * Changes pushed to the active GitLab branch sync back into Lovable * Lovable only edits and syncs one branch at a time ### GitLab Git sync connection types Lovable supports two GitLab connection types: * **GitLab.com**\ The hosted service managed by GitLab Inc. You authorize Lovable with your GitLab.com account. * **GitLab Self-Managed**\ A GitLab instance that your organization runs on its own servers. You create an OAuth application in your instance, so credentials remain under your control, and allowlist Lovable's IP ranges. When you add a new connection, you choose which type to set up. Both types support the same two-way sync, branch operations, and merge request creation between Lovable and your GitLab repository. ### Role-based access for GitLab integration | Role | Allowed action | | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workspace owner or admin only |
  • Add a workspace connection
  • Update a workspace connection
  • Reconnect a workspace connection (re-authorize GitLab)
  • Delete a workspace connection
| |
  • Workspace owner or admin
  • Project owner or admin
|
  • Connect a project to a repository
  • Disconnect a project from a repository
  • Reconnect a project to a repository
| |
  • Workspace editor or higher
  • Project editor or higher
|
  • View sync status
  • Switch branches
  • Create branches
| | Any workspace member, including external collaborators | View the connection in Workspace settings → Git → GitLab (read-only mode) | ## Create a workspace GitLab connection **Workspace admins and owners** can create workspace connections from: * **Workspace settings → Git → GitLab → Add connection** * [**Project settings → Git**](/features/projects/settings#git-tab) **→ GitLab → Add connection** (if a project has not been connected yet) To set up a new connection, follow the steps for your connection type: GitLab.com is the hosted service managed by GitLab Inc. You need a GitLab account. You can create one for free at [gitlab.com](https://gitlab.com). Click **Add connection** and select **GitLab.com**. A popup opens to GitLab's authorization page. Sign in and **authorize Lovable** to access your GitLab account. Lovable requests the `api` scope, which is required to create projects, configure webhooks, manage branches, and open merge requests. Choose where your project repositories should live: * Select your **personal account** or one of your **GitLab groups**. * Click **Connect** next to the namespace you want to use. You can connect multiple group namespaces from the same GitLab account, plus your personal account. You cannot connect the same personal account or group more than once, and a workspace can hold only one personal-account connection. GitLab Self-Managed is intended for organizations that run their own GitLab server and need their code to stay within internal infrastructure. This setup requires: * Admin access to your GitLab instance to create an OAuth application * Network access from Lovable's public IP ranges Click **Add connection** and select **GitLab Self-Managed**. Lovable needs to reach your GitLab instance to sync code and receive webhook events. The setup wizard displays the IP ranges you need to allowlist if your instance is protected by a firewall. Copy each one and add it to your network firewall or GitLab's IP allowlist settings. In your GitLab instance, go to **Admin Area → Applications** (or **Settings → Applications** for a user-level app) and create a new application: * **Name:** Lovable (or any descriptive name) * **Redirect URI:** Use the URI shown in the Lovable setup wizard (for example, `https://lovable.dev/gitlab/callback`) * **Scopes:** `api` * **Confidential:** Yes Save the application and note the **Application ID** and **Secret**. Keep your Application Secret confidential. It grants access to your GitLab instance on behalf of your users. Back in the Lovable setup wizard, fill in: * **GitLab URL:** Your instance URL (e.g., `https://gitlab.yourcompany.com`) * **Application ID:** The client ID from the OAuth app you created * **Application secret:** The client secret from the OAuth app * **Group path (optional):** If you want to restrict access to a specific group, enter the group path (for example, `my-org/my-team`) Click **Continue**. A popup opens to your self-managed GitLab instance's authorization page. Sign in and authorize Lovable. Lovable requests the `api` scope. Choose between your **personal account** or one of your **GitLab groups** within the instance, then click **Connect**. ## Link a project to a GitLab repository When there is an active workspace GitLab connection, **workspace or project admins and owners** can connect a Lovable project to a GitLab repository. * Connecting a project creates a new GitLab repository. The repository is **private by default**, so nobody can see your code unless you change its visibility on GitLab. * Each Lovable project can connect to one repository. Open **Project settings → Git → GitLab**. Under **Connect project**, click **Connect** next to the namespace (personal account or group) where the new repository should be created. Lovable creates a new GitLab repository and starts two-way sync automatically. Don't rename, move, or delete your GitLab project after connecting, and don't rename the GitLab username or group it lives under. Doing so will break the sync, and Lovable won't be able to update your project. ## Manage a project's repository sync After connecting a project to a GitLab repository, you see the following in the project's GitLab settings: * Repository status as **Connected** * Branch picker with active branch name (GitLab branch synced with Lovable) * Clone URLs (HTTPS, SSH) * Option to **View on GitLab** (available from the dropdown) * Option to **Disconnect** (available from the dropdown) Lovable only edits and syncs one branch at a time. By default, this is the repository's default branch (usually `main`). Changes pushed to the currently active branch sync back into Lovable. ### Switch branches 1. Click the branch picker. 2. Search or select a branch. 3. Click the branch to switch. Lovable immediately starts editing and syncing the branch you switched to. You can switch back to the default branch at any time. ### Create a new branch 1. Click the branch picker. 2. Click **+ Create branch** at the bottom of the list. 3. Enter a branch name. Lovable validates it against empty names, invalid characters, and duplicates. Branch names must follow Git naming rules (no spaces, .., leading or trailing dots or dashes, and special characters like \~ ^ : ? \* \[ ] \\). The new branch is created from the **currently active branch** as its source (shown as `Source: ` in the dialog). Lovable automatically switches to the new branch and starts editing and syncing it. The source is your **currently active branch**, not the repository's default branch. If you want to start a new feature branch from `main`, switch to `main` first, then create the new branch. You can't switch branches or create new branches while Lovable is editing the project. ### Clone the repository locally After connecting a project, Lovable provides clone URLs for: * HTTPS * SSH You can clone the repository locally and continue working in your preferred IDE. ### Commit attribution Commits made by Lovable are pushed through the GitLab account that authorized the workspace connection, so GitLab attributes pushes to that user. There is no separate bot identity (unlike the Lovable GitHub app). ### Disconnect a project from GitLab Disconnecting removes the sync relationship between a Lovable project and a GitLab repository. When you disconnect: * **Sync stops.** The two-way connection between Lovable and GitLab ends. * **Your repository stays on GitLab.** It remains intact with all history and files. * **Your project and its code stay in Lovable.** Future changes are stored only inside Lovable. Disconnecting a project does not remove the workspace connection itself. **Workspace or project admins and owners** can disconnect from the project's GitLab settings: in the active repository connection, open the dropdown, select **Disconnect**, and confirm. If a project needs GitLab again, you can link it to any available connection. If you reconnect later: * Lovable creates a new repository with the current version of your project. * The original repository stays unchanged on GitLab and is no longer linked to Lovable. ## Unlink projects from a workspace GitLab connection **Workspace admins and owners** can remove specific projects from a connection without deleting the connection entirely. The connection remains available for other projects. Open **Workspace settings → Git → GitLab**. Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. * Click **Unlink N projects** (where `N` is the number of projects you selected) * Click **Unlink** to confirm When unlinked, those projects no longer sync through this connection. ## Delete a workspace GitLab connection **Workspace admins and owners** can delete GitLab connections. Deleting a workspace GitLab connection: * Removes the connection for all projects * Stops syncing for linked projects * Does not delete repositories on GitLab * Deletes stored credentials Deleting a connection is permanent and cannot be undone. Any projects using this connection stop syncing until a new connection is added and the projects are reconnected. Open **Workspace settings → Git → GitLab**. Select the connection from the list. Review the **Linked projects** section carefully before deleting the connection to avoid unintentionally removing GitLab sync. Under **Delete this connection**, click **Delete** and confirm. ## Limitations The GitLab Git sync integration currently does not support: * Importing existing GitLab repositories into Lovable. You can only export from Lovable to GitLab. * Reconnecting to the same repository after disconnecting. A new repository is created on reconnect. * Connecting the same personal account or group more than once, or more than one personal GitLab account per workspace. * Automatically following repository renames or moves. Unlike GitHub, renaming or moving a GitLab project breaks the sync. ## Troubleshooting Lovable only syncs **one branch at a time,** and that is the branch the project is currently set to in its GitLab repository connection settings. By default this is the repository's default branch (usually `main`). If you pushed commits to a different branch in GitLab, you have two options: * **Merge your changes into the synced branch**. For example, open a merge request from your feature branch into `main` and merge it. Lovable then picks up those commits. * **Switch the synced branch in Lovable**. In your project's GitLab settings, select the branch where your commits live. Lovable starts editing and syncing that branch instead, and your commits will appear. The branch your project was synced to was deleted on GitLab. Lovable automatically switched the project to a new branch called `lovable-fallback` so you can keep editing without errors. Your repository is otherwise untouched. Pick another branch or recreate the original branch. You can leave or delete `lovable-fallback` in GitLab once you've moved on. Your synced branch rejected the push, most often because of protected branch rules or because someone pushed a conflicting change you couldn't be rebased onto. To avoid losing your work, Lovable pushed it to a new `lovable-sync-` branch instead. Open that branch on GitLab, review the changes, and merge them into your protected branch through your usual review process. 1. In GitLab, go to **Settings → Applications** or **Admin Area → Applications**, find the Lovable application, and revoke its access. 2. In Lovable, trigger a sync by making a change in a project linked to your GitLab instance (or wait for the next one). The connection will move into a "needs reconnect" state. 3. In Lovable, as a workspace admin, in the GitLab connection, select **Reconnect** and sign into GitLab again. ## FAQ Files you push from your own computer sync into Lovable (up to GitLab's own limits), but Lovable itself cannot save files larger than **10 MB** into your project: any Lovable edit that touches a file over 10 MB fails. For large media, ask Lovable to "Migrate large files to CDN assets". See the [chat page FAQ](/features/projects/chat) for details. Projects created by Lovable are **private by default**, on every plan. Nobody can see your code on GitLab unless you change the project's visibility yourself in GitLab's settings. No. Just connect and authorize. GitLab will safely store your code. You only need to learn GitLab's features if you want to do more advanced things like branching, merge requests, or CI/CD pipelines. Your browser probably blocked the GitLab login popup. Allow popups for Lovable, then try again. The connection will break. Your project will stop syncing, and you won't be able to edit it in Lovable. To fix this, restore the project to its original path and name in GitLab. If the project was deleted, restore it from GitLab's admin panel. The connection will break. Your project will stop syncing, and you won't be able to edit it in Lovable. To fix this, revert to the original GitLab username or group path. You can't change the linked GitLab account once connected. As a workaround: 1. Disconnect the project from the current GitLab connection (there's a disconnect option in the project's GitLab settings) 2. Delete the existing connection if you want a different personal account (a workspace allows only one personal GitLab account) 3. Create a new connection with the correct GitLab account 4. Reconnect the project to the new connection A new repository is created. The original repository stays on GitLab but is no longer linked to Lovable. Yes. Workspace or project admins and owners can disconnect a project from GitLab at any time in the project's GitLab settings. Your repository stays on GitLab, but syncing stops. If you reconnect later, a new repository is created. No. You can only export from Lovable to GitLab, not the other way around. Lovable only syncs **one branch at a time**, and that is the branch the project is currently set to (by default the repository's default branch, usually `main`). Merge your changes into the synced branch, or [switch the synced branch](#switch-branches) in your project's GitLab settings. Yes. The branch picker in your project's GitLab repository connection lets you [switch to any branch](#switch-branches) in your repository. You can also [create a new branch](#create-a-new-branch) directly from the picker. Lovable forks from the branch you're currently editing, so switch to your intended starting point (usually `main`) first. Yes. You can connect multiple group namespaces from the same GitLab account or self-managed instance, plus one personal account. Each Lovable project is then linked to one repository within one of those namespaces. **GitLab.com** is the hosted service managed by GitLab Inc. **GitLab Self-Managed** is a GitLab instance that your organization runs on its own servers. Self-Managed requires you to create an OAuth application in your instance and allowlist Lovable's IP ranges. Lovable requests the `api` scope, which is the minimum required to create projects, configure webhooks, manage branches, and open merge requests on your behalf. Only if Lovable's public IP ranges can reach your instance. Lovable needs network access to your GitLab server to push code and receive webhook events. If your instance is strictly internal and cannot be reached from Lovable's IPs, reach out to Sales to discuss a potential custom integration. # Connect your app to Google Maps Platform Source: https://docs.lovable.dev/integrations/google-maps Connect Google Maps Platform to your Lovable app to geocode addresses, calculate routes, search places, embed interactive maps, and pull location-aware data like weather, air quality, and solar potential, using a managed connection or your own API keys. [Google Maps Platform](https://mapsplatform.google.com/) is Google's suite of location APIs and SDKs for geocoding, routing, places, and interactive maps. The Google Maps Platform app connector lets your Lovable app call server-side APIs through Lovable's secure gateway, and renders interactive maps in the browser with a separate referrer-restricted key. Both keys are managed at the workspace level, so any project you link to the connection can use them. With Google Maps Platform connected, your app can: * Geocode addresses and reverse-geocode coordinates * Calculate routes and travel times with the Routes API * Search for and retrieve details about places and businesses with the Places API (New) * Embed interactive and static maps * Validate addresses and snap GPS traces to roads * Pull environmental data (Weather, Air Quality, Pollen, and Solar) for any location * Use Aerial View, Geolocation, Elevation, Time Zone, Route Optimization, and Area Insights Google Maps Platform is a good fit when your app needs location, mapping, navigation, or place data, whether in the backend (server-side calls) or in the frontend (embedded maps in the browser). ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Property listings** | *Build a property listing app where users browse homes on a map, filter by neighborhood, and see commute times from each listing to a chosen address.* | **Map-driven discovery with travel times.**
The app uses embedded maps for browsing, geocoding to place pins, and the Routes API to estimate commutes from each listing. | | **Local business directory** | *Build a directory app where users search nearby restaurants, view details, and see opening hours and reviews on a map.* | **Place search and discovery.**
The app uses Places Autocomplete in the search bar and the Places API to fetch place details, ratings, and hours. | | **Delivery dispatch tool** | *Build an internal tool that plans delivery routes for drivers, optimizes stop order, and shows estimated arrival times.* | **Routing and ETAs for operations.**
The app calls the Routes API server-side to compute optimized routes and renders them on an embedded map. | | **Field service scheduling** | *Build a scheduling app where dispatchers assign jobs to technicians based on location and see travel times between appointments.* | **Location-aware scheduling.**
The app geocodes job addresses and uses the Routes API to compute travel times between back-to-back appointments. | | **Store locator** | *Build a store locator page that shows my retail locations on a map, with filters for services offered and an address search.* | **Public-facing map with search.**
The app uses Places Autocomplete to capture user addresses, geocoding to center the map, and an interactive map to display nearby stores. | | **Travel itinerary planner** | *Build a trip planner where users add stops, see them on a map, and view driving distance and time between each leg.* | **Multi-stop itineraries.**
The app uses Places Autocomplete to add stops, the Routes API for legs and distances, and embedded maps for visualization. | Exact behavior depends on **the Google Maps Platform APIs you enable**, **how you restrict each key**, and **what you ask Lovable to build**. ## How Google Maps Platform connections work Google Maps Platform uses a two-key model because some APIs run on the server and others in the browser: * **Server API key**: private, restricted by API. Used by Lovable's connector gateway to call server-side APIs like Geocoding, Routes, Places, Weather, and Air Quality. Never exposed to the browser. The gateway also attaches a per-workspace tracking ID for usage attribution. * **Browser API key**: public, restricted by website referrer. Marked as **Public** in the connection form and injected into your project as a public environment variable named `VITE_LOVABLE_CONNECTOR_GOOGLE_MAPS_BROWSER_KEY`. Used by the frontend for the Maps JavaScript API and Places Autocomplete. Within your Lovable workspace, you can create multiple Google Maps Platform connections. Server-side calls always go through Lovable's connector gateway; see [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for limits and behavior. The browser key is only authorized for the Maps JavaScript API and Places API (New). Do not call Geocoding, Routes, or any other server-side API directly from the browser, those requests will fail with `REQUEST_DENIED`. Use the gateway instead. Google Maps Platform usage is billed by Google Cloud directly to your billing account based on API calls and map loads. Lovable does not bill you for Google Maps Platform usage when you bring your own keys. Google Maps Platform includes a recurring monthly free tier, see [Google Maps Platform pricing](https://mapsplatform.google.com/pricing/) for current details. ## How to connect Google Maps Platform Workspace **admins** and **owners** can connect Google Maps Platform. When adding a connection, you can choose between: * **Managed by Lovable**: no Google Cloud account or API keys required. For prototyping on `*.lovable.app` only. Not for production; server-side gateway requests are rate limited to at most 12,000 per day per workspace. * **Your own credentials**: bring your own server and browser API keys. Required for custom domains and when going live to production. When the connection is created, Google Maps Platform becomes available to the projects you link it to. Follow the setup steps below based on how you want to connect Google Maps Platform. ### Managed by Lovable Choose this option for the fastest setup, ideal for prototyping. You don't need a Google Cloud account or API keys. Lovable provides and manages the credentials for you. The managed connection only works on `*.lovable.app` preview domains. Maps will not load if your project uses a custom domain. To use Google Maps Platform on a custom domain, switch to **Your own credentials** and add your custom domain to your browser key's referrer restrictions. Lovable will also show a warning in the connection details and on the Publish dialog if it detects a managed connection on a project with a custom domain. The managed connection is for prototyping and preview, not production. Server-side requests through Lovable's connector gateway are rate limited to at most **12,000 requests per day per workspace**. When you go live, connect **Your own credentials** so usage runs on your Google Cloud project and billing account. To connect Google Maps Platform: Open **Connectors** → **App connectors** and select **Google Maps Platform**. Click **Add connection**. In **Display name**, enter a name, for example `Google Maps Platform Managed`. This name is only used in Lovable to identify the connection. Select **Managed by Lovable**. Under **Who can access this connection**, keep access limited to yourself, invite the entire workspace, or restrict to specific people. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. When connected, your Lovable apps can use Google Maps Platform for geocoding, routes, places, and embedded maps on `*.lovable.app` domains. ### Your own credentials Bring your own credentials when you need a custom domain, want to manage Google Cloud billing directly, or want full control over which APIs are enabled and how each key is restricted. You can create multiple Google Maps Platform connections using different keys, which is useful for separating environments or attaching different Google Cloud billing accounts. All Google Maps Platform usage is billed by Google Cloud to your billing account, not by Lovable. #### Prerequisites Before connecting, make sure you have: * A Google Cloud project with billing enabled * The Google Maps Platform APIs you plan to use enabled in that project (see Step 1) * Permission to create and manage API keys in that project * Your project's domains, including its `*.lovable.app` URL and any custom domains * Lovable workspace admin or owner role #### Step 1: Enable the Google Maps Platform APIs you need In the [Google Cloud Console](https://console.cloud.google.com/), enable only the APIs your app uses. For the **browser key**, enable the frontend APIs: * Maps JavaScript API * Places API (New) Optionally, if you want server-rendered map images or map embeds, also enable: * Maps Static API * Maps Embed API For the **server key** (called through Lovable's gateway), enable the APIs your app uses: * Geocoding API * Routes API * Places API (New) * Address Validation API * Aerial View API * Air Quality API * Geolocation API * Maps Elevation API * Maps Platform Datasets API * Places Aggregate API (Area Insights) * Pollen API * Roads API * Route Optimization API * Solar API * Time Zone API * Weather API Google has deprecated the legacy Directions API, Distance Matrix API, and the original Places API. Use the Routes API and Places API (New) instead. #### Step 2: Create the server API key The server key is called by Lovable's connector gateway. Restrict it by API, not by referrer or IP. Open the [Google Cloud Console credentials page](https://console.cloud.google.com/apis/credentials) and select your project. Click **Create credentials** → **API key**. Give it a descriptive name, for example, `Lovable Google Maps Platform server key`. Click **Edit API key**. Under **API restrictions**, select **Restrict key** and enable only the server-side APIs from Step 1 that your app uses. Under **Application restrictions**, leave **None** selected. Lovable's gateway IPs are not published, so adding an IP allowlist will break requests. Save and copy the key. It starts with `AIza` and is 39 characters long. Restrict the server key to only the APIs you actually call. This limits the impact if the key is ever leaked. #### Step 3: Create the browser API key The browser key is referrer-restricted and exposed to the frontend as a public environment variable. In the Lovable connection form, this field is marked **Public** with the caption "This value will be publicly visible in your published app." On the same credentials page, click **Create credentials** → **API key**. Give it a descriptive name, for example, `Lovable Google Maps Platform browser key`. Click **Edit API key**. Under **Application restrictions**, select **Websites** and add every domain your app is served on, for example: * `https://your-project.lovable.app/*` * `https://yourdomain.com/*` and `https://www.yourdomain.com/*` (any custom domains) Under **API restrictions**, select **Restrict key** and enable only **Maps JavaScript API** and **Places API (New)**. The browser key is not authorized for Geocoding, Routes, or other server-side APIs. Save and copy the key. The browser key is public by design and will appear in your app's frontend code. The website-referrer restriction is what prevents other sites from reusing it, always set it before going to production. For more on locking down keys, see [Google's API security best practices](https://developers.google.com/maps/api-security-best-practices). #### Step 4: Connect Google Maps Platform to Lovable Open **Connectors** → **App connectors** and select **Google Maps Platform**. Click **Add connection**. In **Display name**, enter a name, for example, `Google Maps Platform Prod`. Select **Your own credentials**. Paste the key from Step 2 into **Server API Key** ("Server-restricted API key for backend use (geocoding, directions, places)"). Paste the key from Step 3 into **Browser API Key** ("Referrer-restricted API key for the Maps JavaScript API (embedded maps, autocomplete)"). Under **Who can access this connection**, keep access limited to yourself, invite the entire workspace, or restrict to specific people. Click **Connect**. When connected, server-side calls are routed through Lovable's gateway using the server key, and the browser key is available to your frontend as `VITE_LOVABLE_CONNECTOR_GOOGLE_MAPS_BROWSER_KEY`. The connection form validates the key format (it must match `AIza` followed by 35 alphanumeric characters) but does not verify that the keys actually work against Google's APIs. Always test one backend request and one frontend map load after setup. ## Limitations The Google Maps Platform connector has the following limitations: * The **managed connection** only works on `*.lovable.app` domains. Use your own credentials for custom domains and for production. * The **managed connection** is rate limited to at most **12,000 server-side gateway requests per day per workspace** and is not intended for production workloads. * The **browser key** is only authorized for the Maps JavaScript API and Places API (New). All other Google Maps Platform APIs must be called from the server through Lovable's gateway. * **Billing and quotas** are managed in Google Cloud, not Lovable. Set budget alerts and quota caps in the Google Cloud console. * The connector does not support **per-end-user authentication**, each connection uses a single shared set of keys for the workspace. * The **connection-creation form** validates the key format only, not API restrictions or referrer rules. Always test a real request after setup. * The Lovable connector gateway does not expose a public list of egress IPs, so **IP-based restrictions** on the server key are not supported. ## Common issues * **Maps fail to render with `RefererNotAllowedMapError`.** The browser key's website restrictions don't include the domain the app is actually being served on. Add the exact origin (including subdomain and protocol) in the Google Cloud credentials page. * **Server-side calls return `REQUEST_DENIED`.** Either the API isn't enabled in the Google Cloud project, or the server key's API restrictions don't include the API being called. Re-check both in the Google Cloud console. * **`Geocoder` or `DirectionsService` calls fail when called from the browser.** The browser key isn't authorized for Geocoding, Routes, or other server-side APIs. Move those calls to the server so they route through Lovable's gateway with the server key. * **Maps fail on a custom domain with the managed connection.** Expected, the managed browser key is locked to `*.lovable.app`. Switch to your own credentials and add the custom domain to the browser key's referrer restrictions. * **Server-side calls return `429 Too Many Requests` on the managed connection.** The workspace has hit the managed connection's daily gateway limit (12,000 requests per day). Wait for the limit to reset, reduce call volume, or switch to **Your own credentials** for production traffic. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Google Search Console (GSC) Source: https://docs.lovable.dev/integrations/google-search-console Connect your app to Google Search Console (GSC), Google's free service for monitoring search performance, to verify domains, submit sitemaps, read search analytics, and answer SEO questions directly in chat, or to build SEO features into your Lovable app. [Google Search Console](https://search.google.com/search-console) (GSC) is Google's free service for monitoring how a site performs in Google Search. With the GSC connector, you can have Lovable set up Search Console for your Lovable app (verifying the domain, submitting a sitemap), answer SEO questions in chat by reading live data, and optionally build SEO dashboards or tools into your app. With Google Search Console, Lovable can: * Verify your site's domain in Search Console: generate the meta-tag token, embed it in your app's HTML, and complete verification end-to-end * Submit and manage sitemaps for verified sites * Answer SEO questions in chat using live data: top queries, top pages, clicks, impressions, CTR, average position, indexing status * Inspect individual URLs: check index status, last crawl, mobile usability, and rich results * List verified sites in the connected Search Console account * Read sitemap status including warnings, errors, and indexed counts If you want a long-lived SEO surface inside your app, you can build it on top of the same connector. Search Console data is typically delayed by a couple of days. Today's clicks and impressions won't appear in search analytics until Google finishes processing them. Build dashboards and reports around the most recent fully-populated day rather than "today." ## Ways to use the Google Search Console connector There are two ways to get value out of the Google Search Console connector. ### Ask Lovable to do SEO work for you The highest-value use of the connector is letting Lovable do SEO work on your Lovable app while you're building, without you having to write any code. When the connector is linked, you can just chat with Lovable about SEO topics. | Example prompt | What Lovable does | | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | *Verify my Lovable app's domain in Google Search Console.* | Generates a meta-tag verification token, embeds it in your app's HTML ``, deploys it, calls Google's verify endpoint, and adds the site as a verified property in Search Console. | | *Submit my sitemap to Google.* | Generates or locates `sitemap.xml` in your app and submits it to Search Console for the verified property. | | *Why isn't my homepage showing up in Google?* | Runs URL Inspection on the homepage and explains the index status, last crawl, and any indexing issues in plain language. | | *What are my top 10 search queries this week?* | Queries Search Analytics, ranks queries by clicks or impressions, and answers in chat. | | *Did any of my pages drop in rankings last week?* | Pulls Search Analytics for two periods, compares, and highlights the biggest movers. | | *Are there any errors in my submitted sitemaps?* | Lists submitted sitemaps for the property and surfaces any warnings, errors, or low indexed counts. | See [Optimize your app for SEO and AI search](/features/seo-aeo) for more information. ### Build SEO features into your app You can also expose Search Console data inside your live Lovable app: | Example app | Example prompt | Description | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SEO performance dashboard | *Use Google Search Console and build a dashboard that shows clicks, impressions, CTR, and average position for my verified site over the last 28 days.* | **Visualize organic search performance in one place.**
Trend charts plus drill-downs into top queries and top pages. | | Top queries and pages report | *Use Google Search Console and build a weekly report that lists my top 50 search queries and the pages they drive traffic to.* | **Turn raw GSC data into a readable weekly report.**
The app aggregates queries and pages, ranks them by clicks or impressions, and renders an exportable summary. | | Keyword tracking with alerts | *Use Google Search Console and build a keyword tracker that records average position for my target queries each day and flags ranking drops.* | **Watch a list of important queries over time.**
The app records search analytics snapshots on a schedule you set up, compares them across days, and highlights queries that lost ground. | | URL inspection tool | *Use Google Search Console and build a tool where I paste a URL and see its index status, last crawl date, and any indexing issues.* | **Diagnose individual pages without opening Search Console.**
The app calls URL Inspection for the given URL and renders a readable summary of how Google sees it. | | Sitemap manager | *Use Google Search Console and build a tool that lists my submitted sitemaps and lets me submit new ones or delete old ones.* | **Manage sitemaps for a verified site without leaving your app.**
The app lists submitted sitemaps with their status, warnings, and indexed counts, and lets you submit or delete sitemap URLs. | | Period-over-period comparison | *Use Google Search Console and build a report that compares last week to the week before, with movers by query and by page.* | **Quantify growth or regressions over time.**
The app runs two search analytics queries, joins the results, and ranks the biggest movers. | | Multi-site SEO overview | *Use Google Search Console and build an overview that shows traffic for every site I have verified in Search Console.* | **Compare performance across all your verified sites.**
The app fetches each verified property and renders a single dashboard so you can spot which sites are growing or declining. | | Content opportunity finder | *Use Google Search Console and build an app that finds queries where my pages rank between positions 5 and 20, pages I could improve.* | **Surface easy SEO wins.**
The app filters search analytics for queries in striking distance of page one and groups them by landing page so editors know what to update. | | Indexing health monitor | *Use Google Search Console and build a monitor that flags sitemaps with errors or sites that have dropped in impressions week over week.* | **Catch indexing and visibility problems early.**
The app reads sitemap status and search analytics on demand (or on a schedule you set up), compares periods, and highlights regressions in a focused view. | ## How Google Search Console connections work The Google Search Console connector uses OAuth2 against a Google account and runs through Lovable's gateway architecture for secure token storage and automatic refresh. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication. Within your Lovable workspace: * You can create multiple Google Search Console connections. * Each connection is a separate OAuth authorization against a Google account, with its own selected scopes. * Each connection has connection-level access control: by default only the person who created it can use it, but the connection can be opened up to specific workspace members or to the entire workspace. * Multiple projects can use the same connection. This makes it easy to separate environments (for example, a Google account that owns a staging property versus a production property), to connect multiple Google accounts that own different sites, or to keep an account's access scoped to a single person. ## How to connect Google Search Console Workspace **admins** and **owners** can connect Google Search Console. When a connection is created, Google Search Console becomes available across all projects in the workspace, subject to the connection's access settings. ### Prerequisites Before connecting Google Search Console, make sure you have: * A Google account * Lovable workspace admin or owner role You don't need to verify your site in Search Console first. Once connected, you can ask the agent to verify your Lovable app's domain for you. If you already have verified sites in your account, the agent will pick those up automatically. All requests made through this connector use the connected Google account and count toward Google Search Console's standard API quotas. Quota and any associated billing are handled directly by Google, not Lovable. ### Set up your Google Search Console connection Go to **Connectors** and select **Google Search Console**. Click **Add connection**. In **Display name**, enter a name to identify this connection in Lovable (for example, `GSC Prod`). This name is only used inside Lovable. Expand **Advanced settings** to view the Google permissions Lovable will request. Default scopes are pre-selected so the connection can read analytics, manage sitemaps, and verify new sites. Remove any scope you don't need by clicking the **×** next to it. Read-only analytics requires only the **View Search Console data for verified sites** scope, which is marked **Required**. See [Scopes and permissions](#scopes-and-permissions) for the full list. You can update scopes later by editing the connection and reconnecting. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. A Google authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable will redirect you instead. Choose the Google account you want to use, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, you can immediately ask Lovablw to verify your app's domain, submit a sitemap, or answer SEO questions about any of the Google account's verified sites. ## Scopes and permissions Google Search Console connections request scopes against two Google APIs: the Search Console API and the Site Verification API. **View Search Console data for verified sites** is required; the others are optional and can be removed before connecting. | Scope | What it lets the agent do | Required | | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -------- | | **View Search Console data for verified sites**
`webmasters.readonly` | Read-only access to search analytics, verified sites, URL inspection, and sitemap listings. | Yes | | **View and manage Search Console data and sitemaps for verified sites**
`webmasters` | Submit and delete sitemaps, and add new verified sites to Search Console. | No | | **Verify ownership of new sites via the Site Verification API**
`siteverification.verify_only` | Request verification tokens so the agent can prove ownership of a domain. | No | | **Manage the list of sites and domains you control**
`siteverification` | Complete verification, list verified sites, and remove verifications. | No | If you want the agent to verify domains for you, keep the verification scopes selected. If you only want read-only SEO data, you can deselect everything except the required scope. For full details, see Google's references for the [Search Console API](https://developers.google.com/webmaster-tools/v1/api_reference_index) and the [Site Verification API](https://developers.google.com/site-verification/v1/getting_started). ## Verifying a new domain from chat If you grant the verification scopes, Lovable can verify your app's domain end-to-end and add it to Search Console. Just ask it to. The flow has four steps and is built around Google's meta-tag verification method: 1. **Request a verification token.** The agent asks Google for a token for your site. 2. **Embed the meta tag.** The agent adds `` to the `` of your site's root URL. The tag must be server-rendered, not injected client-side, and the change must be deployed before continuing. 3. **Verify ownership.** The agent calls Google's verify endpoint using the same site identifier (including trailing slash) that was used to request the token. A `failedToFindMetaTag` error usually means the deploy isn't live yet, the tag is being injected on the client, the site is behind authentication, or the identifier doesn't match exactly. 4. **Add the site to Search Console.** Once verified, the agent registers the site as a property so it appears in your Search Console account. For example, prompt Lovable: ```text wrap theme={null} Use Google Search Console and verify ownership of https://example.com, then add it to Search Console. ``` When verifying through the connector, only the **meta-tag (`META`) method** is supported. DNS records, HTML file upload, and Google Analytics verification do not work, because the verification token must be server-rendered into the HTML `` of your site's root URL. The site also needs to be publicly reachable by Google's crawler at the time you call the verify endpoint. Use the exact same site identifier in every step, including the trailing slash (for example, `https://example.com/`, not `https://example.com`). A mismatch between the URL you used to request the token and the URL you pass to the verify endpoint is the most common cause of a `failedToFindMetaTag` error after the deploy is live. ## Quotas and limits All requests made through the connector count toward Google Search Console's standard API quotas, which are set by Google and shared with anything else using the same Google account: * **URL Inspection** has a strict per-property daily quota (around 2,000 queries per property per day at the time of writing). Apps or chats that inspect many URLs in bulk will hit this limit quickly. * **Search Analytics** queries are subject to Google's per-minute and per-day quotas. Large date ranges with multiple dimensions return paginated results and may need several requests. * Quotas reset on Google's schedule, not Lovable's. If you hit a `429` or quota error, neither you nor the agent can lift it. Wait for the quota window to reset or reduce request volume. For the current numbers, see Google's [Search Console API usage limits](https://developers.google.com/webmaster-tools/limits). ## Limitations The Google Search Console connector cannot: * Use DNS, HTML file upload, or Google Analytics for site verification. Only the **meta-tag** method is supported through the connector. * Request indexing for a URL (`urlNotifications:publish`). The connector targets Search Console and Site Verification only. * Modify search rankings or request reconsideration on a manual action. * Receive Google Search Console alerts as webhooks or push events. * Support per-end-user Google login (each connection uses a single connected Google account). For workflows the connector doesn't support, you can continue to use the [Google Search Console](https://search.google.com/search-console) web app directly. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Google Workspace Source: https://docs.lovable.dev/integrations/google-workspace Connect your app to Google Workspace to read and send email, manage calendars, store and create files, and use Google tools like Sheets, Docs, and Slides as part of your app's workflows. [Google Workspace](https://workspace.google.com/) includes services like Gmail, Google Sheets, Google Calendar, Google Drive, Google Docs, and Google Slides. The Google Workspace connectors enable your Lovable app to securely access and manage data from these services using your Google account. With Google Workspace, your app can: * Send and read emails with **Gmail** * Read and update spreadsheet data in **Google Sheets** * Create and manage **Google Calendar** events * Upload, organize, and retrieve files from **Google Drive** * Generate and edit documents in **Google Docs** * Create and update presentations in **Google Slides** Each connection is authorized for a single Google account. You can create multiple connections to work with multiple accounts or environments. Building an app that embeds an editable Google Doc, Sheet, or Slides deck? See [Edit Google Docs, Sheets, and Slides in Lovable](/tips-tricks/google-workspace-editing) for the recommended iframe URLs and a copyable knowledge file. ## Common use cases and example apps These examples show both single-service apps and multi-service workflows. You can combine Google connectors within the same project to build more advanced automation and internal tools. | Example app | Example prompt | Description | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sheets-powered CRM | *Build a simple CRM that reads contacts from this Google Sheet and lets me add and edit rows.* | **Manage structured customer data using Google Sheets as a backend.**
The app reads contact records from a spreadsheet, displays them in a clean interface, and writes updates back automatically. | | Team booking page | *Build a booking page that checks our Google Calendar availability and creates events when someone books.* | **Let users schedule time based on real calendar availability.**
The app checks free/busy data, shows open time slots, and creates calendar events when a booking is confirmed. | | Transactional email sender | *When a user submits this form, send them a confirmation email through Gmail.* | **Send automated emails directly from your app**.
The app formats submission details and sends confirmation or notification emails through the connected Gmail account. | | Drive-based file hub | *Build an internal tool that lists our Drive folders and lets me upload and organize files.* | **Create a structured file management experience on top of Google Drive.**
The app lists folders and files, supports uploads, and keeps documents organized without leaving the interface. | | Proposal generator | *Generate a Google Doc proposal from this form and save it to a specific Drive folder.* | **Automate document creation from structured input.**
The app generates a formatted Google Doc using form data and saves it to the appropriate Drive folder for sharing or review. | | Slide deck builder | *Turn this project brief into a Google Slides presentation with a title slide and bullet points.* | **Turn structured content into a starter slide deck.**
The app generates a basic Google Slides deck from your content as a starting point for further editing and styling. | | Expense tracker with receipts | *Build an expense tracker where receipts are uploaded to Drive and logged in a Google Sheet.* | **Combine file storage and structured tracking in one workflow.**
The app uploads receipt files to Drive and logs expense details in Sheets, linking each file to its corresponding record. | | CRM with email history | *Show contacts from my Google Sheet and display the latest emails exchanged with them from Gmail.* | **Enrich contact records with real communication history.**
The app pulls related Gmail conversations and displays them alongside structured CRM data. | | Weekly report automation | *Every Monday, read last week's metrics from Google Sheets and email a summary via Gmail.* | **Deliver recurring reports automatically.**
The app reads data from Sheets, generates a summary, and emails it to stakeholders on a schedule. | | Meeting notes automation | *After a Google Calendar event ends, generate meeting notes and save them as a Google Doc in Drive.* | **Turn meetings into structured documentation.**
The app reads calendar event details, generates organized notes, and saves them as a Google Doc in Drive. | | Client onboarding workflow | *When a new client is added to my Google Sheet, generate a proposal Doc and kickoff Slides deck and save both to Drive.* | **Automate multi-step onboarding workflows.**
The app uses structured client data to generate documents and presentations, storing them in Drive for immediate use. | ## How Google Workspace connections work Google Workspace connections are workspace-level integrations managed by workspace admins or owners. Admins and owners control which services the workspace connects and which permissions (scopes) each connection uses. This connector uses a single shared Google account for everyone who uses the app. If you need each end user to sign in with **their own** Google account and act on their own data, use an **[app user connector](/integrations/app-user-connectors)** instead. All Google Workspace connectors use OAuth 2.0 to securely connect to your Google account. When you create a connection, you sign in with Google and authorize Lovable to access specific services on your behalf. Within your Lovable workspace: * You can create multiple connections per Google service. * Each connection is a separate OAuth authorization tied to a Google account. * Each connection can use different scopes (permissions), so you can control exactly what the connection can access. * Multiple projects within a single workspace can use the same connection. This makes it easy to separate environments (for example, development and production) or connect different Google accounts for different purposes. Google Workspace connectors use Lovable's gateway architecture for secure OAuth handling and automatic token refresh. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. **Connections are tied to a specific Google account** Each Google Workspace connection is authorized using the Google account that signs in during setup. For example: * If you connect Gmail using `employee@company.com`, emails sent through that connection will be sent from `employee@company.com`. * If you connect Google Calendar with your account, events will be created on your calendar. * Files created in Drive, Docs, or Slides will be owned by the connected account. Although the connection is available across the workspace, it always operates on the data of the Google account that authorized it. If your team needs to use a shared mailbox, shared calendar, or dedicated service account, make sure you authenticate using the appropriate Google account when creating the connection. ## How to connect a Google Workspace service Workspace **admins** and **owners** can connect Google Workspace services. When a connection is created, it becomes available across all projects in the workspace. ### Prerequisites * A Google account with access to the service you want to connect * Lovable workspace admin or owner role ### Set up your Google connection Go to **Connectors** and select the Google service you want to connect (for example, **Google Sheets**). Click **Add connection**. In **Display name**, name the connection (for example, `Google Sheets – Production`). Expand **Advanced settings** to view and configure scopes — the Google API permissions your app needs. Default scopes are pre-selected for common use cases. Select only the scopes your app needs. You can update scopes later by editing the connection and clicking **Reconnect**. For full scope documentation, see the [scope reference for each Google service.](https://developers.google.com/workspace/products) * Click **Connect**. The Google sign-in window opens — make sure your browser doesn't block pop-ups. * Sign in with the Google account you want to use, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, your Lovable apps can start using the selected Google service. ## Connecting multiple Google services If your app needs to use several Google services (for example, reading data from Sheets and sending results via Gmail), you can create a separate connection for each service. Each connector has its own OAuth flow and scopes, so they are configured independently. You can: * Connect multiple services to the same Google account * Use different Google accounts for different services * Create separate connections for development and production ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Granola Source: https://docs.lovable.dev/integrations/granola Connect your app to Granola, an AI meeting notes platform, to bring meeting notes, AI summaries, and transcripts from your Granola workspace into your Lovable apps. [Granola](https://www.granola.ai/) creates AI-generated meeting notes, summaries, and transcripts. The Granola app connector lets your Lovable app read meeting context from your Granola workspace using a managed workspace-level connection, so the decisions, requirements, and follow-ups from a meeting flow straight into the product you're building. This page covers Granola as an **app connector**, which provides meeting context both while you build and inside your deployed app. Granola is also available as a [chat connector](/integrations/mcp-servers), which only provides meeting context to the Lovable agent while you build. With Granola, your app can: * Retrieve AI-generated meeting notes and summaries * Access full meeting transcripts on demand * Build workflows around meeting intelligence * Sync action items and notes into your product Granola is a good fit when your app needs to work with meeting context, follow-ups, or past decisions captured in Granola. ## Common use cases and example apps | **Example app** | **Example prompt** | **Description** | | :---------------------------------- | :------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Customer call to product change** | *Use Granola and build the onboarding flow Lisa described in our call yesterday. Pull the notes from Granola.* | **Turn discovery-call decisions into working code the same day.**
The app pulls the relevant Granola note, extracts the requested changes, and applies them to the product. | | **Sprint planning to prototype** | *Use Granola and create the dashboard layout we agreed on in standup this morning.* | **Build from what was actually agreed in a meeting, not from memory.**
The app pulls the standup note from Granola and turns the agreed scope into a first-pass prototype. | | **Client feedback to build** | *Use Granola and implement the navigation changes from the design crit we just had with the client.* | **Move client feedback from a meeting straight into the build.**
The app reads the crit notes, identifies the requested changes, and applies them without a separate spec doc. | | **Action item tracker** | *Use Granola to pull action items from recent meeting notes and turn them into a task board.* | **Turn meeting follow-ups into trackable work.**
The app reads Granola summaries and organizes follow-up items so teams can assign, review, and complete them. | | **Customer call archive** | *Use Granola and build a customer meeting archive with search by account, date, and topic.* | **Make customer conversations easier to find.**
The app pulls transcripts and summaries from Granola so customer-facing teams can review prior calls without searching manually. | | **Product decision log** | *Use Granola to find product decisions from recent meeting notes and show them in a decision log with links to the source note.* | **Preserve meeting decisions in a structured format.**
The app extracts relevant summaries and lets teams browse past decisions with source context. | | **Weekly meeting digest** | *Use Granola and create a weekly digest that summarizes key topics, decisions, and next steps from recent meetings.* | **Summarize multiple meetings into one review flow.**
The app retrieves recent Granola notes and turns them into a concise recurring digest. | | **CRM note sync** | *Use Granola so that after a customer call, the Granola summary and transcript appear in the account timeline.* | **Keep customer records aligned with meeting context.**
The app uses Granola meeting data to enrich CRM-style records with notes, summaries, and next steps. | ## How Granola connections work Each Granola connection uses one Granola API key. The data available to your app depends on the API key type and the permissions of the Granola account or workspace behind that key. Granola supports two API key types: | **API key type** | **Who can create it** | **Granola plan required** | **What it can access** | | :---------------------- | :--------------------------- | :----------------------------- | :------------------------------------------------------------------------------------------ | | Personal API key (Beta) | Any Granola workspace member | Granola Business or Enterprise | Notes you own, notes directly shared with you, and notes in private folders shared with you | | Enterprise API key | Granola workspace admin | Granola Enterprise | All notes in the Team space | ## How to connect Granola Workspace **admins** and **owners** can connect Granola. You can create multiple Granola connections using different API keys. This makes it easy to create separate connections for API keys with different Granola access scopes, for example one connection for personal notes and another for the full Team space. When the connection is created, Granola can be linked to any project in the workspace. Multiple projects can use the same connection. ### Prerequisites Before connecting Granola, make sure you have: * A Granola workspace on a plan that supports the API key type you want to use * A Granola API key * Lovable workspace admin or owner role All API requests made through this connector use your Granola API key. API usage counts toward your Granola plan limits and billing is handled directly by Granola, not Lovable. ### Step 1: Create a Granola API key A Granola API key lets your Lovable app authenticate with Granola and read your meeting notes, summaries, and transcripts. Granola API keys are created in the Granola desktop app. To create a Granola API key: 1. Open the **Granola desktop app** and click on your workspace name. 2. Go to **Settings → Connectors → API**. 3. Click **Create new key**. 4. Choose a key type if Granola prompts you. 5. Click **Generate API Key**. 6. Copy the generated key and store it securely. Your Granola API key functions like a password. Keep it secure, do not share it publicly. You’ll need it in the next step. See Granola documentation for detailed instructions: [Granola API documentation](https://docs.granola.ai/introduction). ### Step 2: Connect Granola in Lovable You can create multiple connections using different Granola API keys. 1. Open **Connectors → App connectors** and select **Granola**. 2. Click **Add connection**. 3. **Display name**: Name the connection, for example `Granola Team Notes`. 4. **API key**: Enter your **Granola API key** (`grn_xxxxxxxx…`). 5. **Who can access this connection**: Keep access limited to specific people or invite the entire workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information 6. Click **Connect**. When connected, your Lovable apps can start accessing Granola meeting notes, summaries, and transcripts. ## Available data Through the Granola connector, your app can access meeting data that the connected API key is allowed to read. | **Data** | **Description** | | :--------------- | :-------------------------------------------------------------- | | Notes | Meeting notes available to the connected Granola API key | | AI summaries | Granola-generated summaries for processed meetings | | Transcripts | Full meeting transcripts when requested | | Owners | The note owner name and email when provided by Granola | | Meeting metadata | Fields returned by the Granola API, such as note IDs and titles | When prompting Lovable, mention what you need. For example, "list my last 10 meetings with their summaries", or "fetch the transcript for the most recent customer call". ## **Limitations** The Granola connector cannot: * Create, update, or delete Granola notes (read-only access) * Return notes that have not finished processing. Granola only returns notes that have a generated AI summary and transcript. Unprocessed notes are excluded from the list. * Support per-end-user Granola login (each end user connecting their own Granola account) * Exceed Granola's API rate limits. Granola API rate limits apply to requests made through the connector. * Lovable gateway limits also apply. See [Gateway-based connectors](https://docs.lovable.dev/integrations/introduction#gateway-based-connectors) for details. Each connection represents one Granola API key. It can only access the notes allowed by that API key type and the connected Granola account or workspace. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to HubSpot Source: https://docs.lovable.dev/integrations/hubspot Connect your app to HubSpot, a CRM platform, to manage contacts, track deals, and automate sales and marketing workflows. [HubSpot](https://www.hubspot.com/) is a customer relationship management (CRM) platform for managing contacts, companies, deals, and support tickets. When connected, your Lovable apps can read and write CRM data, automate workflows, and build internal tools or dashboards on top of your HubSpot account. With HubSpot, your app can: * Access and manage CRM contacts, companies, and deals * Create and track sales pipelines and deal stages * Automate CRM workflows and sales processes * Retrieve analytics and reporting data * Manage tickets and customer service interactions HubSpot is a good fit when your app depends on CRM data, sales pipelines, or customer records stored in HubSpot. ## Common use cases and example apps | Example app | Example prompt | Description | | :---------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Lead capture forms | *Build a lead capture form. Use HubSpot to create or update a contact when someone submits their name, email, and company.* | **Capture leads directly into your CRM so new contacts appear immediately in HubSpot.**
User submits a form, and the app creates or updates a contact record in HubSpot with the provided details so the sales team can follow up. | | Sales pipeline dashboards | *Build a sales pipeline dashboard. Use HubSpot to pull open deals, group them by stage, and add filters for owner and close date.* | **Visualize sales pipeline activity using data from HubSpot.**
The app retrieves deal records from HubSpot, groups them by pipeline stage, and lets users filter the results to understand pipeline health and progress. | | CRM management tools | *Build a CRM management tool. Use HubSpot to display contacts and deals and allow editing key fields directly from the app.* | **Manage CRM records through a simplified internal interface.**
The app retrieves contacts and deals from HubSpot, displays them in editable tables or forms, and writes updates back to the CRM. | | Support ticket trackers | *Build a support ticket tracker. Use HubSpot to pull open tickets and allow agents to update status and add notes.* | **Manage customer support tickets through a simplified interface.**
The app retrieves ticket records from HubSpot, displays them in a filterable list, and lets agents update ticket properties while syncing changes back to the CRM. | | Contact enrichment tools | *Build a contact enrichment tool. Use HubSpot to update contacts with additional company information or attributes.* | **Enrich CRM contact records with additional company information.**
User selects a contact or enters a company domain, and the app updates the HubSpot contact record with attributes such as company size, industry, or website details. | | CRM-powered client portals | *Build a client portal. Use HubSpot to retrieve company information, deal status, and ticket history for each logged-in customer.* | **Provide clients with visibility into their projects and support activity.**
User logs in to a portal where the app retrieves company, deal, and ticket records from HubSpot and displays them in a secure dashboard. | | Deal notifications and alerts (HubSpot + Slack) | *Build a deal notification workflow. Use HubSpot to detect when deals move to "Closed Won" and send a message to a Slack channel.* | **Notify the team about important pipeline events automatically.**
The app monitors deal stage changes in HubSpot and posts formatted alerts to Slack so the team stays informed about new deals and milestones. | ## How to connect HubSpot Workspace **admins** and **owners** can connect HubSpot. You can create multiple HubSpot connections using different service keys. This is useful for separating environments (for example, development and production) or limiting access through scoped permissions. When the connection is created, HubSpot becomes available across all projects in the workspace. ### Prerequisites Before connecting HubSpot, make sure you have: * A HubSpot account with **super admin access** or **developer tools permissions** (required to create service keys) * A HubSpot service key * Lovable workspace owner or admin role All API requests made through this connector count toward your HubSpot API usage limits. Limits depend on your HubSpot subscription and are managed by HubSpot, not Lovable. ### Step 1: Create a HubSpot service key A **service key** allows Lovable to securely access your HubSpot account through the HubSpot API. To create a HubSpot service key: 1. Go to [HubSpot](https://www.hubspot.com/) and set up your account. 2. Navigate to **Development → Keys → Service keys**. 3. Click **Create service key**. 4. Enter a descriptive name, for example `Lovable integration`. 5. Click **Add new scope** and select the scopes your app needs. For example: * `crm.objects.contacts.read` and `crm.objects.contacts.write` * `crm.objects.deals.read` and `crm.objects.deals.write` 6. Click **Update** after selecting scopes and review the selected scopes. 7. Click **Create**, then confirm in the dialog box. 8. Open the service key you created, and click **Show** to reveal the key. 9. Click **Copy** to copy it to your clipboard. Your service key functions like a password. Keep it secure and never share it publicly. You’ll need it in the next step. See HubSpot docs for detailed instructions: [Service keys](https://developers.hubspot.com/docs/apps/developer-platform/build-apps/authentication/account-service-keys). ### Step 2: Connect HubSpot to Lovable You can create multiple connections using different service keys. To connect HubSpot: 1. Go to **Connectors → App connectors** and select **HubSpot**. 2. Click **Add connection**. 3. **Display name**: name the connection, for example `HubSpot Prod`. 4. **Service key**: enter your HubSpot service key (`pat-xxxx…`). 5. **Who can access this connection**: keep access limited to specific people or invite entire workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. 6. Click **Connect**. When connected, your Lovable apps can access CRM data and manage contacts, deals, and other HubSpot objects. ## Limitations The HubSpot connector uses **service keys for authentication**, which support REST API requests only. Service keys cannot: * Receive HubSpot webhooks or event subscriptions * Authenticate calls within HubSpot UI extensions Need each end user to connect **their own** HubSpot account? Use the HubSpot **[app user connector](/integrations/app-user-connectors)** instead. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Inngest Source: https://docs.lovable.dev/integrations/inngest Connect your app to Inngest to add background jobs, scheduled tasks, and durable workflows to your Lovable apps using your own Inngest account. [Inngest](https://www.inngest.com/) is a workflow and background job platform that lets you run durable functions, scheduled tasks, and event-driven workflows. The Inngest app connector lets your Lovable apps call Inngest from your workspace using a managed workspace-level connection. Each Inngest connection uses your own Inngest credentials. After it is connected, projects in your workspace can use the connection to trigger and manage background workflows through your Inngest account. Use the Inngest connector when your app needs to run work outside of a user request, such as sending delayed notifications, processing data on a schedule, or orchestrating multi-step workflows with automatic retries. Use another path when: * You only need simple, one-off API calls that complete within a single request. In that case, a direct Supabase Edge Function may be sufficient. * You need each end user to connect their own Inngest account separately. App connectors are workspace-level, not per-end-user connections. ## Common use cases and example apps | Example app | Example prompt | Description | | :-------------------------- | :------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------- | | Scheduled report generator | *Run a function every Monday at 9am that generates a weekly summary and emails it to the team.* | Automate recurring tasks on a schedule without managing infrastructure. | | Post-signup onboarding flow | *When a user signs up, send a welcome email immediately, then a follow-up email 3 days later.* | Orchestrate multi-step delayed workflows triggered by app events. | | Data sync pipeline | *Every hour, pull new records from an external API and upsert them into the database.* | Run periodic background syncs that retry automatically on failure. | | Processing pipeline | *When a user submits a description, create a base image, fan out to create multiple sizes, save them and email when done.* | Fan out heavy/slow/unreliable processing to improve speed and reliability. | ## How Inngest connections work Each Inngest connection uses one Inngest Event Key and one Signing Key. Within your Lovable workspace: * You can create multiple Inngest connections. * Each connection is a separate credential setup. * Multiple projects can use the same connection. This helps you separate environments, such as staging and production. ## How to connect Inngest Workspace **admins** and **owners** can connect Inngest. When a connection is created, Inngest becomes available across all projects in the workspace. ### Prerequisites * **Connector roles:** workspace admins and owners can create and manage Inngest connections * **Additional admin controls:** on Business and Enterprise plans, workspace admins and owners can enable or disable app connector availability at the workspace level * **Prerequisites:** an Inngest account with an Event Key and Signing Key * **Recommended for production:** use separate Inngest environments for staging and production Inngest usage and pricing are owned by your Inngest account. Charges for function runs are billed by Inngest, not by Lovable. App connector connections are workspace-level. Anyone in the workspace who can use connected projects can use the Inngest connection in those projects. ### Set up your Inngest connection Open **Connectors** → **App connectors** and select **Inngest**. Click **Add connection**. In **Display name**, enter a clear name, for example `Inngest Prod` or `Inngest Staging`. Paste your Inngest Event Key and Signing Key in the authentication fields. You can find these in the Inngest dashboard under **Settings -> Keys**. Click **Create**. Prompt Lovable to add background jobs or scheduled workflows that use Inngest, then test by triggering an event and checking the Inngest dashboard for function runs. ## FAQ Yes. You need your own Inngest account and API keys to create an Inngest connection in Lovable. Function runs through this connector are billed by Inngest, based on your Inngest plan and usage. Yes. You can create multiple connections, for example to separate staging and production environments. Not through this app connector flow. App connectors are configured at workspace level. Verify your Event Key and Signing Key, confirm the function is registered in the Inngest dashboard, and check the Inngest function logs for errors or failed runs. Yes. Inngest supports cron expressions for scheduling functions on recurring intervals, such as every hour or every weekday at a specific time. ## Limitations * An Inngest app connector is a workspace-level credential, not a per-user connection flow. * Functions are managed and monitored through the Inngest dashboard, not within Lovable. * If a connected project stops triggering events after connector changes, open the connection and confirm it is still linked to the project. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Lovable integrations: Connect tools, MCP servers, and APIs Source: https://docs.lovable.dev/integrations/introduction Connect Lovable to external tools, MCP servers, and APIs. Add app functionality, use real data as context, and securely integrate third-party services. **Lovable integrations** let you connect your apps to **external tools, MCP servers, and APIs** to add functionality, use real data as context, and integrate third-party services securely. With Lovable, you can integrate: * **App connectors** to add capabilities to deployed apps * **Chat connectors (MCP servers)** to provide context during app creation * **Any API** for custom functionality ## Lovable integrations overview | **Category** | **Purpose** | **Examples** | | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------- | | **App connector** | Add capabilities and external services that your deployed app can call. Configured once by admins, who can choose who has access to each connection. | Lovable Cloud, Lovable AI, Stripe, Shopify, Firecrawl | | **Chat connector (MCP server)** | Connect your personal tool accounts to provide context while building. Only you can access your connections. | Linear, Notion, Miro, any custom MCP server | | **Any API** | Integrate custom or third-party APIs not built into Lovable when your deployed app needs custom functionality | Any API | **What is an API?**\ API (Application Programming Interface) is a structured way for services or applications to communicate and share data with each other. It defines what you can ask for, what you’ll get back, and how to make the request. ## App connectors: Add capabilities to your published app App connectors are the easiest way to extend the power of your Lovable app. They act like plug-ins that your app can call whenever it needs to perform an action or fetch data. App connectors are ideal when your **deployed app** needs to interact with external services to gain operational capabilities. For quick access to connectors from any location, use the [command palette](https://docs.lovable.dev/introduction/project-search-and-find#command-palette) (Cmd+K on Mac, Ctrl+K on Windows/Linux) and search for connectors. **You can also access connectors** from the following locations: * The Lovable dashboard sidebar navigation * The `+` menu next to the prompt input on the dashboard when starting a new project * The `+` menu next to the prompt input in an existing project chat, under **Project connectors** * The chat input: type `@` and pick an app connector to reference it directly in your message, both when starting a new project and in an existing project chat * Project settings dropdown * The project toolbar, under [**More → Connectors**](/features/projects/editor#the-more-menu) The **Project connectors** page gives you one place to see everything connected to a project. It shows app connectors under **App connections**, and the MCP servers your project can access under **Chat connectors**. To browse the full catalog, select **All connectors**. ### Overview and use cases * [Lovable Cloud](/features/cloud): providing built-in backend services, authentication, database, and full-stack hosting * [Lovable AI](/features/ai): powering your app with advanced AI capabilities * [Aikido](/integrations/aikido): testing your app for exploitable vulnerabilities with AI-powered penetration testing, and generating security reports * [Airtable](/integrations/airtable): reading and writing bases, tables, and records to build custom interfaces on top of Airtable data * [Algolia](/integrations/algolia): adding full-text search, faceted filtering, and indexing to your app with typo tolerance, ranking, and search analytics * [Apollo.io](/integrations/apollo): searching a B2B database of people and companies, enriching contact and organization data, and managing contacts, accounts, and deals * [Asana](/integrations/asana): creating and updating tasks, reading project and team data, and automating work tracking workflows * [Ashby](/integrations/ashby): managing jobs, candidates, applications, and hiring workflows through the Ashby API * [Attention](/integrations/attention): working with sales conversations, transcripts, scorecards, and coaching insights in Attention * [AWS Athena](/integrations/aws-athena): running SQL queries against data in S3 and using the results to power dashboards and reports * [AWS S3](/integrations/aws-s3): reading and writing CSV, JSON, Parquet, and other data files in S3 buckets from your Lovable apps * [BigQuery](/integrations/bigquery): querying datasets and building analytics on Google BigQuery using Workload Identity Federation * [Brevo](/integrations/brevo): sending transactional and marketing emails, managing contacts and lists, and running communication workflows * [Calendly](/integrations/calendly): reading scheduled events, listing event types, creating single-use scheduling links, and managing invitees * [Chargebee](/integrations/chargebee): managing customers, subscriptions, invoices, checkout, and billing workflows from Chargebee * [ClickHouse](/integrations/clickhouse): running SQL queries against a self-hosted or ClickHouse Cloud database * [Contentful](/integrations/contentful): fetching and displaying published content from your headless CMS, including entries, assets, and rich text * [Databricks](/integrations/databricks): running SQL and calling Databricks workspace APIs with OAuth machine-to-machine credentials * [dbt Semantic Layer](/integrations/dbt-semantic-layer): querying governed metrics defined in dbt, sliced by dimensions and time grains, without writing warehouse SQL * [ElevenLabs](/integrations/eleven-labs): generating audio and text-to-speech * [Firecrawl](/integrations/firecrawl): scraping, crawling, and extracting website content * [Fireflies](/integrations/fireflies): reading meeting transcripts, summaries, and conversation intelligence from Fireflies.ai * [GatewayAPI](/integrations/gatewayapi): sending SMS and RCS messages, tracking delivery status, and receiving inbound mobile messaging events * [Gemini Enterprise](/integrations/gemini-enterprise): searching and summarizing connected enterprise data, showing grounded answers with citations, and building search or chat experiences on top of your Gemini Enterprise engine * [Google Maps Platform](/integrations/google-maps): geocoding addresses, calculating routes, searching places, and embedding interactive maps with Google Maps Platform * [Google Search Console](/integrations/google-search-console): reading search analytics, listing verified sites, managing sitemaps, and verifying ownership of new domains * [Google Workspace](/integrations/google-workspace): reading and sending email, managing calendars, storing and creating files, and using Sheets, Docs, and Slides in your app's workflows * [Granola](/integrations/granola): accessing AI-generated meeting notes, summaries, and transcripts from Granola * [GitHub API](/integrations/github-api): reading and managing repositories, issues, and pull requests through the GitHub REST API * [HubSpot](/integrations/hubspot): working with CRM contacts, companies, deals, and service data through the HubSpot APIs * [Inngest](/integrations/inngest): running durable background jobs, schedules, and event-driven workflows with your Inngest account * [KLIPY](/integrations/klipy): searching and embedding GIFs, stickers, and clips, and generating AI emoji from your app * [Linear](/integrations/linear): creating and updating issues, reading project and team data, and building issue tracking workflows * [Lexware](/integrations/lexware): working with accounting data, contacts, invoices, quotations, vouchers, and event subscriptions from Lexware * [Lightspeed](/integrations/lightspeed): working with retail POS products, inventory, outlets, customers, and sales from Lightspeed Retail X-Series * [LinkedIn](/integrations/linkedin): fetching and displaying your profile, creating posts and comments * [Logo.dev](/integrations/logo-dev): displaying company logos by domain, stock ticker, or crypto symbol directly in the browser * [Mailgun](/integrations/mailgun): sending transactional email from a verified domain, and tracking delivery events such as bounces, complaints, and unsubscribes * [Mapbox](/integrations/mapbox): embedding interactive maps with Mapbox GL JS, geocoding addresses, and calculating routes and directions * [Microsoft](/integrations/microsoft): connecting Outlook, Teams, OneDrive, Word, Excel, PowerPoint, and OneNote through Microsoft Graph * [Notion](/integrations/notion): reading and writing pages, querying databases, and building apps backed by Notion content * [Perplexity](/integrations/perplexity): answering questions and running web-backed research * [Pipedrive](/integrations/pipedrive): managing CRM data such as deals, people, organizations, activities, leads, and pipelines * [PrestaShop](/integrations/prestashop): reading and managing ecommerce catalog, order, customer, and inventory data from PrestaShop Webservice * [Replicate](/integrations/replicate): running open-source AI models for image, video, audio, and text generation * [Resend](/integrations/resend): sending transactional and marketing emails from your app workflows * [Salesforce](/integrations/salesforce): querying and managing CRM records including Accounts, Contacts, Cases, and Leads * [Semrush](/integrations/semrush): accessing SEO data, keyword research, domain analytics, backlinks, and position tracking from your Semrush account * [Sevdesk](/integrations/sevdesk): managing contacts, invoices, orders, vouchers, and bookkeeping workflows from Sevdesk * [Shopify](/integrations/shopify): managing ecommerce operations * [Slack](/integrations/slack): sending alerts, reading channels, and posting updates * [Snowflake](/integrations/snowflake): querying data and running SQL against Snowflake using OAuth * [Storyblok](/integrations/storyblok): fetching published or preview content (stories, links, tags, and datasources) from Storyblok's Content Delivery API * [Stripe](/integrations/stripe): handling payments or subscriptions * [Supabase](/integrations/supabase): authenticating users and storing data * [Telegram](/integrations/telegram): sending messages and receiving commands through bots * [TikTok](/integrations/tiktok): reading creator profiles, fetching published videos, and building social integrations from a connected TikTok account * [Twilio](/integrations/twilio): sending SMS and MMS messages, making voice calls, and adding phone-based communication flows * [Twitch](/integrations/twitch): building custom stream overlays, displaying live stream data, tracking channel activity, and creating tools for creators and communities * [Wave](/integrations/wave): reading and managing customers, products, invoices, estimates, vendors, and business accounting data from Wave * [Wix](/integrations/wix): reading and managing Wix sites, ecommerce, bookings, CRM, CMS, and business resources * [X](/integrations/x): looking up users, searching recent public posts, and building read-only social integrations with the X API v2 * [Wiz](/integrations/wiz): scanning your project's dependencies for known vulnerabilities using enterprise-grade software composition analysis * [WooCommerce](/integrations/woocommerce): reading and managing products, orders, customers, coupons, and store data from WooCommerce * [WordPress (self-hosted)](/integrations/wordpress): reading and managing posts, pages, media, and users on self-hosted WordPress sites * [WordPress.com](/integrations/wordpress-com): reading and managing WordPress.com sites and content * [Workday](/integrations/workday): letting each app user connect their own Workday account to read worker, organization, and time off data with their own permissions * [Zoho Books](/integrations/zoho-books): reading and managing accounting records including customers, invoices, bills, expenses, and projects * [Zoho CRM](/integrations/zoho-crm): reading, searching, creating, and updating CRM records such as leads, contacts, accounts, and deals When you need backend functionality, such as authentication, database, and storage, use [Lovable Cloud](/features/cloud), our built-in full-stack hosting platform. ### Key characteristics App connectors are workspace-level integrations that provide reusable app capabilities across projects. * Managed in **Connectors** → **App connectors** * Configured once at the workspace level * Provide functional capabilities your app can call while in use * Enabled by default on Free, Pro, and Business plans * Disabled by default on Enterprise plans * On Business and Enterprise plans, workspace admins and owners can manage connector availability and choose who can create connections in **Connectors → Admin settings → App connectors** ### Who can create connections On **Free and Pro** plans, any workspace member with the editor role or higher can create connections. On **Business and Enterprise** plans, workspace admins and owners can choose one of three states for each connector: * **Disabled**: the connector is unavailable and no one in the workspace can create new connections. (Enterprise plan default) * **Enabled for admins only**: the connector is available but only workspace admins can create new connections. (Business plan default) * **Enabled for editors and admins**: the connector is available and any workspace member with the editor role or higher can create new connections. Some connectors (Lovable AI, Stripe, Paddle, Shopify, and Supabase) only support **Enabled** or **Disabled**. Lovable Cloud availability is managed from the Lovable Cloud connector settings. Individual Lovable Cloud projects can be disabled from the project's Cloud Advanced settings. ### Who can manage connections When creating a connection, you can choose who has access to the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. This means: * **Only people with access** can link the connection to a project. * Projects that use the connection can **only be shared with workspace members that have access** to the connection. You cannot invite people outside your workspace to connections, which means any external collaborators will lose access to the project using the connection. * If someone without access tries to open a project that uses the connection, they will be blocked from accessing it. * You cannot link a connection to a project if doing so would remove the project owner's access. Connection-level access works alongside the [Who can create connection](#who-can-create-connections) settings described above. For example, when a connector is set to **Enabled for admins only**, non-admins can't create new connections, but anyone an admin has explicitly granted access to an existing connection keeps that access. Connection-level access is **not enforced after publishing**. Once a project is published, the live app is accessible regardless of connection access settings. ### App user connectors Some app connectors can also run as **[app user connectors](/integrations/app-user-connectors)**, where **each end user of your published app connects their own account** instead of sharing a single builder-owned credential. Use them when every visitor should act as themselves—seeing their own inbox, calendar, or CRM records. They're also the right fit when users must **inherit their own permissions**, such as querying a data warehouse like Snowflake or Databricks, so each person is limited to the data they're allowed to access and their actions stay accountable to them. ### Gateway-based connectors Most app connectors route through a **secure gateway** between your Lovable app and the third-party service. The gateway handles authentication automatically, keeps credentials out of your project, applies a per-project usage limit, and sends outbound traffic from a stable set of IP ranges. See [Integration security](/integrations/security#gateway-connectors) for the full details, and [Connector data flow](/integrations/security#connector-data-flow) for how data moves between your app and the third-party service. ### Approving connector actions in chat When Lovable's agent wants to use an app connector to make a change, such as sending a message or updating a record, it pauses and asks for your approval first. The approval card describes what Lovable wants to do and shows the request details. Read-only requests run without prompts. You can respond in three ways: * **Allow once**: approve this single action. * **Always allow**: let future actions for this connection, including write actions, run without asking first. * **Skip**: move on without running the action. The **Always allow** preference applies to you and that specific connection. You can change it later from the connection's settings, under **Agent approval for this connection**. ### Managed project secret: `LOVABLE_API_KEY` App connectors and [Lovable AI](/features/ai) rely on `LOVABLE_API_KEY` being present in each project. Lovable creates and manages this project secret automatically. ## Chat connectors: Provide context during app creation [Chat connectors (MCP servers)](/integrations/mcp-servers) give the Lovable Agent access to your internal tools and content, **during app creation**. They provide context so the agent can build apps that reflect your real workflows. Use chat connectors when your app should be created using the real content your organization already relies on. For quick access to connectors from any location, use the [command palette](https://docs.lovable.dev/introduction/project-search-and-find#command-palette) (Cmd+K on Mac, Ctrl+K on Windows/Linux) and search for connectors. **You can also access connectors** from the following locations: * The Lovable dashboard sidebar navigation * The `+` menu next to the prompt input on the dashboard when starting a new project * The `+` menu next to the prompt input in an existing project chat, under **Project connectors** * Project settings dropdown * The project toolbar, under [**More → Connectors**](/features/projects/editor#the-more-menu) The **Project connectors** page gives you one place to see everything connected to a project. It shows app connectors under **App connections**, and the MCP servers your project can access under **Chat connectors**. To browse the full catalog, select **All connectors**. ### Overview and use cases * **Amplitude:** using product analytics and feedback to inform app decisions * **Atlassian (Jira and Confluence):** aligning with tickets, roadmaps, and documentation * **Confidence:** evaluating feature flags, accessing experiment results, and incorporating experimentation logic into your app behavior * **Granola:** turning meeting notes, decisions, and action items into specs and tasks * **Hex**: using notebooks and data workflows to build apps grounded in real analyses * **HeyGen:** generating AI avatars, voiceovers, and videos to bring personalized video content into your apps * **Linear:** importing issues and specs to generate features * **Miro:** accessing your Miro boards and diagrams to generate interactive prototypes * **Notion:** referencing docs and pages to guide app behavior * **n8n:** mirroring or plugging into existing automation workflows * **Polar:** using billing, products, and subscription data to scaffold SaaS apps * **PostHog:** using product analytics and user behavior insights to inform features and flows * **Sanity:** accessing CMS content and schemas to build content-driven apps * **Custom MCP servers:** connecting internal or third-party systems ### Key characteristics Chat connectors let you connect your own tools to provide context while building (not app functionality). * Managed in **Connectors** → **Chat connectors** * Per-user connections, meaning only you can access and manage your connections * Not shared with other workspace members * Not included in your deployed app On **Business and Enterprise plans**, workspace admins and owners can manage chat connector availability for the workspace: * Enable or disable all **MCP server access** in **Settings → Privacy & security** * Enable or disable specific MCP servers in **Connectors** → **Admin settings → Chat connectors** ## Integrate any API with Lovable Lovable can integrate with **any external API**, public or private, authenticated or not. This is the most flexible integration type, allowing you to bring in functionality Lovable does not natively support. When you ask Lovable to integrate an API, it automatically chooses the correct approach: * **If the API requires no authentication**, your app calls the API directly. * **If the API requires authentication**, Lovable prompts you to enable Cloud and add a secret, and automatically creates an Edge Function to protect sensitive credentials. ### APIs without authentication If an API requires no credentials, there is no setup required. Just ask Lovable to integrate the API. For example: ```text wrap theme={null} Integrate Chuck Norris Jokes: https://api.chucknorris.io/jokes/random ``` Lovable detects that no key is required and adds the feature directly to your app. ### Authenticated APIs (requires secrets) For APIs that require authentication credentials or API keys, Lovable handles the integration securely using Lovable Cloud. Credentials are stored as secrets in the linked Cloud project and accessed only through Edge Functions, ensuring they remain protected. **Setup** 1. Ask Lovable to integrate the API and include key details: * Endpoint URLs and HTTP methods * Authentication method (API key header, query param, Bearer token, OAuth) * Required headers (Content-Type, custom headers) * Request and response format examples (JSON, params, bodies) * OpenAPI spec or documentation link 2. Enable [Lovable Cloud](/features/cloud). 3. Add your API key under **Cloud → Secrets.** **For example:** ```text wrap theme={null} Integrate the OpenWeatherMap API. Base URL: https://api.openweathermap.org/data/2.5. Auth: API key passed as a query parameter appid. I need an endpoint to fetch the current weather: GET /weather?q={city}&units=metric&appid={API_KEY}. Docs: https://openweathermap.org/current ``` Lovable generates the integration with an Edge Function and a weather widget where users can enter a city and fetch weather data. ## FAQ Lovable supports three types of integrations: **app connectors**, **chat connectors (MCP servers)**, and **any API**. App connectors add functionality to deployed apps, chat connectors provide context during app creation, and API integrations let you connect to any external service not built into Lovable. **App connectors** are used by deployed apps to call external services and are configured once at the workspace level. **Chat connectors (MCP servers)** are used only during app creation to give the Lovable Agent access to your tools and content, and are never included in the deployed app. Yes. Lovable can integrate with **any external API**, public or private. APIs without authentication can be called directly, while authenticated APIs are integrated securely using Lovable Cloud, secrets, and Edge Functions to protect credentials. # Connect your app to KLIPY Source: https://docs.lovable.dev/integrations/klipy Connect your app to KLIPY to search and embed GIFs, stickers, and clips, and generate AI emojis. [KLIPY](https://klipy.com/) is a media API that lets your Lovable app search and embed GIFs, stickers, and short clips, and generate AI emojis on demand. It's a drop-in media layer for chat, social, and commenting features. With KLIPY, your app can: * Search and embed GIFs, stickers, and short clips * Generate AI emojis on demand * Add a trending media picker to chat and social features Reach for the KLIPY connector when your app needs a media picker, reaction stickers, or generated emojis. For a handful of static images you ship yourself, keep them in your app's assets instead. ## Common use cases and example apps | Example app | Example prompt | Description | | :----------------------- | :---------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Chat with GIF picker** | *Use KLIPY and add a GIF picker to my chat app so users can search and send GIFs inline.* | **Let users react and reply with GIFs.**
The app adds a searchable GIF picker to the message composer and embeds the selected GIF in the conversation. | | **Sticker reactions** | *Use KLIPY and let users react to posts with stickers from a searchable picker.* | **Add expressive sticker reactions.**
The app surfaces a sticker search and attaches the chosen sticker as a reaction. | | **Meme / clip feed** | *Use KLIPY and build a trending feed of GIFs and clips users can browse and share.* | **Surface trending media in a feed.**
The app pulls trending GIFs and clips and renders a browsable, shareable feed. | | **Custom emojis tool** | *Use KLIPY and build a tool that generates custom AI emojis from a text prompt.* | **Generate custom emojis on demand.**
The app sends a prompt to KLIPY and renders the generated AI emojis for the user to download or send. | | **Social composer** | *Use KLIPY and add GIFs, stickers, and emojis to my social post composer.* | **Enrich a post composer with media.**
The app lets users search GIFs, stickers, and emojis so they can drop media into posts. | ## How to connect KLIPY Who can create KLIPY connections depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections). When adding a connection, you can choose between: * **Managed by Lovable** (no KLIPY account or API key required) * **Bring Your Own Key** (connect with your own KLIPY API key) When the connection is created, you can link it to the projects where you want to use it. Anyone building in a project can ask Lovable in chat to link their project to it. Follow the setup steps below based on how you want to connect KLIPY. Choose this option if you want the fastest setup. You don't need to create a KLIPY account or API key. Lovable provides and manages the credentials for you. You can create only one managed KLIPY connection per workspace. Go to **Connectors → App connectors** and select **KLIPY**. Click **Add connection**. In **Display name**, name the connection (for example, `KLIPY Prod`). Under **Authentication**, select **Managed by Lovable**. Managed connections are shared with the **entire workspace** by default. To limit who can use the connection, click **Restrict to specific people** under **Who can use this connection**. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Bring your own API key if you want to manage your KLIPY account, content, usage limits, and account settings directly in the KLIPY partner dashboard. All media requests made through this connector count toward your KLIPY account's limits. Billing and quotas are handled directly by KLIPY, not Lovable. You can create multiple KLIPY connections using different API keys, which is useful for separating environments (for example, development and production) or managing rate limits. ### Prerequisites Before connecting KLIPY, make sure you have: * A KLIPY account and API key * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) ### Step 1: Get your KLIPY API key Sign in to the [KLIPY partner dashboard](https://partner.klipy.com). Generate an API key for your app, or copy an existing one. With your own key you manage your KLIPY account, content, and usage limits directly. Your KLIPY API key functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. ### Step 2: Connect KLIPY to Lovable Go to **Connectors → App connectors** and select **KLIPY**. Click **Add connection**. In **Display name**, name the connection (for example, `KLIPY Prod`). Under **Authentication**, select **Bring Your Own Key**. In **API key**, paste your KLIPY API key. Use **Open KLIPY** below the field to jump to the partner dashboard if you need to generate one. Under **Who can use this connection**, decide who in your workspace can use the connection. You start as the only person with access: * **Only you** (default): leave the access list as is; only you can use the connection and its associated data. * **Invite specific people**: add workspace members by email; only you and the people you add can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable verifies the key against KLIPY before saving the connection. When connected, anyone building in a project can ask Lovable in chat to link their project to KLIPY (based on configured connection-level access). Your Lovable apps can then search and embed media and generate AI emojis through the connector. ## Limitations The KLIPY connector cannot: * Refresh or rotate API keys automatically. For Bring Your Own Key connections, generate a new key in the KLIPY partner dashboard and update the Lovable connection to rotate * Support per-end-user KLIPY login. Each connection represents a single KLIPY key shared across all projects linked to it * Manage your KLIPY account, content settings, or usage limits for Bring Your Own Key connections. Configure those in the KLIPY partner dashboard ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Lexware Source: https://docs.lovable.dev/integrations/lexware Connect your app to Lexware, an accounting and invoicing platform, to work with contacts, invoices, vouchers, articles, and accounting events from your Lovable app. [Lexware](https://www.lexware.de/) is an accounting and invoicing platform for managing business contacts, documents, vouchers, payments, and bookkeeping workflows. The Lexware connector lets your Lovable app call the Lexware API through a connected Lexware account. It is designed for apps that need to read or manage operational accounting data from Lexware. With Lexware, your app can: * Read company profile and accounting settings * Create and retrieve contacts, articles, invoices, quotations, and vouchers * Download generated accounting documents, such as invoice PDFs * React to invoice, payment, and contact changes with Lexware event subscriptions * Build bookkeeping, sales, and finance workflows around Lexware business data Lexware is a good fit when your app needs accounting data, document workflows, or back-office automation connected to a Lexware account. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------- | :-------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Invoice operations dashboard** | *Use Lexware and build a dashboard that lists open invoices, payment status, and customer details.* | **Track invoice work from one internal view.**
The app fetches invoice and contact data from Lexware so finance teams can review outstanding work. | | **Customer accounting portal** | *Use Lexware and build a customer portal that shows invoices, quotations, and downloadable PDFs.* | **Give customers access to accounting documents.**
The app retrieves the right documents from Lexware and presents them in a branded portal. | | **Voucher intake workflow** | *Use Lexware and build a voucher upload and review workflow for incoming expenses.* | **Move expense intake into a guided app.**
The app creates or retrieves voucher records in Lexware and helps operators review missing details. | | **Contact management tool** | *Use Lexware and build an internal tool for searching and updating business contacts.* | **Keep customer and supplier records accessible.**
The app reads contact records from Lexware and gives teams a focused interface for finance-related customer data. | | **Sales quote tracker** | *Use Lexware and build a quotation tracker that shows quote status and related contacts.* | **Monitor quotes before they become invoices.**
The app retrieves quotations and related contact data from Lexware for sales and finance follow-up. | | **Accounting event monitor** | *Use Lexware and build an event monitor for invoice, payment, and contact changes.* | **React to Lexware changes in app workflows.**
The app uses event subscriptions to receive change notifications and then fetches updated resources from Lexware. | ## How to connect Lexware Workspace **admins** and **owners** can connect Lexware. You can create multiple Lexware connections using different API keys, which is useful for separating environments (for example, development and production) or connecting different Lexware accounts. When the connection is created, Lexware becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Lexware, make sure you have: * A Lexware account with access to the public API * A Lexware public API key * Lovable workspace owner or admin role All API requests made through this connector use your Lexware API key. API usage, plan limits, and billing are handled directly by Lexware, not Lovable. ### Step 1: Get a Lexware API key A Lexware public API key lets your Lovable app authenticate with the Lexware API. You can create separate keys for different environments or apps. To create a Lexware API key: Sign in to Lexware and open the [Public API page](https://app.lexware.de/addons/public-api). If Lexware asks you to sign in first, complete the sign-in and then open the link again. Create or generate a public API key. Give it a descriptive name, for example `Lovable integration`, if Lexware asks for one. Copy the API key and store it securely. You need it in the next step. Your API key functions like a password. Keep it secure and never share it publicly. See Lexware documentation for more: [Lexware API documentation](https://developers.lexware.io/docs/). ### Step 2: Connect Lexware to Lovable You can create multiple connections using different API keys. Go to **Connectors → App connectors** and select **Lexware**. Click **Add connection**. 1. **Display name**: name the connection, for example `Lexware Prod`. 2. **API key**: paste your Lexware public API key. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to Lexware (based on configured connection-level access). Your Lovable apps can then work with Lexware accounting, contact, invoice, quotation, voucher, and article data. ## Working with Lexware event subscriptions Lexware supports event subscriptions for change notifications, including invoice, payment, contact, article, voucher, quotation, and related document events. When you ask Lovable to build webhook-based Lexware workflows, your app needs a public HTTPS callback endpoint. Lexware sends event notifications to that endpoint, and the app fetches the changed resource from Lexware after validating the callback signature. Lexware applies a low global rate limit of about 2 requests per second. Use pagination where available, avoid unnecessary parallel requests, and retry rate-limit responses with backoff. ## Limitations The Lexware connector cannot: * Create a Lexware account or API key for you * Automatically rotate API keys. To rotate a key, generate a new key in Lexware and update the Lovable connection * Preserve event subscriptions after the Lexware API key changes. Re-create Lexware event subscriptions after reconnecting with a new key * Support per-end-user Lexware authentication. Each connection represents a single Lexware account shared across projects linked to it ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Lightspeed Source: https://docs.lovable.dev/integrations/lightspeed Connect your app to Lightspeed Retail X-Series, a retail POS platform, to work with products, inventory, outlets, customers, and sales data from your Lovable app. [Lightspeed Retail X-Series](https://www.lightspeedhq.com/pos/retail/) is a retail point-of-sale platform for managing products, inventory, outlets, customers, payments, and sales. The Lightspeed connector lets your Lovable app call the Retail X-Series API through a connected Lightspeed store. With Lightspeed, your app can: * List outlets, registers, payment types, and retail settings * Read product catalogs, brands, price books, and inventory levels * Build customer and sales dashboards from Retail X-Series data * Create workflows around stock, promotions, gift cards, and store credit By default, Lightspeed connections request read scopes for common retail workflows. You can enable additional advanced scopes when your app needs to create or update resources in Lightspeed. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Retail inventory dashboard** | *Use Lightspeed and build an inventory dashboard that shows stock by outlet, low-stock products, and recent stock changes.* | **Monitor inventory across connected stores.**
The app reads product and inventory data from Lightspeed and helps operators spot items that need attention. | | **Sales performance dashboard** | *Use Lightspeed and build a sales dashboard with daily revenue, payment types, top products, and outlet filters.* | **Track store performance in one view.**
The app reads sales, payment, product, and outlet data from Lightspeed so retail teams can review trends without opening the POS. | | **Customer purchase history portal** | *Use Lightspeed and build a customer lookup tool that shows contact details, customer groups, and recent purchases.* | **Give staff context before customer conversations.**
The app combines customer and sales data from Lightspeed in a focused support or store operations screen. | | **Promotion planning tool** | *Use Lightspeed and build a promotion planner that lists products, brands, prices, and current inventory before a campaign starts.* | **Plan retail campaigns from live catalog data.**
The app reads products, price books, promotions, and inventory so merchandisers can choose the right items. | | **Gift card and store credit tracker** | *Use Lightspeed and build a tracker for gift card balances, store credit transactions, and related customer records.* | **Review customer value balances from Lightspeed.**
The app reads gift card and store credit data and links it to customer records for store teams. | | **Supplier and tax reference browser** | *Use Lightspeed and build an admin page that lists suppliers, tax rates, outlets, and user records for operations teams.* | **Surface Retail X-Series reference data for internal workflows.**
The app reads supplier, tax, outlet, and user data so teams can use consistent operational values. | ## How to connect Lightspeed Who can create Lightspeed connections depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections). When adding a connection, you can choose between: * **Managed by Lovable** (no Lightspeed OAuth application required, you only need your store's domain prefix) * **Lightspeed** (bring your own OAuth application with a client ID and client secret) You can create multiple Lightspeed connections using different Lightspeed stores or OAuth apps, which is useful for separating environments or managing multiple retail accounts. When the connection is created, you can link it to the projects where you want to use it. Anyone building in a project can ask Lovable in chat to link their project to it. All API requests made through this connector count against your Lightspeed Retail X-Series API limits and the permissions on the connected account. Billing and quota are handled directly by Lightspeed, not Lovable. Follow the setup steps below based on how you want to connect Lightspeed. Choose this option for the fastest setup. You don't need to register an OAuth application in the Lightspeed developer dashboard. Lovable provides and manages the OAuth application, and you authorize it against your own store. ### Prerequisites Before connecting Lightspeed, make sure you have: * A Lightspeed Retail X-Series account and store * Your store domain prefix, from `https://{domain_prefix}.retail.lightspeed.app` * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) ### Set up your Lightspeed connection Go to **Connectors → App connectors** and select **Lightspeed**. Click **Add connection**. In **Display name**, name the connection (for example, `Lightspeed Prod`). This name is only used inside Lovable to identify the connection. Under **Authentication**, select **Managed by Lovable**. In **Domain Prefix**, enter the store prefix from `https://{domain_prefix}.retail.lightspeed.app`, for example `my-store`. Expand **Advanced settings** to review the permissions your app requests. Default scopes are pre-selected for common read-only retail workflows. See [Scopes](#scopes) for the full list. Managed connections are shared with the **entire workspace** by default. To limit who can use the connection, click **Restrict to specific people** under **Who can use this connection**. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. The Lightspeed authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to Lightspeed if prompted, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to Lightspeed (based on configured connection-level access). Your Lovable apps can then work with Lightspeed Retail X-Series products, inventory, outlets, customers, sales, and related retail data. Bring your own OAuth application if you want to control the application registration, its branding, and its scope set yourself. In the connection form, this option is labeled **Lightspeed**. ### Prerequisites Before connecting Lightspeed, make sure you have: * A Lightspeed Retail X-Series account and store * Access to the [Lightspeed developer dashboard](https://developers.retail.lightspeed.app/applications) * A Lightspeed OAuth application with a client ID and client secret * Your store domain prefix, from `https://{domain_prefix}.retail.lightspeed.app` * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) ### Set up your Lightspeed connection Sign in to the [Lightspeed developer dashboard](https://developers.retail.lightspeed.app/applications). Create an OAuth application for Lovable, or open an existing one you want to use. In your Lightspeed OAuth application, add the redirect URI that Lovable shows during the connect flow. Save the application, then copy the **Client ID** and **Client Secret**. Go to **Connectors → App connectors** and select **Lightspeed**. Click **Add connection**. In **Display name**, name the connection (for example, `Lightspeed Prod`). This name is only used inside Lovable to identify the connection. Under **Authentication**, select **Lightspeed**. This is the bring-your-own-app option. Enter the connection details: * **Client ID**: paste the client ID from your Lightspeed OAuth application. * **Client Secret**: paste the client secret from your Lightspeed OAuth application. * **Domain Prefix**: enter the store prefix from `https://{domain_prefix}.retail.lightspeed.app`, for example `my-store`. Expand **Advanced settings** to review the permissions your app requests. Default scopes are pre-selected for common read-only retail workflows. See [Scopes](#scopes) for the full list. Under **Who can use this connection**, decide who in your workspace can use the connection. You start as the only person with access: * **Only you** (default): leave the access list as is; only you can use the connection and its associated data. * **Invite specific people**: add workspace members by email; only you and the people you add can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. The Lightspeed authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to Lightspeed if prompted, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to Lightspeed (based on configured connection-level access). Your Lovable apps can then work with Lightspeed Retail X-Series products, inventory, outlets, customers, sales, and related retail data. ## Scopes Default scopes are pre-selected for common read-only retail workflows. | Scope | Description | Default | | :---------------------------------------- | :------------------------------------------------------------------------------ | :------ | | Retailer configuration (`retailer:read`) | Read account configuration such as loyalty, timezone, country, and currency. | On | | Outlets (`outlets:read`) | Read outlets. | On | | Registers (`registers:read`) | Read registers. | On | | Payment types (`payment_types:read`) | Read payment types excluding internal payment types. | On | | Products (`products:read`) | Read products, product types, product images, brands, and tags excluding costs. | On | | Price books (`products:read:price_books`) | Read product price books. | On | | Inventory (`inventory:read`) | Read current and historical product inventory levels. | On | | Customers (`customers:read`) | Read customers and customer groups. | On | | Sales (`sales:read`) | Read sales and payments. | On | | Fulfillments (`fulfillments:read`) | Read sale order fulfillments. | On | | Promotions (`promotions:read`) | Read promotions and promotion product eligibility. | On | | Gift cards (`gift_cards:read`) | Read gift cards and gift card transactions. | On | | Store credits (`store_credits:read`) | Read store credit transactions. | On | | Suppliers (`suppliers:read`) | Read suppliers. | On | | Taxes (`taxes:read`) | Read tax rates, tax rules, and tax groups where applicable. | On | | Users (`users:read`) | Read user information except passwords. | On | Additional write, audit, channel, consignment, payment, serial number, service, and webhook scopes are available but off by default. Only select scopes your app needs. For full scope documentation, see [Lightspeed's OAuth scope reference](https://x-series-api.lightspeedhq.com/docs/scopes). ## Limitations The Lightspeed connector cannot: * Create a Lightspeed account for you * Bypass Lightspeed API limits, plan limits, connected-user permissions, or selected OAuth scopes * Provide per-end-user Lightspeed login. Each connection represents a single Lightspeed store authorization shared across projects linked to it * Deliver Lightspeed webhook events through a Lovable-managed webhook subscription If Lightspeed authorization is revoked from the Lightspeed side, you'll need to reconnect the integration in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Linear Source: https://docs.lovable.dev/integrations/linear Connect your app to Linear to create and update issues, read project and team data, and build issue tracking workflows in your Lovable apps. [Linear](https://linear.app/) is a project management tool built for software teams. It lets your Lovable app work with issues, projects, teams, cycles, and comments so you can build internal tools and automations that interact directly with your team's Linear workspace. With Linear, your app can: * Create and update issues and comments * Read team, project, and cycle data * Build dashboards that surface issue status and progress * Automate triage, reporting, and planning workflows Linear is a good fit when your app needs to work with engineering tasks, product planning, or issue tracking directly from your app interface. ## Common use cases and example apps | Example app | Example prompt | Description | | :----------------------- | :--------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bug reporting form | *Build an internal bug reporter that creates a Linear issue when a user submits a report.* | **Let users file bugs directly into Linear from your app.**
The app captures the submission and creates a properly formatted Linear issue in the right team queue, with no manual copy-paste required. | | Sprint dashboard | *Build a sprint dashboard that shows open issues by team and status, grouped by cycle.* | **Give your team a live view of sprint progress without leaving your app.**
The app reads current cycle data from Linear and displays issues by status, assignee, or priority. | | Feature request intake | *Build a product request intake form. When someone submits a request, create a Linear issue in the triage backlog.* | **Turn form submissions into structured Linear issues automatically.**
The app routes incoming requests directly into your Linear backlog so nothing falls through the cracks. | | Issue triage workspace | *Build an internal triage workspace that shows new Linear issues, lets me filter by team and priority, and update status from one view.* | **Help teams review and manage incoming work more efficiently.**
The app reads issues from Linear, organizes them into a focused triage interface, and lets users update priorities or statuses without switching tools. | | Project health dashboard | *Build a project health dashboard that pulls issue counts, completion rates, and blockers from Linear.* | **Combine Linear data with your app's context in a single internal view.**
The app reads project and cycle metrics from Linear and surfaces them alongside other operational data. | ## How Linear connections work Each Linear connection is authorized for a single Linear workspace. When you connect Linear, you authorize Lovable to access Linear on behalf of the authenticated account. Within your Lovable workspace: * You can create multiple Linear connections. * Each connection is a separate OAuth authorization. * Each connection can: * Use different scopes * Connect to a different Linear workspace * Multiple projects within a single workspace can use the same connection. This makes it easy to separate environments (for example, development and production) or manage multiple Linear workspaces. Linear uses Lovable's gateway architecture for secure OAuth handling and automatic token refresh. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. ## How to connect Linear Workspace **admins** and **owners** can connect Linear. When a connection is created, Linear becomes available across all projects in the workspace. ### Prerequisites Before connecting Linear, make sure you have: * A Linear account you can authorize via OAuth * Lovable workspace admin or owner role ### Set up your Linear connection When you connect Linear, your Linear data will be accessible to all users in your workspace. Open **Connectors** → **App connectors** and select **Linear**. Click **Add connection**. In **Display name**, enter a name for the connection, for example `Linear (Prod)`. Expand **Advanced settings** to review or adjust the requested OAuth scopes - the Linear permissions your app needs. **Read** and **Write** are selected by default and cover the most common use cases. Select only the scopes your app needs. You can update scopes later by editing the connection and clicking **Reconnect**. For full scope documentation, see [Linear scope reference](https://linear.app/developers#scopes). * Click **Connect**. The Linear authorization window opens, so make sure your browser does not block pop-ups. * Select the workspace you want to connect, review the requested permissions, and click **Allow**. You’ll be redirected back to Lovable with a confirmation. When connected, your Lovable apps can start using Linear data. ## Limitations The Linear connector does not support: * Receiving incoming Linear webhooks or real-time event subscriptions. Need each end user to connect **their own** Linear account? Use the Linear **[app user connector](/integrations/app-user-connectors)** instead. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to LinkedIn Source: https://docs.lovable.dev/integrations/linkedin Connect your app to LinkedIn, a professional networking platform, to read member profile data and publish posts from your Lovable app. [LinkedIn](https://www.linkedin.com/) is a professional networking platform with APIs for reading member profile data and publishing posts. The LinkedIn connector lets your Lovable app read the connected user their basic profile and email, and publish posts to LinkedIn on their behalf. It's designed for apps that need professional identity, content distribution, or LinkedIn-driven workflows. With LinkedIn, your app can: * Read basic profile details, including name and profile photo * Read the connected member's primary email address * Publish posts on behalf of the connected member The LinkedIn connector connects to a single LinkedIn account per connection via OAuth. It's a good fit for apps that surface profile data in dashboards or CRMs, or automate publishing to a member's LinkedIn feed. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Auto-publish blog posts to LinkedIn | *Use LinkedIn and build a tool that takes a draft article, formats it as a LinkedIn post, and publishes it to my LinkedIn feed.* | **Cross-post written content from one place to a member's LinkedIn feed.**
The app composes a post from an article draft and publishes it on behalf of the connected member. | | Scheduled post composer | *Use LinkedIn and build a scheduler where I draft posts, pick a publish time, and have them go out to LinkedIn automatically.* | **Plan and queue LinkedIn posts ahead of time.**
The app stores drafts with publish times and pushes each post to LinkedIn when its scheduled time arrives. | | Sales outreach companion | *Use LinkedIn and build an app that signs reps in with LinkedIn, pulls their profile into the CRM, and lets them publish prospecting posts.* | **Tie LinkedIn identity and publishing to a sales workflow.**
The app reads the rep's profile into CRM records and publishes posts to their LinkedIn feed when they trigger a campaign. | | Personal brand dashboard | *Use LinkedIn and build a dashboard where I draft, preview, and publish LinkedIn posts, with a record of everything I've shared.* | **Centralize LinkedIn publishing in a single workspace.**
The app provides drafting and preview tools, publishes posts on behalf of the member, and keeps a log of what's been posted. | | Event registration with LinkedIn login | *Use LinkedIn and build an event registration page where attendees sign in with LinkedIn and confirm their profile details.* | **Reduce signup friction by reading profile data from LinkedIn.**
The app authenticates the attendee with LinkedIn, pre-fills name and email, and confirms registration in one step. | ## How to connect LinkedIn Workspace **admins** and **owners** can connect LinkedIn. You can create multiple LinkedIn connections using different accounts, which is useful for separating environments or managing publishing across multiple members. When the connection is created, LinkedIn becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting LinkedIn, make sure you have: * A LinkedIn account you want to connect * Lovable workspace **owner** or **admin** role All API requests made through this connector count against the connected LinkedIn account's API quotas. Quotas and access are managed directly by LinkedIn, not Lovable. ### Set up your LinkedIn connection Go to **Connectors → App connectors** and select **LinkedIn**. Click **Add connection**. In **Display name**, name the connection (for example, `LinkedIn Prod`). This name is only used inside Lovable to identify the connection. Expand **Advanced settings** to review the permissions your app will request. Default scopes are pre-selected for common use cases. | Scope | Description | Default | | :-------------------------------- | :---------------------------------------------- | :------- | | OpenID (`openid`) | Authenticate the member identity with LinkedIn. | Required | | Profile (`profile`) | Read the member's basic profile information. | Required | | Email (`email`) | Read the member's primary email address. | On | | Publish posts (`w_member_social`) | Create posts on behalf of the connected member. | On | For full scope documentation, see [LinkedIn's authorization code flow reference](https://learn.microsoft.com/linkedin/shared/authentication/authorization-code-flow). Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. The LinkedIn authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to LinkedIn if prompted, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to LinkedIn (based on configured connection-level access). Your Lovable apps can then read profile and email data and publish posts on behalf of the connected member. ## Limitations The LinkedIn connector cannot: * Read other LinkedIn members' profiles, connections, or messages * Read or write comments, likes, or reactions * Manage company pages, ads, or organization posts * Receive LinkedIn webhooks or real-time events * Support per-end-user LinkedIn login. Each connection represents a single LinkedIn account shared across all projects linked to it. If LinkedIn authorization is revoked from the LinkedIn side, you'll need to reconnect the integration in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Logo.dev Source: https://docs.lovable.dev/integrations/logo-dev Connect your app to Logo.dev to display company logos by domain, stock ticker, or crypto symbol directly in the browser from your Lovable app. [Logo.dev](https://www.logo.dev/) is a logo and brand image API that lets your Lovable app display company logos by domain, stock ticker, or crypto symbol. It's designed for apps that show company branding, such as directories, dashboards, CRMs, and portfolio trackers. With Logo.dev, your app can: * Display company logos by domain in the browser * Render logos for stock tickers, ISINs, and crypto symbols * Add brand logos to dashboards, directories, and profile cards * Use `img.logo.dev` URLs with size, format, and theme options The Logo.dev connector is frontend-only. It uses a publishable key with the `img.logo.dev` image CDN, so logos load directly in the browser. It's a good fit when your app needs to show company branding without managing image assets yourself. This connector provides a publishable key for the `img.logo.dev` image CDN only. Logo.dev's server-side REST and Search APIs need a separate secret key that this connector does not provide. ## Common use cases and example apps | Example app | Example prompt | Description | | -------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Company directory** | *Use Logo.dev and build a company directory with a logo next to each company name.* | **Show recognizable branding in a list of companies.**
The app renders each company's logo from its domain through `img.logo.dev`. | | **CRM or customer dashboard** | *Use Logo.dev and add company logos to our customer list, keyed by their website domain.* | **Make customer records easier to scan with logos.**
The app looks up each customer's domain and displays the matching brand logo. | | **Stock or portfolio tracker** | *Use Logo.dev and build a watchlist that shows a logo next to each stock ticker.* | **Add company branding to financial data.**
The app renders ticker logos through `img.logo.dev/ticker/` alongside prices and stats. | | **Crypto tracker** | *Use Logo.dev and build a crypto dashboard with a logo for each coin.* | **Pair market data with recognizable coin logos.**
The app renders crypto logos through `img.logo.dev/crypto/` next to each asset. | | **Investor or startup database** | *Use Logo.dev and build a startup database where each company card shows its logo.* | **Turn a list of domains into branded company cards.**
The app fetches logos by domain and displays them on profile and detail cards. | | **Vendor or integrations page** | *Use Logo.dev and build a partners page that shows each vendor's logo in a grid.* | **Render a clean logo wall from a list of domains.**
The app loads each vendor's logo from `img.logo.dev` with consistent sizing. | ## How to connect Logo.dev Workspace **admins** and **owners** can connect Logo.dev. You can create multiple Logo.dev connections using different publishable keys, which is useful for separating environments (for example, development and production) or using keys with different domain restrictions. When the connection is created, Logo.dev becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Logo.dev, make sure you have: * A Logo.dev account * A Logo.dev publishable key (starts with `pk_`) * Lovable workspace owner or admin role Logo requests through this connector count toward your Logo.dev plan. Billing and quota are handled directly by Logo.dev, not Lovable. ### Step 1: Get a Logo.dev publishable key A publishable key lets your Lovable app load logos from the `img.logo.dev` image CDN in the browser. Because it's used in frontend code, you secure it with domain restrictions rather than keeping it secret. To create a Logo.dev publishable key: Sign in to [Logo.dev](https://www.logo.dev/dashboard/api-keys). Go to the **API keys** page in your dashboard. Copy a publishable key (it starts with `pk_`). Create one if you don't have it yet. Restrict the key to the domains where your app runs. This limits where the key can be used once it's in your frontend code. The publishable key is exposed in your app's frontend code, so set domain restrictions in Logo.dev to control where it can be used. Use a publishable key (`pk_`), not a secret key. You'll need it in the next step. See Logo.dev documentation for more: [Logo.dev API keys](https://www.logo.dev/docs/platform/api-keys). ### Step 2: Connect Logo.dev to Lovable You can create multiple connections using different publishable keys. Go to **Connectors → App connectors** and select **Logo.dev**. Click **Add connection**. 1. **Display name**: name the connection, for example `Logo.dev Prod`. This name is only used inside Lovable to identify the connection. 2. **Publishable key**: paste your Logo.dev publishable key (it starts with `pk_`). Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to Logo.dev (based on configured connection-level access). Your Lovable apps can then load company logos directly in the browser through `img.logo.dev`. ## Limitations The Logo.dev connector is frontend-only and cannot: * Call Logo.dev's server-side REST API or Search API (those need a separate secret key this connector does not provide) * Proxy logo requests through a Lovable gateway (logos load directly in the browser from `img.logo.dev`) * Refresh or rotate keys automatically. To rotate, create a new publishable key in Logo.dev and update the Lovable connection * Support per-end-user Logo.dev login. Each connection represents a single Logo.dev account shared across all projects linked to it. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Lovable API Source: https://docs.lovable.dev/integrations/lovable-api Learn what the Lovable API is, what it enables, and how to get started building apps programmatically with Lovable. The **Lovable API** makes it possible to create and share Lovable apps programmatically — turning ideas, prompts, or even images into fully-generated applications with a single link. It’s designed for developers, creators, and teams who want to **integrate Lovable into their workflows** or **automate app generation** from anywhere on the web. ## What is the Lovable API? The Lovable API is a growing suite of features that extend what you can do with Lovable beyond the web interface. The first release, [**Build with URL**](https://docs.lovable.dev/integrations/build-with-url), allows you to generate apps directly from a shareable URL. With it, you can: * Embed **Build with Lovable** buttons on your site or app. * Share app-generating links with teammates or customers. * Integrate Lovable app creation into internal tools or scripts. * Prototype instantly from a single link. ## Why use the Lovable API? * **Automation:** Trigger app creation from code, dashboards, or workflows. * **Integration:** Bring Lovable into your own product experience. * **Speed:** Generate and share new app ideas faster than ever. * **Shareability:** URLs make collaboration simple and frictionless. ## Get started * Read the full technical guide here: [**Lovable API: Build with URL documentation**](https://docs.lovable.dev/integrations/build-with-url) * Learn about the feature and real-world use cases in our announcement post:\ [**Build apps from a link with Lovable Build with URL**](https://lovable.dev/blog/introducing-lovable-api-build-with-url) ## What’s next for the Lovable API? The Lovable API is expanding. The latest addition is the [**MCP Server (Research Preview)**](/integrations/lovable-mcp-server) — a Model Context Protocol server at `https://mcp.lovable.dev` that lets AI clients like Claude Desktop and Cursor manage Lovable projects through natural language. More endpoints and integration options are on the way. Follow updates on the [Lovable Blog](https://lovable.dev/blog). # Lovable MCP server Source: https://docs.lovable.dev/integrations/lovable-mcp-server Connect AI agents and developer tools to Lovable using the Model Context Protocol. Build, iterate, and deploy apps programmatically. ## What is the Lovable MCP server? Lovable exposes itself as a [Model Context Protocol](https://modelcontextprotocol.io/) (MCP) server at `https://mcp.lovable.dev`. This lets an AI client manage your Lovable projects through natural language. When connected, your AI agent can create projects, send messages to Lovable, inspect code, deploy apps, and more, all without leaving the client you're already working in. The Lovable MCP server is available on all plans. This is different from [chat connectors (MCP servers)](/integrations/mcp-servers), which let the Lovable agent connect to your tools. The Lovable MCP server lets external agents connect to Lovable. ### What MCP is MCP (Model Context Protocol) is an open standard that lets AI agents discover and call external tools. When an agent connects to an MCP server, it can see what tools are available and decide when to use them. Lovable's MCP server makes Lovable one of those tools: findable, invokable, and composable. ### Supported AI clients The Lovable MCP server's OAuth flow is currently restricted to the following clients: * **ChatGPT** * **Claude** (Claude Desktop on macOS and Windows, and claude.ai) * **Claude Code** * **Cursor** * **VS Code** Other MCP clients cannot complete the OAuth flow at this time. The rest of this page refers to these supported apps as "the client" or "your client." ### The flow 1. An agent connects to the Lovable MCP server 2. The agent calls a tool (for example, `create_project`) with a description of what to build 3. Lovable builds the project and returns a preview URL 4. You can open the preview, review what was built, and continue iterating by sending more messages 5. The agent keeps building as you refine, adding features, fixing issues, and changing the design 6. When you're happy with it, publish with `deploy_project`. Or don't, publishing is always optional. ## Who this is for * **Developers using ChatGPT, Claude Code, Cursor, or VS Code** who want to spin up and iterate on Lovable projects without leaving their AI client or editor * **Teams** who want Lovable as a step in a larger agent flow: generate content, scaffold a UI, deploy it, and hand off the URL ## Why use the Lovable MCP server * **Agent-driven development:** Let your client scaffold and iterate on Lovable projects using natural language. * **Code inspection:** Read project files, diff changes, and browse edit history programmatically. * **Cross-tool workflows:** Combine Lovable with other MCP-connected tools in a single agent session. ## Common use cases | Scenario | Example prompt to your agent | Outcome | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | | Scaffold a new app | *Create a Lovable project called 'Feedback Hub' with a form for collecting user feedback* | Project created and first build completed | | Iterate on an existing project | *Add a dark mode toggle to my project \[ID]* | Agent sends message and waits for Lovable to finish | | Review recent changes | *Show me what changed in the last three edits to my project* | Unified diff of recent commits | | Deploy an app | *Deploy my project \[ID] and give me the live URL* | Project published; live URL returned | | Inspect the codebase | *List all files in my project and read the main App.tsx* | File tree and file content returned | | Compare multiple variants | *Build 3 versions of a landing page for \[product], each with a different layout and visual style. Deploy all three and give me the live URLs.* | Three deployed projects with live URLs to compare | ## Prerequisites * A Lovable account on any plan. * Third-party MCP client access enabled for your workspace, which allows external clients to connect to the Lovable MCP server * Enabled by default on Free, Pro, and Business workspaces * Disabled by default on Enterprise workspaces. On Enterprise, a workspace admin or owner can enable it in **Settings → Security → Privacy & security**, under [**Third-party MCP clients**](/features/privacy-and-security-settings#third-party-mcp-clients) * One of the [supported AI clients](#supported-ai-clients) installed ## Before you connect When you connect a client to the Lovable MCP server, it has the same account access you do. A few things to know before connecting: * **Scope is your full account, not one project.** Whatever client you connect can list, read, and edit every project you have access to in Lovable. * **Calls run live on your account.** Tool calls use real credits and edit real projects. * **`deploy_project` deploys the app and returns a live URL.** On Free and Pro plans, anyone with the link can reach the app. On Business and Enterprise plans, website access follows the workspace default. The URL may be restricted to workspace members only if internal publishing is configured. * **`query_database` runs SQL with your full database permissions.** Read, write, and schema changes. ## How to connect The Lovable MCP server uses OAuth for authentication. When you connect for the first time, your client opens a browser window to authenticate with your Lovable account. Workspace admins and owners can also find everything on this page inside Lovable: **Settings → Build & deploy → MCP server** shows the server URL, setup steps for common clients, and a **Manage access** shortcut to the workspace's [**Third-party MCP clients** setting](/features/privacy-and-security-settings#third-party-mcp-clients). Pick your client below. Add the Lovable MCP server in ChatGPT using this URL: ```text theme={null} https://mcp.lovable.dev ``` ChatGPT prompts you to authenticate via OAuth when you connect. Add Lovable through Claude's connector settings. Works in Claude Desktop (macOS and Windows) and on [claude.ai](https://claude.ai). In Claude, click the **+** sign. Click **Connectors** → **Browse Connectors**, then search for **Lovable**. Click **Connect**, then sign in to Lovable when Claude prompts you. The Lovable tools appear in the composer's tool menu once authentication is complete. Run this command in your terminal: ```bash theme={null} claude mcp add --transport http lovable "https://mcp.lovable.dev" ``` Alternatively, install the Lovable plugin, which also adds slash commands for common tasks: ```bash theme={null} /plugin install lovable@claude-plugins-official ``` The first time a Lovable tool runs, Claude Code opens a browser window to sign in to Lovable. Verify with `/mcp` (look for the `lovable` server) or ask Claude Code to "list my Lovable workspaces." If you prefer editing the config directly, add the following to your MCP configuration: * **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json` * **Windows:** `%APPDATA%\Claude\claude_desktop_config.json` ```json theme={null} { "mcpServers": { "lovable": { "type": "http", "url": "https://mcp.lovable.dev" } } } ``` If your config file already has an `mcpServers` object with other servers in it, add the `"lovable"` entry **inside** the existing object. Don't paste a second `mcpServers` block, the file won't be valid JSON. Restart Claude Desktop after saving. The Lovable tools will appear in your agent's tool list. Install the **Lovable** plugin in Cursor for a guided setup that connects the MCP server for you and adds slash commands for common tasks: `/lovable-new`, `/lovable-iterate`, `/lovable-db`, and `/lovable-deploy`. Sign in with your Lovable account when prompted on the first tool call. To connect the server manually instead, add the following to your MCP configuration (`~/.cursor/mcp.json` globally, or `.cursor/mcp.json` in your project root): ```json theme={null} { "mcpServers": { "lovable": { "type": "http", "url": "https://mcp.lovable.dev", "auth": { "CLIENT_ID": "6d465f583e1e4ce5801b1616f735670c" } } } } ``` If your `mcp.json` already has an `mcpServers` object with other servers in it, add the `"lovable"` entry **inside** the existing object. Don't paste a second `mcpServers` block, the file won't be valid JSON. Reload your Cursor window after saving. Add the Lovable MCP server through VS Code's MCP settings, or add the following to your MCP configuration file: ```json theme={null} { "servers": { "lovable": { "type": "http", "url": "https://mcp.lovable.dev" } } } ``` VS Code prompts you to authenticate via OAuth in your browser. ## Available tools The Lovable MCP server exposes the following tools. Tool calls run with your Lovable account's permissions and operate on your real projects. A machine-readable version of this reference, including tool parameters, lives at [mcp.lovable.dev/skill.md](https://mcp.lovable.dev/skill.md). It is maintained alongside the server, so it always matches the tools the server currently exposes. The skill, the Claude Code plugin, and client setup guides are open source in the [lovablelabs/mcp](https://github.com/lovablelabs/mcp) repository. ### Identity and workspaces | Tool | Description | | ----------------- | --------------------------------------------------------------------------------- | | `get_me` | Get the authenticated user's profile and workspaces | | `list_workspaces` | List all workspaces you belong to | | `get_workspace` | Get workspace details, including plan, credit balance, member count, and settings | ### Projects | Tool | Description | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `list_projects` | Search and list projects in a workspace, with filtering and full-text search | | `get_project` | Get project details, including editor URL, preview URL, and a screenshot of the current state | | `create_project` | Create a new project with an `initial_message` (the build prompt) to the agent. Optionally start from a template or a design system | | `deploy_project` | Publish a project to production hosting on `lovable.app` and get the live URL | | `remix_project` | Make a copy of an existing project into a workspace. The source project must be accessible to your workspace (your own workspace projects, templates, or projects with public remixing enabled) | | `set_project_visibility` | Set who can access the **project in the editor**, matching the share dialog options: `private` (your workspace audience with **Can edit**, default), `workspace_view` (your workspace audience with **Can view**, requires Business or Enterprise), or `draft` (**Restricted**, only people invited to the project, requires Business or Enterprise). Controls editor access only, not who can visit the published app | | `set_folder_visibility` | Set a folder to personal or workspace visibility. The change applies to all projects in the folder | | `move_projects_to_folder` | Move up to 30 projects into a workspace folder | | `list_template_projects` | List available project templates | | `list_design_systems` | List design systems available in a workspace | ### Agent interaction | Tool | Description | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `send_message` | Send a chat message to a project's AI agent and wait for the response. Supports `plan_mode` (discuss before building) and `files` attachments. Pass `wait=false` to return immediately and poll with `get_message` instead | | `get_message` | Get the status and content of a message, for example after `send_message` with `wait=false` | | `list_messages` | List recent messages in a project, newest first. Useful for finding message IDs when you only have a project ID | ### Knowledge and skills | Tool | Description | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `get_workspace_knowledge` | Get the workspace's [knowledge](/features/knowledge), the custom AI instructions that apply to all projects in the workspace | | `set_workspace_knowledge` | Set the workspace's [knowledge](/features/knowledge). Replaces the existing content entirely | | `get_project_knowledge` | Get a project's [knowledge](/features/knowledge), the custom AI instructions for that project | | `set_project_knowledge` | Set a project's [knowledge](/features/knowledge). Replaces the existing content entirely | | `list_workspace_skills` | List the workspace's [skills](/features/skills) | | `get_workspace_skill` | Get a workspace skill, including its full contents | | `create_workspace_skill` | Create a workspace skill. Workspace admins and owners only | | `update_workspace_skill` | Update a workspace skill. Workspace admins and owners only | | `delete_workspace_skill` | Delete a workspace skill. Workspace admins and owners only. This cannot be undone except by recreating the skill | ### Code inspection | Tool | Description | | ------------ | -------------------------------------------------------- | | `get_diff` | Get the unified diff from a message or commit SHA | | `list_files` | List all files in a project at a specific git ref | | `read_file` | Read the contents of a single file at a specific git ref | | `list_edits` | List the edit history of a project with pagination | ### Cloud database | Tool | Description | | --------------------- | ------------------------------------------------------------------------------------------- | | `get_database_status` | Check whether Lovable Cloud is enabled for a project | | `enable_database` | Enable Lovable Cloud on a Lovable project (takes 30-60 seconds) | | `query_database` | Execute an SQL query on a Lovable Cloud project. Supports reads, writes, and schema changes | ### Connectors | Tool | Description | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | `list_connectors` | List all connector integrations available in a workspace (standard, seamless, and MCP), with their enabled status | | `list_connections` | List authenticated connector accounts for a workspace | | `list_custom_connectors` | List MCP connectors added to a workspace, both from the catalog and custom | | `list_available_connectors` | Browse featured MCP connector templates available to add | | `add_connector` | Get the Lovable dashboard URL where you can add a connector. Connectors are always added through the Lovable UI, never programmatically | | `remove_connector` | Remove an MCP connector from a workspace | ### Analytics | Tool | Description | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `get_project_analytics` | Get historical analytics for a published project: visitors, pageviews, bounce rate, session duration, and breakdowns by page, source, device, and country. Requires `start_date` and `end_date` (RFC 3339) | | `get_project_analytics_trend` | Get the real-time visitor count and 5-minute trend for a published project | ### File uploads | Tool | Description | | --------------------- | -------------------------------------------------------------------- | | `get_file_upload_url` | Get a presigned URL to upload a file for use as a message attachment | ### Client-specific tools Two tools only appear in certain clients: * `render_project_widget` shows a live build-progress widget after `create_project`. It appears in clients that support MCP Apps, such as ChatGPT. * `import-claude-design-from-url` imports a Claude design into a new Lovable project. It appears in Claude clients only. ## Skills A skill is a reusable instruction file that tells your AI client how to use the Lovable MCP server effectively: when to trigger it, how to sequence tool calls, and what patterns to follow. Add it to your client once and it will know how to drive Lovable without extra prompting. Lovable publishes the skill at [mcp.lovable.dev/skill.md](https://mcp.lovable.dev/skill.md). It is maintained alongside the server, so it always matches the tools the server currently exposes. Download the file and add it to your client's skills or instructions directory, for example `.claude/skills/lovable-mcp/SKILL.md` for Claude Code. ## Troubleshooting Run `tools/list` to confirm the connection. If tools don't appear, troubleshoot based on how you connected: * **Connected through the client's UI (OAuth):** Open your client's connector or MCP settings, remove the Lovable entry, and add it again to re-run the OAuth flow. * **Using a config file:** Open the config file and confirm the JSON is valid and the `"lovable"` entry is nested inside the existing `mcpServers` object. Restart the client after saving. Call `list_workspaces` to retrieve valid workspace IDs. If you omit `workspace_id` on `create_project`, Lovable picks the workspace automatically when only one is eligible; if multiple workspaces qualify, the tool returns a `WAITING` response listing them so you can re-call with a specific `workspace_id`. The project ID is incorrect or the project was deleted. Call `list_projects` with the workspace ID to find the correct ID. The project doesn't have a database provisioned. Call `enable_database` first (takes 30-60 seconds), then retry. Confirm the table exists by running `SELECT table_name FROM information_schema.tables` through `query_database` first, then query the table you need. If your workspace has **Enforce SSO** enabled with a session duration (24 hours, 48 hours, or 7 days), the Lovable MCP server requires a fresh SSO sign-in once that window elapses. When the session expires, the server responds with `401 Unauthorized` and a `WWW-Authenticate: Bearer error="invalid_token"` challenge. Spec-compliant MCP clients (Claude Desktop, Cursor, Claude Code) automatically restart the OAuth flow, which opens a browser window so you can re-authenticate against your identity provider. To resolve it, complete the sign-in prompt in your browser. Your client picks up the new token automatically and tool calls resume. See [Set up single sign-on (SSO)](/features/business/sso) for how workspace owners and admins configure session duration. ## FAQ [Chat connectors](/integrations/mcp-servers) let the **Lovable agent** connect to your external tools (for example, Notion, Linear, or Miro) during a build session. The Lovable MCP server is the reverse: it lets **your external client** (ChatGPT, Claude, Claude Code, Cursor, or VS Code) connect to Lovable and control it programmatically. All plans. On Enterprise workspaces, a workspace admin or owner must first enable [Third-party MCP clients](/features/privacy-and-security-settings#third-party-mcp-clients) in **Settings → Security → Privacy & security**. API key authentication is not currently available. OAuth is the only supported way to connect to the Lovable MCP server. Standard Lovable credits apply to `create_project` and `send_message` calls. Other tools are free. The MCP server inherits your Lovable user permissions exactly, with no additional surface area. # Lovable mobile app Source: https://docs.lovable.dev/integrations/lovable-mobile-app Build, prompt, and review your Lovable projects from your phone or tablet. Lovable is available as a native app on iOS and Android, so you can keep building when you're away from your computer. Lovable on mobile shares the same account, projects, and credits as the web app. Sign in once and pick up where you left off on any device. ## Overview The mobile app gives you access to your Lovable projects from your phone or tablet. You can start something new, continue an existing project, prompt with voice or images, and get notified when a build is ready to review. It's designed to complement the desktop experience, not replace it. Most of what you do on the web is available on mobile, with a few exceptions listed below. Heavy editing, complex integrations, and detailed reviews are still better on a larger screen. ## Download iPhone and iPad. iOS 15 or later Phones and tablets. Android 9 or later ## What's different on mobile The mobile app uses a layout designed for one-handed use on smaller screens: * **Swipe between chat and preview.** Inside a project, swipe left or right to switch between the chat and the live preview. On desktop they sit side by side. See [the editor layout](/features/projects/editor#the-two-main-areas). * **Navigation gestures.** Swipe from the edge of the screen to go back. On Android, the hardware back button works too. * **Voice and photo input.** Tap the mic to dictate prompts (with a live waveform while you speak), or use the camera to attach a photo directly to a message. You'll be asked for permission the first time. * **Native sign-in.** Google and Apple sign-in use the system dialogs rather than redirecting through a browser. * **Push notifications.** Opt in from your device settings to be notified when a build is ready or needs your input. Tapping a notification opens the relevant screen. * **AI terms (iOS).** The first time you open the iOS app, you'll be asked to accept the AI terms and conditions. This is required by the App Store. * **Auto-updates.** The app prompts you when a new version is available. Some updates are required to keep things working. Detailed code review, the preview toolbar, and inline comments on the preview need a wider screen and are still best on desktop. ## Buying credits and upgrading plans on mobile **Billing works differently on iOS and Android** On **iOS**, credit top-ups and plan upgrades go through the App Store using Apple's in-app purchases. Web payment surfaces (upgrade buttons, pricing pages, billing settings) are replaced by the native flow. Receipts, refunds, and subscription management live in your Apple ID settings. If you prefer, you can also set up workspace billing on **lovable.dev** in your browser instead. On **Android**, in-app purchases aren't available yet. To top up credits or change your plan from an Android device, open **lovable.dev** in your mobile browser and check out with Stripe as you would on desktop. Your plan and credits sync back to the app automatically. | | iOS | Android | | --------------- | ------------------------- | ---------------------------------------------- | | Buy credits | In-app, via the App Store | In your mobile browser at lovable.dev (Stripe) | | Upgrade plan | In-app, via the App Store | In your mobile browser at lovable.dev (Stripe) | | Manage / refund | Apple ID settings | Lovable account settings on the web | Purchases sync back to the app automatically, regardless of which path you used. ## What's not available on mobile Most of Lovable works the same on mobile as on desktop. The following flows aren't supported in the app yet. Open **lovable.dev** in your browser to use them. ### Account and sign-in * **Creating a new account.** The mobile app's login screen only supports signing in. Sign up at **lovable.dev** first, then sign in to the app. * **Apple Sign-In on Android.** Available on iOS and the web only. On Android, use Google, GitHub, email, or SSO. * **Returning to the app after password reset.** The reset email opens in your browser. After resetting, come back to the app and sign in manually. ### Integrations * **Connecting OAuth integrations.** Connectors that use OAuth (including Slack, GitHub, Google Drive, Airtable, and similar services) can't be connected from the mobile app. Set them up on **lovable.dev**; they'll work in the app once connected. ### Editor and project menu * **Reduced project menu.** Tapping the project name in the editor opens a simplified sheet with **Credits**, **Settings**, **Rename project**, and **Appearance**. It's a compact version of the desktop [project name menu](/features/projects/editor#project-name-menu). * **Preview toolbar.** The [preview toolbar](/features/preview-toolbar) used for selecting elements, leaving comments on the preview, drawing annotations, and editing text directly in the preview isn't shown on small screens. This is a screen-size limitation rather than a platform one, so the same toolbar is hidden on a narrow desktop browser window. * **Mention and file picker.** When typing `@` in chat, the picker shows fewer items and no descriptions to fit the screen. To browse the full list, use the web app. ### Plans and billing * **In-app purchases on Android.** See the section above. * **Pricing page on iOS.** Browsing pricing in-app on iOS isn't supported. The page redirects you to the App Store flow. * **Upgrade prompts.** Inline "Upgrade" buttons that open checkout on the web (for example, from templates or design systems) instead route you through the App Store on iOS or to **lovable.dev** on Android. * **Billing and domain alerts.** Some warning banners (past-due payments, auto-renewal reminders, domain registrar verification) aren't shown in the mobile app. Watch for these by email or by checking your account on the web. ### Workspace management * **Exporting workspace members.** The "Export members" action in workspace **People** settings is web-only. ### Project workflows * **Offline use.** Lovable needs an active connection. There's no offline editing or draft mode. ### Operating system requirements * iOS 14 and earlier, and Android 8 and earlier, are not supported. If you run into something else that feels missing or broken on mobile, let us know. Tap your avatar in the app to open the user menu and use **Send feedback**. The app is updated frequently. ## FAQ Yes. The app is free to download on iOS and Android. Your plan and credits are shared with your Lovable account, regardless of how you sign in. Most of the product works the same way. A few flows (OAuth integrations, account creation, preview toolbar interactions and comments on the preview, some billing actions) still need to be done on **lovable.dev**. See "What's not available on mobile" above. No. Lovable requires an active internet connection. If you go offline mid-session, you'll see an offline indicator until you reconnect. iOS 15 or later on iPhone and iPad. Android 9 or later on phones and supported tablets. Open **lovable.dev** in your mobile browser and check out with Stripe as you would on desktop. Your plan and credits sync back to the app automatically. iOS subscriptions are managed through your Apple ID. Open **Settings → \[Your name] → Subscriptions** on your iPhone or iPad to change or cancel. On iOS, in-app payments go through the App Store. Tap your project name to find the **Credits** section, which links into the native purchase flow. # Connect your app to Mailgun Source: https://docs.lovable.dev/integrations/mailgun Connect your app to Mailgun to send transactional email, manage sending domains, and track delivery events from your Lovable app. [Mailgun](https://www.mailgun.com/) is a transactional email service that lets your Lovable app send email programmatically over the Mailgun API. It's designed for apps that need reliable delivery for receipts, notifications, password resets, alerts, and reports, with detailed tracking for bounces, complaints, and unsubscribes. With Mailgun, your app can: * Send transactional email through the Mailgun API * Send from a verified sending domain you manage in Mailgun * Track delivery events such as bounces, complaints, and unsubscribes * Read message and event metadata for auditing or in-app status * Read domain and route information from your Mailgun account Mailgun is a good fit when you want to send from your own domain, keep control of your sender reputation, or already manage your sending in Mailgun. For standard transactional emails (signup confirmations, password resets, receipts, internal notifications), use the built-in [Lovable Emails](/features/custom-emails). Reach for the Mailgun connector when you want to send from your own verified domain, scale beyond Lovable Emails, or you already manage your sending in Mailgun. ## Common use cases and example apps | Example app | Example prompt | Description | | --------------------------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Order confirmations and receipts** | *Use Mailgun to send order confirmation and receipt emails after checkout.* | **Send transactional notifications from app events.**
The app triggers Mailgun email sends whenever a user completes a purchase or status changes. | | **Account lifecycle email** | *Use Mailgun to send password reset and email-verification messages from `noreply@mydomain.com`.* | **Power account-lifecycle email from your own domain.**
The app generates secure links and sends them through Mailgun using your verified sending domain. | | **Form-to-email apps** | *Use Mailgun and build a contact form that emails submissions to our support inbox.* | **Turn form submissions into routed emails.**
The app validates the submission, formats the content, and sends it to the right recipient via Mailgun. | | **Scheduled reports and digests** | *Use Mailgun to email a weekly KPI digest every Monday at 9am.* | **Deliver recurring reports by email.**
The app compiles the data, renders an email, and sends it on a schedule. | | **Alerts and monitoring** | *Use Mailgun to email me whenever an order over \$1,000 is placed.* | **Surface high-signal events through email alerts.**
The app watches for matching events and emails the right people so they can act quickly. | | **Bounce and deliverability dashboard** | *Use Mailgun and build a dashboard showing bounces, complaints, and unsubscribes from the last 30 days.* | **Use Mailgun event data to monitor deliverability.**
The app reads Mailgun events and presents them in-app so you can clean lists and protect sender reputation. | | **Domain status admin page** | *Use Mailgun and build an admin page that lists our sending domains and their verification status.* | **Surface Mailgun account state inside your app.**
The app reads domain information from Mailgun so operators can manage sending without leaving the product. | ## How to connect Mailgun Workspace **admins** and **owners** can connect Mailgun. You can create multiple Mailgun connections using different API keys, which is useful for separating environments (for example, development and production), targeting different Mailgun accounts, or using keys with different rate limits. When the connection is created, Mailgun becomes available across all projects in the workspace. ### Prerequisites Before connecting Mailgun, make sure you have: * A Mailgun account * A verified sending domain in that Mailgun account * A Mailgun Private API key * The region where your Mailgun account is hosted (EU or US) * Lovable workspace owner or admin role All email sent through this connector counts toward your Mailgun plan and is billed by Mailgun, not Lovable. ### Step 1: Get a Mailgun Private API key A Private API key lets your Lovable app authenticate with the Mailgun API. You can create separate keys for different environments or apps. To create a Mailgun Private API key: Sign in to the [Mailgun app](https://app.mailgun.com/) with the account that owns your sending domain. Go to **Account → Security → API keys**. Create a new Private API key (give it a descriptive name, for example `Lovable integration`) or copy an existing one. Note whether your Mailgun account is hosted in the **EU** or **US** region. You'll need to select the matching region in Lovable. Your Private API key functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See Mailgun documentation for detailed instructions: [Mailgun API reference](https://documentation.mailgun.com/docs/mailgun/api-reference/intro/). ### Step 2: Connect Mailgun to Lovable You can create multiple connections using different API keys. Go to **Connectors → App connectors** and select **Mailgun**. Click **Add connection**. 1. **Display name**: name the connection, for example `Mailgun Prod`. 2. **API region**: select the region your Mailgun account is hosted in (**European Union** or **United States**). The default is **European Union**. The region must match the account the API key belongs to. A US key will not authenticate against the EU API. 3. **Private API key**: paste your Mailgun Private API key. 4. **Who can access this connection**: keep access limited to specific people or invite the entire workspace. See [**Who can manage connections**](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. When connected, your Lovable apps can start sending email and reading account data through Mailgun. ## Sending from your domain Mailgun sends email from domains you've verified in your Mailgun account. The connector does not configure DNS or verify domains for you. Before sending, make sure your sending domain is set up in the Mailgun app and shows as verified, with the required DKIM and SPF records added at your DNS provider. When prompting Lovable, mention the domain you want to send from (for example, `noreply@mydomain.com`) so the generated app uses it consistently. ## Limitations The Mailgun connector cannot: * Verify or register sending domains for you (configure these in the Mailgun app first) * Receive Mailgun event webhooks directly through the connector (you can poll Mailgun's events API instead, or configure webhooks to a Mailgun-side endpoint outside Lovable) * Refresh or rotate API keys automatically. To rotate, generate a new key in Mailgun and update the Lovable connection * Support per-end-user Mailgun authentication (each connection uses a single shared API key, scoped to the workspace) * Use more than one region per connection (a single connection authenticates against either the EU or US Mailgun API) ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Mapbox Source: https://docs.lovable.dev/integrations/mapbox Connect your app to Mapbox to embed interactive maps with Mapbox GL JS, geocode addresses, and calculate routes and directions from your Lovable app. [Mapbox](https://www.mapbox.com/) is a location platform for interactive maps, geocoding, routing, and static map images. The Mapbox connector lets your Lovable app render maps in the browser with Mapbox GL JS and call server-side Mapbox APIs through Lovable's connector gateway. It's designed for apps that need Mapbox-specific styles, Mapbox GL JS, or location features you want to run on Mapbox rather than another maps provider. With Mapbox, your app can: * Embed interactive maps with Mapbox GL JS using a public token * Geocode addresses and search places with the Geocoding API * Calculate routes and turn-by-turn directions * Render static map images for previews and thumbnails For a quick prototype with generic maps, geocoding, or directions, [Google Maps Platform](/integrations/google-maps) can be faster to set up. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Store locator** | *Use Mapbox and build a store locator with clustered pins, address search, and a sidebar that lists the nearest locations.* | **Help visitors find the closest location on a map.**
The app geocodes searches, renders pins with Mapbox GL JS, and updates the list as the map moves. | | **Delivery dispatch board** | *Use Mapbox and build a dispatch board that shows today's stops on a map, calculates route distance between pickup and dropoff, and sorts jobs by ETA.* | **Plan routes and ETAs for field operations.**
The app calls Mapbox routing server-side and renders stops and paths on an interactive map. | | **Real estate listings** | *Use Mapbox and build a property listing app where users browse homes on a map, filter by neighborhood, and open detail pages from each pin.* | **Browse listings on a map-first experience.**
The app centers the map on search results, renders listing pins, and links each pin to a detail page. | | **Travel itinerary planner** | *Use Mapbox and build a trip planner where users add stops, see them on a map, and view driving distance and time between each leg.* | **Visualize multi-stop trips with distances and times.**
The app geocodes stops, draws the route on a Mapbox map, and shows leg-by-leg summaries. | | **Event venue finder** | *Use Mapbox and build an event finder where users search by city, see venues on a map, and filter by capacity or event type.* | **Discover venues through map search and filters.**
The app geocodes venue addresses, renders them as pins, and filters the map and list together. | | **Static map previews** | *Use Mapbox and build an admin page that shows a thumbnail map image for each saved location using the Static Images API.* | **Generate map previews without loading a full interactive map.**
The app requests static map images server-side and displays them in list or card views. | ## How to connect Mapbox Who can create Mapbox connections depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections). You can create multiple Mapbox connections using different tokens, which is useful for separating environments (for example, development and production) or using different Mapbox accounts. When the connection is created, you can link it to the projects where you want to use it. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Mapbox, make sure you have: * A Mapbox account * At least one Mapbox access token: a **public token** (`pk.`) for browser maps, a **secret token** (`sk.`) for server-side APIs, or both * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) All Mapbox API usage counts toward your Mapbox plan and is billed by Mapbox, not Lovable. ### Step 1: Get Mapbox access tokens Mapbox uses two token types for different surfaces. They are not interchangeable. * **Public token (`pk.`)**: browser only. Use it for Mapbox GL JS and map tiles in the frontend. * **Secret token (`sk.`)**: backend only. Use it for geocoding, directions, static images, and every other server-side Mapbox API called through Lovable's connector gateway. Provide at least one token when you connect. Map-only apps can connect with a public token alone. Any server-side Mapbox feature requires a secret token on the connection. To create Mapbox access tokens: Sign in to [Mapbox](https://account.mapbox.com/). Go to [Access tokens](https://account.mapbox.com/access-tokens/). Create the tokens your app needs: 1. **Public token**: create or copy a default public token that starts with `pk.`. Restrict it to your app domains when you go to production. 2. **Secret token** (if you need geocoding, directions, or other server-side APIs): click **Create a token**, give it a descriptive name (for example, `Lovable integration`), choose the scopes your app needs, and copy the token that starts with `sk.`. Copy each token and store it securely. You'll paste them into Lovable in the next step. Your secret token functions like a password. Keep it secure, never embed it in frontend code, and never share it publicly. See Mapbox documentation for details: [Access tokens](https://docs.mapbox.com/help/glossary/access-token/). ### Step 2: Connect Mapbox to Lovable You can create multiple connections using different tokens. Go to **Connectors → App connectors** and select **Mapbox**. Click **Add connection**. 1. **Display name**: name the connection, for example `Mapbox Prod`. This name is only used inside Lovable to identify the connection. 2. **Secret token** (optional): paste your secret token (`sk.`) if your app needs server-side geocoding, directions, static images, or other backend Mapbox APIs. 3. **Public token** (optional): paste your public token (`pk.`) if your app renders Mapbox GL JS maps in the browser. This value is publicly visible in your published app after you link the connection to a project. Under **Who can use this connection**, decide who in your workspace can use the connection. You start as the only person with access: * **Only you** (default): leave the access list as is; only you can use the connection and its associated data. * **Invite specific people**: add workspace members by email; only you and the people you add can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. Lovable validates each token you provide against Mapbox before saving the connection. When connected, anyone building in a project can ask Lovable in chat to link their project to Mapbox (based on configured connection-level access). Your Lovable apps can then render Mapbox GL JS maps with the public token and call server-side Mapbox APIs through Lovable's connector gateway with the secret token. ## Public and secret tokens The connector accepts two tokens with different roles: * The **secret token** (`sk.`) is used for server-side Mapbox API calls. Lovable routes these requests through the connector gateway and exposes the token to your backend as `MAPBOX_API_KEY` after you link the connection to a project. Never use the secret token in frontend code. * The **public token** (`pk.`) is used for Mapbox GL JS in the browser. After you link the connection, Lovable exposes it as `VITE_LOVABLE_CONNECTOR_MAPBOX_PUBLIC_TOKEN`. Restrict this token to your app domains in the Mapbox account dashboard. You must provide at least one token when creating the connection. Browser-only map apps can connect with a public token alone. Geocoding, directions, and other backend Mapbox features require a secret token on the connection. Server-side calls must go through Lovable's connector gateway. Do not call `https://api.mapbox.com` directly from backend code in generated apps. ## Limitations The Mapbox connector cannot: * Use a public token (`pk.`) for server-side Mapbox API calls or through the connector gateway * Use a secret token (`sk.`) in frontend code or Mapbox GL JS * Replace domain restrictions on your public token. You must configure allowed URLs in the Mapbox account dashboard for production domains * Support per-end-user Mapbox authentication. Each connection represents a single Mapbox account shared across all projects linked to it * Refresh or rotate tokens automatically. To rotate, create new tokens in Mapbox and update the Lovable connection If a token is revoked or deleted in Mapbox, reconnect the integration in Lovable with a valid token before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Chat connectors: Connect your tools to Lovable using MCP servers Source: https://docs.lovable.dev/integrations/mcp-servers Connect Lovable to your personal tool accounts using MCP servers as chat connectors. Bring real context from tools like Notion, Linear, Jira, or Miro directly into your builds, moving from idea to validation to live app faster than ever. **MCP (Model Context Protocol)** is an open standard that connects AI systems, like Lovable, to external tools, services, and data sources. In Lovable, MCP servers are used as **chat connectors**. By connecting Lovable to tools such as Notion, Atlassian, or Linear, the Lovable Agent can use real team context to generate more accurate code, prototypes, and documentation. When connected, Lovable can read structured data (like text from docs, issues, or diagrams) and, where supported, perform limited actions such as creating or updating items. Lovable includes several prebuilt chat connectors and supports custom MCP servers on all plans. ## Why use chat connectors Chat connectors unlock two key capabilities: * **Bring your existing context into Lovable.**\ The Lovable Agent can read your team’s documentation, tickets, and design files to build prototypes and flows aligned with your standards. * **Connect your Lovable apps to your workflows.**\ The Lovable Agent can take follow-up actions in your connected tools, such as updating ticket statuses, adding prototype links as comments, or creating new items when supported. Lovable becomes more powerful when it understands your team’s world, eliminating guesswork, speeding up iteration, and helping you go from **idea to live app faster than ever.** ## Prebuilt chat connectors | Tool | Description | Example capabilities | | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Amplitude](https://amplitude.com/docs/amplitude-ai/amplitude-mcp) | Access your Amplitude product analytics and feedback. | **Turn user behavior into better product decisions.**
Bring product insights, user funnels, and feedback into Lovable so you can iterate on flows, optimize layouts, and run experiments with a simple prompt. | | [Atlassian](https://support.atlassian.com/atlassian-rovo-mcp-server/docs/getting-started-with-the-atlassian-remote-mcp-server/) | Access your Jira issues and Confluence pages. | **Turn product documentation into working prototypes.**
Lovable can read product documentation and linked Jira epics (PRDs, specs, architecture docs) to generate prototypes that match your team’s standards. Embed generated prototypes back into Confluence for feedback. | | [Confidence](https://confidence.spotify.com/docs/sdks/mcp-servers) | Access your feature flags and experiment data. | **Build and iterate with real experimentation context.**
Lovable can evaluate feature flags, read experiment results, and incorporate rollout logic into your apps, helping you ship features that are informed by real user experiments. | | [Granola](https://docs.granola.ai/help-center/sharing/integrations/mcp) | Access your Granola meeting notes, decisions, and action items. | **Turn meeting context into specs and tickets.**
Lovable can search across past meetings, pull out decisions and action items, and use what was agreed to generate PRDs, user stories, or follow-up tasks, without digging through notes. | | [Hex](https://learn.hex.tech/docs/administration/mcp-server) | Access your Hex notebooks and workspace data. | **Build apps powered by real analysis and data workflows.**
Lovable can query Hex notebooks, explore datasets, and use results as context to generate data-driven apps, dashboards, and workflows aligned with your existing analyses. | | [HeyGen](https://developers.heygen.com/mcp/overview) | Access your HeyGen avatars, voices, and video generation tools. | **Generate AI avatars and videos directly from your Lovable apps.**
Lovable can use HeyGen to create AI-generated avatar videos, voiceovers, and personalized video content as part of your apps and workflows. | | [Linear](https://linear.app/docs/mcp) | Access your Linear issues and project data. | **Prototype from real issues and tickets.**
Lovable can read Linear issues, including descriptions and acceptance criteria, to generate functional prototypes. Attach resulting apps back to Linear for review. | | [Miro](https://miro.com/ai/mcp/) | Access your Miro boards and diagrams. | **Bring your boards to life.**
Lovable can convert user flows, wireframes, or information architecture from your boards into interactive prototypes you can test and export back for feedback. | | [Notion](https://developers.notion.com/docs/mcp) | Access your Notion pages and databases as context while building. *Need your deployed app to read or write Notion at runtime? Use the [Notion app connector](/integrations/notion) instead.* | **Build directly from your team’s Notion workspace.**
Lovable can read PRDs, design specs, or marketing briefs and turn them into working apps, landing pages, or prototypes. Embed generated Lovable apps back into Notion for seamless collaboration. | | [n8n](https://docs.n8n.io/advanced-ai/mcp/accessing-n8n-mcp-server/) | Access and power your apps with your n8n workflows. | **Build workflow-rich apps with live data.**
Connect your n8n automations to Lovable to pull data from tools like HubSpot, Google Sheets, or Slack, and build user-facing apps powered by existing automations. | | [Polar](https://polar.sh/docs/integrate/mcp) | Access your Polar billing, products, customers, and subscriptions. | **Build subscription-enabled apps with real billing context.**
Lovable can use your Polar setup as context when scaffolding SaaS apps, checkout flows, pricing pages, subscription management, and customer billing experiences. | | [PostHog](https://posthog.com/docs/model-context-protocol) | Access your PostHog product analytics data. | **Turn product analytics into better features.**
Lovable can query user behavior, analyze funnels and events, and use real usage insights to generate flows, features, and improvements grounded in how users actually interact with your product. | | [Sanity](https://www.sanity.io/docs/ai/mcp-server) | Access your Sanity CMS content and schemas. | **Build content-driven apps with your CMS data.**
Lovable can read your Sanity documents, schemas, and structured content to generate apps, landing pages, and content management interfaces aligned with your content model. | | [Sentry](https://docs.sentry.io/product/sentry-mcp/) | Access your Sentry issues, errors, and project insights. | **Debug and monitor your apps with real error data.**
Lovable can read Sentry issues, exceptions, and performance data to help you identify and fix problems faster. | ### How to add a prebuilt chat connector To use prebuilt integrations with popular third-party apps and services: 1. Open **Connectors** and select a chat connector (for example, Notion or Linear). 2. Click **Add connection**. If the connector supports more than one connection type, choose **Chat connector**. 3. Sign in and grant Lovable access to your account. ### Additional setup for specific chat connectors [n8n](https://docs.n8n.io/advanced-ai/mcp/accessing-n8n-mcp-server/) In addition to these steps, you need to do the following in n8n: * Go to **Settings → MCP access** and toggle **Enable MCP access** (requires instance owner or admin permissions) * For each workflow you want to expose, go to **Settings** in the workflow editor and toggle **Available in MCP.** [Amplitude](https://amplitude.com/) If you plan to analyze your Lovable-built app, make sure it is already sending data to Amplitude before using the MCP connector. See the [Amplitude Quickstart guide](https://amplitude.com/docs/get-started/amplitude-quickstart) for setup instructions. [Hex](https://learn.hex.tech/docs/administration/mcp-server) Hex requires you to provide a custom server URL when connecting. For most users, the default URL is `https://app.hex.tech/mcp`. If you are on a single-tenant, EU multi-tenant, or HIPAA multi-tenant instance, replace `app.hex.tech` with your custom Hex domain (for example, `https://your-company.hex.tech/mcp` or `https://eu.hex.tech/mcp`). ## Custom MCP servers For full flexibility, you can connect **custom MCP servers** as chat connectors to bring internal or third-party systems into Lovable. This is perfect for private APIs, internal CRMs, or custom data sources. Explore [remote MCP servers](https://mcpservers.org/remote-mcp-servers), a curated list of high-quality remote MCP servers compatible with Lovable. ### How to connect a custom MCP server To connect a custom or internal MCP server: 1. Open **Connectors**, scroll to the bottom of the **All** view, and select the **Custom** card labeled **MCP** ("Connect your own MCP"). 2. **Server name**: Enter a clear name for your server (for example, *Internal CRM* or *Analytics API*). 3. **Server URL**: Enter the address where Lovable can reach your MCP server. 4. **Authentication:** * **OAuth (default):** Lovable uses OAuth by default. After you click **Add & authorize**, you’ll be prompted to authorize. * **Bearer token or API key:** For servers that don't support OAuth, you can authenticate using a bearer token or API key. * **No authentication**: Connect without credentials if the server doesn't require authentication. 5. **Add server**. The custom MCP server now appears in your list of chat connectors and can provide contextual data for builds. ## Practical examples Each connected app instantly becomes available as context for the Lovable Agent. You can interact with connected tools using natural prompts. | **Scenario** | **Example prompt** | **Example outcome** | | :---------------------------------------------------- | :--------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------- | | A **product manager** connects **Linear** or **Jira** | *Generate a prototype based on tickets in the current sprint.* | Lovable reads issue descriptions and acceptance criteria to build aligned, testable UI. | | A **marketer** links **Notion** or **Confluence** | *Turn our Q4 campaign brief into a landing page.* | Lovable uses the document as context to generate an on-brand, editable page. | | A **designer** connects **Miro** | *Prototype the signup flow from our whiteboard.* | Lovable reads flow diagrams to scaffold UI navigation and turns them into an interactive prototype your team can test. | | An **engineer** links **n8n** or **internal MCP** | *Build a workflow UI that lists users and allows deleting them.* | Lovable builds an app that uses live data and workflows. | ## Security and permissions Chat connectors (MCP server connections) are **per-user connections**. You can review or revoke them anytime in **Connectors**. For quick access inside a project, click `+` in the prompt box and go to **Connectors**. Chat connectors, including custom MCP servers, are enabled by default on all plans, including Enterprise. This differs from [app connectors](/integrations/introduction), which start disabled on Enterprise workspaces until an admin enables them. On **Business** and **Enterprise** plans, workspace **admins and owners** can manage which servers are available as chat connectors for all users: * Go to **Settings → Privacy & security** to enable or disable all **MCP server access** for the entire workspace. * Open **Connectors** → **Admin settings** → **Chat connectors** to enable or disable individual MCP servers as chat connectors. Local MCP servers running on your machine through [Lovable Desktop](/integrations/desktop-app) are disabled by default on Enterprise workspaces. Admins can turn on **Local desktop MCP servers** in **Settings → Privacy & security**. # Connect your app to Microsoft 365 Source: https://docs.lovable.dev/integrations/microsoft Connect Microsoft Outlook, Teams, OneDrive, Word, Excel, PowerPoint, and OneNote to your Lovable app. All use the same Microsoft sign-in and Microsoft Graph pattern—one guide for every Microsoft connector. Lovable offers several **Microsoft** app connectors. Each one targets a specific product, but they all work the **same way**: you sign in with **Microsoft** (Entra ID / Microsoft account), Lovable stores tokens securely, and your app calls **[Microsoft Graph](https://learn.microsoft.com/en-us/graph/overview)** through Lovable’s **connector gateway** with automatic token refresh. ## Included Microsoft connectors | Connector in Lovable | What it’s for | | :----------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | | **Microsoft Outlook** | Email: read, send, and manage mail in the signed-in mailbox (within granted permissions). | | **Microsoft Teams** | Teams and channels: messages, team and channel lists, and related conversations APIs. | | **Microsoft OneDrive** | Files: upload, download, and work with files in the user’s OneDrive. | | **Microsoft SharePoint** | Sites, lists, and document libraries: browse sites, read and write list items, and work with files stored in SharePoint via Graph. | | **Microsoft Word** | Documents: read and write Word files via Graph (for example files stored in OneDrive/SharePoint). | | **Microsoft Excel** | Spreadsheets: read and work with Excel workbooks through Graph. | | **Microsoft PowerPoint** | Presentations: read and write PowerPoint files via Graph. | | **Microsoft OneNote** | Notes: notebooks, sections, and pages in OneNote. | Pick the connector that matches what you are building. You can add **more than one** connection if you need different Microsoft accounts or environments. ## How Microsoft connections work * **OAuth 2.0**: You authorize a **Microsoft account** for that product. Permissions depend on the **scopes** requested for that connector (some connectors expose optional **Advanced settings** for scopes—grant only what your app needs). * **Microsoft Graph**: Requests go to `https://graph.microsoft.com/v1.0/` via Lovable’s **connector gateway**. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for secure token handling and **per-project request limits**. * **Same flow everywhere**: Add connection → sign in with Microsoft → approve consent → link the connection to projects. Only the **connector name** and **API surface** change between Outlook, Teams, OneDrive, etc. Microsoft 365 **licensing**, **tenant policies**, and **Graph throttling** are controlled by **Microsoft** and your organization—not Lovable. ## How to connect (any Microsoft product) Workspace **admins** and **owners** can create Microsoft connections. 1. Open **Connectors** → **App connectors**. 2. Choose the **Microsoft** connector you need—for example **Microsoft Outlook** or **Microsoft Teams** (each product has its own tile). 3. Click **Add connection**, enter a **Display name**, and complete **Connect** / **Sign in with Microsoft**. 4. Accept the permissions shown for that product. 5. **Link** the connection to a project, by prompting the Lovable agent in the project to connect. If your organization uses conditional access or admin consent, you may need your IT admin to approve the app for the tenant. For API details for a specific workload, see the [Microsoft Graph REST API reference](https://learn.microsoft.com/en-us/graph/api/overview). ## Managing and removing connections Steps match other app connectors; only the **product** you select in Settings changes. ### Unlink projects from a connection Editors and above can unlink projects without deleting the connection. 1. Open **Connectors** → **App connectors** and select the **same Microsoft connector** you used (for example **Microsoft OneDrive**). 2. Open the connection → **Linked projects** → choose projects → **Unlink projects**. ### Delete a connection Workspace admins and owners can delete a connection. Deleting a connection is permanent. Linked projects lose access until you add a new connection. 1. **Connectors** → **App connectors** → pick the Microsoft product (for example **Microsoft Excel**). 2. Open the connection → review **Linked projects** → **Delete** under delete options → confirm. ## Limitations * Each connection is tied to **one** authorized Microsoft identity (and that identity’s mail, files, teams, etc., per scopes)—not each visitor’s account unless you build a separate auth story. * **Tenant and admin policies** (consent, MFA, blocked apps) can block or limit sign-in; resolve those in Microsoft 365 / Entra ID. * **Gateway limits** apply as in [Gateway-based connectors](/integrations/introduction#gateway-based-connectors). Need each end user to sign in with **their own** Microsoft account and act on their own mail, files, and data? Use the Microsoft **[app user connector](/integrations/app-user-connectors)** instead. # Connect your app to Notion Source: https://docs.lovable.dev/integrations/notion Connect your app to Notion, an all-in-one workspace for docs, wikis, and databases, to read and write pages, query databases, and build apps backed by content your team manages in Notion. [Notion](https://www.notion.so/) is a workspace for docs, wikis, projects, and databases. The Notion app connector lets your Lovable app reach the pages and databases your team has shared with it, so you can build apps that turn Notion content into a customer-facing experience or push structured data back into Notion as your source of truth. This is the **Notion app connector** for apps you build with Lovable. Your generated app reads and writes Notion content at runtime. Want the Lovable Agent to read your Notion docs while building instead? Use the [Notion chat connector (MCP)](/integrations/mcp-servers) — a separate integration with its own setup. With Notion, your app can: * Read pages, blocks, and rich text from your Notion workspace * Query Notion databases with filters, sorts, and pagination * Create new pages and append blocks to existing pages * Update database rows (for example, status, owner, due date) * Drive content-managed sites and dashboards where editors work in Notion Each Notion connection is authorized for a single Notion workspace and only sees the pages and databases that were explicitly shared with the integration during authorization. You can create multiple connections to work across multiple workspaces or to separate environments. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Marketing site backed by Notion | *Use Notion and build a marketing site that pulls landing pages and a blog from a Notion database.* | **Render a marketing site from content managed in Notion.**
The app fetches pages by slug, renders the matching components, and lets editors ship updates without touching code. | | Internal knowledge base or wiki | *Use Notion and build a searchable knowledge base from our company wiki in Notion.* | **Turn a Notion wiki into a fast, searchable site.**
The app reads the page tree, builds navigation, and renders rich text and embedded blocks for each article. | | Customer-facing help center | *Use Notion and build a help center that lists articles by category from a Notion database.* | **Publish help articles from Notion with a clean reading experience.**
The app paginates by category, renders rich text, and surfaces metadata managed entirely in Notion. | | Project tracker dashboard | *Use Notion and build a project tracker that shows tasks from our Notion database, grouped by status, with filters for owner and due date.* | **Bring a Notion database to life as a focused dashboard.**
The app queries the database, groups and filters rows in the UI, and lets the team see progress at a glance. | | Lead capture form into Notion | *Build a lead capture form. When someone submits it, create a new row in our Leads database in Notion.* | **Push form submissions into a Notion database.**
The app validates the input and writes a new page in the target database so sales can work the lead from Notion. | | Editorial content site | *Use Notion and build a blog that lists articles from a Notion database, supports tag filtering, and renders rich text.* | **Build an editorial reading experience driven by Notion pages.**
The app paginates posts, filters by tag, and renders rich text and embedded blocks. | | Status page or changelog | *Use Notion and build a public changelog that pulls release notes from a Notion database.* | **Let the team write release notes in Notion and surface them publicly.**
The app reads new entries, renders them in chronological order, and exposes an RSS-style feed. | ## How Notion connections work Lovable uses one centrally managed Notion app to power all Notion integrations across workspaces. Within your Lovable workspace: * You can create multiple Notion connections. * Each connection is a separate OAuth authorization tied to a single Notion workspace. * Each connection only sees the pages and databases shared with it during authorization — it cannot reach other content in that Notion workspace. * Multiple projects within a single Lovable workspace can use the same connection. This makes it easy to separate environments (for example, development and production) or work with multiple Notion workspaces from the same Lovable workspace. Notion uses Lovable's gateway architecture for secure OAuth handling and automatic token refresh. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. ## How to connect Notion Workspace **admins** and **owners** can connect Notion. ### Prerequisites Before connecting Notion, make sure you have: * A Notion workspace where you can install integrations (or request admin approval) * Permission in Notion to share the pages and databases your app needs * Lovable workspace **admin or owner** role All API requests made through this connector go to your Notion workspace. Notion API usage counts toward your Notion plan limits and is handled directly by Notion, not Lovable. ### Step 1: Decide what to share with the integration Notion only exposes content that has been **explicitly shared with the integration**. Before authorizing, decide which pages and databases your app should be able to read or write. Share a single top-level page (or database) and let your app reach everything beneath it via Notion's normal inheritance, rather than sharing many pages individually. ### Step 2: Connect Notion to Lovable You can create multiple connections to authorize different Notion workspaces or to keep environments separate. Go to **Connectors** → **App connectors** and select **Notion**. Click **Add connection**. * **Display name**: name the connection, for example `Notion Prod`. * **Who can access this connection**: keep access limited to specific people or invite the entire workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. * Click **Connect**. The Notion authorization window opens — make sure your browser doesn't block pop-ups. * Sign in to Notion if needed and select the workspace you want to connect. * On the **Select pages** screen, choose the pages and databases your app should be able to access. You can update this later from inside Notion. * Review the requested permissions and click **Allow access**. You'll be redirected back to Lovable with a confirmation. When connected, your Lovable apps can start reading and writing Notion pages and databases. ## Working with shared pages and databases Notion's permission model is opt-in: an integration can only see what's been explicitly shared with it. * If your app is missing content it should be able to see, share the page or database with the integration in Notion (**Share** → **Connections** → **Add connections**). * Sharing a parent page automatically shares its sub-pages with the integration. * You can revoke access from inside Notion at any time without removing the Lovable connection — the connection stays connected, the integration just sees less content. * Pages your app creates or updates are attributed to the integration in Notion's page history, not to an individual user. When prompting Lovable, be explicit about which database or page the app should use, for example: *"use the Tasks database to populate the dashboard"*. ## Limitations The Notion connector cannot: * Receive incoming Notion webhooks or events (for example, "page updated" notifications) * Reach pages or databases that haven't been shared with the integration * Authenticate per end user — each connection uses a single Notion authorization shared by everyone using the app * Perform Notion workspace administration (member management, permissions, billing) Multiple connectors that share the same Notion login and Notion workspace also share page permissions, and the most recently configured connector overwrites the permissions for all of them. If your app needs realtime reactions to changes in Notion, build a polling pattern (for example, query the database on a schedule) instead of relying on push events. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Perplexity Source: https://docs.lovable.dev/integrations/perplexity Connect your app to Perplexity, an AI-powered search engine, to retrieve real-time information with verifiable citations. [Perplexity](https://www.perplexity.ai/) is an AI search platform that returns concise answers grounded in live web data and backed by sources. It’s designed for apps that need **fresh, trustworthy information**, rather than static or training-only knowledge. With Perplexity, your app can: * Answer questions using up-to-date information from the web * Generate summaries with clear, verifiable citations * Compare companies, products, or markets in real time * Reduce hours of manual research into seconds Perplexity is a good fit when your app depends on **recent, source-backed information** such as news, research, market intelligence, or fact verification. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------------------- | :----------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sales prep assistants** | *Use Perplexity and build a sales prep assistant that gathers company context before each call.* | **Pull company overviews, recent news, leadership changes, and risk signals using live search**.
The app runs Perplexity queries before a meeting and presents a concise, cited briefing for sales reps. | | **Competitor and market research tools** | *Build a competitor research tool using Perplexity.* | **Summarize funding events, product launches, positioning changes, and market activity**.
The app runs multiple Perplexity searches in parallel and aggregates the results into a research dashboard. | | **Regulatory or policy trackers** | *Build an app that tracks regulatory updates using Perplexity.* | **Monitor new rulings, policy changes, or compliance updates based on recent sources**.
The app regularly queries Perplexity and surfaces newly published or updated information with citations. | | **Fact-checking apps (“Is this true?”)** | *Build a fact-checking app using Perplexity search.* | **Verify claims by retrieving supporting and contradicting sources**.
The app accepts a statement as input and returns a synthesized answer with cited references. | | **Research assistants** | *Use Perplexity and build a research assistant that answers open-ended questions.* | **Answer questions like “What happened in this industry this week?” or “Who are the top competitors for X?”**
The app uses Perplexity to generate structured, cited responses. | ## How to connect Perplexity Workspace **admins** and **owners** can connect Perplexity. You can create multiple Perplexity connections using different API keys, which is useful for separating environments (for example, development and production) or managing rate limits. When the connection is created, Perplexity becomes available across all projects in the workspace. ### Prerequisites Before connecting Perplexity, make sure you have: * A Perplexity account with admin permissions for billing and API key management * A Perplexity API key * Lovable workspace owner or admin role You must have an active Perplexity account with API access. All search and answer requests performed through this connector consume your Perplexity API usage, and billing is handled directly by Perplexity, not Lovable. ### Step 1: Create a Perplexity account and API key An API key lets you connect to Perplexity API and use its features. You can create multiple API keys in Perplexity. To create a Perplexity API key: 1. Go to [Perplexity](https://www.perplexity.ai/) and set up your account. 2. Go to **Account (profile icon) → API**. 3. Go to **API group** to set up your organization. Fill out your organization’s name, address, and tax details. 4. Go to **API billing** and click **Add Payment Method** to enter your credit card information. 5. Go to **API key** and click **Create key**. Give your key a descriptive name, for example, `Lovable integration`. 6. Copy the generated API key and store it securely. Your API key functions like a password. Keep it secure and never share it publicly. You’ll need it in the next step. See Perplexity docs for detailed instructions: [API Groups & Billing](https://docs.perplexity.ai/getting-started/api-groups). ### Step 2: Connect Perplexity to Lovable You can create multiple connections using different API keys. To connect Perplexity: 1. Open **Connectors** → **App connectors** and select **Perplexity**. 2. Click **Add connection**. 3. **Display name**: name the connection, for example `Perplexity Prod`. 4. Under **Authentication**, enter your Perplexity API key (`pplx-xxxx…`). 5. Click **Create**. When connected, your Lovable apps can start using Perplexity to retrieve real-time, cited information. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Pipedrive Source: https://docs.lovable.dev/integrations/pipedrive Connect your app to Pipedrive, a sales CRM, to manage deals, contacts, activities, leads, and sales pipeline data from your Lovable app. [Pipedrive](https://www.pipedrive.com/) is a sales CRM for managing deals, contacts, activities, leads, and pipelines. The Pipedrive connector lets your Lovable app read and manage CRM data through the Pipedrive API. It's designed for sales dashboards, customer portals, workflow automation, and internal tools that need access to Pipedrive records. With Pipedrive, your app can: * Create, update, and list deals across sales pipelines * Manage people, organizations, leads, and activities * Read pipeline, stage, field, and user metadata for CRM workflows * Build dashboards and automations around Pipedrive CRM data * Register webhooks when your app needs to react to Pipedrive changes Pipedrive is a good fit when your team manages sales activity in Pipedrive and wants a custom Lovable app for reporting, operations, customer handoffs, or sales workflows. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------- | :----------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sales pipeline dashboard** | *Use Pipedrive and build a dashboard that shows open deals by stage, owner, and expected close date.* | **Track pipeline health from live CRM data.**
The app reads deals, stages, and users from Pipedrive so sales managers can review pipeline movement in one place. | | **Account handoff tracker** | *Use Pipedrive and build a handoff tracker for won deals that shows the customer, deal value, notes, and next activity.* | **Turn closed-won deals into operational handoffs.**
The app pulls deal, person, organization, and activity data so customer-facing teams can pick up the right context. | | **Lead intake queue** | *Use Pipedrive and build a lead intake queue where new leads can be reviewed, assigned, and moved into the right pipeline.* | **Manage lead qualification from a custom interface.**
The app lists leads and related contacts from Pipedrive, then updates records when a lead is ready for follow-up. | | **Activity follow-up assistant** | *Use Pipedrive and build an app that lists overdue sales activities and lets reps mark them complete after follow-up.* | **Keep sales teams focused on overdue work.**
The app reads activities by owner and due date, then updates Pipedrive after reps complete calls, emails, or meetings. | | **Customer lookup portal** | *Use Pipedrive and build an internal portal where support can search people and organizations before responding to customers.* | **Give support teams quick CRM context.**
The app searches Pipedrive contacts and organizations so teams can see account details without switching tools. | | **Deal-change notifications** | *Use Pipedrive and build a notification workflow that alerts the team when a high-value deal changes stage.* | **React to important CRM changes.**
The app uses Pipedrive webhooks or polling to detect deal updates and notify the right team members. | ## How to connect Pipedrive Workspace **admins** and **owners** can connect Pipedrive. You can create multiple Pipedrive connections using different API tokens, which is useful for separating environments (for example, development and production), connecting different Pipedrive accounts, or managing access for different teams. When the connection is created, Pipedrive becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Pipedrive, make sure you have: * A Pipedrive account * Access to your Pipedrive API token * Lovable workspace owner or admin role All API requests made through this connector count toward your Pipedrive plan limits. Billing and quota are handled directly by Pipedrive, not Lovable. ### Step 1: Get a Pipedrive API token A Pipedrive API token lets your Lovable app authenticate with the Pipedrive API as the Pipedrive user who owns the token. To find your Pipedrive API token: Sign in to [Pipedrive](https://app.pipedrive.com/) with the account you want your Lovable app to use. Open your profile menu and go to **Personal preferences**. Select the **API** tab. If you do not see an API tab, check that your Pipedrive plan and role allow API access. Copy your API token and store it securely. Your API token functions like a password. Keep it secure and never share it publicly. You need it in the next step. See Pipedrive documentation for more: [How to find the API token](https://pipedrive.readme.io/docs/how-to-find-the-api-token). ### Step 2: Connect Pipedrive to Lovable You can create multiple connections using different API tokens. Go to **Connectors → App connectors** and select **Pipedrive**. Click **Add connection**. * **Display name**: name the connection, for example `Pipedrive Prod`. * **API token**: paste your Pipedrive API token. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to Pipedrive (based on configured connection-level access). Your Lovable apps can then read and manage Pipedrive CRM data. ## Working with Pipedrive data and webhooks The connector uses Pipedrive's API token authentication. Each connection represents one Pipedrive user, and API calls use that user's Pipedrive permissions. If your app needs to react to CRM changes, ask Lovable to set up Pipedrive webhooks for the events you care about, such as deal creation, deal stage changes, or lead updates. Pipedrive sends webhook events to a public endpoint in your app. For critical workflows, combine webhooks with periodic API checks because webhook deliveries are not guaranteed by Pipedrive. When prompting Lovable, be specific about the records and operations your app needs. For example, mention whether the app should work with deals, leads, people, organizations, activities, pipelines, or stages. ## Limitations The Pipedrive connector cannot: * Create a Pipedrive account for you * Manage Pipedrive billing, plans, roles, or API access settings * Support per-end-user Pipedrive login. Each connection represents a single Pipedrive user account shared across projects linked to it. * Rotate API tokens automatically. To rotate a token, generate or copy the new token in Pipedrive and update the Lovable connection. * Create a webhook receiver automatically without app code. Ask Lovable to build the public endpoint and register the webhook for the events your app needs. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to PrestaShop Source: https://docs.lovable.dev/integrations/prestashop Connect your app to PrestaShop, an open-source ecommerce platform, to read and manage store catalog, order, customer, and inventory data. [PrestaShop](https://www.prestashop.com/) is an open-source ecommerce platform for managing online stores, products, orders, customers, stock, and pricing. The PrestaShop connector lets your Lovable app call PrestaShop Webservice through a workspace-level connection. It's designed for store operations tools, ecommerce dashboards, custom storefronts, and workflows that need access to PrestaShop store data. With PrestaShop, your app can: * Read products, categories, stock levels, and pricing from your store * Build dashboards for orders, customers, and catalog operations * Manage PrestaShop Webservice resources your API key can access * Keep custom storefronts and internal tools connected to ecommerce data * Use PrestaShop filters, sorting, and field selection for store views The PrestaShop connector is a good fit when your team runs a PrestaShop store and wants a custom Lovable app for catalog management, reporting, inventory checks, customer support, or store operations. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Store operations dashboard | *Use PrestaShop and build a dashboard that shows recent orders, revenue, top products, and fulfillment status.* | **Give operators one place to monitor store activity.**
The app reads orders, products, and customer data from PrestaShop so teams can review store performance without switching tools. | | Product catalog manager | *Use PrestaShop and build an internal catalog manager for searching products, editing prices, and reviewing categories.* | **Manage catalog details from a custom interface.**
The app lists products and categories from PrestaShop and updates records when the connected Webservice key has write permissions. | | Inventory monitor | *Use PrestaShop and build an inventory monitor that highlights low-stock products and recently changed stock levels.* | **Track stock issues before they affect orders.**
The app reads stock availability and product data from PrestaShop and surfaces items that need attention. | | Customer service portal | *Use PrestaShop and build a support portal where agents can search customers, view recent orders, and check order details.* | **Give support teams store context while helping customers.**
The app searches customers and orders from PrestaShop so agents can answer questions faster. | | Custom storefront | *Use PrestaShop and build a storefront that displays products, categories, prices, and stock from my existing store.* | **Render a storefront from live PrestaShop catalog data.**
The app fetches product and category records from PrestaShop and presents them in a customer-facing shopping experience. | | Fulfillment workflow tracker | *Use PrestaShop and build a fulfillment tracker that groups new orders by status and shows products that need packing.* | **Turn order data into an operational workflow.**
The app reads PrestaShop orders and line items so fulfillment teams can prioritize what to process next. | ## How to connect PrestaShop Workspace **admins** and **owners** can connect PrestaShop. You can create multiple PrestaShop connections using different store URLs and Webservice API keys, which is useful for separating environments (for example, staging and production) or connecting multiple stores. When the connection is created, PrestaShop becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting PrestaShop, make sure you have: * A PrestaShop store with Webservice enabled * Your store's public HTTPS URL, including any subdirectory if the store is not hosted at the domain root * A PrestaShop Webservice API key with permissions for the resources your app needs * Lovable workspace owner or admin role All API requests made through this connector use your PrestaShop store and Webservice API key. Store hosting, API access, quotas, and billing are handled by your PrestaShop setup, not Lovable. ### Step 1: Get a PrestaShop Webservice API key A PrestaShop Webservice API key lets your Lovable app authenticate with PrestaShop Webservice. API calls use the permissions assigned to that key. To create a PrestaShop Webservice API key: Sign in to the PrestaShop back office for the store you want to connect. Open the Webservice settings and enable PrestaShop Webservice if it is not already enabled. Note your public store URL. For example, use `https://shop.example.com` for a store at the domain root or `https://shop.example.com/prestashop` for a store hosted in a subdirectory. Add a new Webservice key for Lovable. Use a descriptive name or description, for example `Lovable integration`. Grant the resources and methods your app needs. Common resources include products, categories, orders, customers, and stock availability. For write workflows, include the matching create or update permissions in PrestaShop. Copy the Webservice API key and store it securely. Your Webservice API key functions like a password. Keep it secure and never share it publicly. You need it in the next step. See PrestaShop documentation for more: [PrestaShop Webservice getting started](https://devdocs.prestashop-project.org/9/webservice/getting-started/). ### Step 2: Connect PrestaShop to Lovable You can create multiple connections using different store URLs and Webservice API keys. Go to **Connectors → App connectors** and select **PrestaShop**. Click **Add connection**. * **Display name**: name the connection, for example `PrestaShop Prod`. * **Store URL**: enter your PrestaShop store URL. Include any subdirectory before `/api` if your store is not hosted at the domain root. Do not include query parameters. * **Webservice API key**: paste your PrestaShop Webservice API key. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to PrestaShop (based on configured connection-level access). Your Lovable apps can then read and manage catalog, order, customer, and inventory data through PrestaShop. ## Working with PrestaShop Webservice data The connector sends API calls through Lovable's connector gateway. Do not put your Webservice API key in frontend code, URLs, or custom headers. Common PrestaShop Webservice paths include `/products`, `/categories`, `/orders`, `/customers`, and `/stock_availables`. For read-heavy pages, ask Lovable to use PrestaShop Webservice query parameters such as `display`, `filter[...]`, `sort`, and `limit` to request only the data your app needs. For creates and updates, PrestaShop Webservice often expects XML payloads. Ask Lovable to keep these requests server-side and match the payload format required by the specific PrestaShop endpoint. ## Limitations The PrestaShop connector cannot: * Create, host, or configure your PrestaShop store * Enable Webservice access or assign Webservice permissions in PrestaShop for you * Bypass the permissions assigned to the connected Webservice API key * Bypass limits, modules, or hosting constraints in your PrestaShop setup * Rotate Webservice API keys automatically. To rotate a key, create or update the key in PrestaShop and update the Lovable connection * Support per-end-user PrestaShop login. Each connection represents a single PrestaShop Webservice API key shared across all projects linked to it. * Guarantee that every create or update endpoint accepts JSON. Some PrestaShop Webservice writes require XML payloads. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to QuickBooks Source: https://docs.lovable.dev/integrations/quickbooks Connect your app to QuickBooks, an accounting platform, to build apps that work with customers, invoices, bills, payments, accounts, and company data. [QuickBooks](https://quickbooks.intuit.com/) is an accounting platform for managing company finances, customers, invoices, bills, payments, and bookkeeping workflows. The QuickBooks connector lets your Lovable app work with QuickBooks Online accounting data through a connected Intuit account. With QuickBooks, your app can: * Query customers, vendors, items, accounts, and company information * Read invoices, bills, payments, purchases, and sales receipts * Create accounting dashboards and operational finance reports * Build workflows that create or update QuickBooks records The QuickBooks connector connects to a single QuickBooks Online company through OAuth. It is a good fit for finance dashboards, invoice workflows, customer account tools, payment tracking, and internal operations apps that need accounting data from QuickBooks Online. ## Common use cases and example apps | Example app | Example prompt | Description | | :----------------------- | :-------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Finance dashboard | *Use QuickBooks and build a dashboard that shows revenue, open invoices, overdue balances, and recent payments.* | **Track key accounting metrics from QuickBooks in one place.**
The app reads invoices, payments, customers, and account data, then displays finance trends for internal teams. | | Invoice tracker | *Use QuickBooks and build an invoice tracker that lists sent, paid, and overdue invoices by customer.* | **Give teams a focused view of invoice status.**
The app queries QuickBooks invoices, groups them by status, and highlights accounts that need follow-up. | | Customer billing portal | *Use QuickBooks and build a customer billing portal where staff can search customers and view their invoice history.* | **Make QuickBooks customer and invoice data easier to access.**
The app lets authorized team members search customer records, review balances, and inspect invoice details. | | Expense review app | *Use QuickBooks and build an app that shows recent bills and purchases, grouped by vendor and account category.* | **Organize expenses from QuickBooks for review.**
The app reads bills, purchases, vendors, and accounts, then helps finance teams spot unusual spending. | | Cash flow report | *Use QuickBooks and build a cash flow report that compares paid invoices, open invoices, and upcoming bills.* | **Summarize cash flow signals from QuickBooks.**
The app combines receivables and payables data to show what has been collected and what is due. | | Record creation workflow | *Use QuickBooks and build a form that creates a new customer and draft invoice from an approved request.* | **Turn internal approvals into QuickBooks records.**
The app collects request details, validates required fields, and creates or updates QuickBooks records through the connected company. | ## How to connect QuickBooks Workspace **admins** and **owners** can connect QuickBooks. You can create multiple QuickBooks connections using different Intuit accounts or companies, which is useful for separating sandbox and production environments or managing multiple businesses. When the connection is created, QuickBooks becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting QuickBooks, make sure you have: * A QuickBooks Online company you want to connect * Access to the Intuit account that can authorize API access for that company * Lovable workspace **owner** or **admin** role All API requests made through this connector use your connected QuickBooks Online company and Intuit API access. Billing, quota, and API limits are handled by Intuit, not Lovable. ### Set up your QuickBooks connection Go to **Connectors → App connectors** and select **QuickBooks**. Click **Add connection**. In **Display name**, name the connection (for example, `QuickBooks Prod`). This name is only used inside Lovable to identify the connection. In **Environment**, select **Production** for a live QuickBooks Online company or **Sandbox** for an Intuit developer sandbox company. Leave **Company ID** blank unless you already know the QuickBooks company ID. Intuit usually returns the company ID during authorization. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. The QuickBooks authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to Intuit if prompted, choose the QuickBooks company to connect, review the requested permissions, and approve access. You'll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to QuickBooks (based on configured connection-level access). Your Lovable apps can then query and manage QuickBooks Online accounting data through the connected company. ## Limitations The QuickBooks connector cannot: * Connect to QuickBooks Desktop. It supports QuickBooks Online through Intuit's Accounting API. * Access a QuickBooks company that the connected Intuit account cannot authorize. * Receive QuickBooks webhooks or real-time event notifications. * Bypass Intuit API quotas, rate limits, or account restrictions. * Support per-end-user QuickBooks login. Each connection represents a single QuickBooks company shared across all projects linked to it. If QuickBooks authorization is revoked from the Intuit side, you'll need to reconnect the integration in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Replicate Source: https://docs.lovable.dev/integrations/replicate Connect your app to Replicate to run thousands of open-source AI models for image, video, audio, and text generation from your Lovable app. [Replicate](https://replicate.com/) is a platform for running open-source AI models through a single API. The Replicate connector lets your Lovable app run thousands of models for image, video, audio, and text generation. It's designed for apps that need a specific or open-source model beyond Lovable's built-in AI, such as a particular FLUX fine-tune, a community video model, or a specific Whisper variant. With Replicate, your app can: * Generate images, video, and audio with thousands of open-source models * Run popular models like FLUX, Stable Diffusion, and Whisper * Stream long-running predictions or wait synchronously for fast models * Train and fine-tune custom models on your own data Replicate is a good fit when your app needs a specific model that isn't available through Lovable's built-in AI. ## Common use cases and example apps | Example app | Example prompt | Description | | :-------------------------------- | :-------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- | | **Text-to-image generators** | *Use Replicate and build an app that turns text prompts into images with FLUX.* | **Generate images from text prompts on demand.**
The app sends prompts to a Replicate image model and shows the results to the user. | | **Image-to-video tools** | *Use Replicate and build a tool that animates a product photo into a short video clip.* | **Turn still images into short video clips.**
The app uploads a source image, runs an image-to-video model, and plays back the generated clip. | | **Audio transcription apps** | *Use Replicate and build an app that transcribes uploaded audio with Whisper.* | **Transcribe spoken audio into text.**
The app sends recordings to a transcription model and returns the transcript in-app. | | **Image editing tools** | *Use Replicate and build a tool that removes backgrounds from uploaded product photos.* | **Edit and enhance images automatically.**
The app runs an image-processing model and returns the edited file to the user. | | **Avatar and sticker generators** | *Use Replicate and build an app that creates custom avatar stickers from a selfie.* | **Create personalized image content from user uploads.**
The app feeds a user photo to a generation model and produces styled results. | | **Custom model apps** | *Use Replicate and build an app that runs our fine-tuned model on customer inputs.* | **Serve your own fine-tuned models inside your app.**
The app calls a model you've trained on Replicate and shows the output to users. | ## How to connect Replicate Workspace **admins** and **owners** can connect Replicate. You can create multiple Replicate connections using different API tokens, which is useful for separating environments (for example, development and production) or managing rate limits. When the connection is created, Replicate becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Replicate, make sure you have: * A Replicate account * A Replicate API token * Lovable workspace owner or admin role All predictions run through this connector are billed by Replicate based on the model and how long each run takes. Billing and quota are handled directly by Replicate, not Lovable. ### Step 1: Get a Replicate API token A Replicate API token lets your Lovable app authenticate with the Replicate API. To create a Replicate API token: Sign in to [Replicate](https://replicate.com/). Go to **Account settings → [API tokens](https://replicate.com/account/api-tokens)**. Click **Create token** and give it a descriptive name, for example `Lovable integration`. Copy the token (it starts with `r8_`) and store it securely. Your API token functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See Replicate documentation for more: [API tokens and security](https://replicate.com/docs/topics/security/api-tokens). ### Step 2: Connect Replicate to Lovable You can create multiple connections using different API tokens. Go to **Connectors → App connectors** and select **Replicate**. Click **Add connection**. 1. **Display name**: name the connection, for example `Replicate Prod`. This name is only used inside Lovable to identify the connection. 2. **API token**: paste your Replicate API token (it starts with `r8_`). Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to Replicate (based on configured connection-level access). Your Lovable apps can then generate images, video, audio, and text using Replicate models. ## Limitations The Replicate connector cannot: * Run predictions from client-side code. Calls go through Lovable from a server-side endpoint. * Refresh or rotate API tokens automatically. To rotate, create a new token in Replicate and update the Lovable connection. * Support per-end-user Replicate login. Each connection represents a single Replicate account shared across all projects linked to it. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Resend Source: https://docs.lovable.dev/integrations/resend Connect your app to Resend to send transactional and marketing emails from Lovable apps using your own Resend account. [Resend](https://resend.com/) is an email API platform for sending and managing email delivery. The Resend app connector lets your Lovable apps call Resend from your workspace using a managed workspace-level connection. Each Resend connection uses your own Resend API credentials. After it is connected, projects in your workspace can use the connection to send emails through your Resend account. Use the Resend connector when your app needs to send email as part of product workflows, such as confirmations, notifications, or campaign-related messages. Use another path when: * You only need Lovable Cloud authentication emails from your custom domain. In that case, see [Custom emails](/features/custom-emails). * You need each end user to connect their own email provider account separately. App connectors are workspace-level, not per-end-user connections. ## Common use cases and example apps | Example app | Example prompt | Description | | :---------------- | :----------------------------------------------------------------------------------------- | :-------------------------------------------------------------- | | Order updates app | *Send an order confirmation email through Resend after checkout.* | Send transactional confirmations when users complete an action. | | Booking platform | *When a booking is created, email the customer and the internal team through Resend.* | Trigger multi-recipient operational emails from one workflow. | | User onboarding | *Send a welcome email series through Resend when a new account is created.* | Automate onboarding touchpoints tied to app events. | | Newsletter | *Create a newsletter signup flow that stores subscribers and sends campaigns with Resend.* | Build list and campaign flows using your Resend setup. | ## How Resend connections work Each Resend connection uses one Resend API key. Within your Lovable workspace: * You can create multiple Resend connections. * Each connection is a separate credential setup. * Multiple projects can use the same connection. This helps you separate environments, such as staging and production. ## How to connect Resend Workspace **admins** and **owners** can connect Resend. When a connection is created, Resend becomes available across all projects in the workspace. ### Requirements and billing * **Available on:** all plans * **Connector roles:** workspace admins and owners can create and manage Resend connections * **Additional admin controls:** on Business and Enterprise plans, workspace admins and owners can enable or disable app connector availability at the workspace level * **Prerequisites:** a Resend account and a Resend API key * **Recommended for production:** verify your sending domain in Resend before high-volume sending Resend usage and pricing are owned by your Resend account. Charges for email sending are billed by Resend, not by Lovable. App connector connections are workspace-level. Anyone in the workspace who can use connected projects can use the Resend connection in those projects. ### Set up your Resend connection Open **Connectors** → **App connectors** and select **Resend**. Click **Add connection**. In **Display name**, enter a clear name, for example `Resend Prod` or `Resend Staging`. Paste your Resend API key in the authentication field. Click **Create**. Prompt Lovable to add or update email flows that use Resend, then test with real recipient addresses you control. ## FAQ Yes. You need your own Resend account and API key to create a Resend connection in Lovable. Email sending through this connector is billed by Resend, based on your Resend plan and usage. Yes. You can create multiple connections, for example to separate staging and production environments. Not through this app connector flow. App connectors are configured at workspace level. Verify your API key, confirm sender/domain setup in Resend, and check Resend activity/logs for rejected or failed sends. ## Limitations * A Resend app connector is a workspace-level credential, not a per-user email login flow. * For production reliability, verify your sending domain in Resend and monitor delivery/rejection activity in Resend logs. * If a connected project stops sending after connector changes, open the connection and confirm it is still linked to the project. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Salesforce Source: https://docs.lovable.dev/integrations/salesforce Connect your app to Salesforce, a CRM platform, to read and manage Accounts, Contacts, Cases, and other records. [Salesforce](https://www.salesforce.com/) is a CRM platform for managing customer relationships, sales pipelines, and support cases. The Salesforce connector lets your Lovable app query and update CRM records through your own Salesforce org. It's designed for internal tools, customer portals, and support dashboards that need live access to Salesforce data. With Salesforce, your app can: * Query Accounts, Contacts, Leads, Cases, and other standard objects using SOQL. * Display and filter CRM records in dashboards and internal tools. * Create and update records via the Salesforce REST API. * Run custom SOQL queries for reporting and data exports. It's a good fit for sales ops tools, support portals, and any app that surfaces Salesforce data to your team. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------- | :--------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Support case dashboard | *Use Salesforce and build a dashboard showing open Cases by priority and status.* | **A live view of your support queue, organized by priority.**
The app pulls Cases from Salesforce and groups them so agents can see what needs attention first. | | Account health tracker | *Use Salesforce and build an internal tool showing Account health scores and recent activity.* | **A per-account summary with activity history and key fields.**
The app runs SOQL queries to surface contact counts, open opportunities, and recent case history for each account. | | Lead pipeline viewer | *Use Salesforce and build a pipeline board showing Leads by stage and owner.* | **A Kanban-style board of your Leads, organized by sales stage.**
The app queries Salesforce Leads and renders them by status so reps can track progress across their pipeline. | | Contact directory | *Use Salesforce and build a searchable directory of Contacts with their account and role.* | **A filterable contact list tied to your Salesforce org.**
The app fetches Contact records and lets users search by name, account, or role without leaving the tool. | | Case detail view | *Use Salesforce and build a support portal where users can look up their Cases by email.* | **A self-service portal for customers to check their open Cases.**
The app queries Cases by supplied email and displays status, subject, and latest update for each one. | | Sales activity report | *Use Salesforce and build a weekly report of closed opportunities by rep.* | **An automated report of won opportunities, grouped by owner.**
The app runs a SOQL query against Opportunities and renders a summary table for your weekly sales review. | ## How to connect Salesforce Workspace **admins** and **owners** can connect Salesforce. You can create multiple Salesforce connections using different orgs or External Client Apps, which is useful for separating production and sandbox environments. When the connection is created, Salesforce becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Salesforce, make sure you have: * A Salesforce org (Developer Edition, production, or sandbox) * A Salesforce External Client App with OAuth enabled (see Step 1 below) * Lovable workspace **owner** or **admin** role All API requests made through this connector count against your Salesforce org's API limits. Billing and quota are handled directly by Salesforce, not Lovable. ### Step 1: Create a Salesforce External Client App Salesforce uses External Client Apps to authorize third-party access via OAuth. You need to create one to get a Client ID and Client Secret for Lovable. Salesforce no longer allows creating new Connected Apps. External Client Apps are their replacement, and the Lovable connector works identically with both. If you already have a connection set up with a Connected App, it keeps working and needs no migration. Sign in to your Salesforce org. Click the gear icon in the top-right corner and select **Setup**. In the left sidebar, search for **App Manager** and select it under **Apps**. Click **New External Client App** in the top-right corner. Fill in the required fields: * **Name**: for example, `Lovable Integration` * **API Name**: auto-populated from the name * **Contact Email**: your email address * **Distribution State**: leave set to **Local** Expand the **Enable OAuth** section and check **Enable OAuth**. Set the **Callback URL** to: ```text theme={null} https://api.lovable.dev/workspaces/connectors/standard/oauth/callback ``` Under **Selected OAuth Scopes**, add: * **Manage user data via APIs (api)** * **Perform requests at any time (refresh\_token, offline\_access)** Leave all other settings at their defaults, then click **Create**. Open your new app in **Setup → External Client App Manager**, select the **Settings** tab, and expand **OAuth Settings**. Click **Consumer Key and Secret** to view your credentials: * **Consumer Key**: this is your **Client ID** * **Consumer Secret**: this is your **Client Secret** Copy both values and store them securely. Your Client Secret functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See [Salesforce External Client Apps documentation](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm) for more detail. ### Step 2: Connect Salesforce to Lovable Go to **Connectors → App connectors** and select **Salesforce**. Click **Add connection**. Fill in the connection fields: * **Display name**: name the connection, for example `Salesforce Prod`. This name is only used inside Lovable to identify the connection. * **Environment**: select **Production** for production orgs and Developer Edition. Select **Sandbox** only if your org is a `test.salesforce.com` sandbox. * **Account URL**: your org's My Domain URL, for example `https://acme.my.salesforce.com`. Find this in **Setup → My Domain**. * **Client ID**: the Consumer Key from your External Client App. * **Client Secret**: the Consumer Secret from your External Client App. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. The Salesforce authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to Salesforce if prompted, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to Salesforce (based on configured connection-level access). Your Lovable apps can then query and update CRM records through your Salesforce org. ## Limitations The Salesforce connector cannot: * Access orgs outside the `*.salesforce.com` domain. * Use Salesforce Bulk API or Streaming API endpoints. Each connection represents a single Salesforce org shared across all projects linked to it. Need each end user to sign in with **their own** Salesforce account and act on their own data? Use the Salesforce **[app user connector](/integrations/app-user-connectors)** instead. If Salesforce authorization is revoked from the Salesforce side (for example, if the External Client App is deleted or the authorized user's permissions change), you'll need to reconnect the integration in Lovable before API calls can succeed again. ## Troubleshooting Your Salesforce External Client App has the wrong callback URL. In your Salesforce app settings, set the callback URL to exactly: ```text theme={null} https://api.lovable.dev/workspaces/connectors/standard/oauth/callback ``` Save the change in Salesforce, wait a few minutes for it to take effect, and connect again. Setups created before July 8, 2026 may have copied an incorrect URL from an earlier version of this page. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Integration security Source: https://docs.lovable.dev/integrations/security How Lovable stores and protects integration credentials, plus the gateway, IP allowlisting, and domain restrictions that secure connector traffic. This page covers how data flows through Lovable connectors, how Lovable stores and protects integration credentials, and the security controls that apply to connector traffic: the connector gateway, outbound IP allowlisting, and domain restrictions. ## Connector data flow When your app uses an app connector, Lovable acts as a secure intermediary between your app and the third-party service. For example, when your app displays a SharePoint document, the document is fetched live from Microsoft and handed straight to your app. A connector request follows these steps: 1. Your app requests an item, such as a document, record, or message. 2. The request goes to Lovable's connector gateway. 3. The gateway authenticates with the third-party service using the connection's stored credentials and fetches the item live. 4. The gateway returns the response directly to your app. This design has two practical consequences: * **Access mirrors the connected account.** A connector can only see what the account used to create the connection is permitted to see at the third-party service. If that account has read-only access, your app has read-only access. * **Disconnecting cuts access immediately.** When you delete a connection, its secrets are removed and apps using it stop working. See [Data retention and deletion policy](#data-retention-and-deletion-policy). This flow applies to gateway-based connectors, which covers most app connectors. See [Gateway connectors](#gateway-connectors) for details on the exceptions. ## Credentials ### Access and permissions All connection tokens are stored encrypted. Once a credential is saved, no one can read it back directly: not workspace members, not workspace admins, and not the Lovable AI agent. Each project receives 2 abstract keys: `LOVABLE_API_KEY` that uniquely identifies a project and one key per connection. This connection key is an opaque key that encapsulates all secrets and allows one project to reach the connector gateway. Your app and the agent use this key to call the connector, while the underlying tokens stay in Lovable's secret store. Some secrets can be visible inside a project and to the agent. This applies when a secret is marked public (for example, a publishable key meant for the browser) or when the connector does not route through the gateway. Gateway connectors keep all credentials lovable-side and never expose them in the project. ### Data retention and deletion policy Secrets are deleted from the workspace as soon as the connection is deleted. If an entire workspace is deleted, its secrets are removed after the grace period. Expired or unused connections are never deleted automatically. Remove a connection yourself when you no longer need it. ### Rotation If a credential is leaked, you can rotate the `LOVABLE_API_KEY` for each project. After rotation, the previous key may still be valid for up to an hour depending on caching. ## Gateway connectors Most app connectors route through a **secure gateway** between your Lovable app and the third-party service. If you need to confirm whether a specific connector routes through the gateway, contact Lovable support. The gateway provides the following capabilities: * **Authentication is handled automatically.** The gateway manages OAuth and refreshes expiring tokens in the background, so once connected, your integration keeps working without manual re-authentication. * **Credentials are never exposed in your project.** Tokens are stored securely in the gateway and are not visible in project settings or accessible to workspace admins. Your app calls the connector, and authentication is handled behind the scenes. * **There is a per-project usage limit.** Gateway connectors allow up to **1,000 requests per minute per connector per project**. Each project has its own independent limit, so usage in one project does not affect others. Most apps will not approach this threshold, but if you are building high-volume automations or frequent background operations, you should design with this limit in mind. * **Outbound traffic uses a stable IP range.** Requests from gateway-based connectors leave Lovable from a fixed set of IP ranges that you can allowlist. See [IP allowlisting](#ip-allowlisting) for the ranges. App connectors that do not use the gateway may authenticate differently, such as through a direct API key or credentials managed by Lovable. The capabilities listed above apply only to gateway-based connectors. ## IP allowlisting Requests from gateway-based connectors to third-party services leave Lovable from a fixed set of IP ranges. Partners and enterprise customers can allowlist these ranges to permit Lovable connector traffic through firewalls or IP-restricted APIs. * IPv4: `185.41.150.0/25` * IPv6: `2a07:8241:fca::/48` ## Domain restrictions Some connectors and third-party services let you restrict a key to a set of domains (sometimes called referrer, origin, or HTTP referrer restrictions). When a key is used in your app's frontend code, such as the Logo.dev or Google Maps Platform browser key, domain restrictions limit where the key works so it can't be reused elsewhere. For keys or systems that support domain restrictions, add the domains where Lovable serves your app: * `*.lovable.app/*` * `*.lovable.dev/*` * `*.lovableproject.com/*` * `your production domain` These cover all Lovable's environments. If your app is served from a [custom domain](/features/custom-domain), add that domain to the list as well. ## Share how gateway connectors work Need to explain how Lovable accesses your external data to colleagues, IT, or a security reviewer? Share the one-pager below. It walks through the gateway connector data flow in plain language, without requiring a docs deep dive. A shareable one-pager explaining how Lovable's gateway connectors fetch your data live, what they can access, and how to disconnect. # Connect your app to Semrush Source: https://docs.lovable.dev/integrations/semrush Connect your app to Semrush, an SEO and competitive analysis platform, to power apps with keyword research, domain analytics, backlink data, and project management. The Semrush connector is for embedding Semrush data **inside your deployed Lovable app**. If you just want [Semrush-powered SEO research](/features/seo-aeo#research-seo-with-lovable) while building (keyword ideas, domain analysis, competitive insights for the agent to reason over), you don't need this connector. See [Optimize your app for SEO and AI search](/features/seo-aeo). [Semrush](https://www.semrush.com/) is an SEO, keyword research, and competitive analysis platform that lets your Lovable app work with search data, domain analytics, and marketing insights managed in your Semrush account. It's designed for apps that surface SEO data, track keyword positions, or build dashboards on top of Semrush projects. With Semrush, your app can: * Access SEO data including keywords, backlinks, and domain analytics * Manage Semrush projects and position tracking campaigns * Retrieve organic and paid search insights The Semrush connector targets Semrush's OAuth-protected APIs, including the Projects API, URL, domain, backlinks, and subfolder reports, and position tracking. It's a good fit when your app needs to read SEO data from your Semrush account or extend Semrush workflows with custom interfaces. See Semrush's developer documentation for API availability and limits: [Semrush API docs](https://developer.semrush.com/api/). ## Common use cases and example apps | Example app | Example prompt | Description | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SEO performance dashboard | *Use Semrush and build a dashboard that shows my domain's organic traffic, keyword rankings, and backlink growth over time.* | **Surface Semrush SEO metrics in a focused internal view.**
The app pulls domain analytics and keyword data from Semrush projects and renders charts so marketing teams can monitor performance without opening Semrush. | | Keyword research workspace | *Use Semrush and build a keyword research tool where I can search keywords, see volume and difficulty, and save lists.* | **Create a structured workflow on top of Semrush keyword data.**
The app queries Semrush for keyword metrics, lets users organize results into lists, and saves selections for later review. | | Competitor tracking app | *Use Semrush and build an app that tracks competitor domains and shows their top keywords, traffic estimates, and backlinks.* | **Turn Semrush competitive data into a monitoring tool.**
The app fetches data for a configured set of competitor domains and highlights changes in rankings, traffic, and backlink profiles over time. | | Position tracking reports | *Use Semrush and build a weekly report that summarizes keyword position changes across my Semrush projects.* | **Deliver recurring SEO updates from Semrush project data.**
The app reads position tracking campaigns, compares week-over-week movement, and produces a digest stakeholders can review at a glance. | | Backlink monitoring | *Use Semrush and build an app that lists new and lost backlinks for my domain and flags high-authority links.* | **Monitor link profile changes from Semrush.**
The app fetches backlink data, surfaces gains and losses, and highlights links worth investigating based on domain authority. | | Client-facing SEO reports | *Use Semrush and build a client portal that shows each client their keyword rankings, traffic trends, and project status.* | **Share Semrush insights with clients in a branded interface.**
The app maps Semrush projects to clients, renders the relevant metrics, and gives clients a read-only view of their SEO performance. | | Content opportunity finder | *Use Semrush and build a tool that surfaces keyword opportunities based on search volume, difficulty, and current rankings.* | **Help content teams prioritize what to write next.**
The app combines Semrush keyword and ranking data to identify gaps and recommend topics with the best potential return. | ## How to connect Semrush Workspace **admins** and **owners** can set up Semrush conenctions. You can create multiple Semrush connections by authorizing different Semrush accounts. When the connection is created, Semrush becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Semrush, make sure you have: * A Semrush account * Lovable workspace owner or admin role When you connect Semrush through Lovable, you can either use an existing Semrush account or create a new one during the connection flow. * If you create a **new Semrush account through Lovable**, you'll get **free Semrush credits** on Semrush's free plan, subject to free plan limits and daily usage caps. * If you connect an **existing Semrush account** instead, your **current Semrush subscription limits** apply. Learn more at [semrush.com](https://www.semrush.com/). All API requests made through this connector consume Semrush API units according to your Semrush plan. Billing and quota are handled directly by Semrush, not Lovable. ### Set up your Semrush connection Go to **Connectors → App connectors** and select **Semrush**. Click **Add connection**. In **Display name**, name the connection (for example, `Semrush Prod`). This name is only used inside Lovable to identify the connection. Expand **Advanced settings** to view the Semrush API scopes Lovable will request. All scopes are required for the gateway to reach every supported endpoint and cannot be deselected: | Scope | Semrush permission | What Lovable reads | | ----------------- | ----------------------- | ---------------------------------------------------- | | User identity | `user.id` | The connected Semrush user's identity | | User limits | `user.limits` | The connected user's Semrush API quota | | URL reports | `url.info` | URL-level organic and paid search data | | Domain reports | `domains.info` | Domain-level rankings, traffic, and competitive data | | Backlinks | `backlinks.info` | Backlink profiles, anchors, and referring domains | | Subfolder reports | `subfolders.info` | Organic data for subfolders of a domain | | Projects | `projects.info` | The connected user's Semrush projects | | Position tracking | `positiontracking.info` | Position tracking campaigns and reports | Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. The Semrush authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to Semrush if prompted, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to Semrush. Your Lovable apps can then start using Semrush to read SEO data, manage projects, and build dashboards on top of your Semrush account. ## Limitations The Semrush connector cannot: * Call legacy Semrush endpoints that require API-key (`?key=…`) query-string authentication * Receive Semrush webhooks or event notifications * Support per-end-user authentication (each connection uses a single shared Semrush authorization) * Bypass Semrush API quotas or rate limits. Usage counts against your Semrush plan. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Sevdesk Source: https://docs.lovable.dev/integrations/sevdesk Connect your app to Sevdesk, an accounting and invoicing platform, to manage contacts, invoices, orders, vouchers, and bookkeeping workflows from your Lovable app. [Sevdesk](https://www.sevdesk.de/) is an accounting and invoicing platform for managing business contacts, invoices, orders, vouchers, payments, and bookkeeping workflows. The Sevdesk connector lets your Lovable app call the Sevdesk API through a connected Sevdesk account. With Sevdesk, your app can: * List and manage customers, suppliers, and contact addresses * Create and retrieve invoices, orders, vouchers, and credit notes * Build bookkeeping workflows around payments and account data * Query accounting resources such as countries, tax rules, and categories Sevdesk is a good fit when your app needs operational accounting data, finance workflows, or back-office tools connected to a Sevdesk account. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------- | :--------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Invoice dashboard** | *Use Sevdesk and build an invoice dashboard that lists open invoices, due dates, customers, and payment status.* | **Track invoice work from one internal view.**
The app fetches invoice and contact data from Sevdesk so finance teams can review outstanding work. | | **Customer accounting portal** | *Use Sevdesk and build a customer portal that shows invoices, orders, and credit notes for each customer.* | **Give customers access to accounting documents.**
The app retrieves the right records from Sevdesk and presents them in a branded portal. | | **Contact management tool** | *Use Sevdesk and build an internal tool for searching customers, suppliers, and contact addresses.* | **Keep accounting contacts accessible.**
The app reads Sevdesk contacts, including person contacts, and gives teams a focused interface for customer and supplier data. | | **Voucher review workflow** | *Use Sevdesk and build a voucher review workflow for incoming expenses and receipts.* | **Move expense review into a guided app.**
The app creates or retrieves voucher records in Sevdesk and helps operators review missing details. | | **Order tracking app** | *Use Sevdesk and build an order tracking app that shows active orders and related customer records.* | **Monitor orders before they become invoices.**
The app retrieves orders and related contacts from Sevdesk for sales and finance follow-up. | | **Bookkeeping resource browser** | *Use Sevdesk and build an admin page that lists tax rules, countries, categories, and check accounts.* | **Surface reference data for finance workflows.**
The app reads Sevdesk accounting resources so operators can use consistent values in internal workflows. | ## How to connect Sevdesk Workspace **admins** and **owners** can connect Sevdesk. You can create multiple Sevdesk connections using different API tokens, which is useful for connecting different Sevdesk accounts or users. When the connection is created, Sevdesk becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Sevdesk, make sure you have: * A Sevdesk account with API access * A Sevdesk API token * Lovable workspace owner or admin role All API requests made through this connector use your Sevdesk API token. API usage, plan limits, and billing are handled directly by Sevdesk, not Lovable. ### Step 1: Get a Sevdesk API token A Sevdesk API token lets your Lovable app authenticate with the Sevdesk API. To find your Sevdesk API token: Sign in to [Sevdesk](https://my.sevdesk.de/) with the account you want to connect. Go to **Settings → Users**, then open the user whose API access you want to use. Find the **API token** field and copy the 32-character token. Your API token functions like a password. Keep it secure and never share it publicly. You need it in the next step. See Sevdesk documentation for more: [Sevdesk API documentation](https://api.sevdesk.de/). ### Step 2: Connect Sevdesk to Lovable You can create multiple connections using different API tokens. Go to **Connectors → App connectors** and select **Sevdesk**. Click **Add connection**. 1. **Display name**: name the connection, for example `Sevdesk Prod`. 2. **API token**: paste your 32-character Sevdesk API token. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to Sevdesk (based on configured connection-level access). Your Lovable apps can then work with Sevdesk accounting, contact, invoice, order, voucher, and payment data. ## Working with contacts Sevdesk's contact API separates organizations from person contacts. When you ask Lovable to list contacts, include person contacts if you want customers, suppliers, and individual contacts to appear. For example, ask Lovable: ```text wrap theme={null} Use Sevdesk and build a contacts page that lists organizations and person contacts. Include person contacts from Sevdesk when fetching /Contact. ``` ## Limitations The Sevdesk connector cannot: * Create a Sevdesk account or API token for you * Automatically rotate API tokens. To rotate a token, update the token in Sevdesk and update the Lovable connection * Support per-end-user Sevdesk authentication. Each connection represents a single Sevdesk account shared across projects linked to it * Bypass Sevdesk API limits, plan limits, or permissions on the connected Sevdesk user ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Build a Shopify store with AI Source: https://docs.lovable.dev/integrations/shopify Learn how to create a new Shopify store or connect an existing one to Lovable, then build and launch your storefront. Lovable integrates directly with Shopify so you can **create a new Shopify store or connect an existing one**, then build, customize, and launch a complete e-commerce storefront using natural language. Shopify handles payments, inventory, and logistics when you go live. ## Use cases With Lovable + Shopify, you can build and launch real online stores for: * **Physical products**: sell clothes, gadgets, accessories, or home goods * **Digital products**: offer e-books, courses, music, or software downloads * **Niche brands**: quickly spin up stores for limited-edition merch, local products, dropshipping or side projects * **Small businesses**: showcase bakeries, coffee shops, or craft businesses and accept orders online * **Testing new product ideas**: add a few products and evaluate performance before full-scale production * **Business expansion**: introduce new collections, seasonal campaigns, or bundles with just a prompt ## Before you begin Before you start building your e-commerce store, here are a few important things to know: * **New or existing Shopify stores**\ Lovable supports both **creating new Shopify stores** and **connecting existing Shopify stores**. * **Sandbox store - no Shopify cost (new stores only)**\ When you create a new Shopify store in Lovable, Lovable automatically creates a **sandbox (development) store** so you can build and experiment safely at no Shopify cost. This environment is perfect for setup and testing, but it **won’t process real payments**. * **Claim within 30 days to keep your new store (new stores only)**\ Shopify removes development stores that stay unclaimed for **30 days** after creation. To keep your store, **claim it within that 30-day window**. If you skip claiming when Lovable prompts you, you can still claim later from the Shopify menu, as long as you do it within 30 days of store creation. * **Claiming your store (new stores only)**\ When you’re ready to launch your newly created store, you’ll need to **claim your store**. This migrates it to your Shopify account, makes the claiming Lovable user the Shopify store owner, and starts a **separate 120-day free trial on a Shopify subscription**. In Shopify, you need to activate payments and complete your store setup to start accepting real payments from your customers. * **Required Shopify subscription**\ After the post-claim free trial period, you’ll need a **paid Shopify plan** to continue selling products online. This subscription is managed **directly through Shopify** and is **separate from Lovable pricing**. * **Two distinct periods**\ Don't conflate the two windows: the **30-day unclaimed-store window** is about **keeping the store** (Shopify deletes unclaimed development stores after 30 days), while the **120-day post-claim free trial** is about **billing** (you only need a paid Shopify subscription once that trial ends and you're ready to sell). * **Shopify review policy compliance**\ Before publishing your store, make sure all reviews are **authentic, unbiased, and compliant with** [**Shopify’s Review Policy**](https://help.shopify.com/en/partners/help-support/faq/reviews). ## Enable the Shopify integration By default, the Shopify integration is enabled for your workspace. You can manage the Shopify integration behavior and related Shopify settings for your projects in **Connectors** → **App connectors** → **Shopify** → **Manage permissions** ### Permission preferences The default permission setting is **Ask each time**, meaning you decide whether to enable or disable the Shopify integration for each project. You can change your preference anytime from **Connectors** → **App connectors** → **Shopify** → **Manage permissions** Lovable prompts you when a Shopify integration is needed. You have three options: * **Allow**: enable the integration for the current project. * **Decline**: decline the integration for this request (you may be asked again later). * **Adjust preferences**: change the default behavior for future projects (does not affect the current project). ## Shopify integration flow Follow the steps below to build an e-commerce store with Shopify. ### Step 1: Start a project You can start by: * Creating a new project from scratch * Remixing an existing project Tell Lovable what type of store you want to create and specify Shopify. For example: ```text wrap theme={null} Build an e-commerce store with Shopify for selling handmade scented candles. ``` You can remix: * **Shopify template projects**, see [Lovable + Shopify templates](https://lovable.dev/shopify)\ When remixing, prompt Lovable to integrate Shopify and remove mock data. It is important to use a good, comprehensive prompt. ```wrap theme={null} I would like to replace the products in this store with my own products and create my Shopify store. Please proceed to: 1. Connect to Shopify. 2. Remove all mock product data from the store and create X new products with product images. 3. Update the product cards and product details page to use the new product information. 4. Update the product details page URL to match the new product. 5. Update the add to wishlist component and logic to match this change. 6. Update my cart, buy now CTA, and any related checkout actions on any page to reflect Shopify store integration. ``` * **Projects that were previously connected to a Shopify store**\ To remix a project with a connected Shopify store, you first have to [disconnect the Shopify store](#disconnect-a-shopify-store). Projects with an active Shopify connection can’t be remixed until the store is disconnected. ### Step 2: Create a new Shopify store or connect an existing one In both of the above scenarios, the Agent prompts you to **enable the Shopify connection**. Click **Allow** and choose the Shopify setup. Shopify store setup dialog showing options to create a new store or connect an existing Shopify store You can continue by creating a new Shopify store or by connecting an existing Shopify store you already own. To create a new store, follow the steps below: Click **Create store**. Lovable detects your country automatically and uses it to set the currency of your Shopify store. Your sandbox store is now ready for setup. You can continue building your store as explained in the next steps. * Before the store is claimed, all collaborators in the project can use the Shopify integration with full read/write access. * The development store is free to build on. To keep it, claim it within **30 days** of creation. Shopify removes development stores that stay unclaimed for 30 days. You authenticate directly with Shopify. To connect an existing store, sign in with a Shopify account that has access to that store. To connect an existing Shopify store, follow the steps below: Log into your [Shopify admin](https://admin.shopify.com/) and copy the URL from your browser, for example `https://admin.shopify.com/store/{your store}`. Enter the URL in Lovable. Click **Connect store**. This takes you to Shopify. Sign in to Shopify and click **Install** to install the Lovable app to your Shopify store. When the app is authorized, your Shopify store is connected and you are redirected back to Lovable. You can continue building your store as explained in the next steps. * You can create, update, and delete products directly from the chat. * You can prompt the Agent to fetch and display products from your existing store. - Each collaborator connects their own Shopify account. Lovable prompts them to sign in the first time they perform a Shopify action. What each person can change (create, update, delete products, variants, and discount codes) matches their role and permissions in Shopify. Changes are reflected immediately in your Shopify store. - Shopify sessions last up to 24 hours. When your session expires, Lovable prompts you to reconnect the next time you perform a Shopify action. - Collaborators who haven't connected a Shopify account can still fully build the storefront. ### Step 3: Add products and product images Start by adding products with a **name, description, and price**. For example: ```text wrap theme={null} Add a product named Lavender Breeze Candle, description: ‘A calming handmade soy candle infused with lavender essential oils,’ price: $25. ``` You can edit details later. If your product doesn’t appear, prompt: ```text wrap theme={null} Display the products on the website. ``` Then, enhance your listings with visuals using any of the below options. Always use representative images. **Generate AI images** ```text wrap theme={null} Add an AI-generated image to the product Lavender Breeze Candle. ``` **Upload or attach your own image** ```text wrap theme={null} Add the attached image to the product Lavender Breeze Candle. ``` **Add image from URL** ```text wrap theme={null} Add image from URL to the product Lavender Breeze Candle. ``` ### Step 4: Manage your store Manage your products and refine your store without leaving Lovable. For example, you can tell Lovable to: * Update product names, descriptions, or prices * Remove products * Display all products * Add product filtering functionality and create collections based on different categories * Add product review functionality and only allow reviews on verified purchases * Add percentage-based or fixed amount-based (USD) discount codes and include the validity period * Add wishlist functionality and ability to share the wishlist ```text wrap theme={null} Update the price of Lavender Breeze Candle to $28. Change the description of Vanilla Bean Candle to highlight the wooden wick. Remove the product Cinnamon Spice Candle. Display all products. Create a product review system and only allow reviews on verified purchases. Create a 15% discount code for the product Lavender Breeze Candle. The code should be LAVENDER15 and valid until the end of November 2025. Allow me to add products to the wishlist and share it. ``` ### Step 5: Claim your Shopify store (new stores only) * When the store is claimed, the Lovable user who claimed it becomes the Shopify store owner. * After claiming, Lovable prompts you to sign in to Shopify. This quick sign-in keeps Shopify tools working with your own Shopify account. * Other collaborators can connect their own Shopify accounts. What each person can change matches their role and permissions in Shopify. * Collaborators who haven't connected a Shopify account can still fully build the storefront. When you are ready to claim and launch your new store, be prepared to unlock your store, and set up and activate payments by completing the **KYC (Know Your Customer)** process. This may take some time. Type `Claim the store`. Lovable prompts you to claim the store. Click **Claim**. This opens Shopify in a new tab where you can log in and then complete the claim process. You may also get an email invitation to claim your store. Accept the **Claim store** link from Shopify. This takes you back to your Lovable project. In case the store claim verification fails, clicking **Try again** should resolve it. Your Shopify store is ready. Go to [Shopify Admin](https://admin.shopify.com/) to complete your store setup and activate payments so you can begin selling. See [Shopify payments](https://help.shopify.com/en/manual/payments/shopify-payments/onboarding) for more information. When you claim your store, Shopify assigns a permanent domain for your shop, which is used just for your backend. When you publish your project, your **real store URL** will be your `lovable.app` or your [custom domain](/features/custom-domain). Claim your store within **30 days** of creating it. Shopify removes development stores that stay unclaimed for 30 days. Claiming starts a **separate 120-day free trial** on a Shopify subscription, and after that trial ends you need a paid Shopify subscription to continue selling. ### Step 6: Launch your store When your store setup is complete, [publish your Lovable project](/features/publish) and share your store with the world. At any time, directly from Lovable, you can: * Create, update, and delete products * Manage prices and descriptions * Launch new collections, promotions, or bundles ## Disconnect a Shopify store You can disconnect a Shopify store from a project at any time. This is useful when you want to: * Remix the project (projects with a connected Shopify store cannot be remixed) * Connect a different Shopify store * Create a new Shopify store without starting a new project Disconnecting removes the connection between your Lovable project and Shopify store. Your Shopify store and its data remain intact in Shopify, but your Lovable project is no longer tied to that store and can be reused freely. There are three ways to disconnect: * **Ask the agent**: Type a prompt like `Disconnect my Shopify store` * **Shopify menu**: Click the Shopify icon in the navbar and select **Disconnect store** from the three dots menu * **Project settings**: Go to **Project settings → Shopify** and click **Disconnect** ## FAQ Yes. Lovable supports both **creating new Shopify stores** and **connecting existing Shopify stores**. To connect an existing store, you **sign in directly with Shopify** using a Shopify account that has access to that store. When connected, you can manage products and build your storefront directly from Lovable. This is usually a permissions or session issue: * **Connected an existing store or claimed store:** each collaborator connects their own Shopify account, and what they can change (create/update/delete products, variants, and discount codes) matches their role and permissions in Shopify. If your Shopify role lacks the required permissions, ask the store owner for access. * **Created a new store (not claimed yet):** all collaborators can make changes. * **Expired session:** Shopify sessions last up to 24 hours. Lovable prompts you to reconnect the next time you perform a Shopify action. Collaborators who haven't connected a Shopify account can still fully build the storefront in Lovable. Sometimes Shopify can take a moment to finalize the claim. If verification fails, click **Try again** in Lovable to re-check the claim status. Retrying typically resolves the issue. You cannot remix projects where the Shopify connection has been enabled. To remix a project with a connected Shopify store, first [disconnect the Shopify store](#disconnect-a-shopify-store). You can also remix an existing Shopify template project to get started, see [Lovable + Shopify templates](https://lovable.dev/shopify). Prompt the Agent to do the following: ```text wrap theme={null} Please update the product URL logic to ensure that all new and future products in the store correctly display their respective product detail pages. ``` This should ensure that you won’t have any issues in the future. For all other issues, click **Try to Fix**, and the Agent will address and resolve the issue. Prompt the Agent to update the pages where you’ve seen these products, for example: ```text wrap theme={null} Clear the store from any existing products across all pages except for those that I added to my Shopify store. ``` # Connect your app to Slack Source: https://docs.lovable.dev/integrations/slack Connect your app to Slack to send messages, read channels, automate alerts, generate digests, and integrate workspace workflows using bot or personal access. [Slack](https://slack.com/) is a messaging and collaboration platform that lets your Lovable app work with team communications, channels, and workspace data. The Slack connector enables Slack integration for your app, allowing you to notify teams, summarize conversations, and send structured updates directly to Slack. With Slack, your app can: * Send messages to channels and direct messages * Read messages from public and private channels (with permissions) * List workspace users and channel information * React to messages with emoji * Search Slack content (personal connection) * Manage channels and perform workspace administration (with admin permissions) Each Slack connection is authorized for a single Slack workspace. You can create multiple connections to work across multiple workspaces. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Customer notifications to Slack | *Build a quote request form. When someone submits it, save the data and post a summary to #new-deals in Slack.* | **Notify your team in Slack when customers take action in your app.**
The app captures the submission, formats the key details, and posts them to the appropriate channel so someone can respond immediately. | | Incident dashboard with Slack escalation | *Build an internal incident dashboard and add a “Post Alert” button that sends a structured alert to #ops-alerts in Slack.* | **Consolidate operational data from multiple sources into one internal dashboard.**
When something needs attention, the app posts a structured alert to Slack so the right team can respond immediately. | | Weekly Slack digest app | *Summarize #product and #support from the past 7 days, let me review the summary, then post it to #leadership.* | **Turn busy Slack channels into structured summaries.**
The app reads recent messages, extracts key themes and highlights, and posts a clean digest for leadership or cross-functional teams. | | Automated KPI reports | *Every Monday at 9am, generate a KPI summary and post it to #team-updates.* | **Deliver recurring reports directly to Slack channels.**
The app compiles selected metrics on a schedule and posts formatted updates to keep the team aligned. | | Multi-workspace notifications | *When a deployment finishes, notify our internal Slack workspace and our partner’s workspace.* | **Send notifications across multiple Slack workspaces from a single app.**
The app routes messages to different workspaces based on the event or audience. | | Slack-powered knowledge search | *Build a search interface that lets me search across my Slack messages with filters for date and sender.* | **Create a structured search experience for Slack conversations.**
The app lets users search messages and filter results to quickly find past discussions and decisions. | | Team activity dashboard | *Build a dashboard showing where I’ve been mentioned and which messages need follow-up.* | **Surface Slack activity in a focused internal view.**
The app aggregates mentions and recent activity so users can track conversations and follow up on action items. | | Automated onboarding workflows | *When a new project starts, automatically create Slack channels, add team members, and send a welcome message.* | **Automate Slack setup as part of broader onboarding workflows.**
The app provisions channels, assigns members, and posts welcome messages without manual coordination. | ## How Slack connections work Lovable uses one centrally managed app for Slack to power all Slack integrations across workspaces. Within your Lovable workspace: * You can create multiple Slack connections. * Each connection is a separate OAuth authorization. * Each connection can: * Use different scopes * Have different access types (bot or personal) * Connect to a different Slack workspace * Multiple projects within a single workspace can use the same connection. This makes it easy to separate environments (for example, development and production) or manage multiple Slack workspaces. Slack uses Lovable’s gateway architecture for secure OAuth handling and automatic token refresh. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. ## How to connect Slack Workspace **admins** and **owners** can connect Slack. When a connection is created, Slack becomes available across all projects in the workspace. ### Prerequisites * A Slack workspace where you can install apps (or request admin approval) * Lovable workspace admin or owner role * For admin scopes: Slack workspace admin permissions ### Set up your Slack connection Open **Connectors** → **App connectors** and select **Slack**. Click **Add connection**. In **Display name**, name the connection (for example, `Slack Prod`). * **Connect as a bot** (recommended): Operations are performed as a bot. One bot connection per Slack workspace is sufficient. You can customize the bot's display name and icon within your Lovable projects. * **Connect as yourself** (personal): Operations are performed as the Lovable workspace admin who creates the connection, using their personal Slack account and permissions. Use this when you need personal data access or workspace administration features. Expand **Advanced settings** to view and configure scopes - the Slack API permissions your app needs. Default scopes are pre-selected for common use cases. * **Bot connections**: Default scopes support sending messages, reading channels and DMs, viewing users, adding reactions, and customizing the bot's identity. * **Personal (You) connections**: Default scopes support reading and searching Slack content using your own Slack permissions. Workspace administration requires additional admin scopes and Slack workspace admin permissions. Select only the scopes your app needs. You can update scopes later by editing the connection and clicking **Reconnect**. For full scope documentation, see the [Slack scope reference](https://docs.slack.dev/reference/scopes/). * Click **Connect**. The Slack authorization window opens - make sure your browser doesn't block pop-ups. * Select the workspace you want to connect, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, your Lovable apps can start using Slack to send messages, read channels, and integrate with your team's workspace. ## Slack bot behavior and channel access When you connect Slack as a **bot**, messages are sent from the centrally managed **Lovable app for Slack**. Each project can define its own bot display name and icon. This means different projects can appear as different bots in Slack, even though they all send messages through the same Lovable app for Slack. ### Bot customization You can customize how messages from your project appear in Slack by prompting Lovable to set a custom bot name and icon. For example: ```wrap theme={null} Send messages as ‘Deploy Bot’ bot with a rocket emoji icon. ``` Using a consistent bot name and icon helps teammates quickly recognize which project is sending messages. ### Public channel access The bot automatically has access to all public channels in the workspace. No invitation is required. ### Private channel access You must invite the bot before it can read or post messages by using `/invite @Lovable`. If your app cannot post to a private channel, invite the bot first. ## Limitations The Slack connector cannot: * Receive incoming Slack events (no webhooks or event subscriptions) * Create slash commands * Respond to interactive buttons or modals in real time Need each end user to connect **their own** Slack account? Use the Slack **[app user connector](/integrations/app-user-connectors)** instead. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. ## AI disclosure Lovable is an AI-powered platform. Apps built with Lovable may generate AI-assisted content such as summaries or notifications. AI-generated outputs may occasionally contain inaccuracies and should be reviewed before use. # Connect your app to Snowflake Source: https://docs.lovable.dev/integrations/snowflake Connect Snowflake to your Lovable app using Snowflake OAuth. Run SQL, use the SQL REST API, and work with warehouses and data from your Snowflake account through Lovable’s connector gateway. [Snowflake](https://www.snowflake.com/) is a cloud data platform for **analytics**, **data engineering**, and **AI/ML** workloads. The **Snowflake** app connector uses **Snowflake’s native OAuth** (custom security integration) so your app can call Snowflake through Lovable’s **connector gateway** without embedding long-lived passwords in your project. With Snowflake connected, your app can: * Run **SQL** and use the **SQL REST API** (for example submitting statements and checking status) * Work with **warehouses**, **databases**, and **schemas** your role can access * Build **internal tools**, **dashboards**, and **data workflows** backed by Snowflake Snowflake fits when your organization already centralizes data in Snowflake and you want Lovable apps to query or orchestrate that data securely. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------- | :------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------- | | **SQL explorer** | *Build an internal tool that runs read-only SQL against our `analytics` schema and shows results in a table.* | **Ad-hoc querying** with guardrails you define in app logic. | | **Metric dashboard** | *Show daily revenue and signups from Snowflake summary tables with date filters.* | **Operational dashboards** fed by modeled tables in Snowflake. | | **Pipeline status** | *After a user uploads a file, poll Snowflake for load completion and show pass/fail.* | **Orchestration-style UX** on top of warehouse data. | | **Support lookup** | *Given an account ID, load key fields from our Snowflake `customers` view for the support UI.* | **Enrich product UIs** with trusted warehouse data. | | **Data validation** | *Run lightweight row counts and null checks on staging tables after our ETL runs.* | **Quality checks** using SQL against Snowflake. | ## How Snowflake connections work * **OAuth 2.0 (authorization code)**: You register a **custom OAuth integration** in Snowflake and enter the **Account URL**, **Client ID**, **Client secret**, and **Role** in Lovable. You (or your admin) then complete sign-in with Snowflake to authorize the connection. * **Role**: Choose a role that has the warehouse and object access your app needs. Do **not** use `ACCOUNTADMIN` or `SECURITYADMIN`; they are blocked by the connector validation pattern. * **Gateway**: API requests are proxied through Lovable’s **connector gateway**, which manages tokens. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for limits. For Snowflake-side setup details, see Snowflake’s guide to [OAuth with clients](https://docs.snowflake.com/en/user-guide/oauth-custom). Snowflake **compute and storage** costs are billed by **Snowflake** / your cloud agreement, not by Lovable. ## How to connect Snowflake Workspace **admins** and **owners** can create Snowflake connections. **Link** each connection to the Lovable **projects** that should use it. ### Prerequisites * Access to a **Snowflake account** where you can create or manage an **OAuth security integration** * Permission to use a Snowflake **role** appropriate for your app (not `ACCOUNTADMIN` or `SECURITYADMIN`) * **Lovable workspace admin or owner** role ### Step 1: Create a Snowflake OAuth integration Work with your Snowflake administrator if needed. 1. In Snowflake, create a **custom OAuth security integration** and obtain the **OAuth client ID** and **client secret**. 2. Configure **redirect URIs** and any other settings required by your organization. Use the **redirect URI** that Lovable shows during the connect flow so authorization can complete. 3. Confirm the **account URL** (for example `https://myorg-myaccount.snowflakecomputing.com`). See Snowflake’s documentation: [Configure Snowflake OAuth for custom clients](https://docs.snowflake.com/en/user-guide/oauth-custom). ### Step 2: Connect Snowflake in Lovable 1. Open **Connectors** → **App connectors** and select **Snowflake**. 2. Click **Add connection**. 3. Enter a **Display name** (for example `Snowflake Prod`). 4. Fill in **Account URL**, **Client ID**, **Client secret**, and **Role** exactly as in Snowflake. 5. Start the **Connect** / **Authorize** flow and sign in to Snowflake when prompted. After authorization, link the connection to the projects that should query Snowflake. ## Limitations * **Scopes and roles** are determined by your Snowflake OAuth integration and the **role** you configure; the app cannot exceed those permissions. * **Per-user Snowflake login** is not provided by this connector—it represents a **shared** authorization for the workspace connection. If you need each end user to sign in with **their own** Snowflake account and query under their own role, use the Snowflake **[app user connector](/integrations/app-user-connectors)**. * **Gateway limits** apply as described in [Gateway-based connectors](/integrations/introduction#gateway-based-connectors). ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Storyblok Source: https://docs.lovable.dev/integrations/storyblok Connect your app to Storyblok, a headless CMS and visual page builder, to power content-driven sites and apps with editor-managed stories, components, and assets. [Storyblok](https://www.storyblok.com/) is a headless CMS that lets your Lovable app fetch published or preview content (stories, links, tags, and datasources) managed by your content team in the Storyblok app. It's designed for apps where editorial workflows, visual page building, and structured content live outside the codebase. With Storyblok, your app can: * Fetch stories, links, tags, and datasources from the Content Delivery API * Build content-driven sites backed by Storyblok stories and components * Use published content for live experiences or preview content for draft previews * Render Storyblok rich text and components directly in your app * Drive SEO metadata (title, description, og:image) from content fields The Storyblok connector is **read-only** and targets Storyblok's Content Delivery API (CDN). It's a good fit when your content is authored in Storyblok and your Lovable app is the front end that renders it. ## Common use cases and example apps | Example app | Example prompt | Description | | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Marketing site backed by Storyblok** | *Use Storyblok and build a marketing site that pulls landing pages, blog posts, and navigation from Storyblok.* | **Render a full marketing site from content managed in Storyblok.**
The app fetches stories by slug, renders the matching components, and surfaces SEO metadata so editors can ship pages without code changes. | | **Blog or editorial site** | *Use Storyblok and build a blog that lists articles, supports tag filtering, and renders rich text from Storyblok.* | **Build an editorial reading experience driven by Storyblok stories.**
The app paginates story lists, filters by tag or content type, and renders rich text and embedded components for each post. | | **Product catalog or directory** | *Use Storyblok and build a product directory where editors manage listings in Storyblok and the app renders detail pages by slug.* | **Turn Storyblok stories into a structured directory.**
The app lists items with filters, deep-links to detail pages by slug, and renders fields managed entirely in Storyblok. | | **Documentation or knowledge base** | *Use Storyblok and build a docs site with sections, a sidebar, and search-friendly pages from Storyblok.* | **Publish documentation from Storyblok with a navigable structure.**
The app reads the story tree, builds navigation from `starts_with` queries, and renders each page from rich content. | | **Multi-language content site** | *Use Storyblok and build a localized site that renders content in the visitor's language using Storyblok translations.* | **Deliver localized experiences from a single Storyblok space.**
The app fetches the right language version per route and falls back gracefully when a translation is missing. | | **Preview environment for editors** | *Use Storyblok and build a preview site that shows draft content for editors before publishing.* | **Give editors a way to review unpublished work.**
Connected with a preview token, the app requests `version=draft` so editors see in-progress stories before they go live. | | **Landing page generator** | *Use Storyblok and build a landing page app where each story slug renders a full page with hero, features, and CTAs.* | **Let marketers compose landing pages visually in Storyblok.**
The app maps Storyblok components to UI components and renders complete pages keyed by slug. | ## How to connect Storyblok Workspace **admins** and **owners** can connect Storyblok. You can create multiple Storyblok connections using different access tokens. This is useful for separating environments (for example, development and production), targeting different spaces or regions, or switching between published and preview content. When the connection is created, Storyblok becomes available across all projects in the workspace. ### Prerequisites Before connecting Storyblok, make sure you have: * A Storyblok account and a space * A Content Delivery API access token from that space (public or preview) * Lovable workspace owner or admin role All API requests made through this connector use your Content Delivery API access token. API usage counts toward your Storyblok plan limits and billing is handled directly by Storyblok, not Lovable. ### Step 1: Get a Storyblok access token A **Content Delivery API access token** lets your Lovable app fetch content from your Storyblok space. You can create separate tokens for **published** and **preview** content. To create a Storyblok access token: Sign in to the [Storyblok app](https://app.storyblok.com/) and open the space you want to connect. Navigate to **Settings → Access Tokens**. Click **Generate new token**. 1. Enter a descriptive name, for example `Lovable integration`. 2. Choose the access level: * **Public**: returns only published content. Use this for production sites. * **Preview**: returns published and draft content. Use this for staging or editor preview environments. 3. Click **Generate** and copy the token. Note the **region** of your space (EU, US, CA, AP, or CN). You can find this in your space settings, and it must match the region you select in Lovable. Your access token functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See Storyblok docs for detailed instructions: [Content Delivery API v2](https://www.storyblok.com/docs/api/content-delivery/v2). ### Step 2: Connect Storyblok to Lovable You can create multiple connections using different access tokens. To connect Storyblok: Go to **Connectors → App connectors** and select **Storyblok**. Click **Add connection**. 1. **Display name**: name the connection, for example `Storyblok Prod`. 2. **Space region**: select the region where your Storyblok space is hosted (EU, US, CA, AP, or CN). The default is **European Union (EU)**. The region must match the space the token belongs to. A token from a US space will not authenticate against the EU CDN. 3. **Public or preview access token**: paste your Content Delivery API token. 4. **Who can access this connection**: keep access limited to specific people or invite the entire workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. When connected, your Lovable apps can start fetching Storyblok content. ## Working with published and preview content The Storyblok Content Delivery API returns different content depending on the request: * Public tokens can only return published content. * Only preview tokens can return drafts. When prompting Lovable, mention which version you want. For example, "show draft content" for an editor preview, or "use published content" for a production site. ## Limitations The Storyblok connector is **read-only** and targets the Content Delivery API (CDN). The Storyblok connector cannot: * Create, update, or delete content (editors continue to manage content in the Storyblok app) * Call Storyblok's Management API for content authoring, space configuration, or asset uploads * Receive Storyblok webhooks or publish events * Support per-end-user authentication (each connection uses a single shared token) ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Set up app payments with Stripe Source: https://docs.lovable.dev/integrations/stripe Add one-time payments or subscriptions to your app using chat-driven Stripe integration with Supabase Edge Functions. This article is deprecated. Most projects should use the built-in [Payments](/features/payments) feature instead. Follow this legacy guide only if the built-in Payments feature is not available to you: older projects that use an external Supabase connection, or workspaces where the payments connector is disabled (it is off by default on Enterprise plans). Lovable now lets you set up Stripe entirely through **chat**. **Chat‑driven auto‑setup (recommended)**\ After you connect **Supabase** and save your **Stripe Secret Key** via **Add API Key**, just describe what you need: * “Add three subscription tiers …” * “Create a one‑time checkout for my e‑book at \$29”\ Lovable generates the checkout / portal edge functions, database tables with RLS, and UI buttons—no manual coding or webhooks unless you ask for them. - For **one‑off sales**, be sure your cart or product page already works. - For **subscriptions**, confirm Supabase Auth is in place so Lovable can link Stripe customers to each user’s **id** ### Key takeaways * Use the **chat‑driven flow** for both subscriptions and one‑off payments. * **Never paste your Stripe Secret Key in chat.** Configure it via the in-chat **Add API Key** form. * The form accepts a **Secret key** (`sk_...`) or a **Restricted key** (`rk_...`), for live or test mode. A restricted key with only the permissions you need is recommended. Publishable keys (`pk_...`) do not work here. * **Webhooks are opt‑in.** Lovable relies on edge‑function polling unless you request webhooks. * Debug in **Browser Console → Network/Errors**, **Supabase → Edge Functions → Logs**, and **Stripe Dashboard → Logs**. * Always test in **Stripe Test Mode**, then deploy. ## Requirements Before integrating Stripe, ensure the following prerequisites are met: * The project **must** be connected to Supabase. [Learn more about Supabase](https://docs.lovable.dev/integrations/supabase) * A **Stripe account** with properly configured products. * A working **frontend and backend**: * For individual product sales, ensure a shopping cart and checkout page are functional. * For subscriptions, set up login functionalities and different pricing tiers. **Please note** Stripe integration doesn't work in preview. To test the integration, make sure to deploy. You should also make sure to be in test mode in Stripe when trying out the functionality. When testing payment, card number: 4242 4242 4242 4242, any 3 digits as CVC and any future date will work as a card. ## Stripe payment setup (No‑code chat flow) Lovable now generates all Stripe logic for you. Once your **Stripe Secret Key** is configured via the in-chat **Add API Key** form and your project is **connected to Supabase**, simply tell Lovable what you need in chat—no manual Payment Links required. **Prep your project** * Supabase connected * Stripe Secret Key added via the in-chat **Add API Key** form * (Optional) Prices or product IDs handy Examples: * Create a one-time checkout for my "Digital Course" at \$29 * Set up an annual Premium plan for \$99, tied to each user's id **Review & apply** Lovable auto‑scaffolds the Edge Functions, database tables, and UI components (all tied to the user's id in Supabase). Check the preview, then click **Apply** to deploy. * Subscriptions should always be linked to the authenticated user’s `id` in Supabase for secure, role‑based access. ## Advanced integration: Webhooks & Supabase For complex payment structures such as **subscriptions and role-based access**, Lovable recommends using **Supabase** to securely handle Stripe integration. This allows for proper webhook handling, subscription management, and role-based access control based on payment tiers. The Edge Function that handles the necessary changes to the user account should be set up automatically by the AI. Getting started is simple. Lovable makes connecting Supabase effortless with a built-in native integration: 1. Click the **Supabase button** in the top-right corner of Lovable. 2. Follow the instructions to link your project. 3. Once connected, Supabase enables secure payment processing, subscription management, webhook handling, customer data storage, and error handling. Initiate the process by prompting Lovable: Let's connect Stripe to my project. We will begin with secure payment processing. Lovable will generate the necessary SQL schema for handling payments. This includes database tables for users, subscriptions, and payments. You can review and customize these tables to fit your specific product needs before applying changes. **Edge Functions** in Supabase act as small, high-performance serverless functions that run close to the user, ensuring fast responses. They help process webhook events, such as payment confirmations, before updating the database. **Retrieve the Endpoint URL** from the Edge Function in Supabase. **Go to Stripe Dashboard** > Developers > Webhooks > Create an Event Destination. ![Stripe Dashboard showing the Developers section with Webhooks tab and Create an Event Destination button](https://lovable.dev/content/news/stripe-api.png) **Select Webhook Events** that align with your project needs: * `payment_intent.succeeded` * `payment_intent.payment_failed` * `customer.subscription.created` * `customer.subscription.updated` * `customer.subscription.deleted` **Enter the Endpoint URL** from Supabase. **Copy the Webhook Secret** and store it securely in **Supabase → Edge Functions → Manage Secrets → Add New Secret**. If unsure about naming the secret, ask Lovable in **Plan mode** for guidance. To integrate Stripe securely, avoid sharing your API key directly in chat. Instead: Lovable interface showing the Add API Key form for securely storing Stripe credentials **Go to Stripe Dashboard** > Developers > API Keys. **Copy the Secret Key** (DO NOT paste it directly in Lovable chat). **Use the Lovable "Add API Key" feature** to securely store it. **Important Security Warning** Never paste your **Secret Key** directly in Lovable chat. Treat it like the keys to your house—exposing it could allow unauthorized access to your Stripe account. Instead, store it securely using Lovable's API key feature. * **Use Stripe's Test Mode** to safely test payments. * **Test card details**: * Card Number: `4242 4242 4242 4242` * Any future expiration date * Any 3-digit CVC * **Deploy your app**—Stripe integration does not work in preview mode. ## Debugging & Troubleshooting Open **Developer Tools** (Right-click > Inspect > Console in Chrome). Look for errors and review webhook event logs. Copy error messages and ask Lovable for debugging assistance. Go to **Supabase Dashboard** Edge Functions Logs to check for webhook errors. Navigate to **Stripe Dashboard** Webhook logs Confirm that Stripe is sending data correctly. Switch to **Plan mode** and ask Lovable follow-up questions. Ask Lovable follow-up questions. Use the **Rubber Duck Method** & explain your issue step by step to clarify the problem. # Connect to Supabase Source: https://docs.lovable.dev/integrations/supabase Connect Lovable with Supabase for seamless backend setup, database, auth, storage, real-time, and serverless functions. The Supabase integration connects a [Supabase](https://supabase.com/) project you own to your Lovable project and uses it as your app's backend. When connected, Lovable builds full-stack features directly from chat: it designs your database schema, runs migrations, deploys edge functions, and wires your app's UI to your data, all against your own Supabase project. **Do I need Supabase?** No. [Lovable Cloud](/features/cloud) is the built-in backend and is enabled by default, so most projects never need a separate Supabase account. Lovable Cloud utilizes Supabase's open-source foundation, so you get the same database, auth, storage, and edge function capabilities without any setup. Connect your own Supabase project when you want direct ownership of the backend: your own Supabase account and billing, full access to the Supabase dashboard, or an existing Supabase project you already use. The Supabase integration is available on all plans. ## Supabase or Lovable Cloud? | | Lovable Cloud | Your own Supabase project | | ------------------------------------------------ | ------------------------------------------------ | --------------------------------------------------------------- | | Setup | Automatic, no extra account | Requires a Supabase account and project | | Billing | Credits in your Lovable workspace | Your Supabase subscription, billed by Supabase | | Backend management | The Cloud view inside Lovable | Supabase dashboard | | Auth settings and social login providers | Configured through Lovable | Configured in the Supabase dashboard | | Infrastructure (backups, instance size, pausing) | Managed by Lovable | Managed by you in Supabase | | Best for | Most projects, fastest path to a working backend | Teams who want to own their Supabase account and infrastructure | Switching between the two is not automatic. There is no one-click migration from Lovable Cloud to Supabase or from Supabase to Lovable Cloud, so it's worth deciding early which backend you want a project to use. See [Export Lovable Cloud data](/features/advanced-settings#export-lovable-cloud-data) for details on exporting Cloud data. ## What you can build With Supabase connected, you can prompt Lovable to build complete backend features: * **Store and query data**: Lovable designs tables and relationships from a plain-language description and connects your UI to them. * **Sign users in**: email and password authentication, social logins, and access control backed by Supabase Auth. * **Upload and serve files**: images, documents, and other media stored in Supabase Storage buckets. * **Run server-side code**: Supabase Edge Functions for payments, emails, AI features, scheduled tasks, and external API calls. * **Keep secrets safe**: API keys for services like Stripe or Resend are stored securely in your Supabase project, never in your app's code. * **Update in real time**: live chat, feeds, and dashboards using Supabase's real-time subscriptions. For the full picture of everything the Supabase platform offers, see the [Supabase documentation](https://supabase.com/docs). ## Prerequisites * A Supabase account. [Sign up](https://supabase.com/dashboard/sign-up) or [sign in](https://supabase.com/dashboard/sign-in); the free tier is enough to get started. * A Supabase project to connect, or a Supabase organization where you can create one. ## Connect Supabase to Lovable Connecting involves two separate actions, often done by different people: 1. **Link a Supabase organization to your Lovable workspace.** A workspace owner or admin does this once per organization. Linked organizations become available to everyone in the workspace. 2. **Connect a Lovable project to a Supabase project.** Anyone with edit access to the project can do this, using any project from a linked organization. If you're a workspace owner or admin doing this for the first time, the connect dialog walks you through both actions in one flow. ### Link your Supabase organization (workspace owners and admins) You can link an organization from any of these places: * **The Supabase connector page**: open [**Connectors**](/integrations/introduction) from the dashboard sidebar, select **Supabase**, and click **Connect Supabase** (or **Manage Connected Organizations** if the workspace already has one). * **The connect dialog in a project**: in the editor, open **More → Cloud**, click **Already have a Supabase project? Connect it here**, and use **Add Organization**. * **When creating a project**: on the dashboard, click **+** in the prompt box, open **Databases**, and choose **Add Supabase organization**. Whichever you choose, a Supabase window opens where you sign in and authorize Lovable for the organization you pick. The organization then appears under **Linked Supabase organizations** and is available to every member of the workspace. Members don't need their own Supabase accounts to connect projects from it. Only workspace owners and admins can add or reconnect organizations. If these options are disabled for you, ask a workspace admin to link the organization first. ### Connect your Lovable project to a Supabase project When an organization is linked, anyone with edit access to a project can connect it. Start from either place: * **When creating a new project**: on the dashboard, click **+** in the prompt box, open **Databases**, and pick a Supabase project under the **Supabase** heading (or type "Supabase" in the menu search). The new Lovable project is created with that Supabase project as its backend. * **In an existing project**: connect from the Cloud view in the editor: In the editor, open **More → Cloud** and click **Already have a Supabase project? Connect it here**. The link appears on projects that don't have a backend yet, next to the **Enable Cloud** option. In the **Linked Supabase organizations** dialog, click **Continue**. The **Connect project** step lists the Supabase projects in your linked organizations. Click **Connect** next to the project you want to use. Don't have a Supabase project yet? Click **Create Project** to open the Supabase dashboard, create one there, and then return to Lovable to connect it. After connecting, the Cloud view shows your Supabase project's name and status, with quick links to the Supabase dashboard. You can now prompt Lovable to build backend features. If the connect link shows **Wait for Lovable to finish working**, Lovable is still processing a request in this project. Wait for it to finish, then try again. ## How Lovable works with your Supabase project With Supabase connected, Lovable manages your backend from chat. You don't need to write SQL or copy code into the Supabase dashboard. ### Database Supabase provides a hosted PostgreSQL database, so your app keeps the full power and scalability of SQL without you managing servers. Whenever a feature needs to store data, describe it in plain language and Lovable designs the tables, columns, and relationships for you: ```text wrap theme={null} Add a feedback form where users can leave a message and a 1 to 5 rating, and store the responses in the database. ``` Schema changes run as reviewed migrations: Lovable writes the SQL, shows it to you, and asks for your approval in chat before running it. After you approve, Lovable executes the migration on your Supabase project, saves the migration file in your project's code (under `supabase/migrations/`), and regenerates the TypeScript types your app uses. Lovable also asks for your approval before inserting or changing data. Reading data for debugging (for example, checking why a page is empty) does not modify anything. You can always work with your data directly in the Supabase dashboard as well: the **Table Editor** shows rows in a spreadsheet-like view where you can inspect and edit records, and the **SQL Editor** lets you run your own queries. **Real-time updates**: Supabase can stream database changes to your app, which enables features like live chat, notifications, or dashboards that update for all users without refreshing. Prompt Lovable to make a feature update in real time and it wires up the subscription: ```text wrap theme={null} Make the chat update in real time so new messages appear without refreshing. ``` ### Authentication Prompt Lovable to add signup and login flows backed by Supabase Auth: ```text wrap theme={null} Add email and password login, and require users to be signed in to access the dashboard. ``` Lovable wires the pages to your Supabase project, so users who register through your app appear under **Authentication** in the Supabase dashboard, where you can also add test users manually. Authentication settings themselves live in your Supabase project, not in Lovable. To offer social logins (such as Google or GitHub), enable the provider in your Supabase dashboard's **Authentication** settings and supply the OAuth credentials the provider requires. Then prompt Lovable to add the matching sign-in button and flow to your app: ```text wrap theme={null} Add a "Sign in with Google" button to the login page. ``` While testing, turn off email confirmation in your Supabase dashboard's **Authentication** settings so test accounts can sign in immediately. Re-enable it before launching to real users. ### Edge functions Supabase Edge Functions are serverless functions: small pieces of backend code that run on Supabase's infrastructure, without you provisioning or managing a server. They're the right tool whenever your app needs logic that can't or shouldn't run in the user's browser. Typical uses: * **AI features**: calling a model API to summarize, classify, or chat. * **Sending emails or notifications**: for example, a welcome email on signup via an email API like Resend. * **Processing payments**: creating checkout sessions and handling webhooks with Stripe. * **Scheduled tasks**: recurring jobs like a nightly cleanup or a daily summary. * **Calling external APIs with secret keys**: anything that uses credentials you can't expose in frontend code. You don't write these functions yourself. Describe the behavior in chat, and Lovable writes the function, deploys it to your Supabase project, and updates your app to call it: ```text wrap theme={null} When a user submits the contact form, send me an email notification with the message contents using Resend. ``` When a function fails, Lovable reads its logs and surfaces the error in chat to help you fix it. You can also monitor your functions yourself in the Supabase dashboard under **Edge Functions**, where each function has its own logs. ### Secrets Many backend features depend on secret API keys, such as a Stripe secret key for payments or a Resend key for email. When a feature needs one, Lovable detects it and prompts you to enter the value through a secure input. Secrets are stored in your Supabase project, where your edge functions can read them; they never appear in your app's code or repository, and Lovable does not read stored secret values back. ```text wrap theme={null} Add a checkout button that processes payments with Stripe. ``` For example, when Lovable deploys a payment function, the function reads your Stripe secret key from Supabase's secret store to authenticate with Stripe. You can manage stored secrets in the Supabase dashboard under your project's **Edge Functions** settings. ### Storage Supabase Storage hosts files (images, videos, PDFs, and other media) alongside your database, organized into buckets with their own access permissions. Ask for a file upload feature and Lovable builds the upload logic and creates the buckets, asking for your approval before creating or changing buckets on your Supabase project: ```text wrap theme={null} Let users upload a profile picture on the account settings page and show it in the header. ``` Uploaded files are stored in a bucket in your Supabase project, and Lovable handles retrieving the file URLs to display them in your app. You can browse files and manage bucket permissions in the Supabase dashboard under **Storage**. Upload size limits follow your Supabase plan (on Supabase's free tier, individual files are limited to 50 MB); see [Supabase pricing](https://supabase.com/pricing) for current limits. ### Security checks Lovable runs automated security checks against your database configuration, including Row Level Security (RLS) coverage, and flags issues it finds after schema changes. **Before going live**, make sure every table has Row Level Security policies that restrict who can read and write each row. Ask Lovable to review your policies (for example, "Make sure users can only see and edit their own data"), and verify them yourself in the Supabase dashboard. Missing RLS policies are the most common way app data gets exposed. ## Managing the connection The connection has two levels, managed in different places: the **project connection** (which Supabase project a Lovable project uses) and the workspace's **linked organizations** (which Supabase organizations the whole workspace can use). ### Manage the project connection In the editor, open **More → Cloud** on a connected project. From there you can: * See the connected project's name and health status. * Jump to the Supabase dashboard: the project overview, user management, SQL editor, edge functions, and secrets. * Disconnect the project. Your backend lives in Supabase, so day-to-day management of data, users, and files happens in the Supabase dashboard. ### Manage linked organizations (workspace owners and admins) Open [**Connectors**](/integrations/introduction) from the dashboard sidebar, select **Supabase**, and use **Manage Connected Organizations** to link additional Supabase organizations or reconnect one whose access has expired. The **Manage organizations** button in a connected project's Cloud view opens the same place. ### Disconnect Supabase In the editor, open **More → Cloud**. The view shows your connected Supabase project. Click **Disconnect**, then confirm in the **Disconnect Supabase** dialog. Disconnecting stops Lovable from deploying edge functions and reading your database schema, but it does not change your code and does not delete anything in your Supabase project. You can reconnect to the same or a different Supabase project later. ## Limitations * Each Lovable project connects to one Supabase project at a time. * There is no automatic migration between Lovable Cloud and your own Supabase project, in either direction. * Supabase usage limits (database size, file upload size, bandwidth) follow your Supabase plan. Check [Supabase pricing](https://supabase.com/pricing) for current limits. ### Lovable features that require Lovable Cloud Some Lovable features are built for [Lovable Cloud](/features/cloud) backends and don't apply when you bring your own Supabase project: * **In-editor backend views**: the Database, Users, Storage, Secrets, Jobs, Usage, and Logs views in the Cloud section. With your own Supabase project, you use the Supabase dashboard instead. * **Managed infrastructure**: daily backups with restore, pausing, and instance resizing from inside Lovable. You manage backups, compute, and billing in Supabase. * [**Built-in payments**](/features/payments): Paddle and Stripe payments through Lovable require Lovable Cloud for webhooks and subscription data. * [**Custom emails**](/features/custom-emails): sending your app's emails from your own domain requires Lovable Cloud. * **Configuring auth through Lovable**: enabling social login providers and changing auth settings from chat, including [managed Google authentication](/features/google-auth) and [SAML SSO for your app's users](/features/saml-sso), works on Lovable Cloud only. On your own Supabase project, configure these in the Supabase dashboard. * [**Signed-in browser testing**](/features/browser-testing): Lovable can test your app as a logged-in user on Lovable Cloud only; with your own Supabase project it tests pages that don't require signing in. * [**Sensitive data scanning**](/features/sensitive-data-scanning): PII detection covers Lovable Cloud databases and storage. ## Troubleshooting Lovable can't find the connected Supabase project. The linked project may have been deleted in the Supabase dashboard, or your workspace's access to the Supabase organization may have changed. Click **Disconnect** to clear the broken link, or **Manage organizations** to reconnect the organization and pick a project again. Projects that aren't ready in Supabase (for example, paused or still provisioning) can't be connected, and Lovable shows **Check project status in Supabase**. Open the Supabase dashboard, make sure the project is active, then try again. Linking a Supabase organization requires workspace admin permissions. Ask a workspace owner or admin to link the organization; after that, anyone with edit access to a project can connect it. Lovable is still processing a chat request or another operation in this project. Wait for it to finish, then start the connection again. ## FAQ No. [Lovable Cloud](/features/cloud) is the default backend and covers database, authentication, storage, edge functions, and AI features without a separate account. Connect your own Supabase project only if you want to own and manage the backend yourself. Yes. Supabase is a separate platform with its own account and billing. Lovable credits cover the building work Lovable does; everything your backend consumes (database, storage, bandwidth) is billed by Supabase under your Supabase plan. Both platforms have free tiers, so you can start without paying. Workspace owners and admins link Supabase organizations to the workspace. After an organization is linked, anyone with edit access to a project can connect it to a Supabase project from that organization, without needing their own Supabase account. Viewers can't connect projects. No. This was how the integration used to work, but Lovable now runs database migrations for you. It shows you the change, asks for approval in chat, executes the migration on your Supabase project, and keeps migration files and generated types in your project's code. There is no automatic migration in either direction. If you need to move, you'll recreate the schema and move data manually: export your data from the current backend, connect the new one, and ask Lovable to rebuild the schema. For exporting from Lovable Cloud, see [Export Lovable Cloud data](/features/advanced-settings#export-lovable-cloud-data). Yes. Each Lovable project connects to one Supabase project, but nothing stops several Lovable projects from connecting to the same Supabase project (for example, a customer app and an admin dashboard sharing one database). All of them read and write the same data, so design your schema and RLS policies with that in mind. Yes. Ask Lovable to create an edge function that acts as a custom API endpoint or webhook for the external service; this works the same way on Lovable Cloud. With your own Supabase project, you additionally get direct access to Supabase's auto-generated REST API and client libraries, so external tools can also read and write your data without going through an endpoint you build. Lovable stops deploying edge functions and reading your database schema. Your code is not changed, and nothing is deleted from your Supabase project. You can reconnect later. # Connect your app to Telegram Source: https://docs.lovable.dev/integrations/telegram Send and receive Telegram messages in apps you build with Lovable. This is for app integrations, not for chatting with Lovable in Telegram. [Telegram](https://telegram.org/) is a messaging platform that lets your Lovable app communicate with users through chats, groups, and channels. The Telegram connector enables Telegram integration for your app, allowing it to send notifications, respond to user messages, and trigger workflows directly from Telegram conversations. This is an integration for apps you build with Lovable. Your app can send and receive messages through Telegram bots. Want to chat with Lovable inside Telegram instead? Use [Lovable in Telegram](/tips-tricks/lovable-telegram-bot). Telegram bots act as a chat interface for your app, letting users receive updates or interact with app features without opening the app interface. With Telegram, your app can: * Send messages, photos, documents, and other media to users or groups * Receive and respond to user messages and commands (via polling) * Create interactive buttons and custom keyboards * Guide users through workflows such as booking, ordering, or submitting requests * Deliver alerts, reports, and reminders through chat * Broadcast updates to Telegram groups or channels Telegram is a good fit when your app needs to notify users about events, broadcast updates, or allow users to request information directly through chat. ## Common use cases and example apps | Example app | Example prompt | Description | | :---------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Online store with Telegram notifications and order tracking | *Build an online store where customers can place orders, send our team a Telegram message whenever a new order is created, and let customers message a Telegram bot with their order number to check delivery status.* | **Manage store activity and customer updates through Telegram.**
When a customer places an order in the app, the app sends a message with the order details to a Telegram chat for the team. Customers can also message the Telegram bot with their order number, and the app returns the current delivery status. | | API monitoring dashboard with Telegram alerts | *Build a monitoring dashboard that checks our API every minute and sends a Telegram alert if the service stops responding.* | **Monitor systems and send alerts through Telegram when problems occur.**
The app checks service health on a schedule and posts a message to a Telegram chat when downtime or errors are detected so the team can respond quickly. | | Customer support inbox with Telegram chat | *Build a support inbox app where customers can message a Telegram bot and the conversation appears in our support dashboard.* | **Provide customer support through Telegram conversations.**
Users message the Telegram bot, the app records the request in the support system, and the team can respond through the dashboard or automated replies. | | Analytics dashboard with Telegram reports | *Build a KPI dashboard that calculates daily metrics and posts a summary to our team Telegram group every morning.* | **Deliver recurring reports through Telegram.**
The app aggregates metrics on a schedule and sends a formatted summary message to a Telegram chat or group so teams can stay informed without opening the dashboard. | | Market data tracker with Telegram price alerts | *Build a market data tracker that monitors cryptocurrency or stock prices and sends a Telegram message when a selected price threshold is reached.* | **Send alerts when tracked values change.**
The app monitors financial data from an API and sends a Telegram message when a price crosses a configured threshold so users can react immediately. | ## How Telegram connections work Each Telegram connection uses a **bot token**, which represents a single Telegram bot created through [@BotFather](https://t.me/BotFather). Within your Lovable workspace: * Each connection represents **one Telegram bot** * You can create **multiple connections** if you want to use multiple bots * Multiple projects can use the **same connection** Telegram uses a **bot token authentication model**, not OAuth, so there is no authorization flow or token refresh process. Telegram uses Lovable's gateway architecture for secure credential handling. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. ## How to connect Telegram Workspace **admins** and **owners** can connect Telegram. When a connection is created, Telegram becomes available across all projects in the workspace. ### Prerequisites Before connecting Telegram, make sure you have: * A Telegram account * A Telegram bot and bot token created using [@BotFather](https://t.me/BotFather) * Lovable workspace **admin or owner** role ### Step 1: Create a Telegram bot and get a bot token Telegram bots are created and managed through [@BotFather](https://t.me/BotFather), Telegram's official bot management tool. To create a bot and obtain a token: 1. Open Telegram and search for **@BotFather**, or go to [https://t.me/BotFather](https://t.me/BotFather). 2. Send the command `/newbot`. 3. Follow the prompts: * Choose a display name for your bot * Choose a username that ends in `bot` (for example, `myapp_notify_bot`) 4. BotFather will generate a **bot token** that looks like: ```text theme={null} 123456789:ABCDefghIJKLMnopQRStuvWXYz1234567 ``` 5. Copy the token and store it securely. Your bot token functions like a password. Keep it secure and never expose it publicly. You’ll need it in the next step. See Telegram docs for detailed instructions: [BotFather](https://core.telegram.org/bots/features#botfather) ### Step 2: Connect Telegram to Lovable 1. Open **Connectors** → **App connectors**. 2. Select **Telegram**. 3. Click **Add connection**. 4. Fill in the connection details: * **Display name**: Give the connection a descriptive name (for example, `Telegram Prod`). * **Bot token**: Paste the bot token you received from @BotFather. 5. Click **Create**. Lovable will verify the token and create the connection. Once connected, your Lovable apps can start sending and receiving Telegram messages. ## Limitations The Telegram connector currently does not support: * **Webhooks** for receiving incoming messages. Use `getUpdates` (polling) to receive incoming messages instead. * **Per-user Telegram login** (each end user connecting their own account) To receive incoming messages, your app should periodically request updates from the Telegram Bot API. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to TikTok Source: https://docs.lovable.dev/integrations/tiktok Connect your app to TikTok to read creator profiles, fetch published videos, and build social integrations from your Lovable app. [TikTok](https://www.tiktok.com/) is a short-form video platform with APIs for accessing creator profiles and content. The TikTok connector lets your Lovable app read account profile data, access video metadata, and build creator workflows that rely on TikTok account information. With TikTok, your app can: * Read basic profile data including display name and account ID * Access follower counts, like counts, and video statistics * Read extended profile details such as bio and avatar * Fetch a list of published videos and their metadata The TikTok connector is read-only and connects to a single TikTok account via OAuth. It's a good fit for creator tools, social dashboards, content portfolios, and analytics apps built around a specific TikTok account. ## Common use cases and example apps | **Example app** | **Example prompt** | **Description** | | :-------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Creator analytics dashboard | *Use TikTok and build a dashboard that shows my follower count, total likes, and video performance over time.* | **Surface TikTok account metrics in a focused dashboard.**
The app reads profile stats and video data, displays trends over time, and gives a creator a single place to track growth. | | Video portfolio site | *Use TikTok and build a portfolio page that displays my published TikTok videos with titles and view counts.* | **Showcase a creator's TikTok content on a custom website.**
The app fetches the list of published videos and renders them alongside metadata such as titles, thumbnails, and engagement counts. | | Campaign tracker | *Use TikTok and build a campaign tracker that stores TikTok video metadata for sponsored posts and links them to campaign records.* | **Track campaign content tied to a connected TikTok account.**
The app reads published video metadata, matches videos to campaigns, and keeps reporting data organized in one place. | | Content management tool | *Use TikTok and build a tool that lets me review my published TikTok videos, add internal notes, and tag them by campaign.* | **Build a lightweight content management layer on top of published TikTok videos.**
The app lists videos fetched from TikTok and lets you add custom fields, tags, or notes stored separately. | | Profile sync utility | *Use TikTok and build a utility that syncs my TikTok display name and account identifiers into my CRM records.* | **Keep internal systems aligned with TikTok account details.**
The app reads profile data from the connected TikTok account and writes it to the appropriate CRM fields to reduce manual updates. | ## How to connect TikTok Workspace admins and owners can connect TikTok. You can create multiple TikTok connections using different accounts, which is useful for separating environments or managing multiple creators. When the connection is created, TikTok becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting TikTok, make sure you have: * A TikTok account you want to connect (you can also create one during the OAuth flow) * Lovable workspace **owner** or **admin** role All API requests made through this connector consume TikTok API units according to your TikTok plan. Billing and quota are handled directly by TikTok, not Lovable. ### Set up your TikTok connection Go to **Connectors → App connectors** and select **TikTok**. Click **Add connection**. In **Display name**, name the connection (for example, `My TikTok`). This name is only used inside Lovable to identify the connection. Expand **Advanced settings** to review the permissions your app will request. Default scopes are pre-selected for common use cases. Scopes control what data the connection can access. All four scopes are selected by default. You can remove any optional scope, except **Read basic profile information**, which is required and cannot be removed. | **Scope** | **Description** | | :------------------------------------------------------ | :------------------------------------------ | | Read basic profile information (`user.info.basic`) | Display name and account ID | | Read user stats (`user.info.stats`) | Follower count, like count, and video count | | Read extended profile information (`user.info.profile`) | Bio, avatar, and profile details | | Read published video metadata (`video.list`) | List of published videos and their metadata | For full scope documentation, see [TikTok's API scopes reference](https://developers.tiktok.com/doc/tiktok-api-scopes/). Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [**Who can manage connections**](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. The TikTok authorization window opens, so make sure your browser doesn’t block pop-ups. If it does, Lovable redirects you instead. Sign in to TikTok if prompted, review the requested permissions, and click **Allow**. You’ll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to TikTok (based on configured connection-level access). Your Lovable apps can then start reading TikTok profile data and video content. ## Limitations The TikTok connector is read-only. It cannot: * Upload or publish videos to TikTok * Access private videos or draft content * Read comments, DMs, or notifications * Manage followers or interact with other accounts * Receive TikTok webhooks or real-time events * Support per-end-user TikTok login. Each connection represents a single TikTok account shared across all projects linked to it. If TikTok authorization is revoked from the TikTok side, you'll need to reconnect the integration in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Twilio Source: https://docs.lovable.dev/integrations/twilio Connect your app to Twilio to send SMS and MMS messages, make voice calls, and add phone-based communication flows directly to your Lovable app. [Twilio](https://www.twilio.com/) is a cloud communications platform that lets your app reach users by phone. It works well for apps that need to send real-time text updates, add phone verification, trigger voice calls, or support messaging-based workflows. With Twilio, your app can: * Send and receive SMS and MMS messages * Make and manage voice calls * Support WhatsApp messaging flows * Validate and look up phone numbers Twilio is a good fit when your app needs to communicate with users by phone or text, rather than only through in-app notifications or email. ## Common use cases and example apps | Example app | Example prompt | Description | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **SMS notifications and alerts** | *Build an order tracking app that sends customers a text when their order ships, with a tracking link.* | **Send real-time SMS updates triggered by events in your app.**
The app detects a status change, generates the message, and sends it to the customer automatically. | | **Phone verification flows** | *Build a signup flow that sends users a one-time code by SMS to verify their phone number before creating an account.* | **Add phone-based verification to onboarding or login flows.**
The app sends a one-time code, checks the user's input, and confirms the number before continuing. | | **Appointment reminders** | *Build a booking app that texts customers 24 hours before their appointment and again if the time changes.* | **Send automated reminder messages based on scheduled events in your app.**
The app uses booking data to trigger texts at the right time without manual follow-up. | | **Voice call updates** | *Build a service app that calls customers with a recorded message when their technician is on the way.* | **Trigger outbound voice calls from your app when an important update needs immediate attention.**
The app places the call and delivers a spoken message to the user. | | **WhatsApp support inbox** | *Build a customer support app where users can message the business on WhatsApp and agents can reply from the app.* | **Add WhatsApp as a communication channel in your product.**
The app sends and receives messages through Twilio so conversations can be handled inside your workflow. | | **Phone number validation** | *Build a lead capture form that checks whether a phone number is valid before saving it to the database.* | **Validate and format phone numbers before storing or using them.**
The app checks the number through Twilio so your workflows start with cleaner contact data. | ## How to connect Twilio Workspace **admins** and **owners** can connect Twilio. You can create multiple Twilio connections using different API keys, for example, to separate development and production environments or to manage different Twilio accounts. When a connection is created, Twilio becomes available across all projects in the workspace. ### Prerequisites Before connecting Twilio, make sure you have: * A Twilio account * A Twilio phone number if your use case requires sending SMS, MMS, or making calls * A **Standard** Twilio API key * Lovable workspace owner or admin role All SMS, MMS, voice, WhatsApp, and other Twilio usage through this connector is billed directly by Twilio based on your Twilio account and plan. Billing is handled by Twilio, not Lovable. ### Step 1: Create a Twilio API key Twilio uses an **API Key SID** and **Secret** instead of a single token. This is more secure than using your main Auth Token because API keys can be revoked independently. To create a Twilio Standard API Key: 1. Go to the [Twilio Console](https://console.twilio.com/) and sign in. 2. Navigate to **Account → API keys & tokens**. 3. Click **Create API key**. 4. Enter a **Friendly name**, for example `Lovable integration`. 5. Choose the **Region** for the key: * **United States (US1)**: default for most accounts * **Ireland (IE1)** * **Australia (AU1)** 6. Leave **Key type** set to **Standard**. 7. Click **Create API key**. 8. Copy both the **API Key SID** (starts with `SK`) and the **Secret**. The Secret is shown only once, so store it securely before leaving the page. Your API Key Secret works like a password. Keep it secure and never share it publicly. You'll need it in the next step. Before sending production traffic, treat this as an unmanaged connector and secure your Twilio credentials. Keep your `API Key Secret` private, enable Twilio **SMS Pumping Protection**, and review **SMS Geo Permissions** so only intended destination countries are enabled. You will also need your **Account SID** (starts with `AC`), which is available in the Twilio Console. Twilio API credentials are region-specific, so the region you select when creating the key should match the region you use when setting up the Lovable connection. See Twilio documentation for detailed instructions: [Create API keys in Twilio console](https://www.twilio.com/docs/iam/api-keys/keys-in-console) ### Step 2: Connect Twilio to Lovable 1. Open **Connectors** → **App connectors** and select **Twilio**. 2. Click **Add connection**. 3. In **Display name**, enter a name for the connection, for example `Twilio Prod`. 4. In **Region**, select the same Twilio region used for the API key: * **United States (US1)** * **Ireland (IE1)** * **Australia (AU1)** 5. In **Account SID**, enter your Twilio Account SID (starts with `AC`). 6. In **Standard API Key SID**, enter the API Key SID you created (starts with `SK`). 7. In **API Key Secret**, enter the Secret shown when you created the key. 8. Click **Create**. When connected, your Lovable apps can use Twilio to send messages and power phone-based communication flows. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Twitch Source: https://docs.lovable.dev/integrations/twitch Connect your app to Twitch to build custom stream overlays, display live stream data, track channel activity, and create tools for creators and communities directly from your Lovable app. [Twitch](https://www.twitch.tv/) is a live streaming platform focused on gaming, creative content, and real-time community interaction. The Twitch connector lets your Lovable app access Twitch API so you can power stream overlays, dashboards, and community tools that react to what is happening on a channel. With Twitch, your app can: * Display live chat from a Twitch channel * Show follower and subscriber counts * Track custom goals such as follower or subscription milestones * Look up stream status, viewer counts, and channel metadata * Retrieve clips, schedules, and channel information * Send chat messages to a Twitch channel * Search channels, games, and categories Twitch is a good fit when your app lives alongside a stream. Examples include overlays, moderation tools, event dashboards, and creator analytics apps. ## Common use cases and example apps | Example app | Example prompt | Description | | --------------------------------------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Custom stream overlay** | *Build a stream overlay that shows my live chat, latest follower, and current sub goal in my brand colors.* | **Replace generic overlay tools with a fully custom overlay.**
The app displays chat using Twitch's IRC connection and fetches follower and subscription data through the Twitch API to render a branded overlay for the stream that can be added as a browser source in streaming software like OBS Studio (Open Broadcaster Software. | | **Subscriber or follower goal tracker** | *Build an overlay widget that shows a progress bar toward my 1000 follower goal.* | **Display milestone progress live on stream.**
The app fetches follower or subscriber counts from Twitch and renders a progress bar that updates as the numbers change. | | **Live chat overlay** | *Build a live chat overlay that shows recent messages from my Twitch channel.* | **Display chat messages directly in a stream overlay.**
The app connects to Twitch chat using the IRC WebSocket endpoint and renders incoming messages in real time. | | **Event broadcast overlay** | *Build a tournament overlay where moderators can update scores and match info during the broadcast.* | **Power overlays for live events or tournaments.**
Moderators update match information through a control panel and the overlay reflects the updates instantly for viewers. | | **Multi-channel stream tracker** | *Build a dashboard that shows which channels from my list are currently live.* | **Monitor a list of streamers and see who is live right now.**
The app checks stream status across multiple channels and displays viewer counts and stream titles. | | **Clip discovery browser** | *Build an app where I can search for a Twitch channel and browse their top clips.* | **Explore highlights from Twitch channels.**
The app retrieves clips from the Twitch API and presents them in a searchable interface. | | **Moderator dashboard** | *Build a moderation panel that lists followers and lets moderators send chat announcements.* | **Give moderators a structured interface for managing community activity.**
The app retrieves follower data and lets moderators post messages to chat directly from the dashboard. | ## How Twitch connections work Twitch uses OAuth 2.0 for authentication. When you connect Twitch, you authorize Lovable to access Twitch on behalf of the authenticated account. Twitch uses Lovable's gateway architecture for secure OAuth handling and automatic token refresh. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors) for details on authentication and usage limits. Each Twitch connection is tied to one Twitch account. You can create multiple connections if needed. For example, you might connect separate accounts for development, production, or different creators. ## How to connect Twitch Workspace **admins** and **owners** can connect Twitch. When the connection is created, Twitch becomes available across all projects in the workspace. ### Prerequisites Before connecting Twitch, make sure you have: * A Twitch account * A Lovable workspace admin or owner role ### Step 1: Choose the account to connect Your connection uses a Twitch account directly. No developer application or API key is required. Make sure the connected account has the permissions required for your use case. For example: * To read follower data, the account must have moderator access for the channel. * To send chat messages, the account must have permission to post in the channel. * To access subscription data, the connected account must be the channel owner. For most overlay setups, connecting the streamer's own account provides the broadest access. ### Step 2: Connect Twitch to Lovable 1. Open **Connectors** → **App connectors** and select **Twitch**. 2. Click **Add connection**. 3. In **Display name**, enter a name for the connection. For example `Twitch Production`. 4. **Configure scopes (optional)** Expand **Advanced settings** to configure the Twitch API permissions your app needs. Default scopes include: * `user:read:email` — View the account's email * `channel:read:subscriptions` — View channel subscription data * `moderator:read:followers` — View follower data for moderated channels * `user:write:chat` — Send messages to Twitch chat Additional scopes are available for features such as clips management, predictions, polls, analytics, and channel points. Only enable the scopes your app needs. You can update scopes later by editing the connection and selecting **Reconnect**. For the full list of scopes, see the [Twitch OAuth scope reference](https://dev.twitch.tv/docs/authentication/scopes/). 5. Click **Connect**. A Twitch authorization window will open. Make sure pop-ups are allowed. 6. Log in to Twitch, review the requested permissions, and click **Authorize**. Once authorization is complete, the connection will appear in Lovable and your apps can begin using Twitch data. ## Limitations The Twitch connector currently cannot: * **Read Twitch chat in real time through the gateway**\ Twitch chat uses IRC over WebSocket, which cannot be proxied through the Lovable gateway. To read chat messages, your app must connect directly to Twitch's chat endpoint: `wss://irc-ws.chat.twitch.tv` Reading public chat does not require authentication. Sending chat messages through the Twitch API does require authentication. * **Receive EventSub webhooks**\ Incoming Twitch events such as stream start notifications or follow events are not currently supported. * **Support per-user Twitch login**\ Each connection authenticates a single Twitch account. End users of your app cannot connect their own Twitch accounts through this connector. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Wave Source: https://docs.lovable.dev/integrations/wave Connect your app to Wave, an accounting and invoicing platform, to build apps that work with customers, products, invoices, estimates, and business accounting data. [Wave](https://www.waveapps.com/) is an accounting and invoicing platform for small businesses. The Wave connector lets your Lovable app read and manage business, customer, product, invoice, estimate, vendor, account, sales tax, and transaction data through Wave's GraphQL API. With Wave, your app can: * List businesses and read accounting metadata * Create and update customers, products, invoices, and estimates * Query accounts, sales taxes, vendors, and transaction data * Build small-business finance workflows on top of Wave data The Wave connector connects to a single Wave account via OAuth. It's a good fit for small-business dashboards, invoice workflows, customer management tools, and finance operations apps tied to a connected Wave business. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Small-business finance dashboard | *Use Wave and build a dashboard that shows my businesses, customers, unpaid invoices, and recent transactions.* | **Track Wave business activity in one workspace.**
The app reads accounting metadata, invoices, customers, and transactions so a business owner can monitor work without opening Wave. | | Invoice management app | *Use Wave and build an app where I can list invoices, filter by customer, and create draft invoices for new work.* | **Manage invoice workflows from a custom interface.**
The app works with Wave invoice and customer data, then stores internal workflow notes separately in your Lovable app. | | Customer account portal | *Use Wave and build a customer portal that shows invoice history and customer details for each account manager.* | **Give teams a focused view of customer billing data.**
The app reads Wave customers and invoices, then organizes them around your internal account management workflow. | | Product and service catalog | *Use Wave and build a catalog manager that lists my products and services and lets me update descriptions and prices.* | **Keep Wave products and services easier to review.**
The app reads and updates product records so your team can maintain billing items from a tailored interface. | | Estimate tracking tool | *Use Wave and build an estimate tracker that lists estimates, groups them by status, and helps me follow up with customers.* | **Turn Wave estimates into a sales follow-up workflow.**
The app reads estimate and customer data, then adds reminders, filters, and internal status tracking. | | Vendor and expense overview | *Use Wave and build an app that shows vendors, accounts, and recent transactions for my finance team.* | **Surface Wave accounting data for operations reviews.**
The app queries vendors, accounts, and transaction data so finance teams can review activity in a purpose-built view. | ## How to connect Wave Workspace **admins** and **owners** can connect Wave when the connector is available in their workspace. Connector availability follows workspace app connector settings: enabled by default on Free, Pro, and Business plans, and disabled by default on Enterprise plans unless an admin enables it. You can create multiple Wave connections using different Wave accounts, which is useful for separating businesses, environments, or client accounts. When the connection is created, Wave becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Wave, make sure you have: * A Wave account you want to connect * Access to the Wave business data your app needs * Lovable workspace **owner** or **admin** role All API requests made through this connector count against the limits and availability of your Wave account. Billing and quota are handled directly by Wave, not Lovable. ### Set up your Wave connection Go to **Connectors → App connectors** and select **Wave**. Click **Add connection**. In **Display name**, name the connection (for example, `Wave Main Business`). This name is only used inside Lovable to identify the connection. Expand **Advanced settings** to review the permissions your app requests. Default scopes are pre-selected for common Wave use cases. | Scope | What it allows | Default | | :------------------------------------------ | :-------------------------------------------------- | :------- | | User: read (`user:read`) | Read the authorized Wave user's profile | Required | | Business: read (`business:read`) | List and read Wave businesses available to the user | Required | | Accounts: full access (`account:*`) | Read and manage accounting accounts | On | | Customers: full access (`customer:*`) | Create, read, and update customers | On | | Estimates: full access (`estimate:*`) | Create, read, update, and send estimates | On | | Invoices: full access (`invoice:*`) | Create, read, update, and send invoices | On | | Products: full access (`product:*`) | Create, read, and update products and services | On | | Sales taxes: full access (`sales_tax:*`) | Create, read, and update sales taxes | On | | Transactions: full access (`transaction:*`) | Write and manage money transactions | On | | Vendors: full access (`vendor:*`) | Create, read, and update vendors | On | For full API documentation, see [Wave's API reference](https://developer.waveapps.com/hc/en-us/articles/360019968212-API-Reference). Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Connect**. The Wave authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to Wave if prompted, review the requested permissions, and click **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to Wave (based on configured connection-level access). Your Lovable apps can then call Wave through the connector gateway and work with the Wave resources allowed by the selected scopes. ## Limitations The Wave connector cannot: * Access Wave resources outside the selected OAuth scopes * Access Wave businesses that the connected Wave account cannot access * Receive Wave webhooks or event notifications * Bypass Wave API limits, account availability, or plan restrictions * Support per-end-user Wave login. Each connection represents a single Wave account shared across all projects linked to it. If Wave authorization is revoked from the Wave side, you'll need to reconnect the integration in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Wix Source: https://docs.lovable.dev/integrations/wix Connect your app to Wix, a website and business platform, to read and manage Wix sites, ecommerce, bookings, CRM, and CMS resources. [Wix](https://www.wix.com/) is a website and business platform for managing sites, stores, bookings, customer data, and content. The Wix connector lets your Lovable app call Wix APIs with your Wix API key and account ID. It's designed for apps that need to work with Wix site and business data from a Lovable project. With Wix, your app can: * List and inspect Wix sites available to the connected account * Read and manage ecommerce, bookings, CRM, CMS, and business resources through Wix APIs * Build dashboards and workflows around Wix account or site data * Run server-side admin operations through the connector gateway Wix is a good fit when you already manage sites or business operations in Wix and want a Lovable app to use that account data. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Wix site dashboard | *Use Wix and build a dashboard that lists all sites in my Wix account and shows key status details.* | **Show Wix account data in one internal view.**
The app lists sites available to the connected account and helps operators choose the right site before fetching site-level data. | | Ecommerce order operations | *Use Wix and build an admin page for reviewing recent store orders and customer details.* | **Manage Wix store operations from a Lovable app.**
The app calls Wix ecommerce APIs so your team can review order and customer information in a custom workflow. | | Booking management panel | *Use Wix and build a booking operations dashboard for upcoming appointments and customer records.* | **Bring Wix booking data into a workflow app.**
The app reads bookings-related resources and presents schedule and customer context for your operations team. | | CRM customer lookup | *Use Wix and build a customer lookup tool that searches CRM contacts and displays recent activity.* | **Search Wix CRM data from an internal tool.**
The app retrieves contact records and related business data for support, sales, or account management workflows. | | CMS content browser | *Use Wix and build a content browser that lets editors review CMS collections for a selected site.* | **Review Wix CMS data outside the Wix dashboard.**
The app uses the selected site context to fetch content resources and present them in a focused editorial view. | | Multi-site operations app | *Use Wix and build an operations tool that starts by asking which Wix site to manage, then shows relevant store and site details.* | **Support accounts with multiple Wix sites.**
The app queries the connected account's sites first, then uses the selected site for site-level API calls. | ## How to connect Wix Workspace **admins** and **owners** can connect Wix. You can create multiple Wix connections using different API keys and account IDs, which is useful for separating environments, managing multiple Wix accounts, or limiting access by workspace connection. When the connection is created, Wix becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Wix, make sure you have: * A Wix account * A Wix API key from the API Keys Manager * The Wix account ID associated with that API key * Lovable workspace owner or admin role All API requests made through this connector use your Wix API key. Wix API usage, quotas, and billing are handled directly by Wix, not Lovable. ### Step 1: Get a Wix API key and account ID A Wix API key and account ID let your Lovable app authenticate with Wix APIs through the connector gateway. To get the values you need: Sign in to [Wix](https://www.wix.com/) with the account you want to connect. Go to the [Wix API Keys Manager](https://manage.wix.com/account/api-keys). Create a new API key for Lovable, or copy an existing key you want this connection to use. Give new keys a descriptive name, for example `Lovable integration`. Copy the account ID shown in the API Keys Manager. You need it when connecting Wix in Lovable. Your Wix API key functions like a password. Keep it secure and never share it publicly. You need it in the next step. See Wix documentation for more: [Wix API keys](https://dev.wix.com/docs/api-reference/articles/authentication/api-keys/about-api-keys). ### Step 2: Connect Wix to Lovable You can create multiple connections using different API keys and account IDs. Go to **Connectors → App connectors** and select **Wix**. Click **Add connection**. Enter the connection details: * **Display name**: name the connection, for example `Wix Prod`. This name is only used inside Lovable to identify the connection. * **Account ID**: paste the Wix account ID from the API Keys Manager. * **API key**: paste your Wix API key. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to it. Your Lovable apps can then read and manage Wix business data through Wix APIs. ## Working with account and site-level APIs Wix has account-level and site-level API calls. If your app does not know the Wix site ID yet, ask Lovable to list the sites available to the connected account first. Your app can then let someone choose a site before making site-level requests. The connector gateway adds Wix authentication headers from the stored connection. Your app should use the connection secret that Lovable syncs to the project, not the Wix dashboard API key, when it calls the gateway. ## Limitations The Wix connector cannot: * Create or rotate Wix API keys for you. To rotate credentials, create a new key in Wix and update the Lovable connection. * Expose Wix API keys to browser code. Calls should go through server-side code and the connector gateway. * Choose a Wix site automatically when an account has multiple sites. Ask the user to select the site your app should use. * Support per-end-user Wix login. Each connection represents one Wix account, API key, and account ID shared across projects linked to it. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Scan your projects for vulnerabilities with Wiz Source: https://docs.lovable.dev/integrations/wiz Automatically scan your Lovable projects for vulnerabilities and code-security issues using Wiz to catch known CVEs and risky code patterns before you ship. ## What is Wiz security scanning [Wiz](https://www.wiz.io/) brings automated security scanning to Lovable. When connected, Wiz scans your project for vulnerable dependencies and risky code patterns and surfaces findings directly in your project's [Security view](/features/security-view). Wiz scanning combines two analyses: * **Software composition analysis (SCA)**\ Examines your project's dependency tree (package lockfiles, installed libraries, and transitive dependencies) to identify packages with known CVEs * **Static application security testing (SAST)**\ Analyzes your source code for security issues like unsafe patterns, hardcoded secrets, and risky API usage For each finding, Wiz reports the severity, the affected location, remediation guidance, and a link to the full details in Wiz. This is complementary to Lovable's other [built-in security scans](/features/security): * **Basic scan** checks row-level security policies, database configuration, and npm dependencies for common issues and known vulnerabilities. * **Deep scan** uses AI to analyze your code for vulnerabilities like exposed secrets, open endpoints, and input validation issues. * **Wiz scanning** adds enterprise-grade vulnerability and code-security detection backed by Wiz's continuously updated security database. Wiz scanning runs as part of Lovable's standard security scan suite. When you trigger a security scan, Wiz runs alongside the other scanners automatically. ## When to use Wiz scanning * **Before launching or deploying**\ Run a scan to check for vulnerable dependencies and risky code patterns before going live. * **After adding or updating dependencies**\ Re-scan after installing new packages or updating existing ones to check for newly introduced vulnerabilities. * **As an ongoing practice**\ Wiz scans run automatically as part of the security scan suite, so connected projects are continuously checked as new vulnerabilities are disclosed. * **For compliance and security posture**\ Use Wiz scanning alongside other security scanners to maintain a comprehensive view of your project's security status. ## How Wiz scans your project When a security scan runs, Lovable mounts your project code into a secure sandbox environment and runs the Wiz CLI scanner against it. The scanner examines your project's **software bill of materials (SBOM)** and source files, and checks both dependencies and code against Wiz's security database. Findings are classified by severity: | Wiz severity | Security view level | | :--------------- | :------------------ | | Critical | Error | | High | Warning | | Medium and lower | Info | Vulnerability and supply-chain findings are aggregated by severity into one consolidated entry per level (for example, *"Critical vulnerabilities in application dependencies"*), listing each affected package and its location. SAST findings are shown individually per file and line. Each finding includes: * The affected package or file * The location (file path, and line numbers for SAST findings) * A description and remediation guidance from Wiz * A direct link to the full details in Wiz Findings appear in the **Security view** alongside results from other scanners, in a section attributed to your Wiz connection. Each Wiz finding is labeled with the Wiz logo so you can identify its source. ## Prerequisites * A **Wiz account** with permission to add deployments * **Your Wiz Token URL**: The OAuth authentication endpoint for your tenant (either Cognito or Auth0). If you’re unsure which to use, try Cognito first. Your Wiz administrator can confirm the correct endpoint. * **Lovable workspace owner or admin role** to connect Wiz All scans use your Wiz deployment's permissions and quotas. Usage is handled directly by Wiz, not Lovable. ## How to connect Wiz A workspace admin or owner connects the Lovable workspace to Wiz using a Wiz deployment. Only one Wiz connection can be added per workspace. ### Step 1: Create a Lovable integration deployment in Wiz A Lovable integration deployment lets Lovable authenticate with Wiz to run scans. Go to the [Wiz portal](https://app.wiz.io/). * Go to [Create a new Lovable integration deployment](https://app.wiz.io/settings/deployments/integrations/new/lovable) * Give the deployment a descriptive name (for example, `Lovable`) and choose its scope. * Click **Add integration**. Copy the **Client ID** and **Client Secret**. Store them somewhere secure. The secret is only shown once. Your client secret functions like a password. Keep it secure and never share it publicly. ### Step 2: Connect Wiz to Lovable Go to **Connectors → App connectors** and select **Wiz**. Click **Add connection**. * **Display name**: Name the connection, for example `Wiz`. * **Client ID**: From your Lovable integration deployment in Wiz. * **Client Secret**: From your Lovable integration deployment in Wiz. * **Advanced settings → Token URL**: Lovable defaults to **Cognito** (`https://auth.app.wiz.io/oauth/token`), which is correct for most tenants. If your Wiz tenant uses **Auth0**, switch the Token URL to `https://auth.wiz.io/oauth/token`. Your Wiz administrator can confirm which to use. * **Advanced settings → CI/CD scan policies** (optional): enter a comma-separated list of Wiz CI/CD policy names to run during scans, for example `Default vulnerabilities policy, Default IaC policy`. Leave it blank to run your Wiz tenant's default policies. If a policy name cannot be found, the scan shows a **Wiz scan failed** finding in the project's Security view. You can change these policies later by editing the connection. * **Who can access this connection**: keep access limited to specific people or invite the entire workspace. See [**Who can manage connections**](/integrations/introduction#who-can-manage-connections) for more information. To enable security scanning for the entire workspace, make sure to invite the entire workspace. Click **Connect**. When connected, Wiz scanning is included automatically the next time a security scan runs on any project with access to the connection. ## How to view and fix findings Wiz findings appear in the **Security view** of each project, alongside findings from other scanners. Open your project and go to the **Security** tab. Wiz findings are listed in their own section. Each Wiz finding shows a **Wiz** badge so you can identify its source. Click a finding to expand it and see the full details: affected package or file, location, description, remediation, and a link to the report in Wiz. Update the affected dependency or code to follow the remediation guidance. Run a new scan to verify the issue is resolved. Findings are marked as **(outdated)** when your project has new commits since the last scan. ## Manage the Wiz connection Workspace admins and owners can manage the Wiz connection from **Connectors → App connectors → Wiz**. * **Update credentials**\ Open the connection to edit the Client ID, Client Secret, or Token URL. Useful when rotating deployment credentials. * **Delete**\ This permanently removes the workspace connection and its credentials. This cannot be undone. Wiz scanning will stop across all projects in the workspace, and existing Wiz findings will no longer appear in the Security view. # Connect your app to WooCommerce Source: https://docs.lovable.dev/integrations/woocommerce Connect your app to WooCommerce, an ecommerce plugin for WordPress, to read and manage store products, orders, customers, coupons, and reports. [WooCommerce](https://woocommerce.com/) is an open-source ecommerce plugin for WordPress that lets you run an online store on infrastructure you control. The WooCommerce connector lets your Lovable app read and manage store data through the WooCommerce REST API. It's designed for storefront dashboards, internal operations tools, product management apps, and customer service workflows backed by your WooCommerce store. With WooCommerce, your app can: * List and manage products, variations, categories, and inventory * Read and update orders, refunds, coupons, and customer records * Build dashboards around revenue, fulfillment, products, and customers * Create internal storefront admin tools powered by WooCommerce REST APIs * Automate store workflows that use your WooCommerce data The WooCommerce connector uses a REST API consumer key and secret from your WooCommerce store. It's a good fit when your store runs on WooCommerce and your Lovable app needs secure server-side access to store operations. ## Common use cases and example apps | Example app | Example prompt | Description | | :----------------------------- | :----------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Store operations dashboard** | *Use WooCommerce and build a dashboard that shows today's orders, revenue, low-stock products, and fulfillment status.* | **Give operators one place to monitor store health.**
The app reads orders, products, and reports so the team can track daily performance and act on issues. | | **Inventory management app** | *Use WooCommerce and build an inventory app that lists products, filters by stock status, and updates stock quantities.* | **Keep product inventory current from a custom interface.**
The app fetches products and variations, highlights low-stock items, and updates inventory through WooCommerce. | | **Customer service console** | *Use WooCommerce and build a support console where agents can search customers, view orders, and issue refunds.* | **Help support teams answer store questions faster.**
The app searches customer and order records, shows purchase history, and uses permitted WooCommerce actions for order support. | | **Coupon campaign manager** | *Use WooCommerce and build a coupon manager for creating, listing, and tracking discount codes.* | **Manage promotions without opening WordPress admin.**
The app reads and updates coupons, shows active campaigns, and helps operators review usage. | | **Product catalog editor** | *Use WooCommerce and build a product catalog editor for updating product descriptions, prices, categories, and images.* | **Let teams manage catalog details from a tailored workflow.**
The app reads products and sends updates through WooCommerce based on the permissions on your API key. | | **Fulfillment tracker** | *Use WooCommerce and build a fulfillment tracker that groups open orders by status and flags delayed shipments.* | **Turn order data into a fulfillment queue.**
The app reads order status, groups work by priority, and gives staff a focused view of orders that need attention. | | **Sales reporting app** | *Use WooCommerce and build a sales report that compares products, customers, and coupon performance over time.* | **Create store analytics from WooCommerce data.**
The app reads reports, orders, and coupons to show trends and exportable summaries. | ## How to connect WooCommerce Workspace **admins** and **owners** can connect WooCommerce. You can create multiple WooCommerce connections using different REST API keys, which is useful for separating environments (for example, development and production), connecting multiple stores, or using keys with different permissions. When the connection is created, WooCommerce becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting WooCommerce, make sure you have: * A WooCommerce store with HTTPS enabled * A WordPress admin account that can manage WooCommerce settings * Non-plain WordPress permalinks enabled for REST API routes * A WooCommerce REST API consumer key and consumer secret * Lovable workspace **owner** or **admin** role All API requests made through this connector run against your WooCommerce store. Hosting, plugin, and WooCommerce-related costs are handled outside Lovable. ### Step 1: Get a WooCommerce REST API key A WooCommerce REST API key lets your Lovable app authenticate with your store. The key permissions you choose in WooCommerce control what the connection can do. To create a WooCommerce REST API key: Sign in to your WordPress admin dashboard for the store you want to connect. Go to **WooCommerce → Settings → Advanced → REST API**. Click **Add key**. Enter a description, for example `Lovable integration`, and choose the WordPress user the key belongs to. Choose the permissions your app needs: * **Read**: use this for dashboards, reports, search, and other read-only apps. * **Read/Write**: use this when your app needs to create or update products, orders, coupons, customers, refunds, or inventory. Click **Generate API key**, then copy the **Consumer key** and **Consumer secret**. WooCommerce only shows the consumer secret once. Your consumer key and consumer secret function like a password. Keep them secure and never share them publicly. You'll need them in the next step. See WooCommerce documentation for detailed instructions: [WooCommerce REST API key setup](https://woocommerce.com/document/woocommerce-rest-api/). ### Step 2: Connect WooCommerce to Lovable You can create multiple connections using different WooCommerce REST API keys. Go to **Connectors → App connectors** and select **WooCommerce**. Click **Add connection**. * **Display name**: name the connection, for example `WooCommerce Prod`. * **Store URL**: enter the HTTPS URL of your WooCommerce store, for example `https://store.example.com`. * **Consumer key**: paste the WooCommerce REST API consumer key. It starts with `ck_`. * **Consumer secret**: paste the WooCommerce REST API consumer secret. It starts with `cs_`. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to WooCommerce (based on configured connection-level access). Your Lovable apps can then read and manage WooCommerce data based on the REST API key permissions. ## Working with WooCommerce REST API permissions WooCommerce controls access through the permissions on the REST API key you create. If your app only needs dashboards, reports, product lists, or customer lookup, use a **Read** key. If your app needs to create or update store data, use a **Read/Write** key. The connector verifies credentials by listing products from your store. If verification fails with a route error, check that WooCommerce REST API routes work on your store and that WordPress permalinks are not set to **Plain**. ## Limitations The WooCommerce connector cannot: * Create WooCommerce REST API keys or change their permissions for you. Configure keys in WordPress admin first. * Bypass the permissions on the connected REST API key. * Configure WordPress permalinks, hosting, SSL, plugins, or WooCommerce settings. * Call general WordPress APIs or WooCommerce endpoints outside the connected store's `/wp-json/wc/v3` REST API path. * Refresh or rotate consumer keys automatically. To rotate credentials, generate a new key in WooCommerce and update the Lovable connection. * Support per-end-user WooCommerce login. Each connection represents a single WooCommerce store account shared across all projects linked to it. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to WordPress (self-hosted) Source: https://docs.lovable.dev/integrations/wordpress Connect your app to a self-hosted WordPress site to read and manage posts, pages, media, and users through the WordPress REST API. [WordPress](https://wordpress.org/) is open-source CMS software you host on your own domain or server. The **WordPress (self-hosted)** connector lets your Lovable app read and manage posts, pages, media, and users on that site through the WordPress REST API. It's designed for headless CMS apps, editorial dashboards, and content workflows backed by a WordPress install you control. With WordPress (self-hosted), your app can: * List and display posts, pages, and custom post types * Upload and manage media library assets * Read site settings, categories, tags, and user profiles * Build headless CMS experiences on self-hosted WordPress This connector is for **self-hosted WordPress** sites. For **WordPress.com** hosted sites, use the [WordPress.com](/integrations/wordpress-com) connector instead. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Marketing and landing pages** | *Use WordPress (self-hosted) and build a marketing site where the homepage and key sections load titles, body, and images from my WordPress site.* | **Ship pages powered by CMS content.**
The app fetches posts or pages from WordPress and renders them as components so editors can update copy and media without changing app code. | | **Blog and editorial sites** | *Use WordPress (self-hosted) and build a blog that lists recent posts and shows each post's content, featured image, and excerpt.* | **Run a blog backed by WordPress.**
The app loads post lists and detail views from the API and reflects new publishes from the WordPress dashboard. | | **Resource or help center** | *Use WordPress (self-hosted) and build a help center where each article is a WordPress page with search and categories.* | **Centralize articles in WordPress.**
The app queries pages or posts and builds navigation and article views from your CMS structure. | | **Media library browser** | *Use WordPress (self-hosted) and build an admin page that lists media from my WordPress library with search and upload.* | **Manage media from a custom interface.**
The app reads and uploads media through the WordPress REST API based on the connected user's permissions. | | **Editorial publish workflow** | *Use WordPress (self-hosted) and build a form that creates a draft post on my WordPress site when someone submits it.* | **Turn submissions into drafts.**
The app creates or updates content through the API so editors finish work in WordPress. | | **Content dashboard** | *Use WordPress (self-hosted) and build a dashboard that shows recent posts, categories, and tags from my site.* | **Give operators a focused view of site content.**
The app reads posts, categories, and tags and presents them in one place outside the WordPress admin. | ## How to connect WordPress (self-hosted) Workspace **admins** and **owners** can connect WordPress (self-hosted). You can create multiple WordPress connections using different sites or Application Passwords, which is useful for separating environments (for example, staging and production) or connecting multiple self-hosted sites. When the connection is created, WordPress (self-hosted) becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting WordPress (self-hosted), make sure you have: * A self-hosted WordPress site with HTTPS enabled * WordPress 5.6 or later (Application Passwords require this version) * Non-plain WordPress permalinks enabled for REST API routes * A WordPress user account with the permissions your app needs * A WordPress Application Password for that user * Lovable workspace **owner** or **admin** role All API requests made through this connector run against your WordPress site. Hosting, plugins, and site-related costs are handled outside Lovable. ### Step 1: Get a WordPress Application Password A **WordPress Application Password** lets your Lovable app authenticate with the WordPress REST API using HTTP Basic auth. The connected WordPress user's role controls what the connection can read or change. To create a WordPress Application Password: Sign in to the WordPress admin for the site you want to connect. Go to **Users → Profile** if you are creating a password for your own account. To create a password for another user, go to **Users → All Users**, open that user, and edit their profile. Scroll to **Application Passwords**. Enter a name for the application, for example `Lovable integration`, then click **Add New Application Password**. Copy the generated password and store it securely. WordPress shows it once. You can paste it with or without spaces. Note the HTTPS URL of your WordPress site (for example, `https://blog.example.com`) and the WordPress username for the account you used. Your Application Password functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See WordPress documentation for more: [Application Passwords](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/) and the [WordPress REST API handbook](https://developer.wordpress.org/rest-api/). ### Step 2: Connect WordPress (self-hosted) to Lovable You can create multiple connections using different sites or Application Passwords. Go to **Connectors → App connectors** and select **WordPress (self-hosted)**. Click **Add connection**. 1. **Display name**: name the connection, for example `WordPress Prod`. 2. **Site URL**: enter the HTTPS URL of your WordPress site, for example `https://blog.example.com`. You can enter the site root or a REST discovery URL such as `https://blog.example.com/wp-json`. 3. **Username**: enter the WordPress username for the Application Password. 4. **Application password**: paste the Application Password you generated in WordPress. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. When connected, anyone building in a project can ask Lovable in chat to link their project to WordPress (self-hosted) (based on configured connection-level access). Your Lovable apps can then read and manage WordPress content based on the connected user's permissions. ## Working with WordPress permalinks and REST API routes WordPress REST API routes require permalinks that are not set to **Plain**. If verification fails with a route error such as `rest_no_route`, check that pretty permalinks are enabled under **Settings → Permalinks** in WordPress admin. Lovable accepts your site root URL or a REST discovery URL and connects to the WordPress REST API v2 path (`/wp-json/wp/v2`). Your site must use HTTPS in the **Site URL** field. The connector verifies credentials by calling the WordPress `users/me` endpoint. If verification fails, confirm the username and Application Password match, the user still exists, and the password has not been revoked in WordPress. ## Limitations The WordPress (self-hosted) connector cannot: * Connect to **WordPress.com** hosted sites. Use the [WordPress.com](/integrations/wordpress-com) connector for those sites. * Create Application Passwords or change WordPress user roles for you. Configure these in WordPress admin first. * Bypass the permissions of the connected WordPress user account. * Configure WordPress permalinks, hosting, SSL, plugins, or site settings for you. * Call WooCommerce store APIs. Use the [WooCommerce](/integrations/woocommerce) connector for store operations. * Refresh or rotate Application Passwords automatically. To rotate credentials, create a new Application Password in WordPress and update the Lovable connection. * Support per-end-user WordPress login. Each connection represents a single WordPress account shared across all projects linked to it. If an Application Password is revoked in WordPress, update or recreate the connection in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to WordPress.com Source: https://docs.lovable.dev/integrations/wordpress-com Use WordPress.com as a headless CMS with Lovable: fetch posts, pages, and media for your app’s UI, and build workflows that publish or update content through a secure OAuth connection. [WordPress.com](https://wordpress.com/) can work like a **headless CMS**: editors manage posts, pages, and media in WordPress, while your **Lovable app** fetches that content over the API and decides how it looks and behaves. The **WordPress** app connector lets your app use **WordPress.com's APIs** on your behalf after you sign in with a WordPress.com account. With WordPress connected, your app can: * **Load content from WordPress** — list and read posts, pages, and related fields your account can access * **Build dynamic pages and layouts** driven by CMS content instead of hard-coding copy in the repo * **Show blogs, marketing sections, and resource pages** that stay up to date when editors publish in WordPress * **Combine WordPress content with the rest of your app** — for example, sync or display selected posts alongside your own data * **Automate publishing workflows** — for example, create or update drafts when you describe that behavior in chat (within what the API allows for your site) The integration is built for **WordPress.com**, not for self-hosted WordPress. For self-hosted sites, see the [WordPress integration](/integrations/wordpress). ## Common use cases & example apps | Example app | Example prompt | Description | | :----------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Marketing and landing pages** | *Use WordPress and build a marketing site where the homepage and key sections load titles, body, and images from my WordPress site.* | **Ship pages powered by CMS content.**
The app fetches posts or pages from WordPress and renders them as components so editors can update copy and media without changing app code. | | **Blog and editorial sites** | *Use WordPress and build a blog that lists recent posts and shows each post’s content, featured image, and excerpt.* | **Run a blog backed by WordPress.**
The app loads post lists and detail views from the API and reflects new publishes from the WordPress dashboard. | | **Resource or help center** | *Use WordPress and build a help center where each article is a WordPress page with search and categories.* | **Centralize articles in WordPress.**
The app queries pages or posts and builds navigation and article views from your CMS structure. | | **Product or listing-style content** | *Use WordPress and build a catalog-style page that shows items I maintain as posts (or custom content) with filters.* | **Present structured listings from WordPress.**
The app reads entries and fields exposed by the API and renders filters and cards based on your content model. | | **Event and announcement pages** | *Use WordPress and build a page that loads upcoming events from WordPress and sorts them by date.* | **Highlight time-based content.**
The app fetches posts or pages that represent events and orders them using dates you store in WordPress. | | **Editorial or publish workflows** | *When I submit this form, create a draft post on WordPress with the title and body I provide.* | **Turn submissions into drafts.**
The app creates or updates content through the API so editors finish work in WordPress. | Exact capabilities depend on **what you ask Lovable to build**, **which sites your WordPress.com user can access**, and **the permissions you approve** when connecting. ## How WordPress connections work * One connection is tied to the **WordPress.com user** who completes sign-in. * That user's **visible sites and allowed actions** follow WordPress.com's rules and the **scopes** granted at authorization. * You can create **multiple connections** (for example, separate accounts or environments) and **link different projects** to different connections where your workspace setup allows it. When a project needs WordPress, Lovable may prompt you to allow or decline the integration for that project, depending on your preference. ## How to connect WordPress.com Workspace **admins** and **owners** can connect WordPress.com. When a connection is created, WordPress.com becomes available across all projects in the workspace. ### Prerequisites * A **WordPress.com** account that can access the target site or sites * **Lovable workspace admin or owner** role ### Set up your WordPress connection Open **Connectors** → **App connectors** and select **WordPress.com**. Click **Add connection**. In **Display name**, choose a clear name (for example, `WordPress Marketing` or `WordPress Staging`). Click **Connect** (or the equivalent action). A **WordPress.com** authorization window opens. Sign in, choose the account if prompted, review the requested access, and approve. When you return to Lovable, the connection should show as active. When connected, projects that are allowed to use this connection can call WordPress.com through Lovable’s gateway while you build and after you publish. ### Use WordPress in a project In chat, describe what you want using plain language and mention WordPress when it matters. For example: ```text wrap theme={null} Use WordPress as the CMS. Load the five most recent posts from my site and show title, date, excerpt, and link on the homepage. ``` ## FAQs The connector is built around **WordPress.com**. Self-hosted **WordPress** sites are a different product; they may still work with some WordPress.com or Jetpack flows depending on your setup, but you should assume this integration targets **WordPress.com** unless your site is explicitly connected in a way WordPress.com's API supports. **WordPress.com** billing, plans, and any API-related limits are between you and **WordPress.com**. Lovable does not replace your WordPress.com subscription or quotas. **Workspace admins and owners** add and remove WordPress connections. Other roles may still **use** the connector in projects when your workspace and project permissions allow it. No. With **gateway-based** connectors, credentials stay in the gateway. Your project does not store the OAuth tokens in plain view. See [Gateway-based connectors](/integrations/introduction#gateway-based-connectors). The app connector represents the **connection you configured** at the workspace level, not per-end-user WordPress login. If you need each user to authenticate to WordPress individually, you typically design a **custom** auth or API flow in your app rather than relying on this app connector alone. Confirm you used the correct **WordPress.com** account, that the site appears in that account, and that you approved the requested permissions. If you changed passwords or revoked access at WordPress.com, **reconnect** the integration from **Connectors** using your connector's reconnect or edit flow. ## Limitations & troubleshooting For underlying API concepts and endpoints, see [WordPress.com developer documentation](https://developer.wordpress.com/docs/api/). Lovable exposes access through the connector; not every documented endpoint is used in every project. * **API coverage** depends on WordPress.com, your **site type**, and **permissions** granted at connect time. Not every WordPress admin task is available through the API. * **Gateway limits** apply per connector and project as described in [Gateway-based connectors](/integrations/introduction#gateway-based-connectors). * If something works in the WordPress.com dashboard but not in your app, check whether the action is **exposed to the API** for your site and account. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Workday Source: https://docs.lovable.dev/integrations/workday Connect your app to Workday, the HR and workforce platform, to let each app user read worker, organization, and time off data with their own Workday permissions. [Workday](https://www.workday.com/) is an enterprise platform for HR, finance, and workforce management. The Workday connector lets your Lovable app read Workday HCM data such as workers, organizations, and time off through an API client registered in your own Workday tenant. Workday is available as an [app user connector](/integrations/app-user-connectors): each end user of your published app connects their own Workday account, and every request runs with that user's own Workday permissions. There is no shared, workspace-wide Workday connection. With Workday, your app can: * Read worker profiles, job, and organization data * Query time off balances and requests * Call any Workday REST API allowed by your API client's functional areas and the connected user's permissions It's a good fit for employee self-service tools, HR dashboards, directories, and org charts where each person sees exactly what they can see in Workday. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Employee self-service portal | *Use Workday and build a portal where each signed-in employee sees their own profile, job details, and time off balance.* | **Give every employee a personal HR view.**
The app reads the connected user's own worker record and time off data from Workday. | | Team directory | *Use Workday and build a searchable directory of the people and teams I can see in Workday.* | **Browse people and org data without opening Workday.**
The app lists the workers and organizations the connected user is allowed to see, with search and filters. | | Org chart explorer | *Use Workday and build an org chart that shows reporting lines for my organization.* | **Visualize reporting structure from live Workday data.**
The app reads organization and worker data and renders an interactive chart scoped to the user's access. | | Time off dashboard | *Use Workday and build a dashboard where I can review my time off balances and requests.* | **Track time off in one place.**
The app queries the connected user's time off balances and requests and presents them in a single view. | | Manager team view | *Use Workday and build a view where managers see their direct reports and upcoming time off.* | **Support managers with their own team data.**
The app reads the reporting relationships and time off data the signed-in manager can access in Workday. | | Custom report viewer | *Use Workday and build a viewer for our Workday custom report so the team can filter and sort results.* | **Bring a Workday custom report into an app interface.**
The app calls the report under the connected user's permissions and adds filtering and sorting on top. | ## How the Workday connector works An app user connector has two parts: a client you configure once for your workspace, and the individual sign-ins your users complete inside your published app. * **The client** holds the details of an API client registered in your Workday tenant: three endpoint URLs, a client ID, and a client secret. It never contains any individual user's data. * **Each user connects their own account.** The first time a user needs Workday data, your app sends them through Workday's sign-in and consent flow. Lovable stores their tokens encrypted in the connector gateway, never exposed to your app code or to you as the builder. * **Requests go through the connector gateway**, which injects the right user's credentials, refreshes expiring tokens automatically, and inserts your tenant into REST paths so app code never needs to know it. Access is the intersection of two things: the functional areas selected on the API client in Workday, and the connected user's own Workday security. Neither the app nor Lovable can widen either one. ## How to connect Workday Who can create Workday clients depends on your plan and workspace settings. See [Who can create connections](/integrations/introduction#who-can-create-connections). You can create multiple Workday clients using different API clients, which is useful for separating environments (for example, a sandbox and a production Workday tenant). When the client is created, anyone building in a project can ask Lovable in chat to connect it to their project. ### Prerequisites Before connecting Workday, make sure you have: * A Workday account and permission to register an API client in your Workday tenant, or a Workday administrator who can do it for you * Permission to **create connections** in your Lovable workspace (see [Who can create connections](/integrations/introduction#who-can-create-connections)) * Authentication in your app ([Lovable Cloud](/features/authentication) or your own), so each visitor is signed in before they connect their Workday account All API requests made through this connector run against your Workday tenant and are governed by your Workday agreement. Billing and quota are handled directly by Workday, not Lovable. ### Step 1: Register an API client in Workday The connector authenticates through an API client you register in your own Workday tenant. Work with your Workday administrator if you don't have access to these tasks. In Workday, search for and run the **Register API Client** task. Set **Client Grant Type** to **Authorization Code Grant** and **Access Token Type** to **Bearer**. Keep **Support Proof Key for Code Exchange (PKCE)** disabled. Workday issues no client secret for PKCE clients, and the connector authenticates with the client secret. Paste this exact value as the **Redirection URI**: ```text theme={null} https://connector-gateway.lovable.dev/api/v1/app-users/oauth2/callback ``` This value applies to the app user connector. If your workspace offers Workday as an **App connector** (a shared workspace connection), its redirection URI is different — always copy the exact value shown in the Lovable setup form for the connection type you're creating. Check **Non-Expiring Refresh Tokens** so user connections survive idle periods. With Workday's default 30-day timeout, users must reconnect after a month of inactivity. Under **Scope (Functional Areas)**, select only the areas your app needs (for example, **Staffing** for worker data). Leave everything else at its default, and do not enable Implicit, JWT, or SAML grants. After clicking **OK**, copy the **Client ID** and **Client Secret**. The secret is shown only once. Run the **View API Clients** task and copy the **Workday REST API Endpoint**, **Token Endpoint**, and **Authorization Endpoint** for your new API client. You paste each one as is into Lovable in the next step. The client secret functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. ### Step 2: Create the Workday client in Lovable Go to **Connectors** and select **Workday**. Click **Add connection** and choose **App user connector**. In **Display name**, name the client (for example, `Workday production`). This name is only used inside Lovable to identify the client. Fill in the fields with the values from Workday: 1. **Workday REST API Endpoint**, **Token Endpoint**, and **Authorization Endpoint**: paste each URL exactly as shown under **View API Clients**. 2. **Client ID** and **Client Secret**: paste the values you copied when registering the API client. Under **Who can use this client**, decide who in your workspace can use the client. You start as the only person with access: * **Only you** (default): leave the access list as is; only you can use the client. * **Invite specific people**: add workspace members by email; only you and the people you add can use the client. * **Invite entire workspace**: click **Invite entire workspace** to make the client available to everyone in your Lovable workspace. See [Who can manage connections](/integrations/introduction#who-can-manage-connections) for more information. Click **Create client**. ### Step 3: Add the connect experience to your app Once the client exists, tell Lovable in chat what you want, and it connects the client to your project and builds the in-app connect flow. For example: ```text wrap theme={null} Let each signed-in user connect their own Workday account and show their time off balance on the dashboard. ``` The first time a user taps **Connect**, your app sends them to Workday to sign in and approve access. After that, the app reads Workday data as that user. When the client is created, anyone building in a project can ask Lovable in chat to connect it to their project (based on configured client-level access). Your published apps can then let each user connect their own Workday account and read their HCM data. ## Limitations The Workday connector cannot: * Provide a shared, workspace-wide Workday connection. Every request runs as an individual app user who has connected their own Workday account. * Exceed the functional areas configured on the API client or the connected user's own Workday permissions. A 403 response means the API client lacks that functional area or the user lacks access in Workday. * Keep users connected past your tenant's refresh token timeout unless the API client uses non-expiring refresh tokens. With the default 30-day timeout, users must reconnect after a month of inactivity. If a user revokes authorization on the Workday side, they need to reconnect in your app before API calls can succeed again. ## Manage the Workday client * **Users can disconnect** their own Workday account at any time, which revokes their stored tokens. * **Edit the client** from **Connectors** → **Workday** to update credentials or change who can use it. * **Deleting the client** removes Workday access for every user in the linked projects. See [Integration security](/integrations/security) for how credentials are stored, rotated, and deleted. # Connect your app to X (Twitter) Source: https://docs.lovable.dev/integrations/x Connect your app to X with an app-only Bearer token to look up users, search recent public posts, and build social integrations from your Lovable app. [X](https://x.com/) is a social platform for public posts and conversations. The X (Twitter) connector lets your Lovable app call the [X API v2](https://docs.x.com/x-api/introduction) using an app-only Bearer token from your X Developer account. It's designed for apps that look up profiles, search recent public posts, or build read-only social dashboards. With X, your app can: * Look up users by username or ID * Search recent public posts * Read public post metadata by ID * Build dashboards and integrations on top of X API v2 data The connector uses an app-only Bearer token, so it supports read-only access to public data. It cannot post, like, follow, or send DMs on behalf of a user account. It's a good fit for profile lookups, keyword monitoring, and public content feeds. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------------- | :-------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | **Profile lookup page** | *Use X and build a page that shows profile info for an X username.* | **Display public profile details from X.**
The app fetches user metadata by username and renders name, handle, and other public fields. | | **Keyword monitoring dashboard** | *Use X and build a dashboard that searches recent posts on X for a keyword.* | **Track public conversation around a topic.**
The app queries recent post search results and presents them in a filterable feed. | | **Social proof widget** | *Use X and build a widget that shows recent posts from a list of accounts.* | **Surface curated public posts in your app.**
The app looks up posts by ID or username and renders a timeline-style view. | | **Influencer directory** | *Use X and build a directory where I enter usernames and see follower counts and bios.* | **Aggregate public profile stats for a roster of accounts.**
The app batches user lookups and displays bios and metrics in a table. | | **Event hashtag tracker** | *Use X and build a live feed of posts matching an event hashtag.* | **Monitor public posts for a campaign or event.**
The app searches recent posts for a hashtag and refreshes results on a schedule. | | **Competitive mentions board** | *Use X and build a board that tracks recent posts mentioning our brand name.* | **Watch brand mentions across public posts.**
The app runs scheduled searches and highlights new matches for the team. | | **Research and reporting tool** | *Use X and build an internal tool that exports recent posts about a topic as JSON.* | **Pull public post data for analysis or reporting.**
The app searches and fetches post metadata through the gateway for downstream use. | ## How to connect X Workspace **admins** and **owners** can connect X. You can create multiple X connections using different Bearer tokens, which is useful for separating environments (for example, development and production) or using tokens from different X apps. When the connection is created, X becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting X, make sure you have: * An [X Developer account](https://developer.x.com/) * An X app with an app-only Bearer token * Lovable workspace **owner** or **admin** role All API requests made through this connector count toward your X API access tier and rate limits. Billing and quota are handled directly by X, not Lovable. ### Step 1: Get an X app-only Bearer token An app-only Bearer token lets your Lovable app authenticate with the X API v2 for read-only public data. You generate it in the X Developer Portal for a specific app. To create an X Bearer token: Sign in to the [X Developer Portal](https://developer.x.com/en/portal/dashboard). Create a **Project** and **App** if you do not have one yet, or open the app you want to use. In your app settings, go to **Keys and tokens** (or **User authentication settings** → **Keys and tokens**, depending on your portal layout). Under **Authentication Tokens**, find **Bearer Token** and click **Generate** (or **Regenerate**). Copy the token and store it securely. Your Bearer token functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See X documentation for details on access tiers, endpoints, and rate limits: [X API introduction](https://docs.x.com/x-api/introduction). ### Step 2: Connect X to Lovable You can create multiple connections using different Bearer tokens. Go to **Connectors → App connectors** and select **X (Twitter)**. Click **Add connection**. 1. **Display name**: name the connection, for example `X Prod`. This name is only used inside Lovable to identify the connection. 2. **Bearer token**: paste your app-only Bearer token from the X Developer Portal. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. Lovable verifies the token against the X API before saving the connection. When connected, anyone building in a project can ask Lovable in chat to link their project to X (based on configured connection-level access). Your Lovable apps can then look up users and search recent public posts through the connector. ## Limitations The X connector is read-only with an app-only Bearer token. It cannot: * Post, reply, like, repost, or follow on behalf of a user * Send or read direct messages * Access protected accounts or a user's private timeline * Support per-end-user X login. Each connection uses a single shared Bearer token across all projects linked to it * Bypass X API rate limits. Cache results, back off on `429` responses, and avoid tight polling loops If you revoke or regenerate the Bearer token in the X Developer Portal, update the connection in Lovable with the new token before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Zoho Books Source: https://docs.lovable.dev/integrations/zoho-books Connect your app to Zoho Books, an accounting platform, to read and manage customers, invoices, estimates, bills, expenses, and projects. [Zoho Books](https://www.zoho.com/books/) is accounting software for managing customers, invoices, estimates, expenses, bills, projects, and bookkeeping workflows. The Zoho Books connector lets your Lovable app read and manage accounting records through your own Zoho Books account. With Zoho Books, your app can: * List organizations and use organization IDs for accounting API calls * Create and manage customers, vendors, invoices, estimates, and sales orders * Read bills, expenses, purchase orders, and projects for dashboards and reports * Build approval, reporting, and bookkeeping workflows through the connector gateway It's a good fit for finance dashboards, customer billing portals, expense workflows, and internal accounting tools that need live Zoho Books data. ## Common use cases and example apps | Example app | Example prompt | Description | | :--------------------------- | :-------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Invoice operations dashboard | *Use Zoho Books and build a dashboard that shows invoices by customer, due date, and payment status.* | **Track invoice status from Zoho Books in one focused view.**
The app reads invoices from the connected organization, groups them by status, and helps finance teams follow up on overdue payments. | | Customer billing portal | *Use Zoho Books and build a customer portal where customers can view their invoices, estimates, and payment history.* | **Give customers a self-service view of billing records.**
The app fetches customer, invoice, and estimate data from Zoho Books and displays the records tied to each account. | | Expense approval tool | *Use Zoho Books and build an expense approval app where managers can review expenses by project and vendor.* | **Review Zoho Books expenses in a structured approval flow.**
The app reads expense records, lets managers filter by project or vendor, and records approval decisions in your app. | | Accounts payable tracker | *Use Zoho Books and build a tracker for bills and purchase orders that flags upcoming due dates.* | **Help operations teams stay ahead of vendor payments.**
The app reads bills and purchase orders from Zoho Books and highlights records that need review or payment. | | Project finance dashboard | *Use Zoho Books and build a project dashboard that shows expenses, invoices, and profitability by project.* | **Connect project work to financial outcomes.**
The app reads project, expense, and invoice data so teams can monitor budgets and margins without exporting spreadsheets. | ## How to connect Zoho Books Workspace **admins** and **owners** can connect Zoho Books. You can create multiple Zoho Books connections using different Zoho accounts, regions, OAuth apps, or organization IDs, which is useful for separating production and sandbox environments or managing multiple legal entities. When the connection is created, Zoho Books becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Zoho Books, make sure you have: * A Zoho Books account * Access to the Zoho API Console for your Zoho Books data center to create a Server-based Application * The data center where your Zoho Books account is hosted, such as United States, Europe, India, Australia, Japan, Canada, China, or Saudi Arabia * The Zoho Books organization ID you want to use, if you want to pin the connection to one organization * Lovable workspace **owner** or **admin** role All API requests made through this connector count against your Zoho Books API limits and your Zoho Books plan. Billing and quota are handled directly by Zoho Books, not Lovable. ### Step 1: Create a Zoho API console application Zoho Books uses OAuth to authorize third-party access. Create a Server-based Application in the Zoho API Console for the same data center as your Zoho Books account to get the Client ID and Client Secret for Lovable. | Zoho Books data center | API Console URL | | -------------------------------- | ------------------------------------------------------------- | | United States (`books.zoho.com`) | [api-console.zoho.com](https://api-console.zoho.com/) | | Europe (`books.zoho.eu`) | [api-console.zoho.eu](https://api-console.zoho.eu/) | | India (`books.zoho.in`) | [api-console.zoho.in](https://api-console.zoho.in/) | | Australia (`books.zoho.com.au`) | [api-console.zoho.com.au](https://api-console.zoho.com.au/) | | Japan (`books.zoho.jp`) | [api-console.zoho.jp](https://api-console.zoho.jp/) | | Canada (`books.zohocloud.ca`) | [api-console.zohocloud.ca](https://api-console.zohocloud.ca/) | | China (`books.zoho.com.cn`) | [api-console.zoho.com.cn](https://api-console.zoho.com.cn/) | | Saudi Arabia (`books.zoho.sa`) | [api-console.zoho.sa](https://api-console.zoho.sa/) | Sign in to the Zoho API Console URL that matches your Zoho Books data center. Click **Add Client** or **Get started**, then choose **Server-based Applications**. Fill in the application details: * **Client Name**: for example, `Lovable Integration` * **Homepage URL**: your app or company website URL * **Authorized Redirect URIs**: add `https://api.lovable.dev/workspaces/connectors/standard/oauth/callback` Save the application, then copy the generated **Client ID** and **Client Secret**. You need both values in Lovable. Your Client Secret functions like a password. Keep it secure and never share it publicly. You need it in the next step. See [Zoho's API console documentation](https://www.zoho.com/accounts/protocol/oauth.html) for more detail. ### Step 2: Connect Zoho Books to Lovable Go to **Connectors → App connectors** and select **Zoho Books**. Click **Add connection**. Fill in the connection fields: * **Display name**: name the connection, for example `Zoho Books Prod`. This name is only used inside Lovable to identify the connection. * **Data center**: choose the region where your Zoho Books account is hosted. Check your Zoho Books URL, for example `books.zoho.eu` means Europe. * **Client ID**: the Client ID from your Zoho API console application. * **Client secret**: the Client Secret from your Zoho API console application. * **Organization ID** (optional): enter a numeric Zoho Books organization ID if you want the connection metadata to include it. If you leave this empty, your app can fetch organizations after connecting. Expand **Advanced settings** to review the Zoho Books permissions Lovable requests. Default scopes are selected for common accounting workflows. **Settings: read** is required because the connector verifies the connection and lists organizations through Zoho Books settings APIs. You can remove optional scopes if your app does not need that accounting area. | Scope | What it allows | Default | | ------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------- | | Settings: read (`ZohoBooks.settings.READ`) | List organizations and read settings data such as users, taxes, currencies, and items | Required | | Contacts: full access (`ZohoBooks.contacts.ALL`) | Create, read, update, and delete customers and vendors | On | | Invoices: full access (`ZohoBooks.invoices.ALL`) | Create, read, update, and delete invoices | On | | Estimates: full access (`ZohoBooks.estimates.ALL`) | Create, read, update, and delete estimates and quotes | On | | Sales orders: full access (`ZohoBooks.salesorders.ALL`) | Create, read, update, and delete sales orders | On | | Purchase orders: full access (`ZohoBooks.purchaseorders.ALL`) | Create, read, update, and delete purchase orders | On | | Bills: full access (`ZohoBooks.bills.ALL`) | Create, read, update, and delete bills | On | | Expenses: full access (`ZohoBooks.expenses.ALL`) | Create, read, update, and delete expenses | On | | Projects: full access (`ZohoBooks.projects.ALL`) | Create, read, update, and delete projects and project tasks | On | For full scope documentation, see [Zoho Books OAuth scopes](https://www.zoho.com/books/api/v3/oauth/#scopes). Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. The Zoho Books authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to Zoho Books if prompted, review the requested permissions, and click **Accept** or **Allow**. Lovable redirects you back with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to Zoho Books (based on configured connection-level access). Your Lovable apps can then read and manage Zoho Books records through your connected Zoho account. ## Working with organizations Most Zoho Books resource endpoints require an `organization_id` query parameter. If you enter **Organization ID** when creating the connection, Lovable includes that value in the connection metadata so the app can reuse it. If you leave **Organization ID** empty, ask Lovable to fetch organizations first through the connector, then pass the returned organization ID on calls for records such as contacts, invoices, bills, expenses, and projects. ## Limitations The Zoho Books connector cannot: * Support per-end-user Zoho Books login. Each connection represents a single Zoho account shared across all projects linked to it. * Receive Zoho Books webhook events through the connector. * Bypass Zoho Books API limits, rate limits, or plan restrictions. * Remove the need for `organization_id` on Zoho Books resource calls. Apps need to use the configured organization ID or fetch it from `/organizations`. If Zoho Books authorization is revoked from the Zoho side, or if the Zoho API console application is deleted or changed, you'll need to reconnect the integration in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect your app to Zoho CRM Source: https://docs.lovable.dev/integrations/zoho-crm Connect your app to Zoho CRM, a sales CRM platform, to read and manage leads, contacts, accounts, deals, and other CRM records. [Zoho CRM](https://www.zoho.com/crm/) is a customer relationship management platform for managing leads, contacts, accounts, deals, activities, and sales workflows. The Zoho CRM connector lets your Lovable app read, search, create, and update CRM records through your own Zoho CRM account. With Zoho CRM, your app can: * Query and display Leads, Contacts, Accounts, Deals, Tasks, Cases, Products, Quotes, and Invoices * Search and filter records for dashboards, portals, and internal tools * Create and update records across standard and custom CRM modules It's a good fit for sales dashboards, lead intake tools, customer portals, and operational apps that need live CRM data from Zoho CRM. ## Common use cases and example apps | Example app | Example prompt | Description | | :------------------------ | :-------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Lead intake dashboard | *Use Zoho CRM and build a dashboard that shows new Leads by source, status, and owner.* | **Track new leads from Zoho CRM in one focused view.**
The app reads Leads from Zoho CRM, groups them by status, and helps sales teams prioritize follow-up. | | Deal pipeline board | *Use Zoho CRM and build a pipeline board where I can view Deals by stage and update deal status.* | **Manage deal movement from a custom interface.**
The app fetches Deals from Zoho CRM, displays them by stage, and writes updates back to the connected CRM account. | | Account health portal | *Use Zoho CRM and build an account health portal that shows Accounts, related Contacts, and recent activities.* | **Give teams a clear account summary backed by CRM data.**
The app reads Accounts, Contacts, Tasks, and Calls so account managers can review context without opening Zoho CRM. | | Customer lookup tool | *Use Zoho CRM and build a searchable customer lookup tool for Contacts and Accounts.* | **Create a fast internal search experience for customer records.**
The app searches Zoho CRM modules and displays the fields your team needs for support or sales workflows. | | Quote and invoice tracker | *Use Zoho CRM and build a tracker that lists Quotes and Invoices by customer and status.* | **Surface commercial records from Zoho CRM in a reporting view.**
The app reads Quotes and Invoices, filters by account or status, and helps teams follow up on open items. | ## How to connect Zoho CRM Workspace **admins** and **owners** can connect Zoho CRM. App connectors are enabled by default on Free, Pro, and Business plans. On Enterprise plans, workspace admins and owners can manage app connector availability for the workspace. You can create multiple Zoho CRM connections using different Zoho accounts, regions, or OAuth apps, which is useful for separating production and sandbox environments. When the connection is created, Zoho CRM becomes available across all projects in the workspace. Anyone building in a project can ask Lovable in chat to link their project to it. ### Prerequisites Before connecting Zoho CRM, make sure you have: * A Zoho CRM account * Access to the Zoho API Console for your Zoho CRM data center to create a Server-based Application * The data center where your Zoho account is hosted, such as United States, Europe, India, Australia, Japan, Canada, or China * Lovable workspace **owner** or **admin** role All API requests made through this connector count against your Zoho CRM API limits and your Zoho CRM plan. Billing and quota are handled directly by Zoho CRM, not Lovable. ### Step 1: Create a Zoho API console application Zoho CRM uses OAuth to authorize third-party access. Create a Server-based Application in the Zoho API Console for the same data center as your Zoho CRM account to get the Client ID and Client Secret for Lovable. | Zoho CRM data center | API Console URL | | ------------------------------ | ------------------------------------------------------------- | | United States (`crm.zoho.com`) | [api-console.zoho.com](https://api-console.zoho.com/) | | Europe (`crm.zoho.eu`) | [api-console.zoho.eu](https://api-console.zoho.eu/) | | India (`crm.zoho.in`) | [api-console.zoho.in](https://api-console.zoho.in/) | | Australia (`crm.zoho.com.au`) | [api-console.zoho.com.au](https://api-console.zoho.com.au/) | | Japan (`crm.zoho.jp`) | [api-console.zoho.jp](https://api-console.zoho.jp/) | | Canada (`crm.zohocloud.ca`) | [api-console.zohocloud.ca](https://api-console.zohocloud.ca/) | | China (`crm.zoho.com.cn`) | [api-console.zoho.com.cn](https://api-console.zoho.com.cn/) | Sign in to the Zoho API Console URL that matches your Zoho CRM data center. Click **Add Client** or **Get started**, then choose **Server-based Applications**. Fill in the application details: * **Client Name**: for example, `Lovable Integration` * **Homepage URL**: your app or company website URL * **Authorized Redirect URIs**: add `https://api.lovable.dev/workspaces/connectors/standard/oauth/callback` Save the application, then copy the generated **Client ID** and **Client Secret**. You'll enter both values in Lovable. Your Client Secret functions like a password. Keep it secure and never share it publicly. You'll need it in the next step. See [Zoho's API console documentation](https://www.zoho.com/accounts/protocol/oauth.html) for more detail. ### Step 2: Connect Zoho CRM to Lovable Go to **Connectors → App connectors** and select **Zoho CRM**. Click **Add connection**. Fill in the connection fields: * **Display name**: name the connection, for example `Zoho CRM Prod`. This name is only used inside Lovable to identify the connection. * **Data center**: choose the region where your Zoho account is hosted. Check your Zoho CRM URL, for example `crm.zoho.eu` means Europe. * **Client ID**: the Client ID from your Zoho API console application. * **Client Secret**: the Client Secret from your Zoho API console application. Under **Who can access this connection**, decide who in your workspace can use the connection: * **Only you** (default): only the person creating the connection can use it and its associated data. * **Invite specific people**: only you and explicitly added workspace members can use the connection and its associated data. * **Invite entire workspace**: click **Invite entire workspace** to make the connection available to everyone in your Lovable workspace. See [Connection-level access](/integrations/introduction#connection-level-access) for more information. Click **Connect**. The Zoho CRM authorization window opens, so make sure your browser doesn't block pop-ups. If it does, Lovable redirects you instead. Sign in to Zoho CRM if prompted, review the requested permissions, and click **Accept** or **Allow**. You'll be redirected back to Lovable with a confirmation. When connected, anyone building in a project can ask Lovable in chat to link their project to Zoho CRM (based on configured connection-level access). Your Lovable apps can then read, search, create, and update CRM records through your connected Zoho CRM account. ## Limitations The Zoho CRM connector cannot: * Support per-end-user Zoho CRM login. Each connection represents a single Zoho CRM account shared across all projects linked to it. * Bypass Zoho CRM API limits, rate limits, or plan restrictions. * Return record lists without explicit fields. Zoho CRM rejects list requests that omit the `fields` parameter. * Receive Zoho CRM webhooks or real-time record-change events. If Zoho CRM authorization is revoked from the Zoho side, or if the Zoho API console application is deleted or changed, you'll need to reconnect the integration in Lovable before API calls can succeed again. ## How to unlink projects from a connection Editors and above can remove specific projects from a connection without deleting the connection entirely. The connection will remain available for other projects. To unlink projects: Open **Connectors** and select . Open the connection you want to manage. Under **Linked projects**, check the projects you want to unlink. Click **Unlink projects** and confirm. When unlinked, those projects will no longer have access to through this connection. If a project needs again, you can link it to any available connection. ## How to delete a connection Workspace admins and owners can delete connections. Other members can delete a connection if they created it, or if they have been explicitly granted access to it. Deleting a connection is permanent and cannot be undone. It will remove the credentials from all linked projects, and any apps using this connection will stop working until a new connection is added. Before deleting, review the **Linked projects** section to see which projects are currently using the connection. To delete a connection: Open **Connectors** and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Create an account Source: https://docs.lovable.dev/introduction/create-an-account Create your Lovable account to start building and iterating on full-stack web applications using natural language. A Lovable account is your personal identity on Lovable, it's how you sign in, manage your profile and preferences, and access the workspaces where projects live. You only need one account, no matter how many teams or projects you work on. Anyone with an email address can **sign up for free**. After sign-up, Lovable automatically creates your first personal workspace on the free plan so you can start building right away. ## Sign up at [lovable.dev](http://lovable.dev) Create an account at **lovable.dev/signup** using any of these methods: * **Email and password** * **Google** * **GitHub** * **Apple** * **Single sign-on (SSO)**: SAML or OIDC, for organizations on Business and Enterprise plans that have configured SSO with Lovable If your organization uses SSO, ask your admin which provider to use. You can also link SSO to an existing account later from **Account settings → Linked accounts**. After sign-up, Lovable automatically creates your first personal workspace on the **free plan** with a 5 daily credit allowance (up to a maximum of 30 per month), and takes you to the dashboard. ## Access your account settings You can open your account settings at any time: * Go directly to [**lovable.dev/settings/account**](https://lovable.dev/settings/account), or * Click the workspace switcher (top-left of the dashboard) → **Settings → Your account** See [Account settings](/introduction/lovable-account-settings) for the full list of what you can configure (profile, username, preferences, linked accounts, two-factor authentication, and more). ## Reset your password If you signed up with **email and password**, you can reset it from the sign-in page: 1. Go to [**lovable.dev/login**](https://lovable.dev/login). 2. Enter your account email and click **Forgot password?** 3. Open the reset email and follow the link to set a new password. You're signed in automatically once your password is set. If you signed up with **Google**, **GitHub**, **Apple**, or **SSO**, there is no separate Lovable password. **Forgot password?** does not send a reset email for these accounts and shows a **Password reset unavailable** message instead. Sign in with the same provider you used to create your account, and reset that provider's password through the provider (for example, [Google Account recovery](https://accounts.google.com) or [GitHub password reset](https://github.com/password_reset)). If your only sign-in method was an SSO provider that has since been removed from your workspace, use the recovery flow on the login page to set a password for the first time. See [Recover access after an SSO provider is removed](/features/business/sso#recover-access-after-an-sso-provider-is-removed). To check which sign-in methods are linked to your account, go to **Settings → Your account → Linked accounts**. The **Primary** badge marks the provider you originally signed up with. See [Account settings](/introduction/lovable-account-settings#linked-accounts). ## Account vs. workspace A Lovable account is your personal identity on Lovable. It's separate from a workspace. * Your account is you and holds your sign-in, your profile, your preferences. * A workspace is where you work, alone or shared with people you invite, and holds your projects, members, billing, and credits. You sign in with one account, and from that account you can belong to one or many workspaces. See [Workspace](https://docs.lovable.dev/features/workspace) for everything workspace-related. ## What's next Now that your account is set up: * **Create your first project** from the dashboard. See [Lovable dashboard](/introduction/dashboard-overview). * **Invite your team** to your workspace from **Settings → People**. See [People](/features/people). * **Personalize your account**: Set your name, avatar, and profile visibility from **Settings → Your account**. See [Account settings](/introduction/lovable-account-settings). * **Secure your account**: Enable two-factor authentication from **Settings → Your account → Two-factor authentication**. See [Two-factor authentication](/introduction/two-factor-authentication-2-fa). * **Upgrade your plan** if you need more daily credits or team features. See [Subscription plans](/introduction/subscription-plans). # Credits and usage Source: https://docs.lovable.dev/introduction/credits-and-usage Learn how Lovable credits work, what uses credits, how to check usage, and how to add credits with top-ups. Lovable uses one credit balance for building your app, hosting and running it with Lovable Cloud, and AI features your deployed app uses. Use **Settings → Plans & credit usage** to understand your credit balance, track credit usage, add credits, and manage top-ups. **Looking for billing, plan changes, or how to cancel?** Open [Plans & credit usage](https://lovable.dev/settings/billing) directly, or go to **Settings → Plans & credit usage** in Lovable. From there, select **Manage** to update billing details or download invoices, and use **Manage → Downgrade to free** to cancel a paid subscription. See [Manage your subscription](/introduction/subscription-plans#manage-your-subscription) and [Cancel your subscription](/introduction/subscription-plans#cancel-your-subscription). For available plans, plan feature differences, subscription tiers, billing cycles, invoices, and cancellation, see [Subscription plans](/introduction/subscription-plans). **Rolling out gradually: Lovable now uses one credit balance for building your app, hosting and running it with Lovable Cloud, and AI features in deployed apps.** This update is rolling out gradually. Some workspaces may still see the previous Cloud and AI balance experience during the rollout. * **Cloud and AI balances became credits.** Any remaining Cloud and AI dollar balance was converted into credits at your plan's credit rate and added to your balance. * **Cloud and AI costs have not changed.** Monthly Cloud and AI grants are now issued as credits instead of dollars, but the cost for running your projects is the same. * **All credit controls now live in Plans & credit usage.** The old Cloud and AI balance tab, Cloud and AI specific top-ups, and dollar-based auto top-up have been replaced by credit-based controls in **Settings → Plans & credit usage**. Review your top-up settings there to make sure the threshold and amount still match your needs. No action is required, and your projects, hosting, and AI features keep running through the change. ## What is a credit? A credit is the unit Lovable uses to measure and pay for usage across your workspace. Credits let you build apps, run deployed apps, and power AI features from one balance. Your credits cover three types of usage: | Usage type | What credits pay for | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Build usage | Sending messages in Lovable to plan, generate, edit, or update your app | | Cloud usage | Hosting and running your app with [Lovable Cloud](/features/cloud), including database, network, storage, edge functions, and realtime usage in deployed apps | | AI gateway usage | [AI features](/features/ai) your deployed app uses, such as calls your app makes to AI models | ## Where credits come from Your workspace receives credits from two kinds of sources: 1. [Usage-specific grants](#usage-specific-grants), which apply only to one type of usage. 2. [General credits](#general-credits), which can be used to build your app, host and run your app with Lovable Cloud, and power AI features in deployed apps. Lovable always uses usage-specific grants before general credits. After usage-specific grants run out, Lovable uses the general credits closest to expiry first. ### Usage-specific grants Usage-specific grants are included credits that apply to one type of usage. Lovable always uses them before general credits. For example, daily build credits apply only to build usage, the monthly Cloud grant applies only to Cloud usage, and the monthly AI grant applies only to AI gateway usage. Usage-specific grants refresh automatically, but their refresh schedule depends on the grant and plan type. Unused usage-specific grants do not roll over. | Grant | What it covers | When it refreshes | Expiry | | :------------------ | :-------------------------------- | :------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------- | | Daily build credits | Build usage only | Every day at 00:00 UTC | End of day | | Monthly Cloud grant | Cloud usage only |
  • Free: 1st of each calendar month at 00:00 UTC
  • Pro and Business: subscription billing cycle
|
  • Free: end of calendar month
  • Pro and Business: end of billing cycle
| | Monthly AI grant | AI features in deployed apps only |
  • Free: 1st of each calendar month at 00:00 UTC
  • Pro and Business: subscription billing cycle
|
  • Free: end of calendar month
  • Pro and Business: end of billing cycle
| Included usage-specific grants by plan: | Plan | Daily build credits | Monthly Cloud grant | Monthly AI grant | | :------- | :---------------------------- | :------------------- | :------------------ | | Free | 5 per day, up to 30 per month | 20 credits per month | 4 credits per month | | Pro | 5 per day | 20 credits per month | 4 credits per month | | Business | 5 per day | 20 credits per month | 4 credits per month | Monthly Cloud and AI grants are a temporary offering and subject to change. You can see the breakdown of included usage-specific grants by hovering the **info** icon next to **Free usage included** above the credit bar. Free, Pro, and Business workspaces include monthly Cloud and AI grants so you can host apps with Lovable Cloud and use AI features in deployed apps without spending general credits on that usage first. Once a grant runs out, general credits cover any additional Cloud or AI gateway usage. For the full plan comparison and paid subscription tiers, see [Subscription plans](/introduction/subscription-plans). ### General credits General credits can be used after usage-specific grants run out to build your app, host and run your app with Lovable Cloud, and power AI features in deployed apps. | Credit source | When it is added | Expiry | | :-------------------------------- | :----------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | | Monthly plan credits | Start of billing period |
  • Monthly plans: 2 months from issue date
  • Annual plans: 1 month after the annual billing period ends
| | Top-up credits (Pro and Business) | On one-time top-up purchase or auto top-up | 12 months from purchase | | Bonus credits | When granted (gifts and promotions) | Depends on the grant, shown in [Credit balance details](#view-your-credit-balance) | You can see a breakdown of your general credit types and their expiry dates in the [Credit balance](#view-your-credit-balance) dialog. All unused monthly plan credits automatically roll over at the end of each billing cycle, as long as your subscription remains active. ## Usage costs Credits are used across three main areas: building your app, hosting and running it with Lovable Cloud, and powering AI features in deployed apps. Each area uses credits differently, based on the type of work performed or resources consumed. To see where your credits are going over time, use [Usage details](#tracking-credit-usage). ### Build costs Credits are used when you work with Lovable to plan, generate, edit, or update your app. Lovable has two main modes: | Mode | How credits are charged | | :--------- | :------------------------------------------------------------------- | | Plan mode | Every message costs 1 credit | | Build mode | Cost depends on the complexity of the request and the work completed | Use [Plan mode](/features/plan-mode) to think through an idea, investigate a problem, compare approaches, or create a plan before changing code. Plan mode never modifies your code, and every message deducts 1 credit. Use [Build mode](/features/agent-mode) when you want Lovable to implement changes directly in your project. Build mode pricing is usage-based. Small, focused edits usually cost less than larger generations, multi-step changes, or requests that require more codebase exploration, verification, browser checks, web search, or image generation. Here are some illustrative Build mode examples: | User prompt | Work done | Credits used | | :------------------------------- | :------------------------------------------------------------------ | :----------- | | Make the button gray | Changes the button styles | 0.50 | | Remove the footer | Removes the footer component | 0.90 | | Add authentication | Adds login and authentication logic | 1.20 | | Build a landing page with images | Creates a landing page with generated images, a theme, and sections | 2.00 | Credit costs shown are illustrative examples. Actual credits used vary depending on the complexity and scope of your specific project. Click the three-dot menu below any Lovable response in the chat to see its exact cost. See [response actions](/features/projects/chat#act-on-lovables-responses). Stopped Build mode requests are charged based on the work completed so far. View Message Cost To review Build usage over time, go to **Settings → Plans & credit usage → Usage details** and select **Build credits**. You can filter by time range and view usage by project or person. ### Cloud costs Cloud usage is measured based on the Lovable Cloud infrastructure resources your deployed app consumes. It draws from your available credits, starting with any monthly Cloud grant included in your plan. | Usage driver | What affects cost | | :--------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Database server | The instance size your database runs on, how long it stays active, and how much traffic or querying it handles. Larger instances support more users, traffic, queries, and data, but use more credits. Paid plan users can choose a larger instance size from the Cloud tab. Free plan users can upgrade their plan to move beyond the default instance. See [Upgrade instance](/features/advanced-settings#upgrade-instance) for more information. | | Database storage | The amount of data your database stores, such as users, orders, messages, and app records | | Network | Data sent or received by your app, such as API responses, downloads, uploads, images, and media | | Storage | The amount of uploaded or generated files your app stores, such as images, documents, and videos | | Compute | Your app's code running behind the scenes, such as processing payments or sending emails | | Realtime | Live updates sent through your app, such as chat messages, notifications, or collaborative updates | Cloud usage usually increases when more people visit your app, your app stores more data or files, users upload or download larger files, your app sends more API responses or media, your app runs more code behind the scenes, or Realtime features send more messages. For more information, see [Lovable Cloud](/features/cloud). To reduce a project's Cloud usage, work through the checklist in [Reduce a project's Cloud usage](/features/usage-and-costs#reduce-a-projects-cloud-usage): pausing, right-sizing the instance, fixing slow queries, cleaning up storage, or removing Cloud entirely. To review Cloud usage, go to **Settings → Plans & credit usage → Usage details**, then select **Run credits**. You can filter by time range and view usage by project. The **Cloud tab → Usage** view inside a project shows the same breakdown, already filtered to that project, so you can see which categories drive its usage while you work on it. The **Run credits** view includes both Cloud and AI gateway usage. The usage chart breaks Cloud usage into categories such as Database, Network, Storage, Compute, and Realtime. Database usage includes both database server and database storage. Run Credits Breakdown ### AI gateway costs AI gateway usage is measured when AI features inside your deployed app make model calls. These requests are separate from the Lovable agent that helps you plan, build, and edit your project. The built-in AI connector runs on a usage-based pricing model, so credit usage scales with how much your app uses AI features. Each model call deducts credits based on the model used and the number of tokens processed. On Free, Pro, and Business plans, AI gateway usage draws from the monthly AI grant first. After that, it draws from general credits if available. AI gateway usage rates are based on the underlying provider model costs. To estimate relative model costs, refer to the official provider pricing sources linked from the [supported model list](/features/ai#supported-models-for-ai-features-in-your-app). | Usage driver | What affects cost | | :------------ | :--------------------------------------------------------------------------------------------------------------------- | | Model choice | More capable models usually cost more than smaller or faster models | | Input tokens | Longer prompts, documents, chat history, or retrieved context increase usage | | Output tokens | Longer AI responses increase usage | | Call volume | More users or more frequent AI actions create more model calls | | Feature type | Chatbots, document question answering, image generation, embeddings, and automations can have different usage patterns | For more information, see [AI features for your app](/features/ai). To review AI gateway usage, go to **Settings → Plans & credit usage → Usage details** and select **Run credits**. You can filter by time range and view usage by project. The **Run credits** view includes both Cloud and AI gateway usage. The usage chart shows the top models used (see image in Cloud costs). ## View your credit balance You can check your credit balance from the dashboard, the project editor, or **Settings → Plans & credit usage**. To quickly check your credit balance, click your workspace name in the top-left of the dashboard, or click the project name when you are inside the project editor. Both places show a credit bar with a quick view of your remaining credits. Click the credit bar to open **Plans & credit usage** for more details. The credit bar shows your remaining daily build credits, monthly credits, personal credits, team credits, or commitment credits, depending on your plan. Workspace admins and owners on paid plans can also open the **Credit balance** dialog for a detailed view of workspace credits, including credit types, expiry dates, and recent credit activity. Select **Details** to open the **Credit balance** dialog. The dialog has two tabs: **Breakdown** and **History**. ### Breakdown tab Available on Pro and Business plans. Not shown for Enterprise. The **Breakdown** tab lists your general credit grants, including each grant’s type, expiry date, and remaining amount. Grants expiring soonest appear first. A note at the top of the tab confirms that Lovable uses the general credits closest to expiry first. Credit Balance Breakdown | Credit type\* | Description | | :--------------- | :------------------------------------------------------------------------------------------------------------------------- | | Monthly credits | General credits included with your plan. Issued at each billing cycle renewal. | | Rollover credits | Unused monthly credits carried forward from a previous billing period. | | Bonus credits | One-off promotional credits from Lovable support, a referral (when someone you invited signs up), or an affiliate program. | | Top-up credits | Credits purchased through one-time top-ups or auto top-ups. | \**Not all credit types appear for every workspace.* ### History tab Available on Pro, Business, and Enterprise plans. The **History** tab shows credit activity for up to the past 12 months, sorted newest first. Because credit history recording started on March 8, 2026, early history may show less than 12 months of activity. Over time, the tab will show a full 12 months of credit history. Each row shows the event type, date, and credit change. Positive values mean credits were added, and negative values mean credits were removed or expired. Credit Balance History | Event type | Description | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Monthly credits granted | Monthly plan credits were issued at renewal or plan start. | | Monthly credits expired | Unused monthly plan credits expired at the end of their validity window. | | Bonus credits granted | Promotional credits were added to your account, for example from Lovable support, a referral, or an affiliate program. | | Bonus credits expired | Promotional credits expired unused. | | Top-up credits granted | Credits purchased through a one-time top-up or auto top-up were added to your account. | | Top-up credits expired | Purchased top-up credits expired unused. | | Commitment credits granted | Enterprise only. Your committed credit balance was issued or renewed. | | Credits converted | A one-time entry created during the transition to credits as the single balance, reflecting the conversion of your previous Cloud and AI balance into credits. | ## Tracking credit usage Go to **Settings → Plans & credit usage → Usage details** to see a detailed breakdown of where your credits go across build usage, Cloud usage, and AI gateway usage. The **Usage** card on the **Plans & credit usage** page shows recent usage at a glance. Select **More usage details** to open the full **Usage details** page. **Ask Lovable about your workspace’s credit usage directly in chat.** Ask a question about credits, spend, or cost, and Lovable looks up your usage and answers in the conversation using the same numbers shown in **Settings → Plans & credit usage**. For example, ask *How many credits did this workspace use this month?*, *How many credits have I used?*, *Which project used the most Run credits?*, *Which AI gateway model is using the most credits?*, or *Which Lovable Cloud category is driving usage?* Usage answers follow the same visibility rules as **Usage details**. ### Usage visibility by role Usage visibility depends on your workspace plan, workspace role, the usage type, and whether you have access to the project. | View | Who can see it | Notes | | :------------------- | :-------------------------- | :--------------------------------------------------------------------------------------------------------------------- | | Your own usage | Editors, admins, and owners | You can see your own build usage. | | Total usage | Editors, admins, and owners | Shows total workspace usage across the selected filters. | | Project usage | Admins and owners | Shows usage by project. If you do not have access to a project, its usage is included, but the project name is hidden. | | Other members’ usage | Admins and owners | Only admins and owners can view Build usage for other workspace members. | On Enterprise workspaces, usage details are visible to admins and owners only. Editors may see a limited **Plans & credit usage** summary with their own personal usage and remaining team credits, but they cannot view detailed usage, workspace commitment totals, project usage, or other members’ usage. ### Filters Narrow the view with these filters: * **Credit type:** switch between **All credits**, **Build credits** for building and editing, or **Run credits** for Cloud and AI gateway usage. * **Project:** admins and owners can see usage per project across **All credits**, **Build credits**, or **Run credits**. Selecting a project updates the chart to show that project’s usage for the selected credit type. Clear the selected project to return to the full view. * **People:** see your own build usage, or, if you are an admin or owner, see build usage per workspace member. This filter is only available when viewing **Build credits**. Selecting a person updates the chart to show that person’s build credit usage. Select **View details** to open [User insights](/features/people#user-insights) for that member. Clear the selected person to return to the full view. * **Group:** admins and owners can see build credit usage per group. This filter is only available when viewing **Build credits**, and is available to Business and Enterprise workspaces. Selecting a group updates the chart to show that group’s build credit usage. Clear the selected group to return to the full view. * **Time range:** view the last 30 days, last 90 days, or a custom range of up to 90 days. ### Reading the chart The heading above the chart shows your total credits for the current filter and time range, such as *5,352 credits in last 30 days*. The chart shows daily credit consumption. Hover over a bar to see the details for that day. Usage data may be up to a minute behind your most recent activity. New Run credit usage can take up to 24 hours to appear. Each bar breaks down by usage type: * **Cloud usage** breaks down into Database (server and storage), Network, Storage, Compute, and Realtime. * **AI gateway usage** shows a breakdown by the top three models used. Run usage history, which includes Cloud and AI gateway usage, starts on the date your workspace switched to the unified credit balance (June 1, 2026 at the earliest). Dates before then show Build usage only. This helps you answer questions like *Which project is driving my hosting costs?* or *Which member used the most credits this month?* directly from **Usage details**. ### Projects and People tabs Below the chart, usage is broken down in two tabs: * **Projects:** credits used per project across the selected credit type. Search and sort projects by usage, then select a project to apply the filter and update the chart. * **People:** build credits used per workspace member. This tab is available when viewing **Build credits**. Search and sort members by build credit usage, then select a person to apply the filter and update the chart. Project usage is visible to admins and owners. If you do not have access to a project, its usage is included, but the project name is hidden. Editors, admins, and owners can view their own build usage. Usage for other workspace members is visible to admins and owners only. On Enterprise workspaces, all usage details are visible to admins and owners only. ## Credit top-ups Credit top-ups are available on **Pro and Business plans**. Use them to add credits to your workspace balance so you can continue building your app, hosting and running it with Lovable Cloud, and using AI features in deployed apps. Workspace **owners** and **admins** on paid plans can add credits in two ways: * **Auto top-up**: add credits automatically when your balance runs low * **One-time top-up**: buy credits manually when you need them You can buy credit top-ups from: * **Settings → Plans & credit usage** * The **low-credits alert in chat** when you’re running out of credits Pricing depends on your plan. Top-up credits are purchased outside your monthly subscription, so they have their own price per credit. | Plan | Top-up price | Price per credit | | -------- | ------------------- | ----------------- | | Pro | \$15 per 50 credits | \$0.30 per credit | | Business | \$30 per 50 credits | \$0.60 per credit | Credit top-ups are billed as one-time payments through Stripe. An invoice or receipt is generated for every purchase. Top-up credits are valid for **12 months** from your most recent purchase. If you consistently need more credits each month, upgrading your plan is usually better value. See [Subscription plans](/introduction/subscription-plans) for more information. ### Auto top-up Auto top-up automatically purchases credits when your balance reaches or falls below a threshold you set. Use it to keep building your app, hosting and running it with Lovable Cloud, and using AI features in deployed apps when your balance gets low. Top-ups run as often as needed, as long as the next top-up would not exceed your monthly spend limit. Go to **Settings → Plans & credit usage**. Select **Add credits → Auto top-up → Set up**. Choose when auto top-up runs, how many credits it adds, and the maximum amount it can add each month. * **Top-up amount**: the number of credits added to your workspace each time auto top-up runs. * **When my balance falls below**: the credit threshold that triggers the auto top-up. Auto top-up runs when your balance reaches or falls below this amount. * **Monthly spend limit:** the maximum number of credits auto top-up can add in a calendar month. You are charged only for credits actually added. Use this to control monthly top-up charges, or leave it at **No limit**. | Setting | Default | Credit options | | :-------------------------- | :---------- | :---------------------------------------------------------------------- | | Top-up amount | 100 credits | 50, 100, 150, 200, 300, 500, 1,000 credits | | When my balance falls below | 25 credits | 25, 50, 100 credits | | Monthly spend limit | 400 credits | 100, 200, 400, 1,000, 2,000, 5,000, 10,000, 25,000 credits, or No limit | Select **Turn on auto top-up**. The UI shows the cost for each top-up and, if you set a monthly spend limit, the maximum monthly cost. Your default payment method is charged only when a top-up is triggered. Auto top-up runs only if both conditions are met: 1. Your balance reaches or falls below your selected threshold. 2. The top-up would not exceed your monthly spend limit. The monthly spend limit resets on the 1st of each calendar month at 00:00 UTC, displayed in your timezone. It is not tied to your subscription billing cycle. **Auto top-up is paused when you upgrade from Pro to Business** If you upgrade from Pro to Business, Lovable pauses auto top-up, because the price per credit changes with your plan. Review your auto top-up settings after upgrading and re-enable it if the new pricing works for you. Re-enabling auto top-up or saving new auto top-up settings clears the pause. ### Turn off auto top-up Workspace owners and admins can turn off auto top-up at any time to stop further automatic credit purchases. Go to **Settings → Plans & credit usage**. Click **Edit** next to **Auto top-up enabled.** Click **Turn off auto top-up** to stop future automatic charges. Your existing credit balance is not affected. Turning off auto top-up does not refund previous purchases. You can still add credits manually with a one-time top-up at any time. ### One-time top-up Use a one-time top-up to add credits manually without changing your subscription. This is useful if you run out of credits mid-cycle or have occasional spikes in usage. Go to **Settings → Plans & credit usage**. Select **Add credits**, then select **Buy once**. Choose between 50, 100, 150, 200, 250, 300, 400, 500, 1,000, 2,000, 3,000, 5,000, or 10,000 credits. The UI shows the cost before you buy. Select **Buy credits** and confirm payment. Credits are added to your workspace instantly. Multiple purchases are allowed. ## Alerts and notifications Lovable shows alerts when your workspace is close to a limit, runs out of credits, or needs billing attention. Alerts can appear as chat nudges, in-app banners, blocking dialogs, inline messages, or emails to workspace owners and admins. You may be notified when: * **Your workspace is running low on credits.** A nudge appears above the chat input with your remaining credits and an option to add more. * **Your workspace runs out of credits.** When you try to continue building your app, Lovable shows a blocking dialog and building stops until credits are available. * **A deployed app is paused because your workspace has no available credits.** Lovable shows an in-product message when a deployed app that relies on Lovable Cloud or AI features pauses. * **Cloud or AI gateway usage approaches a limit.** Lovable shows an in-app alert on the **Plans & credit usage** page. * **Credits are expiring soon.** A chat nudge may appear when top-up or rollover credits are nearing expiry. * **Auto top-up fails.** Lovable emails workspace owners and admins and shows an in-app banner with options to retry the charge or update the payment method. * **Auto top-up reaches its monthly spend limit.** Lovable emails workspace owners and admins when auto top-up reaches the monthly spend limit you set. * **A non-admin runs out of credits.** They can send a credits ping to workspace owners and admins asking them to add credits. If your workspace runs out of credits, building stops, and deployed apps that rely on Lovable Cloud or AI features can pause until credits are available again. To keep your workspace and apps running: * **Free plan:** upgrade to a paid plan to get more credits and unlock top-ups. * **Paid plans:** enable auto top-up, or add credits with a one-time top-up. To prevent deployed apps from stopping because of an empty balance, enable **auto top-up** on Pro or Business plans. Lovable then adds credits automatically when your balance falls below a threshold you set. For busier apps, set a higher trigger threshold, such as **50** or **100 credits**, so credits are added before your balance gets close to zero. You can also review **Usage details** over a 90-day range to see whether your usage is trending up. ## FAQ Previous Cloud and AI balances were converted using each workspace’s **plan credit rate**. Pro and Business use different plan credit rates because Business plans include additional functionality, such as advanced controls and governance features. For the full feature comparison, see [Subscription plans](/introduction/subscription-plans). | Plan | Plan credit rate | Example conversion | | :------- | :---------------- | :-------------------------- | | Pro | \$0.25 per credit | \$10 converts to 40 credits | | Business | \$0.50 per credit | \$10 converts to 20 credits | Because Pro and Business use different plan credit rates, the same previous Cloud and AI balance can convert into a different number of credits depending on the workspace plan. This does **not** mean Cloud or AI gateway usage is cheaper on Business. It means fewer credits are deducted because each Business credit represents more dollars. The number of credits is different, but the Cloud and AI gateway value is the same. Usage stops as soon as no applicable credits are available. Deployed apps stop responding to new requests. Service resumes when credits become available again, either through a one-time top-up, auto top-up, or the next applicable grant refresh. Free plan monthly grants refresh on the 1st of each calendar month at 00:00 UTC. Pro and Business monthly Cloud and AI grants refresh with the subscription billing cycle. Without credits, you cannot continue building your app. Go to **Settings → Plans & credit usage**. From there, you can upgrade your plan or, if you’re on a **Pro or Business plan**, buy one-time credit top-ups without changing your subscription. For plan upgrades and subscription tiers, see [Subscription plans](/introduction/subscription-plans). Yes. Different credit types expire at different times: * Monthly plan credits expire 2 months after issue on monthly plans. On annual plans, monthly plan credits are issued monthly and expire 1 month after the annual billing period ends. * Top-up credits expire 12 months after purchase. * Monthly Cloud grants expire at the end of the calendar month on Free plans, and at the end of the billing cycle on Pro and Business plans. * Monthly AI grants expire at the end of the calendar month on Free plans, and at the end of the billing cycle on Pro and Business plans. * Daily build credits expire at the end of the day. Your balance breakdown shows the expiry date of each general credit grant. Lovable spends soonest-expiring general credits first to minimize what you lose. No. Unused usage-specific grants do not roll over. * Daily build credits refresh every day at 00:00 UTC. * On Free plans, monthly Cloud and AI grants refresh on the 1st of each calendar month at 00:00 UTC. * On Pro and Business plans, monthly Cloud and AI grants refresh with the subscription billing cycle. Free, Pro, and Business plans all include a 4-credit monthly AI grant for AI gateway usage in deployed apps. On Free, the grant refreshes on the 1st of each calendar month at 00:00 UTC. On Pro and Business, it refreshes with the subscription billing cycle. Unused AI grant credits do not roll over. Enterprise plans do not include the monthly AI grant. Contact your account team for account-specific details. Monthly plan credits are granted at the start of each billing period. This happens every month on the same date your subscription started. On annual billing, monthly plan credits are still issued monthly and expire 1 month after the annual billing period ends. To see your billing period, go to **Settings → Plans & credit usage**. Yes. You can quickly check your credit balance from the dashboard or from a project. From the dashboard, click your workspace name in the top-left. From a project, click the project name in the top-left of the editor. Yes. Open **Usage details** from **Plans & credit usage**. You can filter by project across **All credits**, **Build credits**, and **Run credits**. You can filter by member or group (on Business and Enterprise) when viewing **Build credits**. Yes. Workspace owners and admins can set monthly credit limits for workspace members. Member credit limits apply to build usage only: Cloud and AI gateway usage from deployed apps does not count against a member's monthly limit. There are two types of member credit limits: | Limit type | What it does | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Default monthly member credit limit | Sets the default number of credits each member can use per calendar month. This applies to all members who do not have an individual override. Leave it empty to use no limit. | | Individual member credit limit | Sets a custom monthly credit limit for a specific member. This overrides the workspace default for that member. Available on all paid plans. | To set the workspace default, go to your workspace settings and update **Default monthly member credit limit**. See [General workspace settings](/features/workspace-admin-settings#general-workspace-settings).  To set an individual member limit on all paid plans: 1. Go to **Settings → People**. 2. Click the three-dot menu at the end of the member's row. 3. Select **Set credit limit**. 4. Enter the monthly credit limit and save. Member credit limits reset on the 1st of each month at 00:00 UTC, independent of your workspace billing cycle. When a member reaches their limit, they cannot use more workspace credits until the limit resets or an owner or admin changes their limit. Workspace owners and admins can manage the plan, top-ups, and auto top-up. Editors, admins, and owners can view total usage and their own build usage. Project usage and other members’ usage are visible to admins and owners only. If someone does not have access to a project, the project name is hidden. On Enterprise workspaces, usage details are visible to admins and owners only. ## Troubleshooting If an auto top-up fails, Lovable shows a banner in the workspace dashboard and in **Settings → Plans & credit usage**. This can happen if your card is declined, expired, or no longer available. Use **Retry charge** to run the auto top-up again with your current default payment method. The banner is dismissed once the retry succeeds. Use **Update payment method** to open the Stripe customer portal and add or change your card. The next auto top-up attempt uses your updated payment method. Workspace owners and admins also receive an email when an auto top-up is declined. If your credit balance reaches zero before the charge succeeds, building your app, hosting and running apps with Lovable Cloud, and AI features in deployed apps stop until credits are added. When you upgrade from Pro to Business, Lovable automatically pauses auto top-up because the per-credit top-up price changes. This prevents your next top-up from being charged at the new Business price without confirmation. After the upgrade, Lovable shows a prompt in the workspace dashboard and in **Settings → Plans & credit usage**. You can re-enable auto top-up at the new Business price. Your previous top-up amount and monthly spend limit are preserved, so you only need to confirm. You can also keep auto top-up off and use one-time top-ups instead. Auto top-up stays paused until you choose one of these options. Re-enabling auto top-up or saving new auto top-up settings clears the pause. Check **Settings → Plans & credit usage** for your credit balance. If your balance and any applicable monthly Cloud or AI grants are at zero, add credits, enable auto top-up, or wait for the next applicable grant refresh. On Free plans, monthly Cloud and AI grants refresh on the 1st of each calendar month at 00:00 UTC. On Pro and Business plans, monthly Cloud and AI grants refresh with the subscription billing cycle. To prevent this in the future, consider enabling auto top-up on Pro or Business plans and reviewing **Usage details** to understand which projects or usage types are consuming credits. You may have reached your monthly cap for daily build credits. Daily build credits are capped per calendar month on Free plans only. Free workspaces receive 5 daily build credits, up to 30 per calendar month. After a Free workspace reaches the cap, the daily 5 credits stop being granted for the rest of that calendar month. Daily build credits resume on the 1st of the next calendar month at **00:00 UTC**. For example, on Free, you receive daily build credits for the first 6 days each month (6 × 5 = 30), then none until the next month starts. Pro and Business workspaces receive 5 daily build credits every day at 00:00 UTC, with no monthly cap. If you need more credits before then, upgrade your plan or add credits with a one-time top-up on a Pro or Business plan. # Dashboard overview Source: https://docs.lovable.dev/introduction/dashboard-overview Learn how to navigate the Lovable dashboard, start new projects, and access your workspace settings. The dashboard is your home base in Lovable. It's where you create new projects, access existing ones, and navigate to your workspace settings. lovable-dashboard ## Starting a new project The prompt input box is front and center on the dashboard. Type a description of what you want to build and click send to create a new project. See [Quick start](/introduction/getting-started) for more information. For every way to start a project, see [Ways to create a project](/features/projects/overview#ways-to-create-a-project). ### The prompt input Type your idea into the text field or click the microphone button to use voice input and dictate your prompt. Lovable uses your description to generate a working app. You can be as brief or detailed as you like, for example, `a todo app with dark mode` or a multi-paragraph specification. See [Prompting best practices](/prompting/prompting-one) for more information. ### The `+` menu Click the `+` button to the left of the input to access additional options: * **Attach**: Upload images or files to include as context for your project or capture and attach a screenshot for Lovable to reference * **Design:** Choose from the [template](/features/business/design-templates) library to start with a pre-built foundation (Business and Enterprise plans) or select a [design system](/features/design-systems) to apply consistent styling (Enterprise only) * **Connectors:** Connect [Lovable Cloud](/features/cloud) or [Supabase](/integrations/supabase) for database and backend services, connect [chat connectors](/integrations/mcp-servers) (MCP servers) for context while you build, and manage [connectors](/integrations/introduction) for deployed apps ### Project access Project access defaults to **workspace** on all plans and can be managed from the **Share** button in the top bar of any project. Additionally, on Business and Enterprise plans, you can adjust project access even before creating the project. See [Project access](/features/project-visibility) and [Share a project](/features/share-project) for more information. ### Build mode vs Plan mode Use the mode toggle next to the send button to switch between: * [Build](/features/agent-mode): Lovable generates and modifies code in your project (default) * [**Plan**](/features/plan-mode): Discuss and plan your project without making code changes ## Sidebar and navigation The sidebar on the left gives you access to everything in your workspace. Click the collapse/expand button at the top of the sidebar, or press `Cmd+B` (Mac) / `Ctrl+B` (Windows/Linux). Navigation items show tooltips on hover when the sidebar is collapsed. ### Workspace selector At the top of the sidebar, click your workspace name to switch between workspaces you belong to. Each workspace has its own projects, members, and billing. Learn more about workspaces in [Lovable workspace](/features/workspace). ### Navigation * **Home**: Return to the dashboard home page * **Search**: Open the [command palette](/introduction/project-search-and-find#command-palette) to find projects, folders, and settings. Keyboard shortcut: `Cmd+K` (Mac) or `Ctrl+K` (Windows/Linux). * **Resources**: Browse templates to remix and build your next project * **Connectors**: Browse and manage available [app and chat connectors](/integrations/introduction) ### Projects section Expandable groups for navigating your projects: * **All projects**: Opens the full projects list. Expand the chevron in the sidebar to see your [folder tree](/introduction/project-folders) and navigate directly to folders. * **Starred**: Projects you've starred for quick access * **Created by me**: Projects you own * **Shared with me**: Projects and [folders](/introduction/project-folders) others have shared with you See [Find and search projects](/introduction/project-search-and-find) for more information. ### Recents section Below the projects section, the sidebar shows your recently accessed projects, ordered by last access time. ### Share Lovable The referral card at the bottom of the sidebar lets you share Lovable with others. You earn **100 credits for each paid referral** who signs up through your link. Not available on Enterprise plans. ### Upgrade plan If you're on a Free or lower-tier plan, an upgrade card appears in the sidebar. Click it to view available plans and upgrade your workspace for more credits and features. See [Subscription plans](/introduction/subscription-plans) for more information. ## Manage projects from the dashboard Your projects appear as cards. Each card shows the project's name and a preview, and a **Published** badge appears once the project is live, linking straight to the published app. Hover over a card to star the project, copy links from the share menu (**Copy project link** and **Copy published app link**), or open the three-dot menu: * **Open in new tab**: Open the project in a new browser tab. * **View published site**: Open the live app. Available once the project is [published](/features/publish). * **Analytics**: Open your published app's [analytics](/features/analytics). * **Move to folder**: Organize the project into a [folder](/introduction/project-folders). * **Remix**: Create an independent copy of the project. See [Remix a project](/features/projects/remix). * **Transfer to workspace**: Move the project to another workspace. See [Move a project to another workspace](/features/projects/settings#move-a-project-to-another-workspace). To rename a project, open its settings, or delete it, open the project and use the project name menu or [Project settings](/features/projects/settings). ### Select several projects at once On desktop, click and drag across an empty area of the project list to select multiple projects, or press **Ctrl+A** (**Cmd+A** on Mac) to select all. On touch devices, press and hold a card. A toolbar appears with the actions you can run on the whole selection: * **Move to folder**, or **Remove from folder** when you're inside a folder * **Transfer** the selected projects to another workspace * **Delete** the selected projects. This appears only when you can delete everything you selected: projects you own, or any project if you're a workspace owner or admin. * **Unstar**, when selecting projects in your **Starred** list Use **Clear** to empty the selection and start over, or **Cancel** (**Esc**) to exit selection mode. ## User menu Click your avatar at the bottom-left of the sidebar to open the user menu. From here, you can access the following: * **Profile**: View your public profile page * **Settings**: Opens your account settings. Shortcut: `Cmd+.` (Mac) / `Ctrl+.` (Windows/Linux) * **Appearance**: Customize your Lovable dashboard look * **Background gradient**: Choose between visual themes for the dashboard background * **Color theme**: Switch between light, dark, or system (follows your OS preference) You can also change the theme quickly via `Cmd+K` → type "theme". * **Support**: Access various help resources * **Documentation**: Links to docs and resources * **Community**: Visit the Lovable community * **Homepage**: Go to [lovable.dev](http://lovable.dev) * **Sign out**: Log out of your account ## Inbox and notifications Click the inbox icon next to your avatar to open the notification panel. A count badge shows unread items, and a red dot indicates new notifications. ### Inbox tab The Inbox tab shows pending actions that need your attention: * **Workspace invitations**: Accept or decline invitations to join a workspace * **Project invitations**: Accept or decline invitations to collaborate on a project * **Project access requests**: Approve or deny requests from others wanting access to your projects * **Workspace access requests**: Approve or deny requests from others wanting to join your workspace * **General notifications**: System notifications ### What's new tab The **What's new** tab shows feature announcements and product updates, including: * New integration launches and connector availability * Product feature releases * New Lovable changelog announcements ## Keyboard shortcuts | Shortcut | Action | | ------------------ | ----------------------------- | | `Cmd+K` / `Ctrl+K` | Open search (command palette) | | `Cmd+B` / `Ctrl+B` | Toggle sidebar | | `Cmd+.` / `Ctrl+.` | Open your account settings | # Delete account Source: https://docs.lovable.dev/introduction/delete-account Permanently delete your Lovable account, with a 30-day grace period to change your mind. Deleting your Lovable account removes your sign-in, your profile, and any data tied to you as an individual. It's a one-way action, but Lovable gives you a **30-day grace period** during which you can sign back in and **cancel the deletion** before it finalizes. This page covers what gets deleted, how the flow works, and how to undo a scheduled deletion. Deleting your account is different from leaving a workspace or canceling a subscription. If you only want to step away from a team or manage your subscription plan, see [Leave a workspace](/features/workspace#leave-a-workspace) or [Subscription plans](/introduction/subscription-plans) for info on downgrading or canceling a subscription. ## Before you delete Account deletion is irreversible after 30 days. If you still want to proceed, keep these things in mind: * **Workspaces you own.** You must [transfer workspace ownership](/features/people) of any workspace you're the only owner of. If you don't, the workspace and everyone's projects in it will be deleted along with your account. * **Active subscriptions.** Any active workspace subscriptions tied to workspaces you own are canceled when those workspaces are deleted. * **Projects you want to keep.** [Move them to another workspace](/features/projects/settings#move-a-project-to-another-workspace) or [transfer project ownership](/features/projects/settings#transfer-project-ownership) before deleting. * **Username.** Your `@username` becomes available for someone else to claim once the 30-day window expires. ## What gets deleted When deletion finalizes (after 30 days), Lovable permanently removes: * Your **active subscriptions** * Any **workspaces you own**, unless you transferred ownership before deletion * Your **workspace memberships** and **pending invitations** * Your **account** and all associated data: profile, username, linked accounts, MFA enrollments, preferences, and skills ## How deletion works Account deletion uses a **30-day grace period**. When you confirm: * Your account is **scheduled for deletion** 30 days from the day you confirm. * You're signed out of all sessions and you cannot keep using Lovable. * For the next 30 days, your account remains **recoverable**. You can sign back in and cancel. * Active workspace subscriptions continue billing. Cancel any subscriptions you don't want to be charged for. * **After 30 days**, your account, profile, and any data not transferred to another workspace are **permanently removed**. ## Deletion flow Open **Settings → Your account → Delete account** and click **Delete account**. The dialog walks you through these steps: 1. **Workspaces.** If you're the **only owner** of any workspace, you must first [transfer workspace ownership](/features/people) to another member otherwise the workspace is also deleted. Type the workspace name to confirm each one. 2. **Email confirmation.** Type your account email to confirm. 3. **Reason.** Pick a reason for leaving (required) and optionally add details. This helps us improve the product. 4. **Confirm deletion**. Click **Delete account** to confirm deletion. You'll see a **Deletion scheduled** confirmation, then be signed out automatically. ## Cancel deletion within 30 days To cancel a scheduled deletion before the 30-day window expires: 1. Sign back in to [**lovable.dev**](http://lovable.dev) with the same account. Lovable shows you a full-screen **Account scheduled for deletion** page, including your scheduled deletion date. 2. Click **Keep my account** to cancel the deletion. Your account is restored immediately. A **Deletion canceled** toast message confirms the action. Your sign-in, profile, workspaces, and preferences all return to exactly how they were before you scheduled deletion. If you sign in but aren't ready to decide yet, click **Sign out** on the same page. Your account stays scheduled for deletion, and you can come back later within the 30-day window. # Delete a workspace Source: https://docs.lovable.dev/introduction/delete-workspace Permanently delete a workspace you no longer need, with a 60-day grace period during which Lovable support can restore it. Workspace owners can delete a workspace they no longer need. Deleting a workspace removes the workspace itself, all projects in it, all member access, and the workspace's billing relationship with Lovable. When you confirm deletion, members lose access immediately and the workspace is scheduled for permanent deletion. Lovable gives you a **60-day grace period** during which Lovable support can restore the workspace before deletion finalizes. Workspace deletion is available on Free, Pro, and Business plans. To delete an Enterprise workspace, contact your Lovable account team. Deleting a workspace is different from: * **Leaving a workspace.** If you only want to step away from a team, see [Leave a workspace](/features/workspace#leave-a-workspace). * **Canceling a subscription.** If you want to cancel or downgrade the plan, see [Subscription plans](/introduction/subscription-plans). * **Deleting your account.** If you want to remove your Lovable account entirely, see [Delete account](/introduction/delete-account). ## Before you delete Workspace deletion is irreversible after 60 days. Before you proceed: * **If the workspace has other owners**, coordinate with them first. Any owner can delete the workspace on their own. * **Transfer any projects you want to keep** to another workspace. Once deletion finalizes, every project inside the workspace is deleted with it. ## What happens when you delete a workspace When you confirm deletion: * Members lose access immediately. * Projects stop serving traffic on their `*.lovable.app` URLs. * The workspace disappears from your workspace switcher. * The workspace's subscription is scheduled to cancel at the end of the current billing period. * Any eligible open invoices are voided automatically. You will not be billed for the next cycle. When deletion finalizes after 60 days, Lovable permanently removes: * The workspace and all of its projects * All members and pending invitations * Connected integrations and any keys or tokens stored for them * Custom domains and branded URLs ## How to delete a workspace Only workspace owners can delete a workspace. 1. Open **Settings → Workspace**. 2. Scroll to **Delete workspace** and click **Delete workspace**. 3. Review how many members and projects will lose access. 4. Type the workspace name exactly as shown. 5. Click **Delete workspace**. You are returned to the dashboard. If you belong to other workspaces, Lovable switches you to one of them. ## Restore a deleted workspace During the 60-day grace period, contact [Lovable support](https://lovable.dev/support) to restore the workspace. Include the workspace name or ID. Restoring brings back the workspace, its projects, member access, and subscription state where possible. After 60 days, the workspace and everything in it is permanently deleted and cannot be recovered. # FAQ Source: https://docs.lovable.dev/introduction/faq Answers to common questions about building apps, managing projects, account settings, security, and how Lovable works. ## Getting started Lovable is an AI-powered platform that enables users of any skill level to create full-stack websites through natural language. Simply describe what you want, and Lovable builds it for you. A **workspace** is the shared space where you and the people you invite build together. It holds your projects, members, billing, and settings in one place, and every project lives inside a workspace. Key things to know: * Your plan and credits belong to the workspace, not to individual members. Everyone in the workspace builds from the same shared credits. * A workspace is how you buy Lovable for a group of people: upgrade one workspace to a paid plan, invite everyone into it, and the whole group builds from one subscription on one invoice. * Membership is unlimited on all plans, and plans are priced by credits, not seats. * Each member can create and work on as many of their own projects as they want inside the shared workspace. * Workspace owners and admins can set a [default monthly credit limit](/features/workspace-admin-settings#general-workspace-settings) and [per-member overrides](/features/people#set-a-per-member-credit-limit) so no single person uses up the shared credits. * You can belong to several workspaces and switch between them at any time. See [Workspace](/features/workspace) for more information. If you can imagine it, you can build it with Lovable. From simple landing pages to powerful tools tailored for niche use cases, Lovable gives you the flexibility to create whatever you need, without limits. No. Lovable is designed for all levels of experience. Whether you're a developer or a non-technical user, you can create websites using Lovable. To create a project, simply type a message into the message box on the dashboard. See [ways to create a project](/features/projects/overview#ways-to-create-a-project). Just describe what you want to build and Lovable will take it from there and generate a starting point for your project. Remember to start small and build in increments! Yes, you can remix projects with public remixing enabled, one of your own projects, or projects you have access to. Remixing allows you to reuse the current state of a project as a starting point and build upon it. It’s a great way to explore new ideas, make adjustments, or iterate with different changes while preserving the original version. See [Remix a project](/features/projects/remix). ## Building with Lovable Building efficiently with Lovable is all about using the right techniques. Anyone can do it with a bit of practice. To help you get started, check out our [guide](https://mastering-lovable.lovable.app/). * Be clear and specific. * Focus on one feature at a time. * Build incrementally. * Use buzz-words for getting the design right. Use **Try-to-fix** option. Lovable will try to solve the issue automatically. Using the button doesn't deduct any credits. If **Try-to-fix** doesn't resolve the issue, ask the Lovable Agent to investigate the issue. Explain what you are seeing and what specific parts aren't working. If that doesn’t work, you can preview an older working version and then revert to that version if needed, or revert and edit a past message to explore a different approach. Nothing gets lost — all changes made after that point stay in the chat and can be reapplied anytime. Refactoring improves code structure and efficiency without altering functionality. It helps: * Optimize performance by removing redundancies. * Improve maintainability for future updates. * Prevent conflicts by structuring logic more clearly. If you need to add backend capabilities to your application, you can: * Connect to Lovable's built-in backend - [Lovable Cloud](https://docs.lovable.dev/features/cloud) * Use Lovable's native [Supabase integration](https://docs.lovable.dev/integrations/supabase) Yes, you can add authentication by using [Lovable Cloud](https://docs.lovable.dev/features/authentication) or integrating with [Supabase](https://docs.lovable.dev/integrations/supabase). Simply prompt the AI to add it and follow the instructions. Yes, you can integrate APIs like OpenAI, Stripe, and more by specifying them in your prompt. Read more [here](/integrations/introduction). No! Never enter your API keys directly in Lovable. If you're integrating with an API, we recommend you use [secrets in Lovable Cloud](https://docs.lovable.dev/features/secrets) or [Supabase](https://docs.lovable.dev/integrations/supabase) to store your API keys, so they are only used in backend code and never exposed in the browser. See [Add payments to your app](/features/payments) for detailed instructions. Use the built-in [SEO & AI search review](/features/seo-aeo) to check metadata, indexing, structured data, accessibility, performance, mobile usability, sitemap configuration, `robots.txt`, and other technical SEO issues. Lovable can also help you: * Research keywords, competitors, backlinks, and content opportunities using Semrush-powered SEO research * Configure [Google Search Console](/integrations/google-search-console) and submit your sitemap * Optimize metadata, Open Graph previews, and structured data * Improve AI-search visibility through semantic HTML, `llms.txt`, and structured Markdown rendering * Connect [custom domains](/features/custom-domain) and manage canonical URLs For implementation guidance and ongoing maintenance best practices, see [Optimize your app for SEO and AI search](/features/seo-aeo). It depends on complexity. By breaking tasks into smaller steps, planning ahead, and refining based on feedback, you can move quickly while ensuring quality. ## Features You can find the **Project settings** by clicking your project name at the top left of the editor and then selecting **Settings**. See [Project settings](/features/projects/settings) for everything you can manage there. Yes, from the **Share** button in the top bar of any project. See [Share a project](/features/share-project) for more information. Yes. When navigating to a private project, you can request viewer or editor access from the project owner. This keeps private work secure while making collaboration easier. Yes. The "Edit with Lovable" badge shown on published apps can be hidden on paid plans. Go to **Project settings → Publishing** and turn on **Hide Lovable badge**. The setting is per project, so toggle it for each project separately. See [Project settings](/features/projects/settings#publishing). The change takes effect on your live site right away, no republish needed. If you later downgrade, your live site keeps the badge hidden until your next publish, when the badge returns and the setting turns off. See [What turns off when you downgrade](/introduction/subscription-plans#what-turns-off-when-you-downgrade). Yes, navigate to the **Project settings** where you'll find the option to rename the project. See [Project settings](/features/projects/settings#details). To make a copy of a project, you **remix** it. Go to the **Project Settings** and select the **Remix** option. Remixing creates a copy of the project in your currently selected workspace. You can then edit it independently. The **Include project history** toggle controls whether the copy includes the original chat history. It does not copy version history. Secrets and database data are never copied. See [Remix a project](/features/projects/remix) for the full guide, including what carries over to the copy. Projects connected to an external Supabase project can only be remixed by people with edit access to the source project. Yes, navigate to the **Project settings** where you'll find the option to **Delete** the project. See [Project settings](/features/projects/settings#danger-zone). This is final and there is no way to restore deleted projects. Plan mode (previously Chat mode) is ideal for planning features, debugging issues, and understanding changes before writing or modifying code. See [Brainstorm with Plan mode](/features/plan-mode) for more information. No. Lovable manages the underlying model used by the agent in [Build mode](/features/agent-mode) and [Plan mode](/features/plan-mode). The agent runs on current frontier models, and Lovable rolls out model upgrades automatically to all users, so there is no setting to switch the agent between specific models. If you want to choose a specific model for AI features inside your own deployed app, see [AI features for your app](/features/ai), which lists the supported models you can call from your app. Yes. You can see the code and manually edit the code using Lovable's [Code mode](/features/code-mode). Yes, you can edit text or colors using the [preview toolbar](/features/preview-toolbar). Yes, you can collaborate on projects inside Lovable. See [Collaboration](/features/collaboration) for more information. See [Publish](/features/publish) and follow the steps outlined there to publish your project. See [Custom domain](/features/custom-domain) to add a custom domain to your project. Yes. See [Project analytics](/features/analytics) for more information. Yes. Images as design inspiration, sketches of your desired layout, or screenshots of UI flaws are super helpful while designing your website. Videos aren’t supported yet, but screenshots can often do the job. Yes. You can [download your codebase as a zip](/features/code-mode#download-your-projects-codebase) from the code editor, or transfer your code to GitHub or GitLab and do whatever you'd like with it. See [GitHub integration](/integrations/github) for more information. No, currently there is no way to start a Lovable project from already existing code on for example GitHub. You can view your project history by simply scrolling up in the chat or pressing the **History** toggle at the top of the editor. You can also select older versions to preview them or restore your project to that version. See [Version history](/features/projects/history). Yes. You can preview an older working version and then revert to that version if needed, or edit a past message and revert to explore a different approach. Nothing gets lost — all changes made after that point stay in the chat and can be reapplied anytime. * Find the option to revert under each response in the chat or in the history tab when you select the version you want to revert to. * Find the option to edit a past message and revert under each past message you sent in the chat. See [Version history](/features/projects/history) for the full guide. Reverting restores your project's code only. It does not restore or roll back database data, so records created or deleted after that version stay as they are. ## Lovable API The **Lovable API** makes it possible to create and share Lovable apps programmatically — turning ideas, prompts, or even images into fully-generated applications with a single link.  The first release, **Build with URL**, allows you to generate apps directly from a shareable URL. With it, you can: * Embed a **Build with Lovable** button on your website or application. * Share predefined prompts via URLs with friends, colleagues, or on social media. * Automate app generation as part of internal workflows. * Rapidly prototype apps using URLs with prompts and reference images. Learn about the feature and real-world use cases in our announcement post: [Build apps from a link with Lovable Build with URL](https://lovable.dev/blog/introducing-lovable-api-build-with-url). Read the full technical guide here: [Lovable API: Build with URL documentation](https://docs.lovable.dev/integrations/build-with-url). ## Managing your account Unfortunately, changing the email address directly is not possible at this time. As a workaround, you can create a new account with your desired email address and move your projects into it by remixing them. See [Move a project to another account](/features/projects/remix#move-a-project-to-another-account) for the steps. To delete your account, go to **Settings → Your Account**, scroll down and press **Delete account**. This will permanently remove your account and all associated data. See [Delete account](/introduction/delete-account) for more information. No, you can't reactivate a deleted account. However, you can cancel a scheduled deletion within 30 days. See [Delete account](/introduction/delete-account) for more information. Yes, if you are the current workspace owner. Only an owner can promote existing members to owner. Go to **Settings → People**, and click the role dropdown next to the member’s row, then choose a new role. Changes take effect immediately. See [People](/features/people) for more information. Yes. Workspace owners can delete a workspace from **Settings → Workspace → Delete workspace**. Members lose access immediately, and the workspace is permanently deleted after a 60-day grace period during which Lovable support can restore it. See [Delete a workspace](/introduction/delete-workspace) for more information. Go to **Project settings → Transfer ownership** and select a workspace member. The new owner must be a full workspace member. See [project roles](/features/projects/overview#project-roles). Collaborators and pending invitees are not eligible. Invite them as a member from **Settings → People** first. The new owner will have full control of the project. Your access after the transfer depends on your workspace role. **Two-factor authentication (2FA)** adds an extra layer of security to your Lovable account by requiring a one-time code when you sign in, in addition to your usual sign-in method. To enable 2FA, go to **Settings → Your account**. See [Two-factor authentication (2FA)](/introduction/two-factor-authentication-2-fa) for more information. Lovable identifies **skills** based on how you use the platform across your projects. If you have any skills, you can find them in **Settings → Your account**. To qualify for a skill in a category: * You must have actively worked on a project, with at least **5 user messages** sent in that project. * Within those projects, at least one app you built must have at least **20 visitor sessions** to the live app (bot traffic excluded). * Accounts flagged for fraud or abuse are not eligible. You can optionally post one skill to your LinkedIn profile by clicking **Add to LinkedIn** next to the skill. The skill appears publicly under **Licenses & certifications** and updates automatically. Only one skill can be posted to LinkedIn at a time, and you can disconnect at any time. See [Skills](/introduction/lovable-account-settings#linkedin-skills-beta) for more information. ## Policies and security Go to [Help & Support](https://lovable.dev/support) and use the support form. If the form is unavailable, you can email [support@lovable.dev](mailto:support@lovable.dev). See the [support policy](/introduction/support-policy) for details on response times and coverage. Go to [Privacy policy](https://lovable.dev/privacy). Go to [Terms of Service](https://lovable.dev/terms). Please see our [Terms of Service](https://lovable.dev/terms) to read more about our refund policy. Yes, Lovable is compliant with industry-recognized security standards and follows best practices for data protection and risk management. We undergo independent third-party audits and maintain certifications such as ISO 27001:2022 and SOC 2 Type II. You can view our current compliance status, subprocessors and policies [here](https://trust.lovable.dev/) Yes, Lovable is fully GDPR compliant. We follow strict data protection and privacy practices in accordance with the General Data Protection Regulation (GDPR), which applies to all organizations handling personal data of individuals within the EU. Our systems are continuously monitored to ensure compliance, and we are committed to protecting user data globally. Enable **two-factor authentication (2FA)** from your account settings (**Settings → Account → Your account**). See [Two-factor authentication (2FA)](/introduction/two-factor-authentication-2-fa) for more information. ## How Lovable works New Lovable apps created from May 13, 2026 use TanStack Start with server-side rendering (SSR), except on Enterprise plans. Older apps use React + Vite. These apps continue to work as before and use prerendering on deployed public URLs so search engines, social-preview bots, and AI crawlers can read rendered content. Both stacks are designed to support [SEO and AI search visibility](/features/seo-aeo) without requiring external prerendering. Lovable uses Tailwind for styling and supports backend functionality through [Lovable Cloud](/features/cloud), [Supabase](/integrations/supabase), and [third-party APIs](/integrations/introduction). Lovable builds **web applications**, and you can design them to be fully mobile friendly. If you want an installable app on phones, there are two common paths: make your published app a Progressive Web App (PWA) that users add to their home screen, or wrap your published app with a tool like Capacitor to submit it to the App Store or Play Store. See the [publishing FAQ](/features/publish#faq) for details on both. Lovable processes recent messages to maintain context. For the best results, include relevant details in each prompt to ensure clarity and accuracy. You as the creator do! # Quick start Source: https://docs.lovable.dev/introduction/getting-started Create your first project, navigate the dashboard, add backend capabilities, and publish your app step by step Welcome to this step-by-step guide on how to create a full-stack application using Lovable: Welcome Lovable Dashboard ## The Lovable platform overview To get started, head over to [lovable.dev](https://lovable.dev) and create an account. Once registered, you'll be able to create your first project. Simply enter an initial prompt to kick things off, and Lovable will do the rest! This is the **starting block** for any project in Lovable, where you can bring your ideas to life instantly. At Lovable, simplicity is key: * [**Here**](https://lovable.dev/) **you kickstart your project** with a single prompt. * **Explore all projects**, including the latest and featured ones. * **Jumpstart with a template** from our curated selection. * **Personalize your experience** by viewing and editing your profile. * [**Manage your account**](https://lovable.dev/settings) to check monthly credits and adjust settings. * [**Upgrade or downgrade**](https://lovable.dev/settings/plans) **your plan** seamlessly. At Lovable, every project follows a structured workflow. See [Projects](/features/projects/overview) and [the project editor](/features/projects/editor) for the full picture. * **Edit with ease** using a chat-based interface. * **Attach images** for precision edits and inspiration. * **Select and visually edit components** for a seamless design experience. * **Switch effortlessly** between Build mode and Plan mode. * **Track changes** with version history and revert to any previous version. * **Navigate through pages** of your project with ease. * **Enable remixing** or rename your project as needed. * **Use Lovable Cloud** (or integrate with Supabase) for backend capabilities. * **Collaborate via GitHub** to edit and manage your code. * **Publish, deploy, and share** your project with a preview link (remember to re-publish after changes). * **Toggle between web and mobile view** for responsive design. * **Refresh the preview modal** to see updates instantly. * **Open your project directly** using the preview link. Every project’s settings ([full reference](/features/projects/settings)) empower you to: * **View key project details** like total edits and creation date. * **Set up custom knowledge** to tailor your project’s context. * **Connect to a GitHub repository** for seamless collaboration. * **Control who can access the project** from the **Share** menu, which sits outside settings. See [Share a project](/features/share-project). * **Manage the badge display** (available for paid plans only). * **Rename your project** anytime. * **Delete your project** (⚠️ Danger Zone). You can always quickly access: * **Dashboard** for an overview of your projects. * **Account settings** to manage your profile and preferences. * **Documentation and Support** for guidance and assistance. * **Log out** securely from your Lovable account. ## Start your project There are several ways to get started with Lovable, depending on your preferences and resources: Lovable’s prompt-based system makes app creation simple. * Just describe what you want to build in the prompt box. * The more specific you are, the better the results. * Start with clear and detailed prompts. * You can refine and adjust your project as you go. Example: *"Create a dashboard with user login, monthly sales in a line chart, and customer demographics in a pie chart."* You can remix projects with public remixing enabled, one of your own projects, or projects you have access to. Remixing allows you to reuse the current state of a project as a starting point and build upon it. It’s a great way to explore new ideas, make adjustments, or iterate with different changes while preserving the original version. See [Remix a project](/features/projects/remix). Projects connected to an external Supabase project can only be remixed by people with edit access to the source project. If you have a design in Figma, take a screenshot of any part of it. You can paste the screenshot directly into Lovable or drag-and-drop the image file. Once you press Enter, Lovable will convert your design into functional code. Use [**Excalidraw**](https://excalidraw.com/) or any similar tool to sketch your UI. Take a screenshot of your drawing, then paste or drag-and-drop it into Lovable. The platform will transform your sketch into working code. [More information here.](https://www.youtube.com/watch?v=c0zhLzcVJRI) If you want to replicate an existing webpage: Take a screenshot using shortcuts like *Cmd+Shift+4* on Mac or tools like the [GoFullPage Chrome Extension](https://chromewebstore.google.com/detail/gofullpage-full-page-scre/fdpohaocaechififmbbbbbknoalclacl). Paste or drag the screenshot into Lovable. Lovable will recreate the structure of the webpage in your project. [More information here.](https://www.youtube.com/watch?v=tYDqBMilHkM) ## Edit your project The [Custom knowledge](/features/knowledge) in Lovable acts as your project's **blueprint**, organizing functionality, design, and goals in one place. The preview toolbar lets you select elements on the page and either edit them instantly, such as updating text or colors, or describe changes in plain language so the agent updates them. See [Preview toolbar](/features/preview-toolbar) for more information. Speed matters when building AI-driven apps, but so do stability and control. That’s why we’ve upgraded versioning to make tracking changes effortless. See [Version history](/features/projects/history) for the full guide. You can preview an older working version and then revert to that version if needed, or edit a past message and revert to explore a different approach. Nothing gets lost — all changes made after that point stay in the chat and can be reapplied anytime. Keep your work organized by bookmarking important edits, making it easy to find and revisit them later. The history panel now works like Google Docs, making tracking changes easier.