MiniMax Responses API With M3: Node.js, Python, Streaming, and Tools

Last verified: July 18, 2026.

The MiniMax Responses API provides an OpenAI Responses-compatible route for generating text and invoking tools with MiniMax M3. It supports non-streaming JSON and server-sent event streaming at one endpoint:

POST https://api.minimax.io/v1/responses

This route is useful for new integrations that prefer an item-based output array, a convenience output_text field, built-in reasoning controls, and function tools. It is distinct from Chat Completions even though both use the https://api.minimax.io/v1 SDK base URL. See the MiniMax API hub for the wider endpoint map.

Quick reference

Item	MiniMax Responses value
SDK base URL	https://api.minimax.io/v1
Direct endpoint	POST https://api.minimax.io/v1/responses
Model	MiniMax-M3
Required request fields	model and input
System-level guidance	instructions
Output limit	max_output_tokens
Streaming switch	stream: true
M3 reasoning default	none / disabled
Tool policy	tool_choice: "auto" or "none"
Response statuses	completed, incomplete, failed

The API key belongs on your server. Do not place it in a Gutenberg block, front-end JavaScript, a public repository, or a downloadable application bundle.

Python example with the OpenAI SDK

python -m pip install openai
export MINIMAX_API_KEY="replace-with-a-server-side-key"

The sample makes persistence and truncation behavior explicit. MiniMax’s documented response represents store as false and the supported truncation strategy as disabled.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MINIMAX_API_KEY"],
    base_url="https://api.minimax.io/v1",
)

response = client.responses.create(
    model="MiniMax-M3",
    instructions=(
        "You are a technical editor. Answer directly and separate facts "
        "from assumptions."
    ),
    input="Explain exponential backoff in four bullet points.",
    max_output_tokens=800,
    reasoning={"effort": "none"},
    store=False,
    truncation="disabled",
)

if response.status == "completed":
    print(response.output_text or "")
elif response.status == "incomplete":
    print("Incomplete response:", response.incomplete_details)
else:
    print("Failed response:", response.error)

response.output_text concatenates all text outputs and is convenient for a simple text-only result. Do not use it as your only parser when tools or reasoning are enabled. The authoritative output list may contain message, reasoning, and function-call items that need separate handling.

Node.js example with the OpenAI SDK

npm install openai

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.MINIMAX_API_KEY,
  baseURL: "https://api.minimax.io/v1",
});

const response = await client.responses.create({
  model: "MiniMax-M3",
  instructions:
    "You are a technical editor. Answer directly and separate facts from assumptions.",
  input: "Explain exponential backoff in four bullet points.",
  max_output_tokens: 800,
  reasoning: { effort: "none" },
  store: false,
  truncation: "disabled",
});

switch (response.status) {
  case "completed":
    console.log(response.output_text ?? "");
    break;
  case "incomplete":
    console.error("Incomplete response", response.incomplete_details);
    break;
  case "failed":
    console.error("Failed response", response.error);
    break;
  default:
    console.error("Unexpected status", response.status);
}

If an SDK version rejects a field that the MiniMax endpoint documents, update the SDK or send raw HTTP after validating the payload. Do not remove status handling merely because a basic example returned completed.

What the main request fields do

Field	Use	Implementation note
model	Selects the model	Use the exact ID MiniMax-M3 in these examples.
input	Text or a full conversation-content array	Send only the context required for the request.
instructions	System instructions	Keep stable policy and role guidance here.
max_output_tokens	Caps generated output	A cap controls cost and runaway output; it does not reserve tokens.
stream	Enables SSE	Default is false.
tools	Defines callable functions	Validate every generated argument before execution.
tool_choice	Allows or blocks tool selection	Documented values are auto and none.
service_tier	Selects admission tier	standard is the default; priority costs 1.5× standard.
prompt_cache_key	Supplies a prompt-cache routing identifier	Measure cached tokens; the key alone does not prove a hit.
text	Controls output format	Use only subfields documented and tested for the selected model.
reasoning	Controls reasoning output	M3 defaults to disabled; non-none values enable it.

