# 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. ### 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 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/privacy-and-security-settings#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#improving-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](/features/design) 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/workspace#manage-workspace-members-and-invitations) 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/workspace#invite-via-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](/features/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#how-do-i-use-a-cdn-or-reverse-proxy-with-my-custom-domain). ### 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) You can now view your [Lovable vibe coding level](/tips-tricks/linkedin-certification) 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-paid-plans) 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-using-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/faq#how-do-i-enable-two-factor-authentication-2fa) 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](https://docs.lovable.dev/introduction/plans-and-credits#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 → Workspace → Plans & credits*. * 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*. ### 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. [Learn more about Design features](https://docs.lovable.dev/features/design). ### **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. # 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 [credit usage](/introduction/plans-and-credits#credit-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. # 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. ## 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 # Audit logs Source: https://docs.lovable.dev/features/audit-logs Monitor workspace activity with Enterprise audit logs. Filter by action, member, 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:** Settings → Workspace → 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, 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
| | **Authentication** |
  • SSO workspace access
| ## Audit log table By default, the page shows logs for **All actions**, **All members**, and **All time**. 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 `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. ## Filtering audit logs You can combine all three filters to focus on specific activity: * **All actions** lets you filter by a specific action type, such as `Member added`, `Member removed`, `Workspace updated`, `Project created`, or `Prompt sent`. * **All members** lets you select a workspace member using the searchable member picker. * **Time range** includes presets such as **All time**, **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 **member** to review activity from a specific user. 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 member popover to copy details such as user ID, IP address, or user agent if needed. ## 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. Audit logs do not currently support self-serve export. Audit log entries can be expanded to view structured JSON details, which can be copied if needed. 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. # 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 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 * It cannot upload or download files * It cannot perform right-click interactions * 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 ## 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. Go to **Project settings.** 3. Set the project visibility to **workspace.** 4. Enable **Use as a template.** 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** * **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 **Settings → Workspace → 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 **Settings → Workspace → 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. * In the Okta Admin Console, go to **Applications → Browse App Catalog**. * Search for **SCIM 2.0 Test App (Header Auth)**, then click **Add integration**. * Choose an **App label**, then finish creating the integration. Okta may prompt you to configure SAML/SSO settings while creating the integration. SCIM provisioning does not require SAML. If you already have SSO configured, you can skip SAML here and continue to provisioning. If you do need to enter SAML values, use the Lovable SSO values (ACS URL and Entity ID) from [Set up single sign-on (SSO)](/features/business/sso). * In your Okta app, go to **Provisioning → Integration**. * Click **Configure API Integration**, then enable **API Integration**. * Enter: * **Base URL**: `https://api.lovable.dev/scim/v2` * **API token**: your Lovable SCIM API key If **Test API Credentials** fails, try entering the token as `Bearer ` (include the `Bearer` prefix and a space). * If available, enable **Import Groups**, then click **Import Groups**. * Click **Test API Credentials**, then **Save**. Go to **Provisioning → To App** and make sure these are enabled: * **Create Users** * **Update User Attributes** * **Deactivate Users** * Assign users (or groups) to the Okta app. * 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 **Settings → Workspace → 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 **Settings → Workspace → 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 **Settings → Workspace → 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 **Settings → Workspace → 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. ## Troubleshooting SCIM only provisions users whose email domain is verified for your workspace. To fix: 1. Go to **Settings → Workspace → 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 **Settings → Workspace → 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 **Settings → Workspace → 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 **Settings → 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/cloud-saml-sso). That is configured per project under **Cloud → Users → Auth settings** and is a different feature. 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 only:** users must start sign-in from Lovable (SP). **Identity provider (IdP)-initiated SSO** (starting from an IdP dashboard tile) is **not supported**. ## 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 [Custom domains](/features/custom-domain) for more information. ## 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 **Settings → Workspace → 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` * 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 * Go to **Okta Admin Console → Applications.** * Click **Create App Integration** and select **OIDC**. Then select the **Web Application** application type. * Give the app a name, for example `Lovable OIDC SSO`. * Set **Grant type** to `Authorization Code` * Remove the default redirect URIs. * Add the Lovable redirect URL to Okta **Sign-in redirect URIs**: `https://auth.lovable.dev/__/auth/handler` * Select **Assignments**: assign the application to your users/groups who should access Lovable. Click **Save**. Your application is now created in Okta. In Okta, go to **Sign On → OpenID Connect ID Token**, select **Okta URL** from the Issuer dropdown, and **Save**. In Okta, copy the following value from the **Sign On** tab and enter it in Lovable. * Okta `Issuer URL` → Lovable `OIDC Issuer URL/Discovery Endpoint` In Okta, copy the following values from the **General** tab and enter them in Lovable. * 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 everything is configured correctly, the validation should be successful. In Lovable, click **Configure provider** to finish the configuration of Okta as your OIDC SSO provider. * Go to **Okta Admin Console → Applications.** * Click **Create App Integration** and select **SAML 2.0**. * Give the app a name, for example `Lovable SAML SSO`. * Single sign-on URL: `https://auth.lovable.dev/__/auth/handler` * Audience URI (SP Entity ID): `https://auth.lovable.dev/__/auth/handler` * Name ID format: `EmailAddress` Click **Finish.** Your application is now created in Okta. In Okta, go to **Sign On → SAML 2.0 → Metadata details**, and copy the **Metadata URL**. In Lovable, choose between quick SAML provider setup or manual configuration: **Option 1: Quick setup - import from 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 **Metadata URL** 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**. 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. ## 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. ## 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. 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 **Settings → Workspace → Identity** and choose the **session duration** to configure how long users stay signed in before requiring re-authentication (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. No. **IdP-initiated SSO** (starting from an IdP dashboard tile) is not supported. Lovable supports **SP-initiated sign-in only**. Users must start sign-in from Lovable. 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. 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 **Settings → Workspace → Identity** after you have configured your provider. You cannot edit your configured SSO provider. To make any updates, you first need to delete the existing SSO provider and then configure it again. # Add SAML single sign-on to Lovable Cloud apps Source: https://docs.lovable.dev/features/cloud-saml-sso Let end users of your Lovable Cloud app sign in with their company identity provider (Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, 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). That is a workspace-level setting and a different feature. ## 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. ## Why use SAML SSO * 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 * 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 * A [Lovable Cloud](/integrations/cloud) project (auth must be Lovable-managed) * SSO must be allowed by your [workspace auth policy](/features/security-center#auth-policy) * **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. * **Email domains:** Comma-separated list of 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 * **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 * **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. SP-initiated only. Users must start sign-in from your app. 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. # View and edit project code Source: https://docs.lovable.dev/features/code-mode View and manually edit your project’s source code directly in the Lovable code editor. This feature gives you direct access to your project’s underlying codebase. You can inspect files, make targeted edits, and troubleshoot issues without switching tools or exporting your project. Build Code Editor ### What you can do From the code editor view, you can: * Browse your full project file structure * Search across files and jump to specific components * Inspect and edit files directly * Format code * Copy file content * Download files * Download the full project codebase as a ZIP * Reference files in chat to make targeted edits and discussions faster and clearer **Mention code files in chat**. \ Type `@ `or click the **reference file in chat** button in the code editor to mention specific files. For example: \ `@src/components/UserProfile.tsx add a loading state here` ### Good to know * Changes made here immediately affect your project * Code editing is available on paid plans only * This is intended for manual adjustments and is not required when building in Build mode # 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. ### Project permissions Please note that free plans do not have admin roles. Some of the features presented might be available on specific plans only. | | **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 | No | **Yes** | **Yes** | | Disconnect Supabase | No | No | **Yes** | **Yes** | | Transfer project | No | No | **Yes** | **Yes** | | Delete project | No | No | **Yes** | **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 your teammates to your workspace, and they'll have access to all the projects in it. They can see, edit and publish the workspaces's projects. 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 then all projects in the workspace use those credits, no matter who sends the messages. 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 projects * 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 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. ## 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. ### 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. 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` recorded 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. 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). 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. 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 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. ## 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 at \$1 per 1,000 emails and deducted from your [Cloud and AI balance](/integrations/cloud#usage-based-cloud-and-ai-pricing). * 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: * [Lovable Cloud](/integrations/cloud) must be enabled for your project. * 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 → 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. 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 → 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 → 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 → 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 → 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 → 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 → 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 Lovable Cloud and integrate with Cloud Auth to send authentication 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 at **\$1 per 1,000 emails** and deducted from your [Cloud and AI balance](/integrations/cloud#usage-based-cloud-and-ai-pricing). 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 → 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. # Visual edits Source: https://docs.lovable.dev/features/design Use visual edits to modify UI elements, adjust layouts, and update styling without writing code. **Visual edits** is a no-code visual editor that lets you customize your project visually and make fast, targeted changes to layouts, text, colors, and images without writing code. This makes it easy for anyone to update a project quickly and confidently, regardless of technical experience. ## Key benefits * **Edit anything:** Update any UI element in your project without restrictions * **No-code editing:** Make changes without writing code * **Agent-powered:** All updates happen through the Lovable agent * **Free to use:** No credits required, within the daily edit limit * **Faster iteration:** Update and preview changes instantly * **Accessible editing:** Designers, marketers, and product teams can all contribute ## Usage limits Visual edits are free, with a daily usage limit. * 100 edits per user every 24 hours * 500 edits per IP address every 24 hours * When the limit is reached, additional edits require credits * Limits reset automatically every 24 hours ## Visual editing capabilities The visual editor gives you full control over your UI directly in the live preview. * **Select and edit any element** on the page * **Multi-select elements** using `⌘ Command`(Mac) or `⊞ Win`(Windows) * **Layout controls** for alignment and positioning * **Adjust margins and padding** on individual sides of containers * **Edit text, colors, and fonts** directly from the sidebar * **Apply advanced text formatting**, including line breaks and styling * **Replace images** by uploading files or adding image URLs * **Generate AI images** by editing images with prompts ## Quick start 1. Click **Visual edits** in the prompt box. 2. Select any element in the live preview. 3. Make changes using the visual editing panel. 4. Preview updates in real time. 5. Click **Send**. # 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 publish 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 publish 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 publishes, 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 publish. ### 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 publish 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. * Any project can be turned into a design system from the project settings. When a project is marked as a design system, it becomes available for other projects in the workspace to connect to. * An unpublished design system cannot be used as the basis for a new project. Publish it first. * A project can be connected to at most one design system at a time. Detaching a connected design system isn't supported yet. Ensure to pick the right one before connecting. * If your design system or related documentation is hosted within your VPC, reach out to your account team for guidance. ## 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: Auto-fetch an existing React library** If your design system is implemented as React components, share the repository or documentation URL in the chat. * If public, Lovable fetches it automatically * If private, Lovable fetches it using the secrets you configured Once imported, Lovable extracts a schema from your component source on publish — variants, props, and examples are captured automatically. For additional 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 fetching an existing library, ignore the guided questions and proceed to enter the 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. ## Connect a design system to projects Attach a design system with care. It is not possible to detach a design system from a project. 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. Go to **Project settings → Design systems.** 2. Under **Available**, select a design system and click **Add**. 3. Click **Save.** 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. Republish to push the fix to connected projects. 3. **Add detail**\ Request additional component documentation, token definitions, or usage patterns as needed. Each publish bumps the version and notifies connected projects of an available update. ## `.lovable` folder structure Lovable generates this automatically when you publish. 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. ## 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. Detaching a connected design system isn't supported yet, so review the available design systems before connecting. Yes, any project can be marked as a design system from project settings. Set **Project type** to **Design system**. Once marked, it becomes available for other projects in the workspace to connect to. Go to **Project settings → Design systems**. The tab shows the connected design system (if any) and lets you browse available ones to connect. Yes. Every publish 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 published. An unpublished design system exists as a project but has not been published yet, so it has no schema or rendered documentation. You cannot use an unpublished design system as the basis for a new project. Publish it first. Once published, the design system gets a version number and becomes selectable in the design system picker. Not yet. Detaching a connected design system from project settings isn't supported in this release. Pick the design system you want before connecting. 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. 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. # Build safely with Test and Live environments (Beta) Source: https://docs.lovable.dev/features/environments Safely separate test and production environments in Lovable Cloud. Build in Test, publish intentionally to Live, and prevent accidental changes to production data. 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. Test and Live environments let you separate **development** from **production data** while working in [Lovable Cloud](/integrations/cloud) projects. * **Test**: Your development environment. Lovable always builds in Test when Test and Live environments are enabled. * **Live**: Your production environment. This is what real users interact with. Only updated when you explicitly publish. This gives you a safe way to: * Experiment with new features and schema changes * Test integrations, workflows, and edge functions * Avoid unintended changes to production data By isolating development work in Test and publishing intentionally, you keep Live stable while continuing to iterate quickly. ## Prerequisites * The project must use **Lovable Cloud**. * You must **publish at least once** to create a **Live database** before enabling Test. ## How it works When you enable Test and Live environments, Lovable creates a **Test database** alongside your **Live (production) database**. The following is **copied from Live to Test only once, on setup**: * Database schema * Database data * Cloud configuration This is the only time data or Cloud configuration is copied between environments. After that: * Lovable **always builds in Test, never in Live** * While building in Test, Lovable can reference context from Live to help debug issues, but never modifies Live data * Test and Live environments evolve independently * Application code and database schema are synced through publishing * Database data and cloud configuration are never shared, reset, or overwritten * Publishing syncs structure, not content **Publishing updates how your app works**. When you publish, Lovable syncs your application code and database structure from Test to Live (never the other way around) so your production app behaves the same way. Before each publish, Lovable automatically creates a backup of your **Live database**. This ensures you can recover production data if something unexpected happens during or after publishing. Contact support if you need help restoring a backup. **Publishing does not change what data exists or how your Cloud instance is configured**. Each environment permanently owns its own data and settings. | Application component | Description | Synced on publish and shared between environments? | | --------------------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | | Application code | Your app’s logic (frontend, backend, edge functions), which defines how your app works.
**Built in Test** | Yes | | Database schema | The structure of your database (tables, columns, indexes, migrations).
**Built in Test** | Yes\* | | Database data | The contents of your database (rows, users, records, uploads).
**Environment-specific** | No | | Cloud configuration | Environment settings like auth, secrets, environment variables, integrations, and features.
**Environment-specific** | No | \***Safe schema migrations** that should not cause data loss (for example, adding tables or columns) are **applied to Live automatically on publish**. **Data migrations** (moving or transforming existing data) are **not run automatically**. If a change could **risk data loss**, Lovable: * Explains the situation * Provides an SQL query * Asks you to run it manually in the SQL editor ## Enable Test and Live environments To enable Test and Live environments, follow the steps below: 1. Go to **Cloud view → Advanced settings**. 2. Select **Enable Test and Live environments** option. 3. Complete the onboarding flow. 4. Click **Enable Test and Live environments** button. ### Test and Live Cloud view When you enable Test and Live environments, you can switch between **Test** and **Live** in the Cloud view to inspect data and settings. This selector only controls **what you’re viewing**, not **where Lovable builds**. Editing Live data or Live Cloud configuration (auth, secrets, integrations) affects your production app **immediately**. ## Remove the Test database You can delete the Test database from **Cloud → Advanced settings → Danger zone**. This action: * Deletes all Test data * Disables the Test and Live environments feature * Does not affect Live data As of March 24, 2026, Test and Live environments can no longer be re-enabled once removed. This action is permanent. # 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 Lovable Cloud projects, code execution has access to your database only if the `Read database` and `Add data` permissions are set to `Always allow`. See [Lovable Cloud](/integrations/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 | Maximum file size for uploads and downloads is **20 MB**. ## 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. If you want to delete a file, ask Lovable. ## 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 for [**Lovable Cloud apps only**](/integrations/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](/integrations/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. 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 → Users → Auth → 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 → Users → Auth → 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 → Users → Auth → Google**. Switching the Google authentication setup does not affect existing user accounts. Users can continue signing in with the same Google accounts. ## 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 → 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 expand it 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** 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 expand it 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. # 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. # 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. * **Lovable Cloud**: built-in payments use Lovable Cloud for webhooks and subscription data. 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. ### 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 tab** appears in your 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 automatically sync to your live environment for both Paddle and Stripe. You do not need to recreate them manually. 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. If you create a discount code in test, you must create it separately in your live environment. ## 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. * **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. * **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. 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 requires Lovable Cloud and is 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. 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 * **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 ## Invite members You can invite members in two ways: by email or with an invite link (not available on Enterprise plans). ### 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. 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 **Settings → Identity.** Provisioned members appear in the People tab, where roles and access can be managed. * **Just-in-time (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). See [SSO](/features/business/sso) for more information. * **Verified-email provisioning** (domain-based provisioning): When a user signs up to Lovable with an email matching one of your 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. * **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. 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 & credits** and **Cloud & AI balance** tabs 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. 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 If you are on **Business and Enterprise** workspaces and enable **Enforce SSO**, external collaborators are **blocked by default** until an owner or admin explicitly allows them. To block or limit external collaborator access: 1. Enable **Enforce SSO** in **Settings → Identity**. 2. Open **Settings → Privacy & security** and find the **External collaborator access** control. The **External collaborator access** setting only appears in the **Privacy & security** tab when **Enforce SSO** is enabled. 3. Choose one of the three modes: * **Not allowed** (default once **Enforce SSO** is enabled): **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. * **Viewer only**: External collaborators are capped at **read-only access** on every project they're invited to. * **Editor or below**: External collaborators can have **at most editor access**. ### 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 collaborator access** setting is set to **Editor or below** as part of this flow. If you later change **External collaborator access** to **Not 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. * 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 * 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). 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 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. 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 collaborator access** setting on Business and Enterprise workspaces with Enforce SSO enabled. ## 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 collaborator access (Business and Enterprise with Enforce SSO)
| | Settings → Identity |
  • SSO providers
  • Enforce SSO
  • JIT provisioning
  • Verified-email provisioning
  • SCIM provisioning
