Jede Plattform liefert ein anderes Antwortformat. UnifAPI bündelt sie in einem Envelope, damit Skills zuverlässig abrufen, vergleichen und reagieren.

Kurz gesagt: Dies ist der Antwortkontrakt-Artikel: Öffentliche Plattformen unterscheiden sich, aber Agents brauchen einen Envelope für Paginierung, Abrechnung, Fehler und Datensätze.

Jede Quelle öffentlicher Daten gibt eine andere Antwortform zurück. TikTok verpackt Ergebnisse auf eine Weise, Reddit auf eine andere, YouTube auf eine andere, LinkedIn auf eine andere. Wenn Ihr Agent mit allen direkt spricht, erbt er all diese Variation – die Paginierungslogik verzweigt, die Retry-Policies verzweigen, das Fehler-Parsing verzweigt. Wir lösen das, indem wir jede Operation durch einen Envelope schieben. Das ist das Schema und warum es zählt.

Das Problem

Quell-Variation ist die stille Steuer auf Multi-Plattform-Agents. Die Tool-Nutzungsschleife des Agents muss viele Formen handhaben, und diese Komplexität taucht an drei Stellen auf, die teuer zu warten sind: im Prompt (dem Modell muss jede Form beigebracht werden), in der Retry-Policy (verschiedene Quellen paginieren nach einem Fehler unterschiedlich) und im Fehler-Envelope (die unauthorized-Antwort einer Plattform sieht völlig anders aus als die einer anderen).

Wir beobachteten, wie unsere eigenen Demo-Agents die meisten ihrer Tokens auf Form-Jonglieren statt auf Argumentation verwendeten, und entschieden, dass der richtige Fix am Gateway liegt, nicht beim Agent.

Der UnifAPI-Envelope

Jeder HTTP-Endpunkt, den wir bereitstellen, über jede Plattform hinweg, gibt dieselbe äußere Form zurück: { request_id, data, pagination?, billing }. Die Felder innerhalb von data sind plattformspezifisch – ein TikTok-Video hat hashtags, ein Reddit-Post hat subreddit – aber alles drumherum ist konsistent.

Fehler kollabieren in ein geschlossenes Vokabular. Jeder trägt eine menschenlesbare Nachricht und einen maschinenlesbaren Typ. Das Modell kann nach dem Typ verzweigen, ohne plattformspezifischen Text erkennen zu müssen.

Reshape-Muster, die wir verwenden

Öffentliche Plattformen hinter einem Envelope zu standardisieren bedeutet, dass unsere Reshape-Schicht ein paar Hundert Zeilen pro Plattform umfasst. Drei Muster dominieren.

Cursor-Vereinheitlichung – das Paginierungs-Token jeder Plattform (max_cursor, after, nextPageToken, end_cursor, page) wird zu pagination.cursor. Wir berechnen has_more aus dem Signal, das die Quelle liefert (length === limit, ein explizites has_more-Flag, ein null-Next-Cursor).

Feld-Abflachung – wenn eine Quelle Daten drei Ebenen tief verschachtelt (data.data.children.data, dich meinen wir, Reddit), heben wir sie auf das Top-Level data[]. Das Modell sieht nie die Zwischen-Envelopes; es sieht die Datensätze.

Defensives Parsing – öffentliche Plattformen ändern Feldtypen ohne Vorwarnung (eine Zahl wird ein String, ein Array wird ein Einzelelement, ein Zeitstempel wird null). Die Reshape-Schicht erzwingt für jedes Feld den deklarierten Typ und verwirft den Datensatz nur, wenn die Pflichtfelder fehlen. Diese Disziplin fängt die meisten stillen Fehler ab, die wir beim rohen Durchreichen sahen.

Was bricht, wenn Sie das überspringen

Ohne einen Envelope gehen bei Skalierung zwei Dinge schief. Erstens wächst Ihr Agent-Prompt linear mit der Plattformanzahl – jede neue Plattform fügt einen Absatz hinzu, der ihre Antwortform erklärt. Bei Plattform 10 ist der Prompt der langsamste Teil des Aufrufs.

Zweitens wächst Ihr Retry- und Paginierungs-Code multiplikativ. Jede quellenspezifische Eigenheit interagiert mit jeder anderen Eigenheit, und die Matrix von „funktioniert Retry-nach-Cursor auf Plattform X unter Bedingung Y" explodiert. Teams, die nicht früh normalisieren, schreiben am Ende spät eine Normalisierungsschicht – nach den Bugs.

Was als Nächstes kommt

Der aktuelle Envelope deckt listenartige Endpunkte sauber ab. Die nächste Iteration, an der wir arbeiten, deckt Streaming- und Webhook-förmige Quellen ab – Stellen, an denen die Antwort kein einmaliges { data: [...] } ist, sondern eine Reihe von Ereignissen über die Zeit. Wir formen sie so, dass sie sich aus Sicht des Agents wie ein async Iterator anfühlt, damit die Prompt-Änderung minimal ist.

Wenn Sie heute einen Multi-Plattform-Agent bauen und sehen möchten, wie sich der Envelope in der Praxis schlägt, beginnen Sie mit einem Skill auf unifapi.com/skills oder inspizieren Sie die OpenAPI-Spezifikation auf unifapi.com/openapi.json – jeder Endpunkt, jedes Feld, eine Form.

Was Sie als Nächstes lesen sollten

Tool-Design für den MCP-Katalog – zeigt, wie Agents die Operationen entdecken, die diesen Envelope zurückgeben.

UnifAPI vs. RapidAPI – nutzt Normalisierung als Vergleichspunkt.

OpenAPI-Spezifikation – legt das Live-Schema hinter der Prosa offen.