I work shifts at a factory. On the side, I run 19 production APIs on a single free-tier cloud server, all of them listed on RapidAPI. Total paying subscribers so far: zero. This post is about how I got here, and what I got wrong.
The setup
The server is an Oracle Cloud Always Free ARM instance — 4 cores, 24 GB of RAM, $0 a month. Each API is a small FastAPI app on its own port, kept alive by a simple supervisor script that restarts it if it dies. RapidAPI sits in front as the gateway: it handles keys, quotas, and billing, so I don't have to build any of that myself.
The whole stack costs nothing to run. That was the point. I wanted to learn how real API products work without paying for the lesson.
What I built
The catalog grew in waves over about two weeks:
- A background remover (my first one — it proved the pipeline end to end)
- Utility APIs: screenshots, speech-to-text, text-to-speech, OCR, translation, IP geolocation, live prices
- Validation APIs: email, phone, postal codes, domain health, VAT & IBAN, holidays
- An AI email writer powered by free LLM tiers
- A passive website security scanner — TLS, security headers, exposed-file checks, and a 0–100 score. That one is my flagship.
Every API has a free plan. The paid plans are cheap. The code runs on the VPS; the GitHub repo is the storefront with docs and examples.
The honest numbers
I checked my provider dashboard before writing this:
- 19 APIs live, 1 more (weather) still private
- Paying subscribers: 0
- Revenue: $0.00
- API calls in the last 7 days: 23 — and every single one of them was me, testing my own endpoints during setup
The APIs work. I verified each one end to end through the real RapidAPI gateway, not just locally. The problem is that nobody knows they exist.
What I got wrong
I built first and thought about discovery later. Actually, I didn't think about discovery at all. Listing an API on a marketplace and waiting turns out to be a complete distribution strategy — a bad one.
Two weeks of building, zero weeks of telling anyone. The math is not subtle.
What I'm doing about it
I froze the catalog. No API #20 until people can actually find the first 19. The current plan:
- Submit the APIs to directories and curated lists (one already found my repo on its own and asked to feature it — that email is what woke me up)
- Write posts like this one, with real numbers, including the embarrassing ones
- Keep the free tiers genuinely usable so people who do find the APIs get value fast
Links
- Docs and catalog: https://github.com/hhellll/dev-utility-APIs
- The flagship: Website Security Scanner on RapidAPI (free plan included)
If you've sold APIs through a marketplace before, I'd honestly like to hear what moved the needle for you. "Build more APIs" is the one answer I've already tried.
Top comments (5)
This title hurt in a familiar way. Building is the part we're good at, so we keep building. I'd pick the one API with the most real calls and spend a month only on getting it in front of people. Nineteen products with zero users is still zero; one with ten users is a real conversation.
Honest version: none of the 19 has a real user yet, since the 23 calls in the last 7 days were my own tests, so I am picking on fit rather than usage. My pick is the Website Security Scanner, the flagship: a passive audit of TLS, security headers, cookie flags, exposed files like .env and .git, and outdated tech with known CVEs, with a 0-100 score. That is the one I will spend the next month getting in front of people, answering real header and TLS questions with real results.
Fair challenge. If you want to judge it by output instead of claims: the free plan gives two full scans a month, complete results, not a summary. Run it on your own site and tell me whether the score and findings feel fair. It is the Website Security Scanner in this catalog: github.com/hhellll/dev-utility-APIs
The line about 23 API calls in the last 7 days, all of them you, is a useful number because it shows discovery is the whole problem, not the catalog. One practical tip: instead of submitting to directories broadly, pick one API (the security scanner seems like your flagship) and find five places where people are already asking how to check headers or TLS, like forum threads or GitHub issues, and answer with a real result for their case. A concrete reply to one stranger's problem usually gets a first real call faster than a listing does. Which of the 19 do you think solves a problem people already complain about publicly?
Good point, and thanks for the concrete tip. The Website Security Scanner is my flagship for exactly that reason: it is a passive audit of TLS, security headers, cookie flags, exposed files like .env and .git, and outdated tech with known CVEs, with a 0-100 score, and it never returns exposed file contents. That is the one I will start with, answering real header and TLS questions with real results.