360 AI Model Platform

Separate the aggregator from model authors

The 360 platform offers both 360-developed and third-party models and can route one virtual model name across multiple suppliers for failover. Context, price, availability, and Supported Response Formats shown in the platform belong to a specific model or supplier record; third-party capabilities are not 360-authored. This site currently adapts only the listed /v1/chat/completions and /v1/responses routes.

Protocol migration is not a URL swap

360 documents OpenAI Chat Completions, OpenAI Responses, Claude Messages, and other protocols. A model supports only the subset shown in its catalog record. messages/choices, input/output, Claude content blocks, tool definitions, stream events, and stop reasons are not interchangeable. Direct calls use a 360 Bearer API key; this site uses its own token. Confirm base URL, full model ID, and response format separately.

Asynchronous media IDs identify another resource

Native 360 video creation returns data.id with status: created. Place that exact ID in the video-status query until success or failure, then read url or failure_reason. The ID can encode supplier and model information and must not be split or confused with Chat or Responses IDs. Use bounded backoff and a total deadline, and copy signed result URLs promptly. This site's current api_paths do not include 360 video, so native /v1/videos/async_generations is not a gateway route.

Parse HTTP and business errors together

In the official table, 400/1001 usually means parameters or an unauthorized field. 401/1002 is authentication, while 401/1004 can mean insufficient balance and 401/1006 a daily limit. 429/1005 is request-frequency or token pressure, and 500/1003 is a service failure. Balance, quota, and input errors do not recover through retry; only transient throttling or service errors should receive bounded jittered backoff.

ZDR is not a platform-wide promise

ZDR Supported and Request Log Collection are attributes of a specific supplier record, not guarantees across every model, protocol, or automatic route. A zero-retention workload must verify the exact model and supplier, determine whether failover changes the data boundary, and rely on contractual terms, log settings, and observed responses. Keep keys in a server-side KMS and preserve redacted request IDs, effective supplier, usage, and cost.