| | Settings → Plans & credits | 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. 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. 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). Transfer ownership manually beforehand if you want a specific person to take over. # 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. # 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 **Settings → Security & compliance → 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, 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 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. ### Allow editors to transfer projects **Available on:** Enterprise\ **Default:** Disabled When disabled, only admins and owners can initiate a project transfer. When enabled, editors who own a project can move it to another workspace, including a personal workspace outside your organization. For regulated environments, leave this off. An editor transferring a project to a personal workspace removes it from your governance boundary entirely. ### External collaborator access **Available on:** Business and Enterprise (only visible when **Enforce SSO** is active)\ **Default:** Not allowed Controls whether users outside your SSO domain can be added as collaborators on projects in this workspace, and at what maximum access level. | Option | What it means | | :------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Not allowed (default when Enforce SSO is enabled) | 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. | | Viewer only | External users can be added as read-only project viewers. | | Editor or below | External users can be added as project viewers or editors. | 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 collaborator access** setting is set to **Editor or below** as part of this flow. If you later change **External collaborator access** to **Not 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. 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](#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. ### 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. ### App login methods **Available on:** Business and Enterprise\ **Default:** All methods allowed Controls which sign-in methods are available for apps published by workspace members. Disabled methods are enforced across 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 SMS * Google * Apple * SAML SSO Use the toggle next to each method to enable or disable it. Changes take effect immediately. This only affects how end-users sign in to published apps. It does not change how workspace members sign in to Lovable itself. ## 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. ## 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. ### 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, Cursor, and other IDEs can connect to this workspace through [mcp.lovable.dev](http://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. 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](/integrations/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. ## 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. ### 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 messages, 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. | ### 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. # 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 the feedback to Lovable's AI agent. ## Creating a comment 1. Click the **Comment** button in the toolbar to enter comment placement mode. You can also press ⌥ + c to open the command panel to quickly enter comment mode. 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. ## 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's AI agent: * **Mention Lovable** - Type `@Lovable` in a comment to send the thread as context to the agent. * **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. The agent can then act on it directly. A system message is added to the thread to confirm it was sent. ## Resolving comments Once 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 panel The comments panel gives you an overview of all comment threads in the project. Open it from the sidebar 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. ## 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. ## FAQ Anyone with access to the project can leave comments, regardless of their role. 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 the agent 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's AI agent via `@Lovable` or **Send to chat**, the resulting agent response uses credits as with any other chat message. Yes. The comments panel in the sidebar shows all threads across all pages. Pins are only visible on the page where they were placed. # 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. | | **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** and turn on **Enable public remixing**. **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. # 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. ## 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. ## How to publish your project 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. ## 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. ## 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 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**, 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). Publishing errors are usually caused by build issues in the current version. Ask the Lovable Agent to investigate and help resolve the problem. If the **Publish** button is disabled, 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. # 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. 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 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 → Users → Auth settings → Email** * **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 fixes, and track security coverage across projects at scale. * **Available on:** Business and Enterprise plans * **Access:** Workspace admins and owners * **Location:** Settings → Workspace → 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. ### 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. 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. * **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 **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 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. # 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 **Services → SEO & AI search** in your project. 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. * 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), except on Enterprise plans. 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 **Services → SEO & AI search** in your project. 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 your 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 | Site is indexable | Sitewide `noindex` blocks search engines.
Appears as "Search engines are blocked from indexing" | | Indexing | Home page is reachable | Homepage returns errors or fails to load.
Appears as "Home page isn’t loading" | | Indexing | Indexable by search engines | `X-Robots-Tag: noindex`, blocked robots rules, broken hreflang tags, or Lighthouse indexing failures.
Appears as "Hidden 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), except on Enterprise plans. 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 **Add 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. * On workspaces with **SSO enforcement** on, external collaborators are not allowed by default. Workspace admins and owners can allow them up to a chosen role (viewer or editor) from **Settings → Privacy & security → External collaborator access**. ## 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** | | **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 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 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 expand **People you invited** or **People and groups**, based on your plan, to see the full list of individuals and groups. From this list you can: * **Change someone's role**: click the role dropdown next to their name * **Remove individuals or groups**: click **Remove** on a workspace member, external collaborator, or workspace group * **Remove workspace access** (available only on Business and Enterprise plans): choose **No access** from the role 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. Click **Copy preview link** 3. 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. ## 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. 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 through SSO enforcement. 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. From the project's settings, an owner can **transfer ownership** to another workspace member. Workspace owners and admins also retain full access to every project in their workspace regardless of who the project owner is. 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). 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. # 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. # 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. # 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. 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. * **Pricing plans are workspace-level**\ Each workspace has its **own plan and billing**. A paid subscription applies to **one workspace only**. * **Credits are shared across the workspace**\ All projects in a workspace share the workspace's plan and credits. This applies regardless of which member or external collaborator sends messages. * **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). 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 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 wokspaces** flow if **Workspace discovery** is enabled and your email matches a verified domain. ## FAQ Workspaces support **unlimited members** on all plans. For Enterprise workspaces, custom member limits can optionally be set. 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. Go to the project settings where you'll find the option to **Transfer workspace** for the project. 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. 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**](https://lovable-f9060f1e-doc-198-workspace-settings-admininstration.mintlify.app/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 billing and track usage across your workspace. Lovable uses two separate systems: subscription credits for building and prompting, and a usage-based balance for hosting and in-app AI features in deployed apps. **Note on roles and permissions** * **Billing actions** on both the **Plans & credits** and **Cloud & AI balance** tabs are restricted to workspace **owners and admins only**. * **All other roles** can open these tabs 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. ### Plans and credits Manage your subscription plan and credit balance. View your current plan, renewal date, and a breakdown of available credits, including monthly, daily, rollover, and extra credits with expirations. Workspace owners and admins can upgrade or downgrade plans, switch billing cycles, change credit tiers, top up credits on demand, and buy gift cards. See [Plans and credits](/introduction/plans-and-credits). ### Cloud and AI balance Track and manage usage-based costs for hosting and in-app AI features across your workspace. This balance is separate from subscription credits and is used to pay for deployed apps and AI functionality inside them. View your current balance, including free monthly usage and any added funds, and see how costs are split between [Lovable Cloud](/integrations/cloud) (hosting) and [Lovable AI](/integrations/ai) usage. You can also track detailed usage by project to understand where costs are coming from. Workspace owners and admins can add funds with one-time top-ups or enable automatic top-ups with monthly charge limits, as well as access billing history and payment settings. If your balance runs out, deployed apps may stop working until funds are added or free usage resets. See [Usage based Cloud and AI pricing](/integrations/cloud#usage-based-cloud-and-ai-pricing). ## Members & 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. User provisioning can be handled in multiple ways, including just-in-time (JIT) provisioning through SSO, domain-based provisioning, and SCIM-based sync from your identity provider. Provisioned users appear in the People tab, where roles and access can be managed. SCIM provisioning is available on **Enterprise** plans. All other features are available on **Business and Enterprise** plans. See [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. ### 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 and compliance 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, and authentication policies in one place. Use the Security center to identify and prioritize issues, track scan coverage, and compare security status across projects. You can filter and export data, and trigger security scans without opening individual projects. Available on **Business and 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). # Glossary Source: https://docs.lovable.dev/glossary Definitions of Lovable features, UI/UX terms, frontend and backend concepts, Supabase terminology, and design patterns. ## General concepts * **AI (Artificial Intelligence):** The simulation of human intelligence processes by machines, especially computer systems, enabling tasks like learning, reasoning, and problem-solving.​ * [**Prompt**](https://docs.lovable.dev/tips-tricks/prompting)**:** A piece of text or input that guides AI models in generating outputs or performing certain tasks.​ It is within the core functionality of Lovable and it is with prompts that you create, modify a specific component or element in your application. ## Lovable-specific terms * [**Plan mode**](/features/plan-mode)**:** Lovable goes beyond just generating code; it becomes an interactive assistant guiding you through every phase of development. It helps founders think critically, plan effectively, debug intelligently, and ship confidently. * **Edit Mode**: The action of making changes or modifications to content or code.​ * [**Edit**](https://docs.lovable.dev/features/precision-edit#visual-edits)**:** A tool that allows AI-driven development with Tailwind-native visual controls for easy refinement. * **History:** The system of tracking and managing changes to your app and code over time.​ * [**Knowledge**](https://docs.lovable.dev/features/precision-edit#knowledge-files)**:** Capture essential project details in a living document that evolves with your app. * **Remix:** 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. Note that it is not possible to remix projects when Supabase is connected. * **Preview:** Allows users to view or experience live content or feature functionalities before it is finalized or published, in an interactive way. * **Diff:** A comparison that shows the differences between two versions of a file or code.​ * **/index:** Refers to the main or default page of a website or app, often named "index.html" or "index.js". * [**Lovable API - Build with URL**](https://docs.lovable.dev/integrations/build-with-url)**:** The Lovable API Build with URL feature allows you to programmatically create applications by passing prompts and images via URL parameters. This enables seamless integration with websites, internal tools, or automation workflows, letting users generate Lovable apps with a single click. ## Product & Development concepts ### Product management & Strategy * **MVP (Minimum Viable Product)** – A version of a product with just enough features to satisfy early adopters and validate an idea before full-scale development. * **Roadmap** – A high-level strategic plan that outlines the vision, direction, and planned features for a product over time. * **Feature Request** – A formal or informal suggestion from users or stakeholders for a new capability in a product. * **User Story** – A short, simple description of a feature or requirement written from the perspective of an end user. * **User Journey:** The series of steps a user takes to achieve a specific goal within a product or service.​ * **Persona:** A fictional representation of a target user, based on research, to guide design and development decisions.​ ### Engineering concepts * **PRD (Product Requirements Document):** A comprehensive document that outlines the objectives, features, and specifications of a product to guide development.​ * [**API**](https://lovable.dev/blog/2025-01-28-the-power-of-apis) **(Application Programming Interface):** A way for different services to communicate. Think of it as a protocol that tells you what kind of information you can get or send between systems. The most common types are REST APIs, which many sites use, and GraphQL APIs, which offer a more flexible approach to querying data. * **Refactor:** The process of restructuring existing code without changing its external behavior to improve readability, maintainability, or performance. * **GitHub:** A web-based platform for version control and collaborative software development using Git.​ ### Data & Analytics * **A/B Testing** – A method of comparing two versions of a webpage or feature to determine which performs better based on user behavior. * **Conversion Rate** – The percentage of users who complete a desired action, such as signing up or making a purchase. * **Churn Rate** – The percentage of users who stop using a product over a given period. * **Retention Rate** – The percentage of users who continue using a product over time. * **Event Tracking** – Monitoring specific user actions (e.g., button clicks, form submissions) to gather insights on behavior and engagement. ## UI/UX and frontend development playbook ### Frontend development * **Frontend:** The part of a software application that users interact with directly, encompassing the user interface and user experience elements.​ * **React:** A JavaScript library developed by Facebook for building user interfaces, particularly single-page applications.​ * **Gradient:** A gradual transition between two or more colors or shades in design. * **Tailwind CSS**: Open-source utility-first CSS framework that provides a comprehensive set of pre-defined classes, enabling developers to build custom designs directly within their HTML by applying these utility classes to elements. * **Design Systems:** A collection of reusable components, guidelines, and standards that ensure consistency and coherence in design across a product or brand. ### UI/UX design concepts * **Accent Color:** A distinctive hue used to highlight key elements in a design, often aligning with or complementing the brand's primary color to enhance visual interest.​ * **Theme:** A cohesive set of design choices, including colors, fonts, and layouts, that define the overall aesthetic and user experience of an application or website.​ * **Responsive Design:** An approach to web design ensuring that content adapts seamlessly across various device sizes and orientations, providing an optimal user experience. * **Above the Fold:** The portion of a webpage visible to users without scrolling, crucial for capturing attention and conveying essential information immediately. ​ * **CTA (Call to Action):** A prompt, often in the form of a button or link, encouraging users to perform a specific action, such as "Sign Up" or "Learn More." ​ ### Page structure & Navigation * **Headings (Titles):** Text elements that introduce and organize content sections, typically formatted with varying levels (e.g., H1, H2) to establish a clear content hierarchy.​ * **Footer:** The bottom section of a webpage, commonly containing supplementary information such as contact details, navigation links, and legal disclaimers. ​ * **Breadcrumb:** A navigational aid displaying the user's current location within a site's hierarchy, often represented as a horizontal list of links. ​ * **Favicon** – A small icon displayed in the browser tab, bookmarks, and search results, typically representing a brand or website. * **Meta Title (Title Tag)** – The title of a webpage that appears in search engine results and browser tabs, influencing SEO and user click-through rates. * **Meta Description** – A short summary of a webpage’s content displayed in search engine results, aimed at improving discoverability and user engagement. * **Canonical URL** – A tag used to specify the preferred version of a webpage, helping to avoid duplicate content issues in search engine indexing. * **URL Slug** – The part of a URL that identifies a particular page in a readable format (e.g., `example.com/product-name`). * **Sitemap** – A structured file (XML or HTML) that provides a list of a website’s pages, helping search engines index them efficiently. * **Navigation Bar (Nav Bar)** – A horizontal or vertical menu providing links to essential sections of a website for easy navigation. * **Skip Links** – Hidden links that allow users to bypass repetitive content and navigate directly to the main content, improving accessibility. * **Pagination** – A method of dividing content into multiple pages, commonly used in blogs, search results, and product listings to improve user experience. * **Anchor Link** – A hyperlink that directs users to a specific section within the same page instead of loading a new page. * **404 Page** – A custom error page displayed when a user tries to access a non-existent URL, guiding them back to relevant content. ### **Notifications & Feedback elements** * **Toast:** A brief, non-intrusive notification that appears temporarily to inform users of an action's outcome or provide simple feedback. ​ * **Snackbar** – Similar to a toast, but typically located at the bottom of the screen with optional actions (e.g., "Undo" on a deleted item). * **Tooltip** – A small pop-up box that provides additional information when hovering over or focusing on an element. * **Badge** – A small visual indicator, often used on icons or buttons, to show notifications, counts, or status updates. * **Loading Spinner (Loader)** – A visual indicator that represents a process in progress, such as loading a page or submitting a form. * **Progress Bar** – A horizontal bar that indicates the completion percentage of a task or process. * **Skeleton Loader** – A placeholder UI that mimics the layout of the final content while waiting for it to load, improving perceived performance. ### Overlays & Pop-ups * **Popover:** A transient overlay that presents additional information or options related to a specific UI element, typically appearing upon user interaction. ​ * **Dialog (Modal):** A window that appears in front of the main content to capture user attention, often requiring an action before returning to the primary interface. * **Drawer (Sidebar Panel)** – A panel that slides in from the side of the screen to display navigation options or settings without disrupting the main content. * **Lightbox** – A modal window that displays images or media in an enlarged view, dimming the background for focus. * **Alert Box** – A system-generated or application-triggered message box that informs users of important information, such as errors or warnings. ### Navigation & Selection elements * **Button:** A clickable element that initiates an action or event, such as submitting a form or opening a dialog.​ * **Switch (Toggle):** A toggle control enabling users to switch between two states, such as on or off, often resembling a physical switch. ​ * **Tabs** – A component that organizes content into separate views within a single interface, allowing users to switch between sections without navigating away. * **Stepper (Wizard)** – A component used for multi-step processes, showing users their current step and guiding them through completion. * **Pagination** – A UI pattern that divides content into pages, often used for search results or content-heavy applications. * **Breadcrumb** – A navigational aid displaying the user's current location within a site's hierarchy, often represented as a horizontal list of links. * **Accordion** – A collapsible section that expands or contracts to reveal or hide content dynamically. * **Dropdown Menu** – A list of options that appears when a user clicks or hovers over a button or field, often used for navigation or selection. ### Forms & Input elements * **Form:** A structured collection of input fields allowing users to submit data, such as contact information or search queries.​ * **Radio Group:** A set of related radio buttons permitting users to select only one option from multiple choices. * **Checkbox:** An interactive box that users can check or uncheck to select or deselect an option, allowing multiple selections within a set.​ * **Text Field (Input Field)** – A basic UI element where users can enter text, such as in search bars, login forms, or comments. * **Text Area** – A larger input field designed for multiline text input, commonly used for messages or feedback forms. * **Select (Dropdown Select Box)** – A UI element that allows users to choose one option from a predefined list, often styled as a dropdown. * **Date Picker** – A UI element that lets users select a date from a calendar instead of manually typing it. * **Slider (Range Selector)** – A control that allows users to set a value within a range by sliding a handle along a track. * **File Upload Field** – A component that lets users select and upload files from their device. * **Autocomplete (Typeahead Search)** – A text input that dynamically suggests matching results as users type, improving usability in searches. ### Design styles & Trends You can use those terms in any of your prompt to describe a specific style you are trying to achieve. * **Neobrutalism:** A web design trend characterized by raw, unpolished elements, bold typography, and high contrast, drawing inspiration from mid-20th-century Brutalist architecture. ​ * **Retro:** Design that incorporates styles, motifs, and elements from past decades, evoking nostalgia and vintage aesthetics.​ * **Hacker:** An aesthetic that reflects the DIY and open-source culture, often featuring monospaced fonts, dark backgrounds, and terminal-inspired interfaces.​ * **Glass (Glassmorphism):** A design style uses translucent, frosted glass-like elements with subtle shadows and borders to create depth.​ * **Nudy:** A minimalist design approach that utilizes nude or neutral color palettes to create a soft and understated aesthetic.​ ### Design & Asset resources * [**21st.dev:**](https://21st.dev/) An open-source community registry offering minimal, modern, and reusable React UI components powered by Tailwind CSS and Radix UI, designed to help design engineers ship polished user interfaces more efficiently. * [**Dribble:**](https://dribbble.com/) A leading online community where designers and creative professionals showcase their work, discover design inspiration, and connect with potential clients or collaborators. * [**Noun Project:**](https://thenounproject.com/) A platform providing a vast collection of free icons and stock photos, enabling users to access visual resources for various projects. * [SVG Repo:](https://www.svgrepo.com/) A comprehensive library of over 500,000 open-licensed SVG vectors and icons, allowing users to search, explore, edit, and download graphics suitable for diverse projects. * [Google Fonts:](https://fonts.google.com/) A free library of web-optimized fonts, offering designers and developers a wide selection of typography options to enhance their projects. * [Typewolf:](https://www.typewolf.com/) A resource that assists designers in selecting the perfect font combinations for their projects by showcasing trending typefaces and offering curated font lists. ## Backend development & Databases ### Backend fundamentals * **Backend:** The server-side infrastructure of an application that handles data processing, storage, and business logic.​ * [**Supabase**](https://docs.lovable.dev/integrations/supabase)**:** An open-source backend-as-a-service platform that provides a Postgres database, authentication, instant APIs, and real-time capabilities. * **Webhooks** – Event-driven HTTP callbacks that notify external applications when specific actions occur. ### Database management & Querying * **CRUD (Create, Read, Update, Delete):** The four basic operations performed on data in a database or application.​ * [**SQL (Structured Query Language)**](https://supabase.com/docs/guides/database/overview)**:** A domain-specific programming language designed for managing and manipulating relational databases, enabling tasks such as querying, updating, and organizing data. * **PostgreSQL** – A powerful open-source relational database known for its scalability, extensibility, and ACID compliance. ### Supabase-specific concepts * [**Edge Function**](https://supabase.com/docs/guides/functions)**:** Server-side TypeScript functions, distributed globally at the edge—close to your users. They can be used for listening to webhooks or integrating your Supabase project with third-parties like Stripe, Anthropic or Resend. * [**RLS (Row-Level Security)**](https://supabase.com/docs/guides/database/postgres/row-level-security)**:** A feature in databases that allows control over access to specific rows in a table based on user roles or attributes - basically allowing users to set granular authorization rules, allowing you to write complex SQL rules that fit your unique business needs. * [**Storage**](https://supabase.com/docs/guides/storage)**:** A service or system for storing and managing data, such as images, videos, documents, and any other file type. * [**Bucket**](https://supabase.com/docs/guides/storage/buckets/fundamentals)**:** In Supabase Storage, a bucket is a distinct container that organizes files and folders, determining the access model (public or private) and setting upload restrictions like maximum file size and allowed content types. * [**Endpoint**](https://supabase.com/docs/guides/api)**:** In the context of Supabase, an endpoint refers to a specific URL that allows clients to interact with the database through RESTful API calls, enabling operations like creating, reading, updating, or deleting data. * [**Authentication Provider:**](https://supabase.com/docs/guides/auth) An entity or service that verifies user credentials, enabling secure access to applications or systems. In the context of Supabase, authentication providers include various methods such as password-based logins, magic links, one-time passwords (OTP), social logins, and single sign-on (SSO) integrations, facilitating flexible and secure user authentication. ### Security & Authentication * **OAuth** – A widely-used authentication protocol that enables users to log in to applications using third-party services like Google, Facebook, or GitHub. * **Two-Factor Authentication (2FA)** – A security measure that requires users to provide two forms of identification before accessing an account. * **CORS (Cross-Origin Resource Sharing)** – A security policy that controls which websites or applications can access resources on a server. # AI features for your app Source: https://docs.lovable.dev/integrations/ai Add AI capabilities directly to the apps you build with Lovable. No API keys or provider setup required. Enable chatbots, summaries, document Q&A, translation, automation, image generation, semantic search, and more. 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. ## Enabling the built-in AI connector For the best experience, use the built-in AI connector with [Lovable Cloud](/integrations/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. You can manage the built-in AI connector for your projects in **Connectors** → **App connectors** → **Lovable AI** → **Manage permissions**. Workspace admins can also disable the built-in AI connector entirely for the workspace from **Connectors** → **App connectors** → **Lovable AI**. ### 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 from **Connectors** → **App connectors** → **Lovable AI** → **Manage 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. ## Default model for AI features in your app The built-in AI connector uses **Gemini 3 Flash (preview)** as the default model for AI features in your app. When asking Lovable to add or update an AI feature, you can specify a different supported model or combination of models for that feature. This default model applies to AI features inside your app. It is not the model Lovable uses to write, edit, or reason about your code. For an overview of available models, see [Supported models for AI features in your app](#supported-models-for-ai-features-in-your-app). ## Usage and pricing The built-in AI connector runs on a usage-based pricing model. This means your costs scale with how much you use and are not covered by your subscription. The cost is exactly the same as going directly to the large language model (LLM) provider. There are no hidden fees. To verify costs, refer to the official sources linked in the model list below. Every workspace includes **\$1 of free AI usage per month** to get started. After that, users on paid plans can top up their balance, with costs depending on the underlying model you choose. **Temporary offering, subject to change:** Every workspace gets \$25 Cloud and \$1 AI per month, even for users on the Free plan. You can track and manage your AI usage costs in **Settings** → **Cloud & AI balance**. For more details and examples, see [Usage-based Cloud and AI pricing](/features/cloud#usage-based-cloud-and-ai-pricing). ## Supported models for AI features in your app These models are available for AI features inside the apps you build, such as chatbots, summaries, document Q\&A, image generation, and semantic search. They are not the models Lovable uses to write, edit, or reason about your code. The built-in AI connector uses **Gemini 3 Flash (preview)** as its default model. When asking Lovable to add or update an AI feature, you can specify a different supported model or combination of models for that feature. | Model | Description | Best for | | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | [Gemini 3 Flash Preview (default)](https://ai.google.dev/gemini-api/docs/models/gemini-3-flash-preview) | A fast, efficient Gemini model optimized for responsive, general-purpose use. Balances speed, cost, and strong reasoning for chat-centric and iterative development. | Fast interactive builds, general use cases where responsiveness matters | | [Gemini 3.5 Flash](https://deepmind.google/models/model-cards/gemini-3-5-flash/) | High-efficiency Gemini 3.5 model for fast coding, reasoning, and agentic workflows. | Fast coding, reasoning, and agentic workflows | | [Gemini 3.1 Pro Preview](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-pro-preview) | Google's most capable Gemini 3 model. Delivers stronger reasoning, improved token efficiency, and more grounded, factually consistent responses. Slower and premium-priced. | Advanced coding, long-context understanding, multimodal reasoning, and complex multi-step tasks | | [Gemini 3.1 Flash Lite Preview](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-flash-lite-preview) | The fastest and lowest-cost option in the Gemini 3 family, designed for simple, high-throughput tasks with limited reasoning depth. Currently in preview. | High-volume, lightweight tasks like classification, summarization, translation | | [Gemini 3.1 Flash Image Preview](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-flash-image-preview) | Fast image generation and editing model. Combines strong visual quality with faster generation, improved subject consistency, accurate text rendering, and high-resolution support. Also known as Nano Banana 2. | Rapid image generation, iterative visual editing, product mockups, marketing assets | | [Gemini 3 Pro Image Preview](https://ai.google.dev/gemini-api/docs/models/gemini-3-pro-image-preview) | High-quality image generation and editing model optimized for detailed visuals, text rendering in images, and multi-image composition. Also known as Nano Banana Pro. | Visual asset creation, high-volume image workflows, infographics, creative content | | [Gemini 2.5 Pro](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-pro) | Google's most capable Gemini 2.5 model. High reasoning, large context, slower and most expensive. | Deep reasoning, advanced coding, research, complex multimodal tasks | | [Gemini 2.5 Flash](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-flash) | A balanced Gemini 2.5 model offering good reasoning with lower latency and cost than Pro. | Assistants, analysis, general workflows where speed + intelligence balance matters | | [Gemini 2.5 Flash Lite](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-flash-lite) | The fastest and lowest-cost option in the Gemini 2.5 family, designed for simple, high-throughput tasks with limited reasoning depth. | High-volume, lightweight tasks like classification, summarization, translation | | [Gemini 2.5 Flash Image](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/gemini/2-5-flash-image) | Optimized for generating images. Very cheap per image, not suited for text reasoning. | Image generation, quick visual outputs | | [GPT-5.5 Pro](https://platform.openai.com/docs/models/gpt-5.5-pro) | OpenAI's most capable GPT-5.5 model, built for the hardest reasoning, research, and engineering problems. Features a 1.05M-token context window; input and output above 272K tokens is billed at a higher rate. Slowest and most expensive in the GPT-5.5 family. | Frontier reasoning, in-depth research, complex engineering, and very long-context analysis | | [GPT-5.5](https://platform.openai.com/docs/models/gpt-5.5) | OpenAI's flagship GPT-5.5 model with strong general reasoning and a 1.05M-token context window; input and output above 272K tokens is billed at a higher rate. | Complex reasoning, advanced coding, and long-context knowledge work | | [GPT-5.4 Pro](https://platform.openai.com/docs/models/gpt-5.4-pro) | OpenAI's most capable GPT-5.4 model, optimized for deep reasoning and reliable multi-step execution. Features a 1.05M-token context window; input and output above 272K tokens is billed at a higher rate. Slower and premium-priced. | Advanced coding, deep research, and long-context multi-step reasoning | | [GPT-5.4](https://platform.openai.com/docs/models/gpt-5.4) | OpenAI's flagship GPT-5.4 model, designed for professional knowledge work and complex reasoning. Features a 1.05M-token context window; input and output above 272K tokens is billed at a higher rate. | Complex reasoning, coding and analytical workflows, long-context knowledge tasks | | [GPT-5.4 Mini](https://platform.openai.com/docs/models/gpt-5.4-mini) | Balanced GPT-5.4. Cheaper and faster than GPT-5.4, with strong general-purpose performance. | Assistants, mid-complexity reasoning, business workflows | | [GPT-5.4 Nano](https://platform.openai.com/docs/models/gpt-5.4-nano) | Cheapest and fastest GPT-5.4. Limited reasoning depth, best for quick or simple responses. | Summaries, classification, extraction, high-volume simple tasks | | [GPT-5.2](https://openai.com/index/introducing-gpt-5-2/) | A capable GPT-5 series model designed for professional knowledge work and complex multi-step tasks. | Complex reasoning, deep coding and analytical workflows, long-context knowledge tasks | | [GPT-5](https://openai.com/index/introducing-gpt-5/) | High-accuracy general-purpose model with strong reasoning capabilities. Higher latency and cost compared to smaller GPT-5 variants. | Accuracy-critical tasks, complex decision-making, and high-quality reasoning | | [GPT-5 Mini](https://platform.openai.com/docs/models/gpt-5-mini) | Balanced GPT-5. Cheaper and faster than GPT-5, with strong general-purpose performance. | Assistants, mid-complexity reasoning, business workflows | | [GPT-5 Nano](https://platform.openai.com/docs/models/gpt-5-nano) | Cheapest and fastest GPT-5. Very basic reasoning, best for quick or simple responses. | Summaries, classification, extraction, high-volume simple tasks | | [GPT Image 2](https://platform.openai.com/docs/models/gpt-image-2) (default image model) | OpenAI's state-of-the-art image generation model for high-quality image generation and editing. Supports text and image inputs, flexible image sizes, and high-fidelity image inputs. Default model for image generation in your app. | Visual asset creation, image editing, product mockups, marketing imagery, creative content | | [GPT Image 1 Mini](https://platform.openai.com/docs/models/gpt-image-1-mini) | A cost-efficient version of GPT Image 1 for image generation and editing. Supports text and image inputs, and produces image outputs. | Cost-sensitive image generation, thumbnails, drafts, high-volume image workflows | ### Best and most cost-effective choices * **Best overall intelligence**: GPT-5.5 Pro, GPT-5.4 Pro, Gemini 3.1 Pro, and Gemini 2.5 Pro (deep reasoning, but most expensive) * **Best balance (speed + cost + intelligence)**: Gemini 3.5 Flash, Gemini 3 Flash, GPT-5 Mini, and Gemini 2.5 Flash * **Most cost-effective for scale**: GPT-5 Nano, Gemini 3.1 Flash Lite, and Gemini 2.5 Flash Lite (simple, fast, cheapest) * **Best for images**: GPT Image 2, GPT Image 1 Mini, Gemini 3.1 Flash Image, Gemini 3 Pro Image, and Gemini 2.5 Flash Image ### Embedding models for AI features in your app Embedding models turn text into a format that can be searched by meaning instead of exact keywords. Use them to build semantic search, retrieval-augmented generation (RAG), FAQ bots, document search, and company knowledge bases. When you ask Lovable to build semantic search or a RAG workflow, the built-in AI connector handles the implementation for you. For example, you can 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. Available embedding models: | **Model** | **Best for** | | :----------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------- | | [google/gemini-embedding-001 (default)](https://ai.google.dev/gemini-api/docs/models/gemini-embedding-001) | General-purpose semantic search, document retrieval, and recommendation use cases. Good default for most text-based retrieval workflows. | | [openai/text-embedding-3-small](https://developers.openai.com/api/docs/models/text-embedding-3-small) | Cost-sensitive or high-volume text embedding workloads. | | [openai/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. | | [google/gemini-embedding-2-preview](https://ai.google.dev/gemini-api/docs/models/gemini-embedding-2-preview) | Multimodal retrieval across text, images, video, audio, and PDFs. Currently in preview. | Embedding calls are billed per input token. When you ask Lovable to build semantic search or a RAG workflow, the built-in AI connector handles the backend setup for you. ## 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. 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 AI credits, the server returns a `402 Payment Required` status code. Top up your balance in **Settings** → **Cloud & AI balance** to restore access. 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. The built-in AI connector uses Gemini 3 Flash (preview) by default, but you can ask Lovable to use a different supported model or combination of models for a specific AI feature. If your workspace runs out of AI balance, AI requests return a **402 Payment Required** status code. You can restore access by topping up your balance in **Settings** → **Cloud & AI balance**. # 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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 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, using **Workload Identity Federation (WIF)** so you do not 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** on the service account, and **what you ask Lovable to build**. ## How BigQuery connections work * **Authentication**: The connector uses **Workload Identity Federation** with Google’s security token service. Short-lived access tokens are obtained and refreshed through Lovable’s **connector gateway**—not long-lived JSON keys 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**: The connection is created with BigQuery access scopes (including `https://www.googleapis.com/auth/bigquery` by default). What you can read or run still depends on **IAM and dataset permissions** on the **service account** you configure. * **Workspace binding**: You configure Google Cloud to trust identity tokens for a **workspace-specific audience** (see below). Use the **Workload Identity Provider** resource string and **service account email** in Lovable when creating the connection. BigQuery **query and storage costs** are billed by **Google Cloud** to your GCP billing account, based on bytes processed, slots, and related usage—not by Lovable. ## How to connect BigQuery Workspace **admins** and **owners** can create BigQuery connections. When a connection is created, it can be **linked to projects** like other app connectors so deployed apps use it where allowed. ### Prerequisites Before connecting in Lovable, 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, running queries and reading tables in specific datasets) * Your **Lovable workspace ID** (you will need it for the OIDC **audience** in Google Cloud) * **Lovable workspace admin or owner** role ### 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**. 1. 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). 2. 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). 3. **Allow the pool to impersonate your BigQuery service account**: 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. 4. Copy the **Workload Identity Provider resource name**. 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 1. Open **Connectors** → **App connectors** and select **BigQuery**. 2. Click **Add connection**. 3. In **Display name**, enter a clear name (for example `BigQuery Production` or `Analytics read-only`). 4. In **WIF audience**, paste the **Workload Identity Provider** resource name from Google Cloud (the full `//iam.googleapis.com/projects/.../providers/...` string). 5. In **Service account email**, enter the service account to impersonate for BigQuery access (for example `bq-reader@your-project.iam.gserviceaccount.com`). 6. Complete the flow to **create** or **verify** the connection. Lovable validates the federation setup through the gateway. When connected, projects that are allowed to use this connection can run BigQuery operations 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 * **Per-user Google login** is not what this connector provides: you configure **one** federated identity and service account per connection for the workspace (not each end user’s Google account). * **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 your 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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 now in open Beta, enabling you to build and share Lovable apps using simple, shareable URLs. The Lovable API **Build with URL** feature allows you to programmatically create applications by passing prompts and images via URL parameters. This enables seamless integration with websites, internal tools, or automation workflows, letting users generate Lovable apps with a single click. Each link tells Lovable *what* to build and optionally *what images to include* — and Lovable takes care of the rest. Example: ``` https://lovable.dev/?autosubmit=true#prompt=Create%20a%20todo%20app ``` Clicking this link automatically opens Lovable and begins building a to-do app. ## Use cases You can do the following with Build with URL API: * Embed a **Build with Lovable** button on your website or application. When the user clicks the button, they are taken to Lovable and the app is built automatically. * 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. You can construct the URL yourself or use the [Lovable Link Generator](https://lovable.dev/links). See below for more information. ## Base URL ``` https://lovable.dev/?autosubmit=true# ``` `autosubmit` (boolean): Must be set to `true` to automatically process the request ## URL with parameters ``` https://lovable.dev/?autosubmit=true#prompt=YOUR_PROMPT_HERE&images=IMAGE_URL_1&images=IMAGE_URL_2 ``` ### Parameters | Parameter | Type | Description | Required/Optional | | --------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | | `prompt` | string | Text describing the application to build. Max 50,000 characters. Use URL encoding (for example, `%20` for spaces). Very long URLs might fail due to browser or parsing constraints. | Required | | `images` | string | Max 10 URL-encoded image URLs as references. Image URLs must be publicly accessible. Supported formats: JPEG, PNG, WebP. | Optional | ## Lovable Link Generator Use the [Lovable Link Generator](https://lovable.dev/links) to easily build shareable URLs that generate apps with your chosen prompt and images. 1. Enter your prompt, which describes the application to build (up to 50k characters). 2. Upload up to 10 public image URLs (JPEG, PNG, or WebP). 3. Copy the generated Lovable URL and share it. This tool helps prevent URL-encoding errors and ensures links are formatted correctly. ## Build with URL examples **Basic app generation** ``` https://lovable.dev/?autosubmit=true#prompt=Create%20a%20todo%20app ``` **Single reference image** ``` https://lovable.dev/?autosubmit=true#prompt=Display%20these%20images&images=https://img.com/1.jpg ``` **Multiple reference images** ``` https://lovable.dev/?autosubmit=true#prompt=Display%20these%20images&images=https://img.com/1.jpg&images=https://img.com/2.jpg​ ``` ## Best practices * Keep prompts concise and focused on core features. * Use clear, descriptive language for best generation results. * Include reference images when relevant to help guide the generation process. * Ensure special characters in prompts and image URLs are URL-encoded to avoid parsing issues. ## App creation and authentication flow for shared URLs When a user clicks a **Build with URL** link: * **Logged-in users**: select the workspace for creating the project, then app creation starts automatically. * **Not logged-in users**: redirected to signup/login page. After successful authentication, select the workspace for creating the project, and then the app creation starts automatically, preserving the original prompt and images. ## Error handling If the URL is too long or malformed, you may encounter: * Browser “URL too long” errors * Incomplete parameter parsing * Failed autosubmission # Lovable Cloud Source: https://docs.lovable.dev/integrations/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. All you do is describe what you want directly in Lovable, and Lovable automatically 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. You have the power of a production-ready database, real-time updates, user auth, and storage — with none of the manual setup steps. ## Why choose Lovable Cloud * **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 usage-based pricing. Every workspace starts with **\$25 free usage per month**, enough to launch and run multiple projects (temporary offering, subject to change). Read more in [Usage-based Cloud and AI pricing](https://docs.lovable.dev/features/cloud#usage-based-cloud-and-ai-pricing). ## Enabling Lovable Cloud By default, Lovable Cloud is enabled for your workspace. You can manage Lovable Cloud behavior for your projects in **Connectors** → **App connectors** → **Lovable Cloud** → **Manage permissions** ### Region selection Lovable Cloud projects can be hosted in three different regions: * Americas * Europe * Asia Pacific You can set a preferred default region for hosting new Cloud projects in **Connectors** → **App connectors** → **Lovable Cloud** → **Manage permissions** If no preferred region is set, Lovable automatically selects the region closest to your current location. See [Configuring Lovable Cloud tools](#configuring-lovable-cloud-tools) for more information. 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. ### Permission preferences The default setting for Cloud integration is **Always allow**, meaning Lovable automatically performs the action, without asking for review or approval. You can change your preference anytime from **Connectors** → **App connectors** → **Lovable Cloud** → **Manage permissions** Lovable prompts you when a feature requires backend functionality (for example, authentication or file storage). You have three options: * **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 (does not affect the current project). ### Configuring Lovable Cloud tools Cloud tools have three permission options: * **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. * **Never allow**: Lovable blocks the action, informs you that Cloud access is required, and instructs you to enable Cloud. You can change your Cloud tool preferences anytime from **Connectors** → **App connectors** → **Lovable Cloud** → **Manage permissions** #### 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 | | Cloud region | Select the default region (Closest to me, Americas, Europe, or Asia Pacific) for new Cloud projects. If Cloud is auto-enabled using Always allow, this region will be 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 | ## Lovable Cloud features You’ll find the **Cloud tab** inside any Lovable project by clicking the `+` button next to **Preview** **mode**. Lovable Cloud icon The following features and settings live inside the Cloud tab: ### Database * **Generate schemas automatically**: describe the data you need in plain language, and Lovable creates the tables and schema for you. * **Manage without SQL**: view, edit, and organize records directly in the UI. Update values, inspect tables, and keep your app’s data in sync without writing queries. **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. ### Users & Auth * **User management**: view user accounts, track activity, and manage access control. * **Built-in authentication**: Lovable can generate signup/login pages for your app. Supports email, phone, and Google sign-in. * **Google authentication**: Lovable Cloud supports **Sign in with Google** using OAuth 2.0. Google authentication can be enabled in **Managed** mode (Lovable-managed OAuth) or using **your own Google Cloud credentials (BYOK)**. See [Add Google authentication to Lovable Cloud apps](/features/google-auth) for detailed information. * **Secure by default**: authentication is backed by Lovable Cloud, keeping user credentials safe. ### Storage * **File handling without code**: upload, manage, and serve files such as profile photos, documents, videos, or static assets. * **Storage buckets**: files are stored securely in a project bucket, with URLs or references you can use in your app. Storage buckets are private by default, but can be made public if needed. **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 *Settings → Privacy & security → Block public storage buckets*. * **Limits**: Supports files up to 2 GB. ### Edge Functions * **Serverless logic**: run custom code for APIs, workflows, or advanced features, without provisioning servers. Functions scale automatically with traffic. **Common use cases:** * AI-powered features, such as AI summaries or AI chatbots. Use built-in [Lovable AI](https://docs.lovable.dev/features/ai). * Sending emails or push notifications * Payment processing, for example with [Stripe](https://docs.lovable.dev/integrations/stripe#stripe-integration) * Scheduled tasks * Heavy computations or external API calls **Other highlights:** * **Easy to create**: just describe the function you need in Lovable chat. * **Debugging built-in**: each function includes logs of executions, output, and errors. If something fails, Lovable surfaces the error for quick troubleshooting. ### AI * **Built in AI functionality**: Lovable Cloud comes with built in AI so you can quickly create features that make your app smarter and more engaging. For more information, see [Lovable AI](https://docs.lovable.dev/features/ai). * Some examples of AI powered features include: * **AI summaries** – automatically condense long text into clear takeaways * **AI chatbot or agent** – build conversational helpers into your app * **Sentiment detection** – understand user feedback at scale * You can monitor Lovable AI usage and performance for your project from the AI overview. ### Secrets * **Secure environment variables**: store sensitive data such as API keys, tokens, or credentials without exposing them in code. * **Automatic detection**: when a feature needs a secret, Lovable prompts you to input it through a secure UI. * **Encrypted and safe**: secrets are stored securely and automatically injected into Edge Functions or other integrations. **Example:** Store your Stripe Secret Key once, and Lovable ensures it’s included in payment-processing functions without you hard-coding it. Some secrets, such as the Supabase keys and Lovable API key, are added automatically and are required for the functioning of the Lovable platform. These keys cannot be deleted. ### Logs * **Real-time monitoring**: watch app activity as it happens. * **Debug and trace issues**: identify errors, track events, and ensure your backend is healthy. ### Usage The **Usage** tab gives you a visual breakdown of how your app is consuming Lovable Cloud resources over a selected time period. The time period defaults to **Last 7 days**. You can switch to **Last day** from the dropdown to adjust the period shown. Cloud usage updates daily at 10 AM CET. Usage is broken down across **resource categories**, displayed as a segmented bar and listed individually with a percentage: * **Database server**: used when your app queries or updates data. Adjust your [instance size](#advanced-settings-upgrade-instance) to match your app’s traffic. Larger instances provide more capacity but increase Cloud costs. * **Database storage**: the disk space used by your database to store your app’s data (like users, orders, and settings). * **Compute**: used when your app's code runs. * **Storage**: used to store files like images, videos, and uploads. * **Live updates**: used to send real-time updates to users (for example, notifications or chat). * **Network**: used when your app sends or receives data over the internet. Categories are sorted from highest to lowest. The percentage next to each category shows its share of your total Cloud costs for the selected period. For example, if **Compute** shows 29%, then 29% of your Cloud spend during that time came from compute usage. ### 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 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. ### Advanced settings - 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 your Cloud usage costs will increase as your app usage grows. * **Free plan users**: upgrade from **Tiny** to a larger instance by upgrading your plan at anytime * **Paid plan users**: choose a new instance size from the options below: * **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 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 ## Example flow - Prompting Lovable to build a CRM tool *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. *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. *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. *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) Set up automatic actions that save you time. *When a new lead is added to the Clients table, send me an email notification. Analyze client meeting notes with Lovable AI and save a sentiment score in the Clients table. Sync new contacts automatically. Schedule a daily job at 7 AM that emails me a summary of today’s follow-ups. When a payment is marked ‘paid’ in Stripe, automatically update the related invoice’s status to ‘Paid’.* ### Step 5: Connect to other tools (Secrets) When you use services like Stripe or Google Calendar, they’ll give you private “keys.”\ Lovable will prompt you to add them securely whenever they’re needed, and only your app can use them. ### Step 6: Add AI superpowers (AI) Make the tool act like your assistant. *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.* ## Usage-based Cloud and AI pricing Lovable includes Cloud hosting and built-in AI in all pricing plans, even the Free plan. These services run on a **usage-based pricing model**. This means your costs scale with how much you use and are not covered by your subscription. From your workspace or project, go to **Settings → Cloud & AI balance**. Here, you can: * View workspace balance status * Top up and add funds to your workspace balance (available for paid plans only) * Access your invoice history and manage payment preferences * Track total Cloud and AI usage costs across your workspace * View detailed Cloud and AI usage costs for each project Currently, the list includes all projects, even those not using Lovable Cloud or AI. Projects without usage always show \$0.00. The Cloud & AI balance screen updates as follows: * Cloud usage updates daily at 10 AM CET * AI usage updates continuously - Your **Cloud balance** pays for hosting deployed apps. - Your **AI balance** pays for AI features inside deployed apps. - **Workspace Credits** are separate, only used for messaging while building apps, and can be tracked in **Settings → Plans & credits**. ### Included free usage (all plans) Every workspace receives free monthly usage, regardless of plan and regardless of when in the month you start your plan: * **\$25 Cloud balance** for app hosting * **\$1 AI balance** for AI features These free funds reset on the first day of each month at 00:00 UTC (displayed in your timezone) and are not tied to the billing cycle of your subscription plan. Unused free funds do not roll over to the next month. **Temporary offering, subject to change:** Every workspace gets \$25 Cloud and \$1 AI per month, even for users on the Free plan. ### Adding funds (paid plans only) Adding funds to your workspace balance for Lovable Cloud and AI usage is available only on paid plans. Free plan users must upgrade to access this functionality. Any usage that exceeds the included amount is billed separately and not covered by your subscription. * **Cloud usage:** depends on activity (number of users and interactions) and data transfer (uploads/downloads). * **AI usage:** depends on the model used and task complexity (more advanced models cost more). To verify costs, refer to the official sources linked in our list of supported AI models at [Lovable AI](https://docs.lovable.dev/features/ai). Workspace owners and admins on paid plans can top up balances either by doing a manual one-time top-up or by configuring automatic top-ups. Unused workspace funds roll over month-to-month but expire after one year. **One-time top-up** Top up your workspace balance manually with an amount you choose. 1. Go to **Settings → Cloud & AI balance → Top up → One-time top-up.** 2. Enter a custom amount or choose a predefined option (\$10 min, \$1000 max). 3. Complete the payment securely via Stripe. **Automatic top-up** Automatically add funds when your balance drops below \$10, but remain in control of your monthly charges by adding a monthly charge limit. 1. Go to **Settings → Cloud & AI balance → Top up → Automatic top-up.** 2. Enable automatic top-up. 3. Enter a top-up amount which will be automatically charged and added to your workspace balance when your balance drops below \$10 (\$10 min, \$1000 max). 4. Set a monthly charge limit to control how much can be charged in total each month (\$10 min, \$50,000 max). 5. Click **Save**. \ Your default payment method will be automatically charged when your balance drops below \$10, provided you have not reached your monthly charge limit. When you configure automatic top-up, you can visually monitor your monthly charges from the **Automatic top-up** screen. The monthly charge period resets on the first day of each month at 00:00 UTC (displayed in your timezone) and is not tied to the billing cycle of your subscription plan. ### Alerts and notifications Lovable keeps you informed to avoid unexpected service interruptions: * **Email notifications** sent to workspace owners and admins * **Usage alerts** displayed in the Cloud & AI balance screen and Cloud overview Alerts trigger when your workspace: * Reaches a certain percentage of included usage * Uses up all included usage * Reaches a certain percentage of wallet balance * Uses up all wallet funds If your workspace balance runs out, your application will stop working until funds are added (or free usage resets at the start of the next month). To keep your application working: * **Free plan:** upgrade to a paid plan to add funds. * **Paid plans:** top up your workspace balance any time or enable automatic top-up. ### Example workspace Cloud and AI costs (per month) Here are a few examples to give you a feel for what typical monthly Cloud and AI costs might look like per workspace for different kinds of apps. These numbers are rough estimates, just to help set expectations. Keep in mind: * Your Lovable subscription does not include Cloud or AI costs. You cover those separately. * Every plan includes \$25/month of free Cloud usage and \$1/month of free AI usage per workspace. * The cost of using Lovable AI is exactly the same as going directly to the LLM provider. To verify costs, refer to the official sources linked in our list of supported AI models at [Lovable AI](https://docs.lovable.dev/features/ai). * The AI costs below are estimated using the default model, Gemini 3 Flash. | App type | Example monthly usage | Cloud cost | AI cost | What you pay to Lovable | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ------- | ------------------------------------------------------------------------------------------------------------------------- | | **Personal blog or portfolio** | 500 visits, a handful of posts/comments, some images, tiny server. AI adds summaries or catchy titles (2,500 AI calls/month, 50 input + 150 output tokens each). | \$1 | \$1 | **Subscription only.**