MiniMax also documents sampling controls such as temperature and top_p, plus string-to-string metadata. Change sampling only when you can evaluate the effect. For deterministic business logic, prefer validation and constrained application code rather than relying on a low sampling value as a correctness guarantee.

M3 reasoning: enable or disable, not depth-tune

For MiniMax M3, omitting reasoning disables reasoning output. The explicit equivalent is:

"reasoning": { "effort": "none" }

The compatibility values minimal, low, medium, and high all enable Adaptive Thinking for M3. They do not tune its reasoning depth. Do not label a result “high reasoning” or promise more extensive analysis because high was sent.

M2.x behaves differently: reasoning cannot be disabled. An effort value of none may be accepted by the compatibility layer, but reasoning remains on. Keep model ID and reasoning assumptions together in configuration and regression tests.

Conservative SSE streaming test

MiniMax documents stream: true as an SSE response. Before binding application logic to event names, inspect the raw stream returned to your account and SDK version. This cURL command disables buffering so each event is visible:

curl -N --request POST \
  --url https://api.minimax.io/v1/responses \
  --header "Authorization: Bearer ${MINIMAX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "MiniMax-M3",
    "input": "List three rules for validating webhook signatures.",
    "max_output_tokens": 500,
    "reasoning": {"effort": "none"},
    "stream": true,
    "store": false,
    "truncation": "disabled"
  }'

A production stream handler should parse complete SSE frames rather than arbitrary network chunks, collect text deltas in order, record the terminal status, and handle reconnects conservatively. A connection ending without a terminal completion event must not be treated as a complete answer. Apply HTTP connect, read, and total timeouts, and avoid retrying a side-effecting tool call unless your tool layer is idempotent.

Function tools with Responses

A function tool has a name, description, and JSON Schema-compatible parameters. This first-step Node.js request lets M3 decide whether a shipping quote is needed:

const first = await client.responses.create({
  model: "MiniMax-M3",
  input: "Quote standard shipping for a 2 kg parcel from Paris to Berlin.",
  tools: [
    {
      type: "function",
      name: "get_shipping_quote",
      description: "Return a shipping quote for a route and parcel weight.",
      parameters: {
        type: "object",
        properties: {
          origin: { type: "string" },
          destination: { type: "string" },
          weight_kg: { type: "number", minimum: 0.01 },
        },
        required: ["origin", "destination", "weight_kg"],
        additionalProperties: false,
      },
    },
  ],
  tool_choice: "auto",
  reasoning: { effort: "none" },
  store: false,
  truncation: "disabled",
});

const calls = first.output.filter(
  (item) => item.type === "function_call"
);

for (const call of calls) {
  console.log(call.name, call.arguments);
}

Printing the request is not execution. Parse the arguments, validate their types and allowed values, apply authorization, and run the tool in a constrained environment. MiniMax’s Responses reference documents function-call items in the response output array, but it does not document a complete function-result continuation example or a previous_response_id field. Do not copy another provider’s continuation payload without an account-level test. For a fully documented multi-round loop, use the Chat Completions or Anthropic Messages pattern in the MiniMax function-calling guide.

Treat each request as self-contained unless MiniMax documents a stateful mechanism for this route. Include the conversation and tool state required to reproduce the next step; do not build persistence assumptions from another provider’s Responses implementation.

Prompt caching and token checks

prompt_cache_key is documented as a routing identifier. Use a stable value for requests that share a stable prefix, but do not put raw personal data, secrets, or an entire prompt into the key. Confirm caching through usage.input_tokens_details.cached_tokens, then compare both latency and billed usage across repeat calls.

For detailed cache design, invalidation, and billing distinctions, use the MiniMax prompt-caching guide. Before sending a large request, call POST /v1/responses/input_tokens with the same model, input, instructions, tools, text controls, and reasoning settings. The estimator returns response.input_tokens without generating output.

Parse status before trusting output

