Custom — OpenAI Responses API

A catch-all for any endpoint that speaks the OpenAI Responses API. Same transport as OpenAI direct — Chamade owns the persona (the system prompt) and the model, and keeps conversation state server-side via the Conversations API (conv_xxx, with a previous_response_id fallback).

What it is

Pick Custom (Responses) whenever you have an OpenAI-Responses-compatible URL that isn't one of the dedicated presets. Chamade sends each event as a request to …/v1/responses with the system prompt as instructions and your model in the body, and delivers the reply. It authenticates with Authorization: Bearer <your key>.

Typical endpoints that fit here:

Azure OpenAI — see the recipe below.
Self-hosted / proxy gateways that expose /v1/responses — vLLM, LiteLLM, Ollama (behind a Responses-compatible shim), or your own gateway.
Any managed gateway speaking the modern Responses spec.

Responses, not Chat Completions

The endpoint must implement the Responses API (/v1/responses + the Conversations API for memory), not just legacy /v1/chat/completions. If your endpoint only has Chat Completions, it won't work here.

Azure OpenAI via Custom

Azure OpenAI is an OpenAI Responses endpoint, so it goes straight through Custom — there's no separate preset. Fill in:

Endpoint URL: https://{resource}.openai.azure.com/openai/v1/responses?api-version=preview
API key: from the Azure portal → Keys & endpoints
Model: your deployment name (not the base model id)

Three Azure gotchas

Keep ?api-version=preview in the URL — the Responses API on Azure requires the api-version query string (preview is current). The Custom form won't add it for you.
Use the /openai/v1/… path (the unified surface), not the old /openai/deployments/{name}/… route — Chamade authenticates with Authorization: Bearer, which the v1 surface accepts; the legacy path expects an api-key header and won't work.
The model field is the deployment name, and the deployment must be in a region that ships the Responses API (a Chat-Completions-only region returns 404 on /openai/v1/responses).

Stored prompts — "pick an existing OpenAI agent"

If you've built and published a prompt in the OpenAI dashboard (a pmpt_… id — model + instructions + tools, versioned), you can reference it instead of typing a model and a system prompt. It's the OpenAI equivalent of a hosted agent (like Foundry's agent_reference): the persona lives in your OpenAI dashboard, and Chamade just folds in its XML action convention.

In the provider form, open Stored prompt (OpenAI) and paste the Prompt ID (pmpt_…); optionally pin a Version (blank = production).
The Model field is then ignored — the prompt supplies the model. Leave it blank.
Chamade sends prompt: {id, version} on each turn and folds the system prompt in as the action convention only (request-level instructions would otherwise override your prompt's persona).

OpenAI platform only

Stored prompts are an OpenAI feature — they work against api.openai.com, not Azure OpenAI or third-party gateways. For those, use a model + system prompt. (AgentKit workflows — wf_… — are a different runtime and can't be driven server-side yet; they're not supported here.)

Setup

In your dashboard → an agent → pick the Custom (Responses) preset.
Paste the Endpoint URL, the API key, and the Model (deployment name for Azure).
Save — Chamade runs a healthcheck against the endpoint to validate auth + shape.
To confirm end-to-end, use Test DM / Ping in the dashboard, or message the agent on a connected platform.

Acting & reading

Like every Chamade provider, the agent acts via the XML convention (<write>, <say>, <dm>, <call_join>…), pre-filled in the system prompt. Because Chamade controls the request body for OpenAI-Responses endpoints, the hosted Chamade MCP is also auto-attached as a read backstop (look up account / inbox / call status mid-reasoning) — act with XML, read with MCP. Turn it off in the form if you don't want it.

Memory & context

Conversation state is kept server-side by the endpoint via the OpenAI Conversations API (Chamade passes a conversation id; it falls back to chaining on previous_response_id when the endpoint defaults to store=false). The system prompt is sent as instructions on every turn.

Good to know

The agent needs ≥1 platform account attached in Chamade, or it has nothing to talk to.
Auth is always Authorization: Bearer <key> — endpoints that only accept a different header (e.g. legacy Azure api-key) won't authenticate.
If the healthcheck 404s, the endpoint probably doesn't implement /v1/responses (Chat-Completions-only) — that's not supported here.
For a hosted agent in Microsoft Foundry (its own tools + memory in the portal), use the dedicated Foundry preset instead — that's a different shape (agent_reference), not a plain Responses endpoint.