How to Expose the Claude API as an HTTP Endpoint
What "exposing Claude as an HTTP endpoint" actually means
When developers search for this, they usually have one of two problems. Either they're building an app (mobile, browser extension, internal tool) that needs to call Claude over plain HTTPS without embedding Anthropic SDK credentials client-side, or they want to hand Claude access to a teammate, contractor, or third-party service without sharing their raw Anthropic API key.
The direct answer: you need a thin server that sits between your client and Anthropic's API, accepts requests on a URL you control, authenticates the caller, forwards the request to Claude, and returns the response (or streams it back). You can build that server yourself in under 50 lines, or you can use a hosted gateway like SubToAPI that already handles keys, streaming, usage tracking and multi-user access. The rest of this article covers both paths.
Why you can't just point clients at Anthropic directly
Anthropic's API already is an HTTP endpoint (https://api.anthropic.com/v1/messages), so technically Claude is "exposed" the moment you have an API key. The real problem is almost never the protocol — it's key distribution and control. If you put your Anthropic key in a mobile app, browser extension, or public frontend, anyone can extract it and run unlimited requests on your bill. Exposing Claude safely means putting your own endpoint in front of it, with its own authentication layer, so the real Anthropic key never leaves your server.
Option 1: Build your own proxy server
This is the straightforward DIY approach. A minimal Node/Express proxy looks like this:
import express from "express";
import Anthropic from "@anthropic-ai/sdk";
const app = express();
app.use(express.json());
const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
app.post("/v1/chat", async (req, res) => {
const authHeader = req.headers.authorization || "";
const token = authHeader.replace("Bearer ", "");
if (token !== process.env.INTERNAL_API_KEY) {
return res.status(401).json({ error: "unauthorized" });
}
try {
const response = await anthropic.messages.create({
model: "claude-sonnet-4-5",
max_tokens: 1024,
messages: req.body.messages,
});
res.json(response);
} catch (err) {
res.status(502).json({ error: err.message });
}
});
app.listen(3000, () => console.log("Proxy running on port 3000"));Deploy this to any host (a VPS, a container, a serverless function) and you now have your own HTTP endpoint, https://yourdomain.com/v1/chat, that wraps Claude. Clients call your server with a token you issue; your server holds the actual Anthropic key.
That's the happy path. To make it production-ready you also need:
- Streaming support — forwarding Server-Sent Events so clients get tokens as they're generated, not after the full response finishes.
- Per-client API keys — not one shared secret, but individual revocable keys per app or user.
- Rate limiting — to stop one client from burning your entire Anthropic quota.
- Retry and error handling — Anthropic returns 429s and 5xxs; your proxy needs to handle them gracefully instead of just passing through a generic 502.
- Usage metering — if you're billing teammates or customers for Claude usage, you need to track tokens per key.
- Tool use passthrough — if your app uses Claude's tool calling, your proxy needs to pass tool definitions and tool results through correctly in both directions.
Each of these is doable, but together they turn a 50-line script into a small service you have to maintain, patch, and monitor.
Option 2: Use a managed gateway instead of building one
If the goal is just "give my app, team, or product a clean HTTP API backed by Claude," building and maintaining your own proxy is often more work than the actual feature you're trying to ship. This is the problem SubToAPI solves: it turns your existing Claude access into a hosted HTTPS API with its own application keys (sub_live_...), streaming, tool use, usage metadata, and team seats, without you running any infrastructure.
The call shape is close to Anthropic's own API, so migrating a proxy you already built is usually a find-and-replace of the base URL and key:
curl https://api.subtoapi.app/v1/messages \
-H "Authorization: Bearer $SUBTOAPI_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet-4-5",
"max_tokens": 1024,
"messages": [
{ "role": "user", "content": "Summarize this HTTP endpoint pattern." }
]
}'You generate sub_live_... keys per app or per teammate from the dashboard, revoke them individually, and see usage per key — the parts that take the most engineering time in a DIY proxy. Streaming and tool use work the same way they do against Anthropic directly; see /docs/streaming and /docs/tools for the exact request formats. The /docs/quickstart page walks through getting a key and making your first call in a few minutes, and /docs/messages covers the full request/response schema.
Which approach fits your situation
- Internal script, single user, no billing needs — a small self-hosted proxy is fine. Keep it simple and skip the extras until you actually need them.
- Multiple apps or environments sharing one Claude account — you want per-key scoping and revocation, which means building key management yourself or using a gateway that already has it.
- Team or client-facing product — you need seats, usage visibility, and streaming that doesn't break under load. This is where maintaining your own proxy stops being a weekend project.
If you're past the single-script stage, start with /signup for a free trial and check /pricing for Solo, Team, and Scale plans before deciding whether to keep building your own layer.
Questions
Does exposing Claude as an HTTP endpoint require a special API from Anthropic? No. Anthropic's Messages API is already HTTP-based. "Exposing" it just means adding your own authenticated server or gateway in front of it so clients don't hold your raw Anthropic key.
Can I stream responses through my own HTTP endpoint? Yes, but you need to forward Server-Sent Events correctly rather than buffering the full response. See /docs/streaming for the request/response format if you're using SubToAPI instead of building this yourself.
What's the fastest way to get a working endpoint without building a proxy? Sign up for a SubToAPI key at /signup, generate a sub_live_... key, and call https://api.subtoapi.app/v1/messages directly — no server to deploy or maintain. The /docs/quickstart guide covers the setup end to end.