Référence de l'API tAI

Le point d'accès

Tout, dans cette API, passe par une seule URL :

# URL de base
https://api.artfical.com/v1

Il existe un unique point d'accès de complétion, POST /v1/chat/completions, et un unique point d'accès de listage en lecture seule, GET /v1/models. C'est toute la surface de l'API. Il n'y a pas de point d'accès distinct par modèle, pas de point d'accès distinct pour le streaming par rapport au mode non-streaming (la même URL gère les deux, le choix se faisant via un champ du corps de la requête), et pas de point d'accès distinct pour les tours d'appel d'outils. Si vous avez déjà développé avec l'API Chat Completions d'OpenAI, les points d'accès d'inférence de GitHub, ou l'un des nombreux fournisseurs proposant une structure compatible OpenAI, tout ceci vous sera déjà familier. Cette ressemblance est délibérée : pointer un client compatible OpenAI existant (le paquet officiel openai pour Python ou Node, LangChain, LlamaIndex, un agent de codage comme OpenCode, ou votre propre wrapper léger) vers https://api.artfical.com/v1 avec une clé API tAI devrait fonctionner sans modification de code, ou presque.

Le chemin le plus rapide vers une première requête

Trois choses sont nécessaires : un espace de travail sur console.artfical.com, une clé API créée depuis la page des clés API de cet espace de travail, et n'importe quel client HTTP. Voici la version la plus courte, avec curl :

# Remplacez tai-sk-... par votre propre clé
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."}]
  }'

Cette seule requête constitue une intégration complète et fonctionnelle. Tout le reste de cette section, streaming, appel d'outils, entrée d'image, contrôles d'échantillonnage, est une couche optionnelle par-dessus cette même structure, pas une API différente à apprendre. La page Complétions de chat détaille l'intégralité de la requête et de la réponse ; la page Authentification explique comment la clé elle-même est émise, cantonnée et renouvelée.

Comment cette section est organisée

Les pages de cette section sont regroupées dans l'ordre où la plupart des gens en ont réellement besoin, pas dans l'ordre où l'implémentation sous-jacente se trouve organisée. Le premier groupe, prise en main, couvre ce dont tout le monde a besoin quel que soit le projet : comment s'authentifier, la structure d'une requête et d'une réponse, en quoi le streaming diffère d'une réponse bloquante unique, et comment découvrir quels modèles existent, ce que chacun coûte et ce qu'il prend en charge. Le deuxième groupe, options de requête, couvre tout ce qui est optionnel par-dessus une requête de base : les curseurs d'échantillonnage qui façonnent la génération d'une réponse, comment donner au modèle des outils qu'il peut demander à appeler, et comment envoyer une image accompagnée de texte. Le troisième groupe, référence, est plutôt destiné à être consulté ponctuellement que lu de bout en bout : la structure exacte d'une réponse d'erreur et ce que signifie chaque type, le fonctionnement de la limitation de débit et les en-têtes qui la reflètent, le tableau de tarification par modèle, et une page destinée spécifiquement à quiconque migre une intégration SDK OpenAI existante, détaillant ce qui est pris en charge tel quel et ce qui ne l'est pas.

À qui s'adresse cette section

Cette section s'adresse à quiconque écrit du code interagissant directement avec l'API, que ce soit un service backend, un script, ou un framework d'agent comme OpenCode qui traite tAI comme l'un des multiples fournisseurs interchangeables compatibles OpenAI. Elle suppose une aisance avec les requêtes HTTP et la lecture de JSON, mais aucune familiarité préalable avec tAI en particulier. Si vous cherchez plutôt comment utiliser tAI via le produit de chat lui-même, c'est couvert par la documentation principale de tAI, pas par cette section. Si vous cherchez comment tAI est évalué en matière de sécurité et sur quelles protections le produit est construit, c'est la section Sécurité. Cette section se limite spécifiquement à l'API HTTP destinée aux développeurs : ce que vous envoyez, ce que vous recevez, et ce que signifie chaque champ et chaque en-tête.

Une remarque sur la stabilité

Les structures de requête et de réponse documentées dans cette section sont celles que nous comptons maintenir stables. L'ajout d'un champ est quelque chose à attendre naturellement à mesure que l'API évolue ; en revanche, un champ documenté qui change de signification ou disparaît sans remplacement n'est pas quelque chose que nous faisons à la légère. Lorsqu'un élément est réellement provisoire ou susceptible de changer, la page concernée le précise explicitement plutôt que de vous laisser le découvrir à vos dépens. Si un champ ou un comportement n'est mentionné nulle part dans cette section, considérez qu'il ne fait pas partie du contrat pris en charge, même si vous l'observez par hasard dans une réponse, car il peut changer ou disparaître sans préavis.