Your API Is the Product

APIs are becoming the product. Companies don’t want your UI. They want your capabilities, and they’ll put their own interface on top.

I agree. But if your API is the product, then everything around it is the product too. How consistent it is. How it handles keys. What happens when someone, or something, abuses it.

1. Consistency is a feature

The first thing I noticed wasn’t a bug. It was naming. One parameter was camelCase. The next was snake_case. Some had numbers baked into the name.

It feels nitpicky. It isn’t.

Customers want an API where they don’t have to guess. If I learn how one endpoint works, I should be able to predict how the next one works. Same naming convention everywhere. Same response shape everywhere. If I look for status in one response, it’s there in every response, with the same values.

Consistency is how developers learn to trust you. Every inconsistency is a small tax on every customer, forever.

2. API keys are passwords

Creating an account and generating a key took me under a minute. Great experience. Then I noticed the full key sitting in plain text in the portal, available any time I wanted it.

That’s convenient. It’s also a problem.

API keys should be treated exactly like passwords:

• Show it once. At creation, then never again in full. Browsers cache and store things in ways you don’t control.
• Let users manage it. Rotate, disable, delete. Assume every key will be compromised eventually.
• Keep support out of the loop. The team’s instinct was customer service: if someone loses their key, we’ll send it to them. Here’s what actually happens. Someone copies it into WhatsApp, Telegram, or email, and now it lives in places you’ll never find. Let the user regenerate it instead.

The goal is simple. Limit the number of places a key can exist.

And this matters more now than it did two years ago. Technical and non-technical users are pasting API keys straight into their AI chat sessions. That key is now available to agents, and to whoever else has access to that session. You don’t control where your keys end up anymore. Design like it.

3. Protect yourself at the gateway

The team had usage alerts. When a user hit 140 of their 150 free credits, the founder got an email. Nice upsell trigger.

But an alert isn’t protection. It tells you something happened. It doesn’t stop it.

What you want sits at the API gateway, before the request ever reaches your application:

• Is the key valid?
• Has it exceeded its credit limit?
• Has it exceeded its rate limit? Say, 10 requests an hour on free and 100 on paid. Pick your numbers, but pick them.

Without that, two bad things happen. The first is obvious: a flood of requests takes the system down, and every other customer feels it.

The second is quieter and more expensive. In the cloud, your platform sees the load and helpfully scales up. More compute, more instances. Nobody gets paged. You find out at the end of the month when the bill arrives, and there’s no revenue on the other side of it.

I’ve seen this happen. An API in a cloud environment with no controls, a key that leaked or an agent that went rogue, and a gigantic bill. Rate limiting isn’t a scale problem. It’s a day-one problem.

You don’t have to build it all yourself. Cloudflare, a WAF, your cloud provider’s gateway. Use them.

4. Think like an attacker at signup

Here’s the exercise I use. Imagine your signup page just hit the front page of Hacker News or Reddit. Anyone can click it. What can they do in five minutes?

In this case: create an account, generate a key, and get 150 free credits.

That’s fine for a person. Now picture a bot doing it a thousand times. A credit limit per account doesn’t mean much if creating accounts is unlimited.

The team had already noticed some trial signups that looked suspect. That’s the signal. Your self-serve flow is part of your attack surface. Design it with your go-to-market in mind, and with bad actors in mind, at the same time.

The same goes for AI features

The product has AI summary features where users bring their own LLM key. Good call. If you bundle LLM access into your pricing instead, you need to stop people from overriding your prompts and turning your feature into a free Claude or ChatGPT account. Same problem, new shape.

5. Know where your data quietly lives

The team had a strong policy. Files get processed, results get returned, and everything gets deleted. Nothing is retained. Enterprise customers will love that.

Then I asked one more question. Is that output being logged anywhere?

This is one of the most common leaks I see. Nobody stores customer data in the database. But somewhere in the API server, someone added a line to log the response for debugging. Now the customer’s data is sitting in plain text in your server logs. You didn’t store it. It’s still in your infrastructure.

“We don’t store your data” has to be true across the whole pipeline, not just the database.

Keep the receipt, not the content

Not storing content doesn’t mean not storing anything. Customers will want an audit trail. Uploaded site-plan.pdf. Ran an extraction. Succeeded. Used 3 credits.

Because the day you charge someone 149 credits, they’re going to ask where they went. You want to be able to answer that without holding their files.

6. Build for the developer, and for their AI

Developers live in code and docs. But when they’re evaluating you, they’re in demo mode. They’re looking for the shortest path to one answer: will this work for me?

A few things shorten that path:

• Connect your demo to your docs. If your demo page uses the /extract endpoint, say so, and link to it.
• Let me try it in the explorer. If an endpoint needs a file, let me upload one right there. Don’t make me copy a curl command into a terminal to find out.
• Let me set my defaults once. If I always override the same three parameters, let me save them to my account or pass an override file with each request.
• Tell me what things cost. Showing whether a request is free and how many credits it used is a great way to teach your API.

Your next user is an LLM

Publish an OpenAPI spec. It’s well defined, consistently formatted, and machine readable. Then add a “copy for LLM” button. More and more developers will paste your whole spec into a model and have it write the requests. Humans reading documentation is becoming optional.

The team also asked about building an MCP server. Here’s the short version. An MCP server is a translation layer. Natural language goes in, and it turns that into calls to your API. It doesn’t replace your API. Billing, credits, and auth all still run through it.

You choose which parts of the API to expose, so it’s usually a subset. Start with a local MCP server, then move to a hosted one, ideally serverless so you’re not paying for something that sits idle. A coding agent and a link to your docs will get you most of the way there.

MCP opens your API to non-technical users. That’s a huge win. It’s also one more reason the key handling in section 2 matters.

The product is the whole thing

None of this was a knock on the team. They’d built something impressive, and most of what I flagged was them optimizing for customer experience. That’s the right instinct. It just needs a security lens next to it.

If APIs are the new product, then consistency, key handling, rate limits, and data hygiene aren’t extras. They’re the product. Your customers won’t see most of it. They’ll only notice when it’s missing.

Build it before you need it. The bill always shows up after.