Skip to main content
Swytcho returns JSON responses with a consistent envelope structure across all completion endpoints. Understanding each field helps you extract content reliably, handle edge cases gracefully, and track token consumption for cost management.

Response Envelope

Every non-streaming response from the chat completions endpoint shares the following top-level fields.
string
A unique identifier for this completion request, prefixed with chatcmpl-. Use this ID when reporting issues to Swytcho support.
string
The type of object returned. For chat completions this is always "chat.completion".
integer
Unix timestamp (seconds) of when the completion was generated.
string
The exact model ID used to generate the response, including any date-pinned version suffix (e.g., "swytcho-1-2025-04-01"). This may differ from the alias you requested if the alias was resolved to a pinned version.
array
An array of completion candidates. Most requests return a single choice (choices[0]). See The choices Array below for the full structure of each element.
object
Token consumption statistics for the request. See The usage Object below.

The choices Array

Each element of choices represents one candidate completion.
integer
Zero-based index of this choice in the array.
object
The generated message. Contains a role field (always "assistant") and a content field with the text of the completion. When tool calls are present, content may be null and a tool_calls array is populated instead.
string
The reason the model stopped generating tokens. See Finish Reasons for all possible values and their meanings.

The usage Object

integer
Number of tokens in the input prompt, including the system message and all prior conversation turns.
integer
Number of tokens generated in the response.
integer
Sum of prompt_tokens and completion_tokens. This is the value used to calculate the cost of the request.

Full Example Response

Finish Reasons

The finish_reason field tells you why the model stopped producing tokens. Always check this value before using the response content in downstream logic.
Streaming responses use a different format: the API sends a series of text/event-stream chunks, each containing a partial delta object rather than a complete message. The final chunk includes the finish_reason. See the Streaming guide for a full walkthrough of consuming and reassembling streamed output.