Not every API is meant for everyone. When I first started working with APIs, I assumed every API was something anyone could just sign up for and use. That’s not true at all — APIs are generally grouped into a few categories based on who is allowed to use them, and understanding this distinction matters a lot, both for building software and for security testing.
What Is a Public API?
A public API (sometimes called an “open API”) is available for any developer to use, often after signing up for an API key. Companies release public APIs so outside developers can build tools, integrations, and apps on top of their platform.
Examples of public APIs I’ve worked with or seen in the wild:
- Slack’s Web API, which lets third-party developers build bots and integrations.
- Twitter/X’s API, which lets developers build apps that post tweets or read timelines.
- OpenWeatherMap’s API, which gives weather data to anyone with a free API key.
- Stripe’s API, which lets any online store integrate payment processing.
Public APIs usually come with:
- Documentation explaining every endpoint, often generated from an OpenAPI Specification file.
- Rate limits — a cap on how many requests you can send per minute or day.
- Authentication requirements — API keys, OAuth tokens, or similar.
- Terms of service that define what you are and are not allowed to do with the data.
Because public APIs are meant to be used by strangers, companies generally invest more effort into securing them properly — strong authentication, input validation, monitoring, and abuse detection — since they know from day one that untrusted parties will be sending requests.
What Is a Private API?
A private API (also called an “internal API”) is built for use only within an organization. It is not published for outside developers, and it usually isn’t documented publicly at all. Private APIs let a company’s own frontend talk to its own backend, or let internal services talk to each other — a pattern that’s especially common in microservices architecture, where dozens of small internal services need to communicate constantly.
Examples of private APIs:
- The internal API that a company’s mobile app uses to talk to its own backend servers. Even though the app itself is public, the API behind it was never meant to be called directly by outside developers.
- An API used only between two internal microservices inside a company’s cloud infrastructure, never exposed to the public internet at all.
- An internal admin dashboard’s API that only employees on the company VPN are supposed to reach.
Private APIs are usually built with the assumption that only trusted, internal systems will ever call them — which is exactly why they can end up being weaker from a security standpoint if that assumption ever turns out to be wrong.
What Is a Partner API?
There’s also a middle category worth knowing: a partner API, which is shared only with specific, approved business partners rather than the general public. It usually requires a formal business agreement, and access is tightly controlled — often through IP allow-listing, dedicated credentials, or private contracts, in addition to normal authentication.
A common example is a large retailer exposing a partner API only to its approved shipping and logistics companies, so they can update delivery statuses, but keeping that same API completely hidden from the public internet and from ordinary customers.
Quick Comparison
| Public API | Partner API | Private API | |
|---|---|---|---|
| Who can access it | Any registered developer | Approved business partners only | Internal systems/employees only |
| Documentation | Usually public | Shared only with partners | Usually undocumented publicly |
| Security expectations | Built expecting outside/untrusted traffic | Built for a limited, known set of partners | Often assumes only trusted internal callers |
| Common examples | Stripe, Slack, Twitter/X | Shipping/logistics integrations, banking partners | Internal microservices, mobile app backends |
Why This Distinction Matters for Security Research
If you do bug bounty work or web application security testing, this distinction is genuinely important. Public APIs are expected to be probed by outside developers and are usually built with stronger authentication, input validation, and rate limiting in mind — because the company knows strangers will be sending requests to them.
Private APIs, on the other hand, are often assumed to be “internal only,” and that assumption can lead to weaker validation, since the original developers didn’t expect outside traffic to ever reach them in the first place. When a private API gets accidentally exposed to the public internet — through a misconfigured server, a leaked subdomain, or a mobile app that talks directly to backend endpoints that were never meant to be public — it often becomes a high-value target for testing, precisely because the assumption “only trusted internal systems will call this” is no longer true.
This is why, during recon on a bug bounty target, finding an undocumented or “hidden” API endpoint that clearly wasn’t designed for public use is often far more interesting than testing the well-documented public API — the public one has already been hardened with outside traffic in mind, while the private one may not have been.
Final Thoughts
The line between public, partner, and private APIs comes down to a single question: who was this API designed to be called by? That answer shapes everything else — the documentation, the authentication strength, the rate limiting, and ultimately the security posture of the whole system.
