Response Protocol Compatibility

Token360 routes one public model to one of several upstream providers without requiring your application to understand each provider's response format. The public contract is determined by the endpoint you call, not by the provider selected for that request.

Endpoint contracts

Only models and SKUs that advertise support for an endpoint can be used with it. Check the model catalog and Model Capabilities before integration.

What Token360 normalizes

For successful requests, Token360 normalizes the provider response at the protocol boundary. This includes:

• the public Token360 model name;
• the endpoint's standard response, message, content, choice, output, and event structure;
• usage fields in the location defined by that endpoint;
• tool-call and reasoning fields supported by the selected model;
• stream completion semantics; and
• removal of provider-private routing and diagnostic metadata from the public payload.

This means a route change between upstream providers does not require provider-specific parsing in your application. Parse the response according to the endpoint contract shown above.

Token360 may expose documented compatibility extensions. For reasoning-capable Chat Completions models, reasoning and reasoning_content are stable aliases. If you store assistant messages for a later turn, preserve the fields returned by the API.

Streaming behavior

Streaming is normalized at the event and field level, not at the byte or token-boundary level. Different providers may produce a different number of chunks or split the same text at different positions. Your client should:

• process each event according to the selected endpoint;
• treat optional or nullable fields as optional;
• concatenate text and reasoning deltas in order;
• accumulate tool-call arguments by index; and
• wait for that protocol's terminal event ([DONE] for Chat Completions).

Do not rely on provider names, raw provider payloads, chunk count, or chunk boundaries.

Scope and limits

Protocol compatibility does not mean that every model supports every optional field or endpoint. Model capabilities and allowed parameter values still apply. For the Responses API, Token360 supports upstream continuation with previous_response_id and store, and pins a continuation to the provider route that issued the response. Token360 preserves an explicit store: true or store: false. If store is omitted or set to null, Token360 leaves it unspecified and lets the selected upstream apply its own default. conversation, background: true, and response lifecycle operations such as retrieving, cancelling, or deleting /v1/responses/{response_id} are not currently supported.

Media APIs, asynchronous jobs, Batch, billing, and asset APIs each follow the contract documented in their own API reference. Token360-Native-Params: true changes supported request bodies to a provider-native shape; it does not make provider-private response metadata a stable public interface.

See also:

• Choose an API
• Streaming
• API Reference overview