Common Chat Completions

Unified chat API for switching text models through the model parameter. The request format is compatible with OpenAI Chat Completions.

This endpoint returns one complete JSON response by default. Set stream: true explicitly when you need SSE streaming.

POST https://api.requestbeam.com/v1/chat-completions

Authentication

All requests require Bearer Token authentication.

Authorization: Bearer YOUR_API_KEY

If authentication fails, check:

• Whether the API Key is correct
• Whether the key is valid for this API Base URL
• Whether the request header is spelled correctly
• Whether a proxy rewrites the authorization header

Body

  [
    {"role": "system", "content": "You are a helpful Python tutor."},
    {"role": "user", "content": "How should I learn programming?"}
  ]

Model Parameter Differences

Current text models support minimal streaming and non-streaming Chat requests, but optional parameter acceptance and effects vary by the selected model and its compatibility implementation.

The latest recheck on 2026-09-26 accepted claude-fable-5 with temperature: 0 and returned text. The same recheck rejected claude-sonnet-5 with top_p: 0.9 with HTTP 400 and top_p is deprecated. Omit top_p for that model. Acceptance establishes neither an effect on sampling nor a guarantee for other models or later requests; do not assume that all sampling parameters are supported.

The OpenAI checks on 2026-09-26 accepted stop for gpt-5.6-sol and gpt-5.6-terra. Parameter acceptance can change with the upstream and does not prove that a stop sequence is effective.

Native OpenAI-compatible Chat forwarding preserves top_p and stop in the upstream request. A route that converts Chat to Responses preserves top_p but does not forward stop. Forwarding a field does not establish upstream support or its effect; neither field has a platform-wide guarantee across routes.

Start with a minimal request when switching models, then verify sampling, stop sequences, and advanced tool parameters separately. For stop sequences, inspect the actual text and stop reason, not only the HTTP status. HTTP 200 does not establish a sampling effect. Output budgets must cover both the model's thinking and its final text.

Request Example

{
  "model": "gpt-5.4",
  "messages": [
    {
      "role": "user",
      "content": "Hello, introduce yourself briefly."
    }
  ],
  "stream": false
}

Response

Success Example

{
  "id": "chatcmpl-9876543210",
  "object": "chat.completion",
  "created": 1677652288,
  "model": "gpt-5.4",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "I am an AI assistant that can help with writing, coding, and analysis."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 28,
    "completion_tokens": 42,
    "total_tokens": 70
  }
}

Error Response

See Error Codes and Troubleshooting for the full code reference, protocol differences, and diagnostic steps.

Chat Completions HTTP errors use a flat JSON body, including upstream HTTP errors returned before an SSE stream starts. For example, HTTP 402 returns:

{
  "code": 40000,
  "message": "Insufficient credit. Required: 30000, Available: 20000",
  "type": "api_error"
}

• code: numeric platform error code, separate from the HTTP status and not a string
• message: human-readable error description
• type: api_error
• requestId: optional request identifier for troubleshooting

Check the HTTP status first to determine whether the request succeeded, then compare the numeric code for application-specific handling. Do not compare code with strings such as "400", assume it equals the HTTP status, or parse message as a stable error identifier. Missing or incorrectly typed messages are rejected with HTTP 400 and code: 10000 before provider invocation.

This error format applies to Chat Completions HTTP responses, not errors within an already-started SSE stream or other API protocols. Model Catalog and native protocol endpoints have their own documented error formats.