---
title: "Building a Monetized API, Part 4: Polishing the Developer Portal"
description: "Connect your Zuplo project to GitHub, use Claude Code to generate documentation from your OpenAPI spec, apply a custom theme, and ship a production-ready developer portal."
canonicalUrl: "https://zuplo.com/blog/2026/04/03/building-a-monetized-api-part-4"
pageType: "blog"
date: "2026-04-03"
authors: "martyn"
tags: "API Monetization, Developer Portal"
image: "https://zuplo.com/og?text=Building%20a%20Monetized%20API%2C%20Part%204%3A%20The%20Developer%20Portal"
---
This is Part 4 of the "Building a Monetized API" series, and the final
installment. In [Part 1](/blog/2026/03/31/building-a-monetized-api-part-1), we
set up the API gateway. In
[Part 2](/blog/2026/04/01/building-a-monetized-api-part-2), we added
monetization with meters, plans, and Stripe. In
[Part 3](/blog/2026/04/02/building-a-monetized-api-part-3), we added an MCP
server with plan-gated access. Now we're taking the developer portal from
functional to polished: real documentation, a custom theme, and a
production-ready layout.
## Where we left off
After three parts, we have a fully functional monetized API. The gateway handles
authentication, consumer isolation, and rate limiting. The monetization layer
manages meters, plans, Stripe checkout, and self-serve subscriptions. The MCP
server is gated to paid plans only.
The developer portal already works out of the box. The API reference is
interactive, API keys are pre-populated in the playground, and the pricing table
shows all three plans. But the documentation section is still the default
placeholder content that Zuplo generates when the portal is first created. If
we're asking developers to pay for this API, they deserve proper documentation.
## Step 1: Connecting the project to GitHub
Up to this point in the series, all the work has been done directly in Zuplo's
UI. That's fine for gateway configuration and monetization setup, but for
writing documentation we want a proper local development workflow.
In your Zuplo project, go to **Code** and click **GitHub** to connect to a
repository. You can create a new repository or connect to an existing one. Zuplo
will push the entire project codebase as the initial commit.
Once connected, clone the repository locally:
```bash
git clone git@github.com:your-org/your-project.git
cd your-project
git checkout -b docs
```
Working on a branch is important here. The `main` branch maps to your production
environment in Zuplo, and we don't want documentation drafts going live before
they're ready.
## Step 2: Generating documentation with Claude Code
The Zuplo project contains a `docs` folder that controls the developer portal
via a Zudoku configuration file. It also has a `routes.oas.json` file: the
OpenAPI specification for the API. This is the source of truth for every
endpoint the gateway serves.
Rather than writing documentation from scratch, we can use Claude Code to
generate it from the OpenAPI spec. This is the first time AI has been used in
this series. Everything up to this point has been manual configuration and code.
Open the project in your terminal and run Claude Code with a prompt like:
> Use the `routes.oas.json` as the basis for developer documentation. Create new
> docs in the `docs` folder using Zudoku best practices. Use the Zudoku
> documentation at https://zudoku.dev/docs/llms.txt as a reference.
Claude Code reads the OpenAPI spec, understands the API's endpoints, request and
response schemas, and generates documentation pages covering:
- An introduction and quickstart guide
- Authentication details
- Guides for each major resource (projects, changelogs)
- Filtering and search documentation
- Advanced topics like the MCP server and error handling
This took about four minutes and produced seven documentation pages. Claude also
updated the Zudoku config to set the correct title, metadata, and navigation
structure, and changed the default landing page from the API reference to the
documentation section.
## Step 3: Applying a custom theme
The default developer portal looks clean, but if you're shipping a product, you
want it to match your brand. Zudoku supports [shadcn/ui](https://ui.shadcn.com/)
themes, which means you can apply any compatible theme with just a URL.
For this project, we used a theme from [tweakcn](https://tweakcn.com/) with bold
colors. In the same Claude Code prompt (or a follow-up), you can ask it to apply
the theme by providing the URL. Claude adds the CSS variables to the Zudoku
config, and the entire portal picks up the new color scheme.
You can also generate a logo. We had Claude create a simple SVG with the service
name to replace the default "My Dev Portal" text in the header.
## Step 4: Previewing locally
Before pushing anything, preview the changes locally. Install the project
dependencies and start the Zudoku dev server:
```bash
npm install
npm run docs
```
The portal runs on `localhost:9200`. Check each documentation page, verify the
navigation structure, and make sure the API reference still looks correct
alongside the new content.
One thing to watch for: Claude may duplicate page titles in the sidebar
navigation (the page title appearing both as the nav label and as a heading
inside the page). If that happens, a quick follow-up prompt fixes it.
## Step 5: Pushing to GitHub and preview environments
Once the documentation looks right locally, commit and push the branch:
```bash
git add .
git commit -m "Add developer documentation and custom theme"
git push origin docs
```
Back in the Zuplo UI, go to the **Environments** tab. A new preview environment
has automatically been created for the `docs` branch. This is one of the
powerful aspects of connecting to source control: every branch gets its own
deployed environment with a unique URL.
The preview environment builds and deploys the portal with the new
documentation. You can share this URL with teammates for review before anything
touches production.
Note that the preview environment has its own monetization configuration. The
meters, plans, and Stripe integration you set up on the working copy don't
automatically carry over to preview environments. This is by design: you can
experiment with different monetization setups across environments without
affecting production.
## Step 6: Syncing back to the working copy
The preview environment confirms the documentation looks great. Now we need to
get those changes back into the working copy, which is where all the
monetization configuration lives.
In the Zuplo UI, go to the **Code** tab and switch to the working copy. Open the
**Sync with GitHub** dialog by clicking the GitHub button at the bottom of the
editor, or with the keyboard shortcut **Cmd+Shift+P**. Select the `docs` branch
and click **Pull from GitHub**. This merges the documentation and theme changes
into the working copy without disturbing any of the monetization, metering, or
environment variable configuration.
Once the working copy rebuilds and redeploys, everything is unified: the API
gateway, the monetization layer, the MCP server, and now a fully documented,
custom-themed developer portal.
## The finished developer portal
With all four parts complete, the developer portal now includes:
- **Documentation**: seven pages of generated content covering quickstart,
authentication, resource guides, and advanced topics. The MCP server page even
notes that access is restricted to paid plans, pulled directly from the
project configuration.
- **API reference**: the interactive reference that was already there, with the
API playground and pre-populated API keys.
- **Pricing table**: the three plans (Free, Starter, Pro) with self-serve
subscription management.
- **Custom theme**: branded colors and a logo that make it look like a real
product, not a template.
## What we built across the series
Across four parts, we built a complete monetized API product:
- [x] **Part 1**: API gateway with origin auth, consumer isolation, and rate
limiting
- [x] **Part 2**: Monetization with meters, plans, Stripe integration, and
self-serve subscriptions
- [x] **Part 3**: MCP server with plan-gated access for paid subscribers only
- [x] **Part 4**: Source control, generated documentation, custom theme, and a
production-ready developer portal
This is everything you need to take an API from "deployed somewhere" to
"something developers can discover, evaluate, subscribe to, and pay for." The
gateway handles the infrastructure. The monetization layer handles the business
logic. The developer portal handles the experience.
## Where to go from here
There's a lot more you can do with monetization and developer portal
customization beyond what this series covered. A few ideas:
- **Custom pages**: add a landing page, changelog, or migration guide to the
developer portal using Zudoku's MDX support.
- **Webhooks**: notify your backend when a subscriber upgrades or cancels, so
you can trigger provisioning workflows.
- **Analytics**: use the metering data to understand which endpoints get the
most traffic and optimize your pricing accordingly.
- **Feature flags**: gate additional API capabilities beyond the MCP server by
adding more boolean features to your plans.
Check out the
[monetization documentation](/docs/articles/monetization/quickstart) for the
full range of what's possible. And if you have questions or need help getting
this set up for your own API, [get in touch](mailto:support@zuplo.com). We'd
love to hear what you're building.