Why companies don't offer a public API: the vendor's side

Companies don’t offer a public API because a public API is a promise: they must document it, keep it stable for years, secure it against abuse and support the people who build on it. Many vendors decide that promise costs more than it earns, or that it gives away data and features they would rather sell on a higher plan. The API usually exists anyway, as the private one their own web app calls.

We already wrote about this from your side, the moment your AI agent says the app has no API. This post is the other side: what the vendor is weighing when they say no, with real examples, and what you can do next.

Public, partner, private, internal: what is the difference?

“No API” is rarely literal. Almost every modern web app is a frontend that talks to a backend over HTTP and JSON. Open your browser’s developer tools on any dashboard and you will see the requests fly. That is an API. The question is who is allowed to use it, and on what terms.

Kind	Who can use it	Documented?	Stability promise	Example
Public	Anyone who signs up for a key	Yes, openly	Versioned, deprecations announced	Stripe
Plan-gated public	Customers on certain plans	Yes	Yes, for paying tiers	Circle Admin API, Business plan and up
Partner	Approved companies under contract	Behind a login or NDA	Per contract	Slack Marketplace apps get higher limits
Private / internal	The vendor’s own web and mobile apps	No	None, can change any day	The JSON calls behind almost every dashboard

So the real question behind “why is there no API” is: why does the vendor keep the internal one internal? Here are the reasons that come up again and again.

Why don’t companies offer a public API?

1. A public API is a promise, and promises cost money

An internal API can change on every deploy, because the vendor ships the frontend that calls it at the same time. A public API cannot. Once outside code depends on it, every rename breaks someone.

Stripe, one of the most admired public APIs, put the cost plainly in 2017: “Providing extensive backwards compatibility isn’t free; every new version is more code to understand and maintain.” At the time Stripe had kept compatibility with every API version since 2011 (Stripe engineering blog, August 2017). Stripe can afford that. A 15-person company selling booking software usually cannot, and it also has to pay for docs, keys, a developer portal and support tickets from people who are not even its customers.

2. Security and abuse

Every public endpoint is attack surface. OWASP lists “Improper Inventory Management” as number 9 in its API Security Top 10, and warns that “old API versions or endpoints left running unpatched and using weaker security requirements” are a common way in (OWASP API Security Top 10, 2023). Fewer public versions means fewer old doors to forget about.

Abuse matters too. In May 2025 Slack cut the rate limit on two message-reading methods to one request per minute for commercially distributed apps outside its Marketplace. Its reason: “preventing unsanctioned data scraping and abuse” (Slack changelog, May 29, 2025). Internal customer-built apps were not affected.

Slack developer changelog, “Rate limit changes for non-Marketplace apps”, May 29, 2025, captured October 2026.

3. The data is the moat

For many apps the data your account holds, and the screens you use to work with it, are the product. An open API makes it easy to move that data into a competitor or to build a better client on top of it.

Reddit is the best-known case. In 2023 it started charging for API access. Christian Selig, developer of the third-party client Apollo, said the quoted price was $12,000 per 50 million requests, which he calculated at about $20 million a year for his app (MacRumors, May 31, 2023). Apollo shut down. Nordic APIs collects more cases of the same pattern, from Netflix closing its public API in 2014 to Spotify removing API features in late 2024, and argues that AI scraping now pushes vendors further in this direction (Nordic APIs, January 2026).

4. The API is an upsell

Often the API exists, but only on a plan most customers do not pay for. This is a deliberate pricing choice: integrations matter most to bigger, more automated teams, and those teams pay more.

• Circle lists “API access”, “Admin API” and “Circle MCP” as not included on Professional ($89 a month on annual billing) and included from Business ($199 a month), with 5,000 Admin API requests a month on Business (Circle pricing, as of October 2026).
• Meetup lists “API access” as a Meetup Pro benefit (Meetup API docs, as of October 2026).

Circle Developers overview page, Admin API section, October 2026.

If you are on the lower plan, the vendor’s answer to “is there an API?” is “yes, upgrade”. Sometimes that is the right answer for you. We cover the gaps for Meetup in detail on its integration page.

5. Partners instead of the public

Some vendors open their API only to companies that sign a contract: channel managers, certified resellers, big CRM vendors. Partners are fewer, vetted, and bring revenue or distribution. Random developers bring support load.