Status	What to inspect	Application action
completed	output, output_text, and usage	Process all expected item types, then display or store the validated result.
incomplete	incomplete_details	Do not present the answer as complete. Decide whether a safe retry or a larger output budget is appropriate.
failed	error	Log a redacted diagnostic, map it to a user-safe message, and retry only retryable failures.

HTTP success and model-task success are related but separate checks. Validate the HTTP status and JSON shape, then branch on the response status. Also record the returned model ID, total token usage, cached input tokens, and reasoning tokens when present. This makes cost and behavior changes detectable.

Design repeatable input and instruction boundaries

input can be a simple string or a structured array. Use a string for one-turn text tasks. Use structured items when the application must preserve roles, prior messages, or tool-related content. Keep behavioral policy in instructions and task data in input; this separation makes testing and prompt-cache analysis easier.

Build the complete request envelope in application code: model ID, instructions version, input items, tool definitions, output cap, reasoning setting, service tier, cache key, storage preference, and truncation strategy. Log a hash or internal version for stable instructions instead of copying sensitive text into telemetry. A reproducible envelope lets a team explain why two calls behaved differently.

With truncation disabled, the client should budget context before sending the request rather than expecting the service to silently discard older content. Use the input-token estimator, preserve only history that affects the task, summarize history through a separately evaluated process, and return a controlled error when the request is too large. Silent context loss is especially risky in compliance, financial, and support workflows.

Retry only when the failure is safe to repeat

Separate transport failures, HTTP errors, incomplete generations, failed response objects, and tool failures. A timeout before any tool execution may be retryable with exponential backoff and jitter. A failed validation is usually not retryable until the request changes. A tool call that charged a card, sent a message, or changed data requires an idempotency key or human review before repetition.

• Cap attempts and total elapsed retry time.
• Honor server retry guidance when present.
• Do not switch to the priority tier automatically to hide persistent errors.
• Record request and response IDs in redacted diagnostics.
• Surface a clear incomplete state instead of stitching partial generations together without validation.

Responses API or Chat Completions?

Choose Responses when…	Choose Chat Completions when…
You want an item-based output array and output_text convenience field.	Your application already has stable Chat Completions message and tool-call handling.
You are building a new tool workflow around the documented Responses request.	A framework does not support the Responses route but supports MiniMax’s OpenAI-compatible chat route.
You want the dedicated input-token estimation endpoint.	You have tested chat-specific behavior that the application depends on.

Protocol choice does not improve model quality by itself. Choose the route that matches your application state, SDK support, output parser, and test coverage. For Chat Completions setup, see the MiniMax OpenAI-compatible API guide.

Production checklist

• Keep the MiniMax key in a server-side secret manager and rotate it after exposure.
• Set max_output_tokens, HTTP timeouts, and a tool-loop ceiling.
• Send store: false and truncation: "disabled" explicitly where the client supports them.
• Handle completed, incomplete, and failed separately.
• Parse output by item type; use output_text only as a text convenience.
• Validate function arguments and authorize each side effect outside the model.
• Keep reasoning disabled unless the task benefits from it; do not treat effort labels as M3 depth levels.
• Inspect cached-token usage before claiming that a cache works.
• Estimate large inputs and compare the result with your context and MiniMax pricing limits.
• Redact prompts, tool results, and API errors before observability logs leave the application boundary.

Frequently asked questions

Does MiniMax M3 reason by default on this endpoint?

No. M3 reasoning defaults to none. Sending minimal, low, medium, or high enables Adaptive Thinking, but those values do not select different reasoning depths.

Is output_text the complete response?

It is the concatenation of text outputs. Inspect output when the response can include reasoning or function calls.

Can I assume a response completed because the server returned JSON?

No. Check the response status. An incomplete response includes incomplete_details, while a failed response includes an error object.

Official sources used

• MiniMax Create Response API reference
• MiniMax Responses input-token estimator reference
• MiniMax API overview

Conclusion: The MiniMax Responses API is a practical M3 interface when you need structured output items, SSE, reasoning control, or function tools. Keep request state explicit, parse status and item types defensively, and verify caching, reasoning, and tool behavior with account-level tests before launch.