What AlleForge Does and Doesn't Do for AI APIs
A plain accounting of what AlleForge actually supports for OpenAI, Anthropic, Gemini, and local AI APIs today — and where it stops, stated directly rather than left for you to discover.
AlleForge is an API client. When the API you're testing happens to be OpenAI, Anthropic, Gemini, or a model you're running yourself, that doesn't change much — it's still a request and a response. This page states directly what that gets you today, and what it doesn't, so you don't have to find out the second way.
Where AlleForge fits
An AI API is, mechanically, an HTTP API:
Your request → AI provider's HTTP endpoint → responseAlleForge sends that request the same way it sends any other request. The pieces you'd use are the same pieces you'd use for a payments API, a CRUD backend, or anything else:
- URL and method
- Headers and authentication — including the custom-header patterns AI providers use (see below)
- Request body
- Response inspection — status, headers, body
- Collections to keep a working request around instead of rebuilding it
- Environments to swap a key between dev/staging/prod, or between providers
- Request history, so a prior call is there to compare against
None of this is AI-specific functionality. It's the existing API-development workflow, applied to an API that happens to serve a model.
What you can test today
| Workflow | Status | Notes |
|---|---|---|
| OpenAI HTTP APIs | Supported | Standard HTTP request — method, headers, JSON body, response inspection |
| Anthropic HTTP APIs | Supported | Same workflow; x-api-key and anthropic-version are just headers |
| Gemini HTTP APIs | Supported | Same workflow; x-goog-api-key is just a header |
| Ollama and other local model servers | Supported | Reachable directly, or through AlleForge Agent when a browser build can't reach localhost on its own |
| SSE endpoints (GET, no request body) | Supported | Events parsed incrementally as they arrive, response updates as it streams, request is cancellable mid-stream |
POST-based streaming completions (OpenAI/Anthropic-style stream: true) | Not currently supported | AlleForge's SSE request type only issues a GET with no body — a streaming chat completion needs a POST with a JSON body, so it can't be exercised this way today |
| AWS Bedrock or other SigV4-signed AI endpoints | Not currently supported | AlleForge's AWS Signature auth type doesn't produce a real signature yet — see below |
What AlleForge does not do
Stated plainly, not as a hedge:
- No AI-powered request generation
- No AI-powered response explanation
- No AI assistant built into the product
- No MCP client, server, or MCP-specific debugging
- No dedicated tool-calling or function-calling inspector — a response containing
tool_callsrenders as the JSON it is, like any other response body - No provider-specific streaming-completion support — see the SSE section below for exactly why
- No model-aware behavior anywhere — AlleForge doesn't know or care whether the API on the other end is GPT-4, Claude, Gemini, or Llama; it sends what you built and shows you what came back
This isn't a list of shortcomings to apologize for. It's the actual boundary of a general-purpose API client, stated so you don't have to guess at it.
AlleForge Agent and local AI
AlleForge Agent is a connectivity bridge, not an AI feature. When AlleForge runs as a hosted web app, the browser can't reach localhost on its own — the same restriction that blocks any browser tool from reaching a local server, AI or otherwise (see why browser clients can't reach localhost). Agent runs locally, makes the request as a native process outside the browser sandbox, and hands the response back — for a local Ollama instance exactly the same way as for any other local API. It doesn't detect models, manage them, or do anything specific to AI. The full mechanism, including Ollama's default CORS behavior and the actual fix, is covered in testing local AI APIs from a browser.
Worth saying directly, since the names invite the comparison: Agent is not the "AI Assistance" feature mentioned below. Agent moves bytes between your browser and your local machine. It has no model integration and doesn't generate or interpret anything.
Streaming and SSE
AlleForge's SSE support is real, not a stub: connect, and events are parsed as they arrive and rendered incrementally rather than only once the connection closes; an in-flight stream can be cancelled.
Here's the boundary that matters if you're testing an AI provider's streaming API directly: AlleForge's SSE request type only sends a GET, with no request body. OpenAI's and Anthropic's streaming chat completions require a POST with a JSON payload (the model, messages, and stream: true) — a request shape SSE in AlleForge can't currently produce. Pointed directly at one of those endpoints, the request goes out bodyless and gets rejected before streaming ever starts.
Where this does work: if you've built your own backend endpoint that wraps a provider's streaming API and re-emits it as a GET-based SSE stream (a common pattern — your server holds the request body and the API key, and the browser just subscribes), AlleForge can debug that endpoint the same way it debugs any other SSE stream. That's a real, if narrower, use of the same capability.
AI API authentication
OpenAI, Anthropic, and Gemini each expect a different header for the same basic idea — a bearer token, an x-api-key, or a Google-style x-goog-api-key. None of that requires anything AI-specific from AlleForge: it's the same generic header and environment-variable support already described in AI API authentication, which covers each provider's exact header, plus the one AWS exception below.
One real limitation worth stating here rather than burying: AlleForge's AWS Signature auth type does not currently produce a valid signature. If your AI provider is Amazon Bedrock, or anything else requiring SigV4, that auth type won't work against it today.
Coming soon
"AI Assistance" — an in-app assistant that would draft requests and explain responses — is listed on the changelog as a planned, not-yet-shipped feature. It is not available today. Nothing on this page describes it, and nothing above should be read as a preview of it — everything in the tables above is what exists in the product right now, independent of that roadmap item.
FAQ
Can I test OpenAI APIs with AlleForge? Yes, as a standard HTTP request — set the URL, attach a bearer token, send it, read the response.
Can I test Anthropic APIs?
Yes, the same way — x-api-key and the required anthropic-version header are just headers AlleForge sends like any other.
Can I test Gemini APIs?
Yes, using the x-goog-api-key header the same way.
Can I test Ollama running locally?
Yes. Directly if AlleForge can already reach localhost, or through Agent if it can't — see testing local AI APIs for the exact mechanism and how to fix it if a request is blocked.
Does AlleForge support SSE?
Yes — incremental event parsing, live rendering, and cancellation all work. It's currently GET-only with no request body.
Can AlleForge test OpenAI or Anthropic's streaming responses directly?
No, not yet. Those APIs require a POST with a JSON body to start a stream, and AlleForge's SSE request type can't currently send one. This is a real, current limitation, not a configuration issue.
Is AlleForge Agent an AI assistant? No. Agent is a local network bridge — it moves a request between your browser and your machine. It has no model awareness and generates nothing.
Does AlleForge have AI-powered request generation today? No. That's the "AI Assistance" feature listed on the changelog as planned, not shipped.
Does AlleForge support MCP? No. There's no MCP client, server, or MCP-specific tooling in the product today.
See this in AlleForge
Open API Testing