Lovable has been one of my favorite tools this year. I've used it for prototypes, internal tools, and a bunch of personal projects. It's genuinely great at getting you from idea to working app in minutes.
I was browsing the r/lovable subreddit recently and came across a post asking about offering API services from a Lovable project. It's a great question, and one I think a lot of people building with Lovable are going to hit: you've got a working app with API endpoints, and now you want to let other people use them. But any API you're exposing to the outside world needs authentication, rate limiting, input validation, and documentation.
You could try to vibe code all of that into your app, but API security and access management isn't really something you want to improvise. It's the kind of problem that's already been solved well by purpose-built tools.
That's good news: you don't need to rewrite anything. You can go from unprotected endpoints to a fully secured, documented API with self-serve developer onboarding in about 15 minutes using an API gateway.
- You built an app in Lovable or a similar AI builder and it has API endpoints
- You want to add auth, rate limiting, and docs without touching your backend code
- You want other developers (or AI agents) to be able to use your API
What we're building
For this walkthrough I built a markdown-to-email converter in Lovable. Paste markdown on the left, get email-safe HTML on the right. It supports three rendering engines (Basic, MJML, and React Email) and three templates (Minimal, Newsletter, and Announcement).
The app can be used in the browser, and it can also be used via API, and it's this API that I want to focus on.
The app exposes two API endpoints as Supabase Edge Functions (Lovable uses Supabase for all backend functions. Supabase is great and Zuplo integrates really well with it.):
POST /convertaccepts a markdown string and optionalengine,template, andheader_imageparameters, returns email-safe HTML plus a plain text versionGET /templatesreturns the available templates and rendering engines
Lovable handled the UI, the backend logic, and the deployment. That part took minutes. Now we want to turn these endpoints into something other developers can actually use.
Why bother with an API gateway?
You could ship those raw Supabase endpoints and call it done. Here's why that's a bad idea:
- Authentication. Maybe you've added basic auth to your endpoints, but how do you manage hundreds of API keys? How do you revoke one without redeploying? How do you track which consumer is making which requests?
- Rate Limiting. Supabase Edge Functions cap you at 500K invocations per month on the free plan and 2 million on Pro (then $2 per million after that). A buggy integration or a single enthusiastic consumer can burn through that fast. You need per-consumer limits you can configure without touching application code.
- No input validation. Malformed requests hit your application code directly instead of being rejected at the edge.
- No documentation. Developers who want to integrate have to reverse-engineer your API from source code or guesswork.
- No self-serve onboarding. Every new API consumer requires you to manually create and share credentials.
An API gateway sits in front of your backend and handles all of this without changing a line of your application code. You get security, reliability, and a developer experience that makes your API worth integrating with.
Step 1: Get an OpenAPI spec from Lovable
Before we can set up the gateway, we need a machine-readable description of the API. That means an OpenAPI spec.
You can ask Lovable to generate one. Here's the prompt we used:
Generate an OpenAPI 3.1 specification for the API endpoints in this project. Include request and response schemas with full property descriptions, example values, and mark required fields. Output it as a single JSON file.
Lovable produced a clean spec with properly defined schemas for both endpoints, including:
- Enum constraints on the
templateandenginefields (so only valid values are accepted) - A
format: "uri"constraint on theheader_imageparameter - Separate error response schemas for 400, 405, and 500 cases
- Example values on key properties
Review the output and ask for corrections if needed. In our case it was solid on the first pass (the app is really simple so this is expected), but edge cases and response schemas are worth double-checking. Either way, it gets you most of the way there without writing this spec by hand, which no one wants to do.
Copy the OpenAPI document and save it locally as your-app-name.oas.json.
Pro tip:
Lovable will typically put the openapi.json file in a public directory in
your app, so anyone can access it. If you prefer to keep it private, you can
ask Lovable to output it somewhere else (for example, a non-public folder you
download manually).
Step 2: Import OpenAPI into Zuplo
Head to portal.zuplo.com and create a new project. Choose to import an OpenAPI document and upload the spec from Lovable.
Zuplo creates routes for each endpoint automatically. Each route points back to your Supabase Edge Functions as the upstream URL. At this point, traffic flows through Zuplo to your backend and back, but nothing is enforced yet. It's a transparent proxy.
Now we start adding policies. Here's what the pipeline looks like once you've added them in the next steps.
Step 3: Add API key authentication
In the Zuplo route designer, open the policies section on any route and add the API Key Authentication policy. Drag it to the top of the inbound pipeline.
That's it. Every request now requires a valid API key in the Authorization
header. Requests without one get a 401 Unauthorized before they ever reach
your backend.
You can create API key consumers in the Zuplo portal under Services > API Key Service. Each consumer gets a unique key, and you can attach metadata to it (like a plan tier or organization name) that's available at runtime for custom logic if you want to.
Step 4: Add rate limiting
Add the Rate Limiting policy to the same route's inbound pipeline, right after authentication. Configure it for, say, 100 requests per minute per API key.
Two policies. Maybe 30 seconds of configuration. Your backend is now protected from both unauthenticated access and excessive usage.
Step 5: Add request validation
This is where the OpenAPI spec really pays off. Add the Request Validation policy, and Zuplo automatically validates every incoming request against the schemas in your spec.
Send a POST /convert with engine set to "handlebars" instead of a valid
option like basic, mjml, or react-email? Rejected with a 400 Bad Request
and a clear error message. Miss the required markdown field? Same thing. Pass
a non-URL string for header_image? Caught.
All of this happens at the gateway before the request ever touches your backend. This is a big deal for any app, but especially for AI built ones where input validation might not be comprehensive, or exist at all. The gateway adds a layer of protection that doesn't depend on what the AI did or didn't build into the application code.
You're done with the essentials—auth, rate limiting, and validation are in place. Zuplo also gives you a few extras worth knowing about:
Developer Portal with Self-Serve API Keys
Every Zuplo project automatically generates a developer portal from your OpenAPI spec. It exists as soon as you deploy (and you can customize it as much as you like).
The portal includes:
- Interactive API documentation with request/response schemas and examples pulled directly from your spec
- An API playground where developers can make test calls against your live endpoints
- Self-serve API key management where developers sign up, create their own keys, and start making requests immediately
That last point matters most. Without self-serve key management, every new API consumer requires you to manually create credentials and send them over, which is going to suck for you, and for them. With self-serve keys, developers onboard themselves. This is the difference between "I have some endpoints" and "I have an API product."
Bonus MCP Server for AI agents
Zuplo can also generate an MCP (Model Context Protocol) server from your OpenAPI spec. MCP is the open standard that lets AI tools and agents discover and use APIs as tools in a more tightly controlled way.
The setup is straightforward: in the route designer, click + Add and choose
MCP Server. Set the path to /mcp and add a server name and version if you
like. Zuplo turns each OpenAPI operation into an MCP tool automatically, and the
same auth and rate limiting policies apply.
In this example, the convertMarkdown operation becomes a tool that AI agents
can discover and call.
Once deployed, any MCP-compatible client can connect to your endpoint: Claude Desktop, Cursor, OpenAI agents, and others. An AI agent could convert markdown to email HTML as part of a larger workflow without anyone writing custom integration code.
From side project to API product
Starting from a Lovable app with API endpoints, here's what we added by importing an OpenAPI spec into Zuplo:
- API key authentication so only authorized consumers can access the API
- Rate limiting so no single consumer can overwhelm your backend
- Request validation so malformed requests never reach your app
- A developer portal with interactive docs, an API playground, and self-serve key management
- An MCP server so AI agents can discover and use your API natively
None of this required changing a single line of code in the Lovable app. The gateway sits in front of your backend and handles all of it.
You can also add
custom domains for your API
gateway and developer portal. For example api.yourappname.com and
docs.yourappname.com, so everything runs under your own brand.
So to answer the question from that Reddit post: yes, you can absolutely offer API services from a Lovable project. Lovable gets you to a working app fast. An API gateway gets you from working app to production API just as fast. Together, you can go from an idea to a fully secured, documented, developer-ready API in an afternoon.
...and that's even before we start thinking about Monetization (coming very soon!)
Get started with Zuplo for free (everything in this post is included, except custom domains) at portal.zuplo.com.
