Referencia de la API de tAI

El endpoint

Todo en esta API pasa por una única URL:

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

Hay un único endpoint de completions, POST /v1/chat/completions, y un único endpoint de listado de solo lectura, GET /v1/models. Esa es toda la superficie. No hay un endpoint separado por modelo, ni uno separado para streaming frente a no streaming (la misma URL gestiona ambos, mediante un campo en el cuerpo de la solicitud), ni uno separado para los turnos con llamadas a herramientas. Si ha integrado la Chat Completions API de OpenAI, los endpoints de inferencia de GitHub, o cualquiera de los muchos proveedores que ofrecen una forma compatible con OpenAI, esto le resultará familiar. Esa similitud es deliberada: apuntar un cliente existente compatible con OpenAI (el paquete oficial openai de Python o Node, LangChain, LlamaIndex, un agente de código como OpenCode, o su propio wrapper) a https://api.artfical.com/v1 con una clave de API de tAI debería funcionar con poco o ningún cambio de código.

El camino más rápido a una primera solicitud

Se necesitan tres cosas: un workspace en console.artfical.com, una clave de API creada desde la página de claves de API de ese workspace, y cualquier cliente HTTP. Esta es la versión más corta, usando curl:

# Reemplace tai-sk-... por su propia clave
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."}]
  }'

Esa única solicitud ya es una integración completa y funcional. Todo lo demás en esta sección, streaming, llamadas a herramientas, entrada de imágenes, controles de muestreo, es una capa opcional sobre esta misma forma, no una API distinta que aprender. La página Chat completions recorre la solicitud y la respuesta completas en detalle; la página Autenticación cubre cómo se emite, se delimita en su alcance y se rota la clave misma.

Cómo está organizada esta sección

Las páginas de aquí están agrupadas según el orden en que la mayoría de las personas realmente las necesita, no según el orden en el que la implementación subyacente resulta estar organizada. El primer grupo, primeros pasos, es la parte que todos necesitan sin importar qué estén construyendo: cómo autenticarse, la forma de una solicitud y una respuesta, en qué se diferencia el streaming de una única respuesta bloqueante, y cómo descubrir qué modelos existen y qué cuesta y admite cada uno. El segundo grupo, opciones de solicitud, cubre todo lo que es opcional sobre una solicitud básica: los controles de muestreo que determinan cómo se genera una respuesta, cómo darle al modelo herramientas que puede pedir invocar, y cómo enviar una imagen junto con texto. El tercer grupo, referencia, está pensado para consultarse en lugar de leerse de principio a fin: la forma exacta de una respuesta de error y qué significa cada tipo, cómo funciona la limitación de tasa y qué encabezados la reflejan, la tabla de precios por modelo, y una página específicamente para quien esté migrando una integración existente con el SDK de OpenAI, que cubre qué se admite tal cual y qué no.

Para quién es esta sección

Esta sección está escrita para alguien que programa directamente contra la API, ya sea un servicio de backend, un script, o un framework de agentes como OpenCode que trata a tAI como uno más entre varios proveedores compatibles con OpenAI intercambiables. Asume familiaridad con hacer solicitudes HTTP y leer JSON, pero no ningún conocimiento previo de tAI en particular. Si en cambio busca cómo usar tAI a través del propio producto de chat, eso lo cubre la documentación principal de tAI, no esta sección. Si busca cómo se evalúa la seguridad de tAI y con qué salvaguardas está construido el producto, esa es la sección de Seguridad. Esta sección está delimitada específicamente a la API HTTP orientada a desarrolladores: qué envía, qué recibe de vuelta, y qué significa cada campo y encabezado.

Una nota sobre estabilidad

Las formas de solicitud y respuesta documentadas en esta sección son las que pretendemos mantener estables. Debe esperar que se añadan campos con el tiempo a medida que la API crece; que un campo documentado cambie de significado o desaparezca sin un reemplazo no es algo que hagamos a la ligera. Donde algo sea genuinamente provisional o probable que cambie, la página correspondiente lo dice explícitamente en lugar de dejar que lo descubra por las malas. Si un campo o comportamiento no se menciona en ningún lugar de esta sección, trátelo como si no formara parte del contrato admitido, incluso si llega a observarlo en una respuesta, ya que puede cambiar o desaparecer sin previo aviso.