API Overview¶

stdapi.ai provides OpenAI-, Anthropic-, Cohere- and Ollama-compatible APIs backed by Amazon Bedrock and AWS AI services. Any application that works with OpenAI, Anthropic, Cohere or Ollama works with stdapi.ai by simply changing the API endpoint. Every AWS service behind those endpoints — Amazon Bedrock, Bedrock Mantle, Amazon Polly, Amazon Transcribe and Amazon Comprehend — surfaces as models in a single catalog, discovered from your AWS account at startup.

Supported Endpoints¶

OpenAI-Compatible API¶

stdapi.ai Native Extensions¶

Anthropic-Compatible API¶

Cohere-Compatible API¶

Ollama-Compatible API¶

Responses stream as newline-delimited JSON, the transport Ollama clients expect. The model management verbs that write to a local model store — create, copy, push, delete and the /api/blobs/{digest} upload — are refused with 403, since this deployment stores no models of its own.

Documentation & Tooling¶

stdapi.ai provides multiple resources for exploring and testing the API—choose the one that fits your workflow:

Documentation Resources¶

• Per-endpoint guides – The pages in this section (linked from the endpoint tables above) with parameter details, feature tables, and examples
• API Reference – Browsable rendering of the full OpenAPI specification (request/response schemas for every endpoint)
• OpenAPI Specification – Full machine-readable schema for integration and tooling

Live API Playground¶

When running the server, access these interactive interfaces (can be enabled via configuration options):

MCP (Model Context Protocol)¶

When ENABLE_MCP_STREAMABLE_HTTP=true or ENABLE_MCP_SSE=true is configured, stdapi.ai exposes its endpoints as MCP tools. OpenAI-, Anthropic-, Cohere-, and Ollama-compatible tool names follow the pattern provider_action; the native extension tools use their bare names (search_models, model_pricing).

Ten operations are held back, because a tool schema for a call that can never succeed would only mislead an agent. ollama_create, ollama_copy, ollama_push, ollama_delete and ollama_blob_push always refuse, since this deployment stores no models. The five WebRTC call operations — openai_realtime_call_create, openai_realtime_call_accept, openai_realtime_call_reject, openai_realtime_call_refer and openai_realtime_call_hangup — are held back too: an MCP agent has no peer connection to hold. Name one in MCP_INCLUDE_TOOLS to publish it anyway.

The ten openai_organization_usage_* tools appear only while both USAGE_API and CLOUDWATCH_METRICS are enabled, and openai_organization_costs also needs COST_TRACKING. Without those settings every one of those calls answers 503, so a deployment that has not enabled them spends no context window on their schemas.

Using stdapi.ai¶

stdapi.ai speaks the OpenAI, Anthropic, Cohere and Ollama APIs unchanged. Any application built on one of them—chatbots, coding assistants, automation tools, custom scripts—runs against stdapi.ai once you point it at your deployment's base URL and give it that deployment's API key. The model name usually stays as it is, and changes only where it differs.

That is because the Anthropic, OpenAI and Cohere models Bedrock serves are also published under the names their providers use, derived mechanically from the Bedrock identifier rather than curated by hand: anthropic.claude-opus-5 answers to claude-opus-5, openai.gpt-5.6-sol to gpt-5.6-sol, openai.gpt-oss-120b-1:0 to gpt-oss-120b, cohere.embed-english-v3 to embed-english-v3.0, cohere.rerank-v3-5:0 to rerank-v3.5. A client already asking for one of those names needs no model change at all. Where a name does differ — a model from another provider, or one named for a provider this deployment does not serve — MODEL_ALIASES publishes a served model under the name your application already sends.

What the base URL buys is the catalogue behind it. A model name is resolved against the catalogue your deployment actually serves — Amazon Bedrock, Bedrock Mantle, Polly, Transcribe and Comprehend, across every region you enable — so the choice spans providers instead of one vendor's list. A name the catalogue does not contain is answered with 404: it is never mapped onto another vendor's model of roughly similar class, because that would serve you a different model than the one you asked for. Use GET /search_models to find one.

