API Testing

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 TeamAugust 18, 20266 min read

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  →  response

AlleForge 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

WorkflowStatusNotes
OpenAI HTTP APIsSupportedStandard HTTP request — method, headers, JSON body, response inspection
Anthropic HTTP APIsSupportedSame workflow; x-api-key and anthropic-version are just headers
Gemini HTTP APIsSupportedSame workflow; x-goog-api-key is just a header
Ollama and other local model serversSupportedReachable directly, or through AlleForge Agent when a browser build can't reach localhost on its own
SSE endpoints (GET, no request body)SupportedEvents 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 supportedAlleForge'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 endpointsNot currently supportedAlleForge'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_calls renders 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