OpenAI SDK compatibility

The short version

Change two values, base_url to https://api.artfical.com/v1 and api_key to a tAI key, and the core request/response cycle, chat completions, streaming, tool calling, image input, works the same way it does against OpenAI's own API. This page exists for the parts that don't carry over one-to-one, so a migration doesn't rely on discovering the gaps one failed request at a time.

# Before
client = OpenAI(api_key="sk-...")

# After
client = OpenAI(base_url="https://api.artfical.com/v1", api_key="tai-sk-...")

Works as-is

Feature	Notes
Chat completions	Same request and response shape. See Chat completions.
Streaming	Same SSE chunk shape, including a final usage-only chunk. See Streaming.
Tool / function calling	Same tools and tool_calls shape. tAI never executes tools itself; see Tool calling for why that's different from some other agent-oriented APIs.
Image input	Same image_url content-part shape, base64 data URIs. See Images for which models accept it.
temperature, top_p, presence_penalty, frequency_penalty, seed, stop	Same names, same accepted ranges. See Sampling parameters.
Error envelope	Same {"error": {"message", "type"}} shape. See Errors.
GET /v1/models	Same list envelope, though the field set on each model entry is smaller than OpenAI's own. See Models.

Not currently supported

Feature	What happens if you send it
n (multiple completions)	Ignored. choices always contains exactly one entry.
logprobs / top_logprobs	Ignored. No log-probability data is returned.
response_format (JSON mode / structured outputs)	Ignored. If you need reliably-structured output, the more portable approach is instructing the model in the prompt itself to reply in a specific format (JSON, a fixed template) and parsing the resulting text.
Embeddings, audio, image generation endpoints	Not implemented. tAI's API surface is chat completions and model listing only; see the API overview for the complete endpoint list.
Fine-tuning, batch, and file-upload endpoints	Not implemented.
Organization / project-scoped keys	Not applicable. A tAI key is scoped to one workspace; see Authentication.

None of the unsupported fields cause a request to fail outright; they're accepted and silently ignored rather than triggering a 400. This is a deliberate choice to avoid breaking an existing client that happens to always send, say, n: 1 as a matter of habit even though it's the default value anyway; the risk is a client assuming a genuinely unsupported feature (like n: 3 for three real candidate completions) is working when it silently isn't, so it's worth explicitly checking the response shape rather than trusting no error was raised.

Model names don't carry over

An existing integration's model string, "gpt-4o", "gpt-4.1-mini", or similar, has to be changed to one of tAI's own model IDs (tai-4.0.6P, tai-4.0.6B, tai-4.0.7, tai-4.1, tai-4.2); see the Models page for what each one is positioned for. There's no automatic mapping from another provider's model names to tAI's, since the two catalogs don't correspond one-to-one in capability or naming.

Worth double-checking after migrating

A few things that don't cause an error but are easy to get subtly wrong on a first pass: confirm base_url includes the /v1 suffix (a bare https://api.artfical.com without it won't resolve requests correctly), confirm the API key has the tai-sk- prefix and not a leftover key from wherever the integration was pointed before, and if the integration relies on any of the unsupported fields listed above producing an actual effect, plan for that gap explicitly rather than assuming parity.