*The included free usage entirely covers your Cloud and AI costs.* | | **Small business website** | 5,000 visits, product listings, forms/newsletter signups, product images, tiny server. AI adds simple chat assistant (6,500 AI calls/month, 30 input + 120 output tokens each). | \$5 | \$2 | **Subscription + \$1 (AI)**

*The included free usage entirely covers your Cloud costs and \$1 of AI costs.* | | **Team project manager** | 20 active users, 10,000 visits, tasks and comments, file uploads, live updates, small server. AI adds task suggestions, reminders, comment summaries (6,000 AI calls/month, 200 input + 300 output tokens each). | \$15 | \$5 | **Subscription + \$4 (AI)**

*The included free usage entirely covers your Cloud costs and \$1 of AI costs.* | | **E-comm store** | 10,000 visitors, 500 purchases, many product images, customer/order data, checkout flows, medium server. AI adds product descriptions and a shopping assistant (20,000 AI calls/month, 40 input + 200 output tokens each). | \$65 | \$10 | **Subscription + \$49 (Cloud + AI)**

*The included free usage covers \$25 of Cloud costs and \$1 of AI costs.* | ## FAQ Yes. We designed Lovable Cloud to give you complete control: * **Option 1: Hard budget (zero charges)**\ Stay strictly within the free allowance. If you go over, your projects pause automatically. Your bill stays at \$0. * **Option 2: Top up manually (controlled scaling)**\ Top up your workspace balance with an amount you choose. Your apps scale, and you only pay for usage beyond the free allowance. \ If you spend your workspace balance, you will receive a notification and your projects will pause automatically. * **Option 3: Top up automatically (seamless scaling)**\ Automatically add funds when your balance drops below \$10, but remain in control of your monthly charges by adding a monthly charge limit. Your apps scale without interruption, and you only pay for usage beyond the free allowance.\ If funds cannot be added automatically because you reached your monthly charge limit, your projects will pause when your remaining workspace balance runs out. No, your workspace credits are separate, only used for messaging while building apps. You can track your credit usage in **Settings → Plans & credits**. You can track your Cloud and AI usage in **Settings → Cloud & AI balance**. * Your Cloud balance pays for hosting deployed apps. * Your AI balance pays for AI features inside deployed apps. The cost of using Lovable AI is exactly the same as going directly to the LLM provider. There are no hidden fees. To verify costs, refer to the official sources linked in our list of supported AI models at [Lovable AI](https://docs.lovable.dev/features/ai). 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. No, when you connect your project to Cloud, you can't revert that change or disconnect your project from the Cloud. 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 you can't revert to a previous version of your app in the remixed project if the project is using Lovable backend. For frontend-only projects hosted in the Cloud, reverts are possible. This is technically possible since you own the code in GitHub, but not straightforward. We are looking into making this easier. For more information, see [Self-hosting: Run your Lovable Cloud project anywhere](https://docs.lovable.dev/tips-tricks/self-hosting). You can see the Cloud and AI usage breakdown per project by going to **Settings → Cloud & AI balance.** Currently, the list includes all projects, even those not using Lovable Cloud or AI. Projects without usage always show \$0.00. 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. This can happen if you have too much data running on a smaller Cloud project instance. To fix it, please go to the **Cloud tab → Overview → Advanced settings** and then choose a larger instance size. After you've switched to a larger instance, and given it a couple of minutes to change, the data should load, and your Cloud project should work again. Keep in mind that a larger instance size will result in higher Cloud usage and increased Cloud usage costs. No. Once Cloud is enabled for a project, the selected region is locked and cannot be changed. Existing projects cannot be moved across regions. Lovable automatically preselects the region closest to your current location, but you can change it before confirming. Yes. You can set a preferred default region for new Cloud projects in **Connectors** → **App connectors** → **Lovable Cloud** → **Manage permissions** # 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**, then go to **App 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**, then go to **App 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.** Everyone using a connection sees the same data (the service principal's data). Create separate service principals per access role as a workaround. * **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**, then go to **App 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**, then go to **App 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. # 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. macOS is available now; Windows support is coming soon. 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). Windows support is coming soon. * 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. ## Keyboard shortcuts | Action | macOS | | ---------------------------- | ----------------------- | | Open option menu | `Cmd+K` | | New project tab | `Cmd+T` | | Close current tab | `Cmd+W` | | Switch to tab 1–9 | `Cmd+1` through `Cmd+9` | | Open current page in browser | `Cmd+Shift+O` | | Zoom in | `Cmd+=` | | Zoom out | `Cmd+-` | | Reset zoom | `Cmd+0` | | Preferences | `Cmd+,` | ## 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**, then go to **App 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**, then go to **App 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 Workspace **admins** and **owners** can connect Firecrawl. 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) When the connection is created, Firecrawl becomes available across all projects in the workspace. 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. To connect Firecrawl: 1. Open **Connectors** → **App connectors** and select **Firecrawl**. 2. Click **Add connection**. 3. **Display name**: name the connection, for example, `Firecrawl Prod`. 4. Under **Authentication**, select **Managed by Lovable**. 5. Click **Create**. When connected, your Lovable apps can start using Firecrawl to scrape, crawl, and keep website data up to date. 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. 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 * Lovable workspace owner or admin role ### 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. To create a Firecrawl API key: 1. Go to [Firecrawl](https://www.firecrawl.dev/) and set up your account. 2. Go to your Firecrawl dashboard and navigate to the [API Keys page](https://www.firecrawl.dev/app/api-keys). 3. Click **Create**. 4. Give your key a descriptive name, for example, `Lovable integration`. 5. 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 You can create multiple connections using different API keys. To connect Firecrawl: 1. Open **Connectors** → **App connectors** and select **Firecrawl**. 2. Click **Add connection**. 3. **Display name**: name the connection, for example `Firecrawl Prod`. 4. Under **Authentication**, select **Your own credentials** and use your own Firecrawl API key (`fc-xxxxxxxx…`). 5. Click **Create**. When connected, your Lovable apps can start using 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App connectors**, and select . Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. # Connect to GitHub Source: https://docs.lovable.dev/integrations/github Connect your Lovable project to github.com, GitHub Enterprise Cloud (data residency), or self-hosted 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. 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. ## Why connect Lovable to GitHub Connecting your Lovable project to GitHub lets you: * **Back up your code**: Store your project safely outside Lovable. * **Collaborate easily**: Invite developers, use pull requests, branches, and code reviews. * **Sync changes automatically:** Edits in Lovable appear in GitHub, and changes pushed to the active GitHub branch sync back into Lovable. * **Work locally in your IDE**: Clone, edit, and commit in your IDE while keeping your project synced. * **Deploy outside Lovable**: Self-host or deploy to alternative platforms, see [Deployment, hosting, and ownership options with Lovable Cloud](/tips-tricks/deployment-hosting-ownership). * **Test safely**: Use branches and pull requests to develop features on a separate branch before merging changes to your live project. * **Keep a copy of your code within your own infrastructure (Enterprise)**: connect to GitHub Enterprise Cloud with data residency, or to GitHub Enterprise Server running on your own hardware. 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 integration works Lovable's 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 connection A project repository connection links 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 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 → 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. ## Connect a project to GitHub 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. * 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 rename, move, or delete your GitHub repository after connecting. Doing so will break the sync, and Lovable won't be able to update your project. ## Manage a project's repository connection 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 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 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 renamed, moved, transferred to another owner, or deleted on GitHub. You can either: * **Restore the repository on GitHub.** Rename it back to its original owner, name, and path, 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. 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. Just connect and authorize. GitHub will safely store 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. 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. The GitHub connection breaks. Your project stops syncing, and you are not able to edit it in Lovable. To fix this, restore the repository to its original owner, name, and path. If it was deleted, you can [restore it on GitHub](https://docs.github.com/en/repositories/creating-and-managing-repositories/restoring-a-deleted-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 project to GitLab Source: https://docs.lovable.dev/integrations/gitlab Connect your Lovable project to GitLab.com or a self-managed GitLab instance for code backup, collaboration, and deployment. [GitLab](https://gitlab.com/) is a platform for storing, managing, and sharing code. It provides version control, CI/CD pipelines, code reviews via merge requests, and integrations with popular deployment tools. With GitLab, your app can: * **Back up your code:** Store your project safely outside Lovable. * **Collaborate easily:** Invite developers, use merge requests, branches, and code reviews. * **Sync automatically:** Edits in Lovable appear in GitLab, and changes in GitLab sync back on the default branch (typically `main`). * **Work locally:** Clone, edit, and commit in your IDE while keeping your project synced. * **Deploy anywhere:** Self-host or deploy to alternative platforms. See [Deployment, hosting, and ownership options with Lovable Cloud](/tips-tricks/deployment-hosting-ownership). * **Use your company's infrastructure:** With GitLab Self-Managed, keep your code entirely within your organization's own servers. You don't need GitLab to use Lovable. Many users build and launch entirely within Lovable. ## How GitLab connections work Lovable supports two GitLab connection types through a single unified connector: * **GitLab.com** is the hosted service managed by GitLab Inc. * **GitLab Self-Managed** lets you connect to a GitLab instance that your organization runs on its own servers. When you open GitLab, you choose which type to set up. Both types support the same two-way sync between Lovable and your GitLab repository. Within your Lovable workspace: * You can create multiple GitLab connections. * Each connection is linked to a namespace (personal account or group) on a GitLab instance. * You can connect multiple namespaces from the same GitLab account or instance. * Each Lovable project can be linked to one repository within one of those namespaces. ## How to connect GitLab Workspace **admins** and **owners** can manage GitLab, which includes adding connections and linking or unlinking projects. Users with **editor** role can link or unlink projects. ### Prerequisites * A GitLab account on [gitlab.com](https://gitlab.com) or on your self-managed instance. * Lovable workspace admin or owner role. * For GitLab Self-Managed: admin access to your GitLab instance to create an OAuth application, and network access from Lovable's IP ranges. ### Before you connect * **Single source of truth:** When connected, your code lives in GitLab, not separately in Lovable. * **Two-way sync:** Edits in Lovable appear in GitLab, and vice versa. * **Stable repo path:** The connection depends on the exact GitLab project name, namespace, and instance URL. Don't rename, move, or delete your GitLab project after connecting. Doing so will break the sync, and Lovable won't be able to update your project. ### Step 1: Set up a GitLab connection GitLab.com is the hosted service managed by GitLab Inc. Open **Settings** → **Git** → **GitLab**. 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 namespaces (personal account and groups) from the same GitLab account. You cannot connect the same personal account or group more than once. GitLab Self-Managed is intended for organizations that run their own GitLab server and need their code to stay within internal infrastructure. Open **Settings** → **Git** → **GitLab**. 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 CIDR 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**. ### Step 2: Connect a project to GitLab Once you have an active GitLab connection, **editors and above** can link a Lovable project to a GitLab repository. Each Lovable project can have **one linked repository**. Open **Settings** → **Git** → **GitLab** and click **Connect project**, or click the GitLab icon in the top-right corner of your project. Select the namespace (personal account or group) where the repository should be created. Confirm the transfer. A new GitLab project is created, and two-way sync begins automatically. ## Disconnect a project from GitLab Workspace admins and owners can disconnect (unlink) **any project** from GitLab at any time in the project's GitLab settings. 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 code stays in Lovable:** Future changes are stored only inside Lovable. If you reconnect later: * A **new GitLab repository** is created using your latest Lovable code. * Your **original repository** stays on GitLab but is no longer linked to Lovable. You can't disconnect a project if Lovable can't reach the GitLab repository (for example, if it was renamed, moved, or deleted). ## Limitations GitLab currently does not support: * Importing an existing GitLab repository into Lovable. You can only export from Lovable to GitLab. * Syncing branches other than the default branch (usually `main`). * Reconnecting to the same repository after disconnecting. A new repository is created on reconnect. ## How to unlink projects from a GitLab 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 **Settings**, then go to **Git**, and select **GitLab**. 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 GitLab through this connection. If a project needs GitLab again, you can link it to any available connection. ## How to delete a GitLab connection Workspace admins and owners can delete GitLab connections. 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 **Settings**, then go to **Git**, and select **GitLab**. Open the connection you want to remove. Review the **Linked projects** section. Under **Delete this connection**, click **Delete** and confirm. ## FAQ 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. Unsync the project from the current GitLab connection (there's a disconnect option in settings) 2. Delete the existing connection if you want a different personal account (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 Yes. You can disconnect projects from GitLab at any time in your 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 the **default branch** (usually `main`). Merge your branch into `main` to see it inside Lovable. Yes. You can connect multiple namespaces (your personal account and multiple groups) from the same GitLab account or self-managed instance. 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. Only works on `*.lovable.app` domains. * **Your own credentials**: bring your own server and browser API keys. Required for custom domains and recommended for 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. 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. * 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. ## 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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. ## 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. Per-user Google login for end users is not supported. 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 → App 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 documention, 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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 ## 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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 `+` 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 * The Lovable dashboard sidebar navigation * Project settings dropdown ### Overview and use cases * [Lovable Cloud](/integrations/cloud): providing built-in backend services, authentication, database, and full-stack hosting * [Lovable AI](/integrations/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 * [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 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 * [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 * [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 * [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 * [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 * [Linear](/integrations/linear): creating and updating issues, reading project and team data, and building issue tracking workflows * [LinkedIn](/integrations/linkedin): fetching and displaying your profile, creating posts and comments * [Mailgun](/integrations/mailgun): sending transactional email from a verified domain, and tracking delivery events such as bounces, complaints, and unsubscribes * [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 * [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 * [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 * [Wiz](/integrations/wiz): scanning your project's dependencies for known vulnerabilities using enterprise-grade software composition analysis * [WordPress.com](/integrations/wordpress-com): reading and managing WordPress.com sites and content When you need backend functionality, such as authentication, database, and storage, use [Lovable Cloud](/integrations/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 cannot be disabled. ### 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. ### Gateway-based connectors Most app connectors route through a **secure gateway** between your Lovable app and the third-party service (for example, Slack). 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 simply 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 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` 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. ### Managed project secret: `LOVABLE_API_KEY` App connectors and [Lovable AI](/integrations/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 `+` 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 * The Lovable dashboard sidebar navigation * Project settings dropdown ### 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](/integrations/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 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. * Per-user Linear login where each end user connects their own Linear 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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 a supported 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. 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 supported 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 → Privacy & security → Third-party MCP clients.** * One of the [supported AI clients](#supported-ai-clients) installed ## Before you connect Once 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. 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 the Lovable MCP server through Claude's connector settings. The same flow works in Claude Desktop (macOS and Windows) and on claude.ai. In Claude, go to **Settings** → **Connectors**. Click **Add custom connector**. Set the name to `Lovable` and the URL to `https://mcp.lovable.dev`. Click **Add** to save the connector. Sign in to Lovable when Claude prompts you to authenticate. The Lovable tools appear in the chat composer's tool menu once authentication is complete. Run the following command in your terminal: ```bash theme={null} claude mcp add --transport http lovable "https://mcp.lovable.dev" ``` 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. 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. All tool calls are workspace-scoped to the OAuth token used. ### Projects and workspaces | Tool | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `get_me` | Get the authenticated user's profile and workspaces | | `list_workspaces` | List all workspaces the user belongs to | | `get_workspace` | Get details for a specific workspace | | `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 | | `create_project` | Create a new project, optionally with an initial message to the agent | | `deploy_project` | Publish a project 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, library projects, or projects with public remixing enabled). | | `set_project_visibility` | Set who can access the **project in the editor**: `private` (Workspace, all workspace members, default) or `draft` (Restricted, creator only, 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 | | `list_template_projects` | List available project templates | | `list_library_projects` | List design system library projects 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` | Poll for message completion status after `send_message` with `wait=false` | ### 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 | ### Knowledge | Tool | Description | | ------------------------- | ------------------------------------------ | | `get_workspace_knowledge` | Get the workspace's custom AI instructions | | `set_workspace_knowledge` | Set the workspace's custom AI instructions | | `get_project_knowledge` | Get a project's custom AI instructions | | `set_project_knowledge` | Set a project's custom AI instructions | ### 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 | | `get_database_connection_info` | Get the connection string and API URL for a Lovable Cloud project | ### Connected MCP servers | Tool | Description | | ------------------- | ------------------------------------------------------------------- | | `list_mcp_servers` | List all MCP servers connected to a workspace | | `list_mcp_catalog` | Browse featured MCP server templates available to add | | `list_connectors` | List available connector integrations (standard, seamless, and MCP) | | `list_connections` | List authenticated connector accounts for a workspace | | `add_mcp_server` | Add an MCP server (catalog or custom) to a workspace | | `remove_mcp_server` | Remove an MCP server 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 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 | ## 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. Copy this file and add it to your AI client's skills or instructions directory. ````markdown theme={null} --- name: lovable-mcp description: > Use Lovable's MCP server to create, iterate on, and deploy full-stack web apps from natural-language prompts. Trigger this skill whenever the user wants to build a web app, dashboard, internal tool, prototype, landing page, or any frontend/full-stack project using Lovable — whether they say "Lovable" explicitly or just need a working app built and deployed fast. Also trigger when the user wants to manage Lovable projects programmatically: listing workspace projects, auditing edit history, reviewing diffs, reading project files, checking deployment status, managing databases, or setting AI governance policies. If the user mentions "Lovable," "lovable project," "lovable app," or asks to build/ship/deploy a web app and Lovable is available as a connected MCP, use this skill. Even if they just say "make me an app" or "build a dashboard for X" — if the Lovable MCP is connected, this skill applies. Covers the full lifecycle: create → iterate → review → deploy. --- # Lovable MCP Server Build, iterate, inspect, and deploy full-stack web apps through Lovable's MCP server — without ever opening the Lovable UI. Lovable's agent handles the heavy lifting: you describe what you want in plain language, and it builds a working app (React + Vite + Tailwind + Supabase when needed). The MCP server exposes this capability programmatically, so you can drive the entire workflow from a supported client that supports skills. ## When to use this skill - The user wants a **new web app, dashboard, prototype, or internal tool** built from a description - The user wants to **iterate** on an existing Lovable project (add features, fix bugs, change design) - The user needs to **inspect** a Lovable project: read source files, review diffs, trace edit history - The user wants to **deploy** a Lovable project to production - The user needs **workspace management**: list projects, audit activity, set governance policies - The user wants to **provision or query a database** on Lovable Cloud --- ## Core Workflow The typical flow is: **create → iterate → review → deploy**. Each step maps to specific tools. ### 1. Create a project Use `create_project` with a clear, detailed prompt. The Lovable agent starts building immediately. ``` create_project( workspace_id: "your-workspace-id", // required — get from list_workspaces() description: "Project management dashboard", // required — short project name initial_message: "Build a project management dashboard with a kanban board, team member list, and a sidebar for filtering by status and assignee. Use a clean, modern design with a dark mode toggle." ) ``` Returns: `project_id`, `editor_url`, `preview_url`, `sandbox_url`. **Full parameter list:** - `workspace_id` (required) — target workspace - `description` (required) — short project name, shown in the editor - `initial_message` (optional) — the build prompt sent to the Lovable agent; omit to create a blank project - `tech_stack` (optional, default: `vite`) — override if you need a specific stack - `template_project_id` (optional) — clone from a template; get IDs from `list_template_projects` - `selected_libraries` (optional) — attach workspace design system libraries; get IDs from `list_library_projects` - `visibility` (optional) — `draft` (Restricted: creator only, requires Business or Enterprise) or `private` (Workspace: all workspace members, default) **Prompting tips for initial_message:** - Be specific about what the app should do, not just what it should look like. Lovable's agent is strongest when it understands the *purpose*. - Mention the data model if you have one in mind ("each task has a title, status, assignee, and due date"). - If you want a particular tech choice, say so — otherwise Lovable picks sensible defaults (React, Vite, Tailwind, shadcn/ui). - You can reference design inspirations: "similar layout to Linear" or "card-based like Trello." ### 2. Iterate on what's built Use `send_message` to talk to the Lovable agent on an existing project. This is the same agent quality as the Lovable UI — treat it like a conversation with a skilled developer who can see the entire codebase. ``` send_message(project_id: "...", message: "Add a drag-and-drop feature to the kanban columns. Also, the header font feels too heavy — switch to Inter at 500 weight.") ``` Returns: `message_id`. Use this with `get_diff` to see exactly what changed. **Iteration best practices:** - One conceptual change per message tends to produce cleaner results than cramming five unrelated requests together. - If something went wrong, describe *what you see* and *what you expected* — the agent debugs well when given concrete symptoms. - You can reference specific files: "In `src/components/KanbanBoard.tsx`, the drag handler doesn't update state correctly." ### 3. Review changes Use `get_diff` with the `message_id` from `send_message` to inspect what the agent changed. This is your code review step. ``` get_diff(project_id: "...", message_id: "...") ``` If you want broader context: - `list_files` → discover the project structure at any commit - `read_file` → read the full contents of any file (requires a git ref — get `latest_commit_sha` from `get_project`) - `list_edits` → see the full edit history with timestamps, prompts, and commit SHAs ### 4. Deploy Use `deploy_project` to publish the current build to production. ``` deploy_project(project_id: "...") ``` Returns: the live production URL. On Free and Pro plans the app is publicly accessible immediately. On Business and Enterprise plans, access follows the project or workspace website access setting. --- ## Tool Reference ### Project Operations | Tool | What it does | When to use it | |---|---|---| | `create_project` | Creates a new Lovable project from a prompt | Starting a new app, dashboard, tool, or prototype | | `send_message` | Sends a prompt to the Lovable agent on an existing project | Iterating — adding features, fixing bugs, changing design | | `get_project` | Returns project details (URLs, latest commit, publish status) | Before any project operation, to confirm state and get current refs | | `list_projects` | Lists all workspace projects (supports search) | Discovery, auditing, finding a project by name | | `deploy_project` | Publishes current build to production | Shipping the app | ### Code & History Inspection | Tool | What it does | When to use it | |---|---|---| | `list_files` | Lists all files at a git ref | Discovering project structure before reading specific files | | `read_file` | Returns full file contents at a git ref | Inspecting source code, config, or any project artifact | | `get_diff` | Returns the diff for a specific edit (by message_id) | Reviewing what changed after a `send_message` | | `list_edits` | Full edit history (reverse chronological) | Understanding how a project evolved, locating past changes | | `get_message` | Status and details of a specific message/edit | Checking if a `send_message` completed, is running, or failed | ### Workspace Governance | Tool | What it does | When to use it | |---|---|---| | `list_workspaces` | Lists all workspaces the user belongs to | First call if workspace_id is unknown — most tools require it | | `get_workspace` | Workspace details: plan, credits, members, settings | Checking account state and available credits | | `get_workspace_knowledge` | Returns AI governance policies for the workspace | Understanding what rules apply across all projects | | `set_workspace_knowledge` | Sets AI governance policies workspace-wide | Defining standards (stack constraints, naming, security rules) | | `get_project_knowledge` | Returns project-specific AI context | Understanding a project's defined stack and constraints | | `set_project_knowledge` | Sets project-specific AI context | Defining tech stack, architecture decisions, or constraints for a project | ### Database (Lovable Cloud) | Tool | What it does | When to use it | |---|---|---| | `get_database_status` | Checks if Lovable Cloud DB is enabled | Before any database operation | | `enable_database` | Provisions a PostgreSQL database for the project | When the project needs persistent data storage (one-time) | | `query_database` | Runs SQL against the project's database | Inspecting data, debugging schema, verifying migrations | | `get_database_connection_info` | Returns credentials and connection strings | Connecting external tools (psql, pgAdmin, ORMs) to the DB | ### Analytics | Tool | What it does | When to use it | |---|---|---| | `get_project_analytics` | Historical visitor metrics (pageviews, bounce rate, etc.) | Assessing how a deployed app is performing | | `get_project_analytics_trend` | Real-time visitor count + 5-min intervals | Monitoring traffic right after a deploy | ### File Uploads | Tool | What it does | When to use it | |---|---|---| | `get_file_upload_url` | Returns a signed URL for uploading a file to a project | Adding assets, data files, or binary content | ### MCP Management | Tool | What it does | When to use it | |---|---|---| | `list_mcp_catalog` | Lists available MCP servers in the Lovable catalog | Discovering what external tools can be connected | | `list_mcp_servers` | Lists MCP servers connected to a project | Checking what tools the agent currently has access to | | `add_mcp_server` | Connects an MCP server to a project | Extending agent capabilities with external services | | `remove_mcp_server` | Disconnects an MCP server from a project | Revoking agent access to a tool | ### Templates & Library | Tool | What it does | When to use it | |---|---|---| | `list_library_projects` | Lists projects saved to the workspace library | Finding reusable templates your team has built | | `list_template_projects` | Lists official Lovable starter templates | Finding a starting point before `create_project` | ### Authentication | Tool | What it does | When to use it | |---|---|---| | `get_me` | Returns authenticated user details | Confirming auth works and retrieving user ID | --- ## Common Patterns ### Build and deploy in one flow ``` 1. list_workspaces() → get workspace_id 2. create_project(workspace_id, description, → get project_id initial_message: "...") 3. get_project(project_id) → confirm it's built, get preview_url 4. send_message(project_id, "...") → iterate if needed 5. get_diff(project_id, message_id) → review changes 6. deploy_project(project_id) → ship it ``` ### Audit a workspace ``` 1. list_workspaces() → get workspace_id 2. list_projects(workspace_id) → see all projects 3. For each project of interest: - list_edits(project_id) → review edit history - read_file(project_id, ref, path) → inspect code - get_database_status(project_id) → check DB state ``` ### Debug a stuck project When a user has a Lovable project that isn't working right: ``` 1. get_project(project_id) → get latest commit SHA 2. list_files(project_id, ref) → understand the structure 3. read_file(project_id, ref, path) → read the relevant files 4. list_edits(project_id) → understand what changed recently 5. get_diff(project_id, message_id) → inspect the last few edits 6. send_message(project_id, "...") → send a targeted fix based on what you found ``` ### Set governance before a build For teams that want consistent standards across projects: ``` 1. list_workspaces() → get workspace_id 2. set_workspace_knowledge(workspace_id, "Always use TypeScript strict mode. All components must use shadcn/ui. No inline styles. Use Zustand for state management.") 3. create_project(workspace_id, description, initial_message: "...") → new project inherits these rules ``` --- ## Important Notes - **`create_project` requires `description`; `workspace_id` is auto-selected when possible.** If you don't pass `workspace_id` and the user has multiple eligible workspaces, the tool returns `WAITING` with the workspace list and you must call `create_project` again with the chosen `workspace_id` (ChatGPT users can pick via a widget instead). The build prompt goes in `initial_message`, not `prompt`. - **Always call `list_workspaces` first** if you don't already have a `workspace_id`. Most tools require it. - **`read_file` needs a git ref.** Get `latest_commit_sha` from `get_project` before reading files. - **`get_diff` uses `message_id`**, not commit SHA. Save the message_id from `send_message`. - **`send_message` may take time.** The Lovable agent is building real code. Use `get_message` to poll status if needed. - **One database per project.** `enable_database` is a one-time operation. It provisions PostgreSQL via Lovable Cloud. - **Deployed app access follows your plan's website access settings.** On Free and Pro plans, anyone with the URL can visit the app. On Business and Enterprise plans, the URL may be restricted to workspace members if internal publishing is configured. - **Credit usage.** Every `create_project` and `send_message` draws from the workspace's build credit pool. Check `get_workspace` if you're unsure about remaining credits. - **Availability.** The MCP server is available on all Lovable plans, including Free. ```` ## 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 using `list_files` to browse the project schema, or run a `SELECT table_name FROM information_schema.tables` query first. ## 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. 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. * **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, visual edits, 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**. * **Preview interaction tools.** The toolbar used for visual edits, leaving comments on the preview, drawing, 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, visual edits 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**, then go to **App 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**, then go to **App 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** → **Chat connectors**. 2. **Select a chat connector** (for example, Notion or Linear). 3. Click **Connect**. 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** and go to **Chat connectors**. 2. Click **New MCP server**. 3. **Server name**: Enter a clear name for your server (for example, *Internal CRM* or *Analytics API*). 4. **Server URL**: Enter the address where Lovable can reach your MCP server. 5. **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. 6. **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**. 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** → **Chat connectors** → **Admin settings** to enable or disable individual MCP servers as chat connectors. # 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). # 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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 Connected 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 Connected 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 Connected App Salesforce uses Connected Apps to authorize third-party access via OAuth. You need to create one to get a Client ID and Client Secret for Lovable. 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 Connected App** in the top-right corner. Fill in the required fields: * **Connected App Name**: for example, `Lovable Integration` * **API Name**: auto-populated from the name * **Contact Email**: your email address Under **API (Enable OAuth Settings)**, check **Enable OAuth Settings**. Set the **Callback URL** to: ```text theme={null} https://lovable.dev/oauth/callback ``` Under **Selected OAuth Scopes**, add: * **Access and manage your data (api)** * **Perform requests at any time (refresh\_token, offline\_access)** Leave all other settings at their defaults. Click **Save**, then **Continue**. Salesforce may take a few minutes to provision the app. Once ready, open the Connected App and click **Manage Consumer Details** 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 Connected Apps documentation](https://help.salesforce.com/s/articleView?id=sf.connected_app_create.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 Connected App. * **Client Secret**: the Consumer Secret from your Connected 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: * Support per-end-user Salesforce login. Each connection represents a single Salesforce org shared across all projects linked to it. * Access orgs outside the `*.salesforce.com` domain. * Use Salesforce Bulk API or Streaming API endpoints. If Salesforce authorization is revoked from the Salesforce side (for example, if the Connected 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. ## 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**, then go to **App 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**, then go to **App 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 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**, then go to **App 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**, then go to **App 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**. * **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 and starts a **30-day free Shopify trial**, and makes the claiming Lovable user the Shopify store owner. 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 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**. * **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: Select the country where your store will be based. This will be used to set the currency of your Shopify store. Click **Create 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. To successfully connect an existing store, your Lovable account email must match the Shopify store owner's email. 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. 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. - Only the user who connected an existing store has write access (create, update, delete products, variants, and discount codes). Changes made by the user who connected the store will be reflected immediately in your Shopify store. - Collaborators maintain read-only access to Shopify data (search and retrieve products, variants, and discount codes), but 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. * Only the Lovable user who claimed the store has write access to the store. * Collaborators maintain read-only access to Shopify data (search and retrieve products, variants, and discount codes), but 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). Only claim your store when you are fully ready to launch as you need a paid Shopify subscription after the 30-day free trial to continue selling products online. ### 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, your **Lovable account email must match the Shopify store owner’s email**. When connected, you can manage products and build your storefront directly from Lovable. This is usually a permissions issue: * **Connected an existing store:** only the user who connected the store can make changes (create/update/delete products, variants, and discount codes). * **Created a new store (not claimed yet):** all collaborators can make changes. * **Created a new store (claimed):** the user who claimed the store becomes the Shopify store owner, and **only that user** can make changes. Collaborators still have read-only Shopify access and can 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 [Slack's 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 * Support per-user Slack login (each end user connecting their own Slack) ## 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**, then go to **App 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**, then go to **App 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** for every visitor is not what this connector provides—it represents a **shared** authorization for the workspace connection. * **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**, then go to **App 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**, then go to **App 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**, then go to **App 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**, then go to **App 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. For the latest guidance on setting up payments in Lovable, see the [Payments](/features/payments) article. 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. * **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 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. Lovable’s **native** [Supabase](https://supabase.com/) **integration** lets you manage both your front-end UI and your back-end database through a single, easy-to-use chat interface. In other words, you can design your app’s screens *and* set up a cloud PostgreSQL database without leaving Lovable. This unified approach makes powerful app development accessible to everyone – non‑technical users can rely on Lovable’s guidance, while experienced developers can tap into advanced Supabase features as needed. ## Overview