The cost of this choice is rising. API analyst Kin Lane argued in August 2026 that “Hiding your API docs means you are hiding them from the agents your customers are using” (API Evangelist, August 12, 2026). Your agent cannot email a partner manager and wait three weeks.

6. Small team, other priorities

Many apps people ask us about are built by small teams that chose features over a developer platform. Skool, Partiful and Pirate Ship all have no public API for the actions their users ask for, based on our research for the catalog. It is not hostility. A developer platform competes for the same engineers as the feature their paying users asked for this quarter.

7. Legacy architecture

Older apps render pages on the server, keep state in session cookies and protect forms with tokens built for a browser. Their internal “API” is a set of form posts that only make sense with the HTML around them. Turning that into a clean public API is a rewrite, not a weekend.

Even when an API exists, it can disappear

A vendor that once said yes can change its mind. Medium’s official API docs on GitHub now open with “The Medium API is no longer supported. We do not recommend using it”, and the repository was archived on March 2, 2023 (Medium API docs on GitHub). The docs also say Medium does not allow new integrations.

MCP is the same decision, made again

AI agents add a new door: an MCP server. For a vendor it is the same trade with a new name. An MCP server usually sits on top of an API, so a vendor that never published an API rarely ships MCP. (If the difference between the two is new to you, see MCP vs API.)

The numbers show it. Supergood’s API Report Card grades 1,488 business platforms: 857 of them, about 58%, rate D or worse, and 124 have an official MCP server (as of October 2026, Supergood API Report Card). And where MCP does exist, vendors gate it the same way as the API. Circle MCP starts on the same Business plan as the Admin API.

Expect the same reasons to repeat: read-only MCP servers because writes are riskier, MCP on top plans only, MCP for partners first.

What can you do when an app has no public API?

Use this order. Stop at the first step that works.

1. Check properly for an official API. Look for “developers”, “API” or “integrations” in the footer, the pricing page’s feature table and the help center. Check for a Zapier or Make app too.
2. If an official API covers your task, use it. It is stable, supported and inside the vendor’s terms. This is the best option, even if it means a plan upgrade. Compare the upgrade price with the hours the task costs you.
3. If Zapier or Make covers the exact action, use that. For simple triggers and actions it is the fastest path.
4. Ask the vendor. Requests from paying customers move roadmaps more than you think. A short, specific one works best (template below).
5. If the task is rare, do it by hand. Five minutes a month is not worth an integration.
6. If it is frequent and none of the above works, use a hosted integration that signs in as you, or build and maintain your own. Before you automate a logged-in account, read the app’s terms. The legal side is in is web scraping legal.

Your situation	Best option
Official API covers the action on your plan	Official API
Official API on a higher plan, task saves real hours	Upgrade
Zapier or Make has the exact trigger or action	Zapier or Make
Task happens a few times a year	By hand
No API, task is frequent, you want it in your agent	Hosted integration, or your own script if you will maintain it

A request you can send the vendor

Hi, I’m a customer on the [plan] plan. I’d like to automate [one task, e.g. “creating a booking from our CRM”] with an API or MCP server. Today I do it by hand about [N] times a month. Is a public API or MCP server for this on your roadmap, or is there a partner program I can join? Read access to [X] and write access to [Y] would cover it.

Name one task, one frequency and the exact actions. “Please add an API” gets a polite form reply. “We create 40 bookings a week by hand” gets forwarded to a product manager.

Where Cotlet fits

Cotlet exists for step 6. It hosts unofficial integrations for apps with no API or a narrow one: an MCP server for agents like Claude Code, Codex, Cursor, ChatGPT and n8n, and the same actions as a REST API for scripts, with one key.

How it is designed to work: you sign in to each app once, yourself, in a browser on our side. Cotlet keeps the encrypted session, never your password. It never solves CAPTCHAs or bypasses MFA, and it keeps no payloads after a call. If an app owner objects, the integration is paused within 24 hours for everyone. Some apps, such as banks without a licence, LinkedIn and Instagram, we will not automate at all.

What it does not change: an official API, when it covers your task, is still the better choice. Each page in the integrations catalog shows what the official API offers and what it leaves out, so check that first.

Access is granted per account, and nothing is charged until your access is active. If your app is on the list, request access and pick it.