tAI API-Referenz

Der Endpunkt

Alles in dieser API läuft über eine einzige URL:

# Basis-URL
https://api.artfical.com/v1

Es gibt einen einzigen Completion-Endpunkt, POST /v1/chat/completions, und einen einzigen schreibgeschützten Listing-Endpunkt, GET /v1/models. Das ist die gesamte Oberfläche. Es gibt keinen separaten Endpunkt pro Modell, keinen separaten Endpunkt für Streaming gegenüber Nicht-Streaming (dieselbe URL verarbeitet beides, gesteuert über ein Feld im Request-Body) und keinen separaten Endpunkt für Tool-Calling-Turns. Wenn Sie bereits gegen die Chat-Completions-API von OpenAI, die Inference-Endpunkte von GitHub oder einen der vielen Anbieter mit OpenAI-kompatiblem Format entwickelt haben, wird Ihnen das bereits bekannt vorkommen. Diese Ähnlichkeit ist beabsichtigt: Einen bestehenden OpenAI-kompatiblen Client (das offizielle openai-Paket für Python oder Node, LangChain, LlamaIndex, einen Coding-Agenten wie OpenCode oder Ihren eigenen schlanken Wrapper) mit einem tAI-API-Schlüssel auf https://api.artfical.com/v1 zeigen zu lassen, sollte mit wenigen oder gar keinen Codeänderungen funktionieren.

Der schnellste Weg zur ersten Anfrage

Drei Dinge werden benötigt: ein Workspace auf console.artfical.com, ein über die API-Schlüssel-Seite dieses Workspace erstellter API-Schlüssel und ein beliebiger HTTP-Client. Hier die kürzeste Version, mit curl:

# Ersetzen Sie tai-sk-... durch Ihren eigenen Schlüssel
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."}]
  }'

Diese einzelne Anfrage ist bereits eine vollständige, funktionierende Integration. Alles andere in diesem Abschnitt, Streaming, Tool Calling, Bild-Eingabe, Sampling-Steuerung, ist eine optionale Schicht auf diesem gleichen Grundgerüst, keine andere API, die man extra lernen müsste. Die Seite Chat Completions geht Request und Response im Detail durch; die Seite Authentifizierung behandelt, wie der Schlüssel selbst ausgestellt, mit Berechtigungen versehen und rotiert wird.

Wie dieser Abschnitt aufgebaut ist

Die Seiten hier sind so gruppiert, dass sie der Reihenfolge entsprechen, in der die meisten Menschen sie tatsächlich brauchen, nicht der Reihenfolge, in der die zugrunde liegende Implementierung zufällig organisiert ist. Die erste Gruppe, Erste Schritte, ist der Teil, den jeder braucht, unabhängig davon, was er baut: wie man sich authentifiziert, wie ein Request und eine Response aufgebaut sind, wie sich Streaming von einer einzelnen blockierenden Antwort unterscheidet und wie man herausfindet, welche Modelle es gibt und was jedes davon kostet und unterstützt. Die zweite Gruppe, Request-Optionen, behandelt alles, was optional auf einem einfachen Request aufsetzt: die Sampling-Regler, die bestimmen, wie eine Antwort generiert wird, wie man dem Modell Tools gibt, die es aufrufen kann, und wie man ein Bild zusammen mit Text sendet. Die dritte Gruppe, Referenz, ist eher zum Nachschlagen als zum Durchlesen von vorn bis hinten gedacht: der genaue Aufbau einer Fehlerantwort und was jeder Typ bedeutet, wie Rate Limiting funktioniert und welche Header das widerspiegeln, die Preistabelle pro Modell und eine Seite speziell für alle, die eine bestehende OpenAI-SDK-Integration migrieren, mit einer Übersicht, was unverändert unterstützt wird und was nicht.

Für wen dieser Abschnitt gedacht ist

Dieser Abschnitt richtet sich an alle, die direkt gegen die API programmieren, egal ob das ein Backend-Dienst, ein Skript oder ein Agenten-Framework wie OpenCode ist, das tAI als einen von mehreren austauschbaren OpenAI-kompatiblen Anbietern behandelt. Er setzt Vertrautheit mit HTTP-Anfragen und dem Lesen von JSON voraus, aber keine vorherige Vertrautheit mit tAI selbst. Wenn Sie stattdessen suchen, wie man tAI über das Chat-Produkt selbst nutzt, wird das in der Haupt-tAI-Dokumentation behandelt, nicht in diesem Abschnitt. Wenn Sie wissen möchten, wie tAI auf Sicherheit geprüft wird und mit welchen Schutzmaßnahmen das Produkt gebaut ist, ist das der Abschnitt Sicherheit. Dieser Abschnitt ist speziell auf die entwicklerseitige HTTP-API beschränkt: was Sie senden, was Sie zurückbekommen und was jedes Feld und jeder Header bedeutet.

Ein Hinweis zur Stabilität

Die in diesem Abschnitt dokumentierten Request- und Response-Formate sind diejenigen, die wir stabil halten wollen. Dass ein Feld hinzukommt, ist etwas, das Sie im Laufe der Zeit erwarten sollten, während die API wächst; dass ein dokumentiertes Feld seine Bedeutung ändert oder ohne Ersatz verschwindet, ist nichts, was wir beiläufig tun. Wo etwas tatsächlich vorläufig ist oder sich wahrscheinlich ändern wird, sagt die betreffende Seite das ausdrücklich, statt Sie es auf die harte Tour herausfinden zu lassen. Wenn ein Feld oder Verhalten nirgends in diesem Abschnitt erwähnt wird, behandeln Sie es als nicht Teil des unterstützten Vertrags, selbst wenn Sie es zufällig in einer Antwort beobachten, da es sich ohne Vorankündigung ändern oder verschwinden kann.