Skip to main content
This page shows examples for the OpenAI-compatible API. Request examples show each access method. Most response examples come from a Poolside deployment. Responses from Poolside Platform, OpenRouter, or another provider may differ. If you use another OpenAI-compatible provider or your own model server, use the base URL, API key, and model IDs your provider exposes. Provider-specific request parameters, including reasoning settings, can differ.

Prerequisites

Before you get started, you need:
  1. An API key for your access method: a Poolside Platform API key, an API key for your organization’s Poolside deployment, or an OpenRouter API key. To get a key and send it with Bearer authentication, see Authenticate API requests.
  2. curl or another tool that can make API requests.

List available models

Most API requests require you to pass a model id. To get all available models and their ids:
List models
Response example
In this case, the response includes one model with the id poolside/laguna-s-2.1.

Send a chat prompt

To generate completions from a model, you need the model id and your prompt formatted as content inside messages with the user role:
Send chat prompt
Response example
The usage object reports the tokens used by the request and response. You can set optional parameters. This is not an exhaustive list. Request body:
  • model (required): Model id to use.
  • messages (required): An array of messages representing the conversation.
  • max_completion_tokens (optional): The maximum number of tokens to generate in the completion.
  • chat_template_kwargs (optional, Poolside API): Model-specific chat template settings for Poolside Platform and Poolside deployments. Set enable_thinking to false to turn off thinking for models that support this setting.
  • reasoning (optional, OpenRouter-compatible providers): Reasoning configuration for providers that accept the OpenRouter-style reasoning field.
  • stop (optional): An array of sequences where the API stops generating further tokens.
  • temperature (optional): What sampling temperature to use, between 0 and 2. Higher values like 0.8 make the output more random, while lower values like 0.2 make it more focused and deterministic.
  • stream (optional): Response format. A stream of a series of events or a single JSON object.

Turn off thinking through the Poolside API

Some Poolside models support per-request thinking control through Poolside API chat template settings. To turn off thinking, set chat_template_kwargs.enable_thinking to false:
Turn off thinking
OpenAI-compatible tool calling behavior can vary by model and serving configuration. If you need to force a specific function call with tool_choice, such as "required" or a named function, try turning off thinking first by setting chat_template_kwargs.enable_thinking to false. For request and response formats, see the OpenAI function calling guide.

Control reasoning through OpenRouter

To control reasoning effort through OpenRouter-compatible models, include a reasoning object:
OpenRouter’s generic effort values are max, xhigh, high, medium, low, minimal, and none, but provider and model support varies. Replace <model-id> and max with values that your selected model supports.
The reasoning field is OpenRouter-style: a top-level object, which differs from the OpenAI Chat Completions reasoning_effort parameter. Use it only with OpenRouter or another provider that accepts this field. A direct connection to the OpenAI Chat Completions API at https://api.openai.com/v1/chat/completions rejects the reasoning field.Effort-level support varies by provider and model. Some providers ignore effort settings or apply thinking automatically. Check your provider’s documentation for how it handles the reasoning field.

Preserve reasoning in agentic workflows

For agentic workflows with Poolside models, preserve reasoning_content from assistant responses when you include those responses in follow-up requests. Dropping previous reasoning content can prevent the model from reasoning in later steps. For examples, see the Control reasoning sections on the Laguna model pages.

Stream responses

For example, if you want to receive your response as a series of completion chunks returned as server-sent events, set stream to true. This is useful for real-time applications.
Stream chat prompt
Response example

Send a chat prompt with extra context

Optionally, you can add more context to a query. This is useful when you want to give the model information it does not have. Refer to the Prompting guide for further guidance. Consider the following query:
Ask without context
The model has no mechanism to know the user’s name, so it provides an incomplete response:
Response example
However, if you want the model to answer questions about data you have, you can pass that as context in a message:
Ask with context
In the previous snippet, the message provides context about the user’s name. If you run this example, the response takes this information into account.
Response example
You can also provide multiple context messages or include file contents as context by describing them in system messages.

Extend models with tools

You can extend your model’s capabilities by providing tools (functions) that the model can call during conversations. This enables the model to perform actions like retrieving real-time data, calculations, or interacting with external systems. To use tools, include a tools array in your request and define the functions the model can call:
Define a tool
When the model needs to use a tool, it responds with a tool_calls array in the model response message.
Response example
To continue the conversation, run the tool and provide the tool result:
Send a tool result

Constrain the response format

To constrain a response to a specific JSON structure, include a response_format object with type set to json_schema and a JSON Schema definition. The model returns a JSON string in message.content that follows the schema.
Request structured output
The model returns the structured data as a JSON string in message.content:
Response example
Parse message.content as JSON to get the structured object:
To request a valid JSON object without enforcing a schema, set response_format to {"type": "json_object"} instead.