---
title: "Make Your Lovable App's API Production-Ready with Zuplo"
description: "Walk through adding API key auth, rate limiting, schema validation, a developer portal with self-serve keys, and an MCP server to a Lovable app using Zuplo and an OpenAPI spec."
canonicalUrl: "https://zuplo.com/blog/2026/03/10/add-api-gateway-to-lovable-project"
pageType: "blog"
date: "2026-03-10"
authors: "martyn"
tags: "API Gateway, Tutorial"
image: "https://zuplo.com/og?text=Make%20Your%20Lovable%20App%27s%20API%20Production-Ready%20with%20Zuplo"
---
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](https://www.reddit.com/r/lovable/)
recently and came across a post asking about
[offering API services from a Lovable project](https://www.reddit.com/r/lovable/comments/1otjhxg/offering_api_services_from_a_loveable_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.
## 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 /convert` accepts a markdown string and optional `engine`, `template`,
and `header_image` parameters, returns email-safe HTML plus a plain text
version
- `GET /templates` returns 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 `template` and `engine` fields (so only valid values
are accepted)
- A `format: "uri"` constraint on the `header_image` parameter
- 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`.
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](https://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](https://zuplo.com/docs/policies/api-key-inbound)
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](https://zuplo.com/docs/policies/rate-limit-inbound)
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](https://zuplo.com/docs/policies/request-validation-inbound)
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](https://zuplo.com/docs/articles/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](/blog/zuplo-api-monetization) (coming very soon!)
Get started with Zuplo for free (everything in this post is included, except
custom domains) at [portal.zuplo.com](https://portal.zuplo.com).