tAI API reference

The endpoint

Everything in this API goes through one URL:

# Base URL
https://api.artfical.com/v1

There is a single completion endpoint, POST /v1/chat/completions, and a single read-only listing endpoint, GET /v1/models. That's the entire surface. There's no separate endpoint per model, no separate endpoint for streaming versus non-streaming (the same URL handles both, switched by a field in the request body), and no separate endpoint for tool-calling turns. If you've built against OpenAI's Chat Completions API, GitHub's inference endpoints, or any of the many providers that ship an OpenAI-compatible shape, this will already look familiar. That similarity is deliberate: pointing an existing OpenAI-compatible client (the official openai Python or Node package, LangChain, LlamaIndex, a coding agent like OpenCode, or your own thin wrapper) at https://api.artfical.com/v1 with a tAI API key should work with little or no code change.

The quickest path to a first request

Three things are needed: a workspace on console.artfical.com, an API key created from the API keys page in that workspace, and any HTTP client. Here's the shortest version, using curl:

# Replace tai-sk-... with your own key
curl https://api.artfical.com/v1/chat/completions \
  -H "Authorization: Bearer tai-sk-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "tai-4.1",
    "messages": [{"role": "user", "content": "Merhaba, kendini tanıt."}]
  }'

That single request is a complete, working integration. Everything else in this section, streaming, tool calling, image input, sampling controls, is an optional layer on top of this same shape, not a different API to learn. The Chat completions page walks through the full request and response in detail; the Authentication page covers how the key itself is issued, scoped, and rotated.

How this section is organized

The pages here are grouped to match the order most people actually need them in, not the order the underlying implementation happens to be organized in. The first group, getting started, is the part everyone needs regardless of what they're building: how to authenticate, the shape of a request and response, how streaming differs from a single blocking response, and how to discover which models exist and what each one costs and supports. The second group, request options, covers everything that's optional on top of a basic request: the sampling knobs that shape how a response is generated, how to give the model tools it can ask to call, and how to send an image alongside text. The third group, reference, is meant to be looked up rather than read start to finish: the exact shape of an error response and what each type means, how rate limiting works and what headers reflect it, the per-model pricing table, and a page specifically for anyone migrating an existing OpenAI-SDK integration, covering what's supported as-is and what isn't.

Who this is for

This section is written for someone writing code against the API directly, whether that's a backend service, a script, or an agent framework like OpenCode that treats tAI as one of several interchangeable OpenAI-compatible providers. It assumes comfort with making HTTP requests and reading JSON, but not any prior familiarity with tAI specifically. If you're instead looking for how to use tAI through the chat product itself, that's covered by the main tAI docs, not this section. If you're looking for how tAI is evaluated for safety and what safeguards the product is built with, that's the Security section. This section is scoped specifically to the developer-facing HTTP API: what you send, what you get back, and what every field and header means.

A note on stability

The request and response shapes documented in this section are the ones we intend to keep stable. A field being added is something you should expect over time as the API grows; a documented field changing meaning or disappearing without a replacement is not something we do casually. Where something is genuinely provisional or likely to change, the relevant page says so explicitly rather than leaving you to find out the hard way. If a field or behavior isn't mentioned anywhere in this section, treat it as not part of the supported contract, even if you happen to observe it in a response, since it may change or disappear without notice.