How to
How to connect Claude to software that has no public API
No published API does not mean no way in. Most software still exposes an internal endpoint, a database, or a private app surface, and a custom connector can use any of those to give Claude real read and write access.
To connect Claude to software with no public API, build a custom MCP connector that talks to whatever the software already exposes: an undocumented internal endpoint, the underlying database, a file export, or the app's own private interface. The connector wraps that surface in MCP tools Claude can call inside a conversation you start.
Key takeaways
- A missing public API rarely means a missing surface: there is usually an internal endpoint, database, or export to build on.
- A custom MCP connector wraps that surface in tools Claude can call, so no published API is required.
- The connector authenticates as your own account and never grants Claude more access than you already have.
- Create and update flow inside the conversation, while delete and send wait for a human confirmation.
- This is the standard path for in-house, legacy, and niche software that no connector directory lists.
Can you connect Claude to software with no public API?
You can connect Claude to software with no public API in most cases, because a public API is only one of several surfaces a connector can use. Internal or undocumented endpoints, the underlying database, a private app interface, or a structured export are all valid inputs a custom connector can wrap into tools.
A public, documented API is the convenient path, not the only one. Plenty of software that never published an API still serves an internal API to its own web front end, runs on a database you can reach, or supports scheduled exports.
A custom connector treats whatever surface exists as the integration point. The question is not whether there is a published API, it is which surface the software already exposes and which one is the most stable to build on.
What surfaces can a connector use instead of a public API?
Instead of a public API, a connector can use a private internal endpoint that the app's own UI calls, a direct database connection, a structured file or report export, or the application interface itself. The connector wraps the chosen surface in MCP tools that map to your real schema and fields.
A connector can build on any of these surfaces instead of a public API:
- A private internal endpoint that the app's own UI calls.
- A direct database connection.
- A structured file or report export.
- The application interface itself.
Internal endpoints are common: most modern apps have a back-end the front end already talks to, and a connector can call those same routes with your credentials. Where there is no endpoint at all, a read-only database connection or a recurring export can stand in for reads.
For legacy or on-prem software with none of the above, the connector can drive the application's own interface to read and write, so even software that was never meant to be automated can still be reached.
How do you build a connector for software with no API?
Building a connector for software with no API starts with mapping which surface to use, then wrapping it in MCP tools scoped to your account. We define read tools for the data you query and write tools for create and update, keeping delete and outbound actions behind a confirmation you approve.
Building a connector for software with no API follows a clear sequence:
- 1Map which surface to build on, picking the one most stable to depend on.
- 2Wrap that surface in MCP tools scoped to your account.
- 3Define read tools for the data you query and write tools for create and update.
- 4Keep delete and outbound actions behind a confirmation you approve.
We scope the connector to your real objects and fields, so a tool reflects the way your software actually stores data rather than a generic shape. Read tools and write tools stay separate, which keeps the access surface easy to reason about.
The connector runs inside a Claude conversation you start and acts as you, with your permissions. It never reaches further than your own account can, and high-stakes actions like deleting a record or sending a message always wait for a human confirmation before they run.
Pick the stable surface
When a tool exposes more than one surface, build on the one least likely to change. A documented internal endpoint usually outlasts a UI layout the connector would otherwise drive.
Is it safe to connect Claude to internal software this way?
Connecting Claude to internal software this way is safe when the connector is scoped properly. It authenticates as your own account and inherits your permissions, read and write tools are separate, and destructive or outbound actions require a human confirmation. The connector never grants more access than your account already holds.
Because the connector inherits your existing permissions, it cannot see or change anything you could not see or change yourself. You decide which actions run automatically inside a conversation and which pause for a confirmation step.
For software behind a firewall or running on-prem, the connector can be built to reach it without exposing it publicly, so the data stays inside your environment.