Anywhere a request accepts a model name, it also accepts a glob pattern — claude-sonnet-*, say — and the server serves the most recently released model that matches. The response always names the concrete model that served the request, never the pattern. See Model Wildcard Patterns for the syntax and its rules, and GET /search_models to see everything a pattern matches before relying on it.

On every API, a parameter the model provider rejects returns 400 with the provider's own message.

Using the OpenAI-Compatible API¶

To connect your OpenAI application:

1. Replace the OpenAI API URL with your stdapi.ai deployment URL
2. Use the same authentication mechanism (Bearer token in the Authorization header)
3. Check the model name against what this deployment serves — OpenAI's own names for the models Bedrock offers (e.g., gpt-5.6-sol, gpt-oss-120b) resolve as they stand, as do Bedrock model IDs (e.g., amazon.nova-micro-v1:0) and any configured alias. A name Bedrock does not serve, such as gpt-4o or dall-e-3, returns 404 until you alias it onto one it does

That's it: the rest of the OpenAI SDK call is unchanged.

A malformed request is refused the way the same OpenAI endpoint refuses it, so client code that branches on the error keeps working. Most endpoints — Chat Completions, Responses, Images, Batches, Vector Stores, Conversations, Videos — name the offending parameter in error.param (e.g., messages[0].content) and the failure in error.code (unknown_parameter, missing_required_parameter, invalid_type, invalid_value, or a range code such as integer_below_min_value). Moderations, Audio, Embeddings, Files and Uploads word the message as OpenAI does on those endpoints and mostly leave both null — Moderations and Audio relay the validator's list of faults, capped at the first 20. As OpenAI does, a refused speech response_format or instructions and a refused Files or Uploads purpose still name the parameter.

Using the Anthropic-Compatible API¶

To connect your Anthropic application:

1. Replace the Anthropic API URL (https://api.anthropic.com) with your stdapi.ai deployment URL + /anthropic (e.g., https://your-endpoint.com/anthropic)
2. Use the same authentication mechanism (x-api-key header and anthropic-version header)
3. Check the model name against what this deployment serves — official Anthropic names (e.g., claude-opus-5) resolve to their Bedrock IDs automatically, or use Bedrock model IDs directly

Anthropic names resolving on their own makes the base URL the only change for most applications — the same mechanism that resolves OpenAI's names on the surface above. A Claude version Bedrock no longer serves returns 404 rather than a substitute, so name a current one.

A malformed request is refused in Anthropic's wording, the field then the reason (e.g., messages.0.content: Field required).

Using the Cohere-Compatible API¶

To connect your Cohere application:

1. Replace the Cohere API URL (https://api.cohere.com) with your stdapi.ai deployment URL + /cohere (e.g., https://your-endpoint.com/cohere)
2. Use the same authentication mechanism (Bearer token in the Authorization header)
3. Check the model name against what this deployment serves — Cohere's own names for the models Bedrock offers (e.g., embed-english-v3.0, embed-v4.0, rerank-v3.5) resolve as they stand, as do Bedrock model IDs (e.g., cohere.rerank-v3-5:0, cohere.embed-v4:0) and any configured alias. A Cohere model Bedrock does not serve, such as embed-english-light-v3.0, returns 404 until you alias it onto one it does

That's it: your Cohere rerank and embed integrations are otherwise unchanged.

Using the Ollama-Compatible API¶

To connect your Ollama application:

1. Replace the Ollama host (http://localhost:11434) with your stdapi.ai deployment URL + /ollama (e.g., https://your-endpoint.com/ollama) — mainstream Ollama clients accept a path in their configured host, so the /api/* endpoints keep working unchanged
2. Send the deployment's API key as a Bearer token in the Authorization header; a local Ollama needs no credentials, so this is the one setting an existing client may not already have
3. Pick a model from GET /api/tags — the names a model was pulled under locally (llama3.2:3b) are not served here, and /api/tags is where a client discovers what is, the same way it does against Ollama itself

Everything else is unchanged: the same request bodies, the same newline-delimited JSON streams, the same response fields.

Next Steps¶