When people build with Lovable, they often reach a point where they want to bring in outside data or connect to other apps and services on the internet. Doing that on your own was sometimes impossible even if you were technical: Gmail, for example, requires an approved partnership before the integration works at all.
As Lovable grew, integrations became one of those areas where we knew we wanted to build in more structure and determinism, rather than leaving everything to the agent (and user) to figure out. We also wanted the UX to hide the complexity of acquiring, storing and using credentials at scale. We didn't want users to have to worry about configuring permissions or debugging OAuth, or to be responsible for security best practices.
Over the past 6 months, we went from having no formal integrations, to connecting Lovable to nearly 100 different services, with a pace of adding 1–3 new connectors every week. Here, we'll share more of the inside story behind how we built these and what we're tackling next.
App connectors
We first started by supporting MCP (both pre-built and custom servers) as a quick solution for the agent to get more context in the chat. That is the simpler model most coding tools stop at, including Claude and Codex: you connect something, the agent can use it in the conversation, and it stays there. The connection is never shared with collaborators, and it never ships with a published app. After that launch we wanted to build something more advanced that would let users successfully add functionality and services to their Lovable apps. We call these app connectors, and that's where the majority of our work was spent over the past 6 months.
Stateless connections
We started with very simple, stateless connectors that didn't need any type of OAuth, so that we could ensure that we got the UX right. We quickly worked on prototypes that we could put in front of the company for dogfooding. Since our interface design team does a lot of coding with AI, as soon as they got feedback, they were committing changes directly to the codebase, allowing us to iterate fast.
In three weeks we launched connectors for Firecrawl, ElevenLabs, and Perplexity to cover crawling, voice, and search. This was a proof of concept that showed we were headed in the right direction. We had thousands of users using the feature on day one, and usage kept growing as we added more connectors. Those three are still among the ones people reach for first.
OAuth and stateful connections
The next phase was focused on letting users connect their Lovable apps to their personal third-party data. For example, if you're building a tool for organizing your work, you might want to connect to your Gmail or Slack account.
These types of connectors are more complex, both from a protocol and security perspective. Even though in theory the OAuth protocol is standard, everyone handles the details differently and in sometimes subtle ways. To name a few:
- There is not one well-known URL to reach
- OAuth exchange response bodies are non-enforced
- The credentials expiration date format is up to the implementation
- Scopes can be separated by any characters you want
- Scopes can be additive when you reconnect or replace the previous connection
The big challenge with OAuth 2.0 is keeping the tokens alive. When you connect, you get a refresh_token (a long-lived token, that allows you to generate a short lived token), and an access_token (the short-lived token, that allows you to query the API).
The refresh token lasts longer, but it can still expire — some providers kill it after inactivity, and some rotate it so each refresh is single-use. The access token usually lasts an hour, sometimes less. Use them often enough to keep the grant alive, or both tokens go away and the user has to reconnect.
You can't refresh on every request, because that's slow and inefficient. Sometimes you still have to refresh in the middle of a request. What happens next depends on the provider: some rotate the refresh token, some revoke the old access token immediately, and some leave the old access token valid until it expires on its own. Pending requests have to wait either way.
We put that work in a service we call the Connector Gateway: a proxy between published Lovable apps and third-party APIs. It owns the credentials and the refresh logic, so the deployed app never sees secrets. To handle concurrent refresh, it single-flights per connection: if two requests see an expired access token at once, only one refresh runs and the other waits for the new tokens. If the refresh fails, the in-flight request fails too and we surface a reconnect rather than retrying blindly. Caching and retries sit on top of that. Here is what it looks like simplified:
When a user connects to a third-party service, the OAuth flow starts from lovable.dev, but the resulting credentials are handled by the Lovable API and stored securely in Spanner. The user's deployed Lovable app doesn't handle any secrets and doesn't need to implement anything itself.
All queries go through the Connector Gateway. It manages the token refresh logic (concurrent access, error handling, etc.) and also gives us a central place to add security checks and enterprise features like authentication passthrough, audit logging, and VPC tunneling.
We took about a quarter to set up this technical foundation, which felt quite long by Lovable standards. One reason was preserving a simple UX: if you want to connect to Gmail, you should click one button and not care how it works. Partnerships also take time.
Once the architecture was in place, shipping a new connector became a repeatable process: the integration code can be written in under a minute, then we spend days or weeks on quality, agent behavior, and the vendor. That slower start is what made the weekly cadence possible.
Scaling out
We now have nearly 100 app connectors, and ship 1–3 new connectors every week. Usage grew with the catalog: the number of projects connecting to a connector each day went from 10,000 to 20,000, and more than a million connections have been created and used across the platform. In our most popular apps, 18% use at least one connector.
We also see that projects that use connectors are more successful than ones that don't, in terms of how engaged users are with the project and how many visitors they have.
With agentic coding, we can actually build the code required to ship a new connector in less than a minute. So, one might wonder, why aren't we shipping hundreds of connectors every day?
The answer is that we want each connector to be high quality, and users to succeed with it. We don't only check that the API works. An internal skill authors a connector end to end: it does the click-ops, generates the code, boots a project, sends prompts, and checks that the agent actually uses the connector. Each connector also has evals that run continuously, so we catch regressions and keep the bar from drifting. Once something is in production, we monitor the third-party APIs themselves so we know the connector still works in the wild. Before GA, we still release internally, then to beta testers for days or weeks, and we often fine-tune the agent's knowledge and a few edge cases from those runs.
Each launch is also a partnership. We talk to the vendors, let them test the connector, and take their guidelines. With Slack, for example, we worked through which default scopes to request, and we added more recommendations in our knowledge files for how the agent should use the API.
Future work
We still have many things to improve and make our users' lives easier when it comes to connecting Lovable and third-party services.
One of the challenges with connectors is that Lovable projects are often shared, even though the connection is initiated by one person who is building. In a shared workspace, who should have access to the connected data?
Right now, the default model is that the account that sets up the connection is authorized and everyone in the workspace has access to that account's data. You might currently see warnings like this in our documentation and product:
Still, this relies on users reading and understanding these warnings. To truly prevent someone from accidentally leaking their personal data to their workspace (for example, if they set up a connector with their personal Gmail), we need more controls in the Connector Gateway. The plan is granular permissions, automatically blocking mistakes, a safe default even if you never read a warning, and a security scanner.
There's also another important type of connector that has now shipped: app user connectors. People can connect their own data to power their Lovable app, and they can also build apps that let app users bring their own data and connect it to the app. For example, you might want to build a social tracker that needs to connect to users' social accounts, or an internal scheduling tool that needs to read employees' Google Calendar data.
That is harder than v1. Someone has to own the OAuth client. Apps we didn't write still need consent and verification. And credentials have to stay isolated per app user per app, not shared on the builder's connection.
To get this working just as seamlessly as our other connectors, we had to replicate what we'd already built, and make it possible for anyone to expose that functionality through their app. Each connection still has to be deterministic and secure, so bad actors on the platform can't abuse this to steal people's data. We're excited about how app user connectors let people create SaaS apps and internal tools that harness the full ecosystem of apps and services.
We bet a quarter on the foundation. That is what made nearly 100 connectors and a 1–3-per-week cadence possible. App user connectors have shipped, so published apps can connect each person's own accounts. Next is locking down workspace permissions.
If you want to help us connect the world, we're currently looking for engineers to join Lovable. You can find more information here.
And if you have an idea for a connector, let us know! You can reach out to me (Samuel) on X or LinkedIn.
