Die Rivya API ist der Entwicklerpfad, um Rivya Modellfähigkeiten aus deinem eigenen Produkt, Skript oder Workflow zu nutzen.
Sie ist kein separates Produkt neben Rivya Studio. Sie nutzt dieselbe Account-Grenze, dieselbe Credit Wallet und dieselbe öffentliche Modellschicht, die Nutzer in Rivya sehen. Der Unterschied ist, wie die Arbeit startet: Statt sich durch Studio zu klicken, sendet deine Anwendung Requests mit einem API Key.
Wenn du Endpoint-Details brauchst, beginne mit Rivya API Overview und Rivya API Quickstart. Dieser Artikel ist die Erklärung auf Produktebene: wofür die API gedacht ist, wo sie passt und wann sie nicht der erste Pfad sein sollte.
Die Kurzversion
Rivya API v1 lässt einen eingeloggten Account API Keys erstellen und Rivya Modellfähigkeiten außerhalb des Webinterfaces aufrufen.
Die aktuelle API-Oberfläche umfasst:
- Model Discovery über die API-Modellliste
- asynchrone Image-, Video- und Audio-Generation-Jobs
- Files API Uploads für Modelle, die Referenzmedien brauchen
- Generation Status Polling mit public task IDs
- Account-Credit-Checks
- Chat API Turns, einschließlich optionalem SSE streaming
- signierte Webhooks für Generation Completion
- eine TypeScript SDK beta für Teams, die einen Client Wrapper wollen
Der öffentliche Developer Hub ist Developers. Er ist der beste Einstieg, wenn du eine geführte Übersicht, Links zu API-Key-Settings und einen sicheren Debugger-Flow willst.
Warum Rivya Eine API Hat
Studio ist nützlich, wenn eine Person noch Modelle wählt, Prompts formt, Outputs prüft und entscheidet, was als Nächstes passiert.
Die API ist nützlich, wenn diese Entscheidung zu einem wiederholbaren Produkt- oder Betriebsworkflow geworden ist.
Häufige Beispiele:
- ein Produkt will Bildvarianten erzeugen, nachdem ein Nutzer einen Brief einreicht
- ein Marketing-Workflow muss visuelle Drafts aus strukturierten Kampagneninputs erstellen
- ein internes Tool muss Video- oder Audiojobs einreichen, ohne jemanden den Browser öffnen zu lassen
- ein Support- oder Content-System will einen Chatmodell-Turn in seiner eigenen Oberfläche
- ein Backend-Service will signierte Callbacks, wenn Generation Jobs abgeschlossen sind
In diesen Fällen hält Rivya API die Arbeit mit demselben Rivya Account verbunden, statt einen separaten Stack für Billing, Modellwahl und Task Status zu erzwingen.
Was Die API Nicht Ersetzt
Die API ersetzt nicht jeden Grund, Rivya direkt zu nutzen.
Nutze Studio oder die öffentlichen Arbeitsflächen, wenn:
- der Prompt noch menschliche Erkundung braucht
- die Modellwahl nicht stabil ist
- ein Creator Outputs visuell vergleichen muss
- das Projekt von gespeicherter History und manuellem Review abhängt
- das Team noch nicht entschieden hat, welches Input- und Outputformat wiederholbar werden soll
Nutze die API, wenn der Workflow klar genug ist, um automatisiert zu werden.
Diese Grenze zählt. Eine vage kreative Frage gehört meistens zuerst in Studio. Ein bekannter Produktflow mit vorhersehbaren Inputs kann in die API wechseln.
Die Wichtigsten Bausteine
Betrachte die API als sechs verbundene Teile.
| Baustein | Was er behandelt | Wo du als Nächstes liest |
|---|---|---|
| API keys | Server-to-server Zugriff aus deinem Account | API Authentication |
| Models | Public model IDs und Readiness-Informationen | API Models |
| Generations | Async Image-, Video- und Audiojobs | Create Generation |
| Files | Uploads von Referenzbild, Video oder Audio | Files API |
| Chat | Non-streaming oder streaming Chat Turns | Chat API |
| Webhooks | Signierte Completion Events für Generation Jobs | API Webhooks |
Die API-Docs sind die Quelle für Request- und Response-Shape. Dieser Artikel hilft dir zu entscheiden, welchen Teil du zuerst brauchst.
Wie Credits Funktionieren
API-Nutzung zieht aus derselben Rivya Account Credit Wallet wie Studio.
Das bedeutet, die API ist kein anonymer Modellproxy. Ein Request gehört zu einem Rivya Account, nutzt einen von diesem Account erstellten API Key und folgt derselben produktweiten Credit-Grenze, die in API Credits beschrieben ist.
Für Teams ist das nützlich, weil Studio-Experimente und API-Nutzung in einem operativen Modell bleiben. Du kannst ein Modell manuell testen und dann den wiederholbaren Teil in eine Integration verschieben, ohne eine zweite Billing-Schicht zu schaffen.
Wie Files Hineinpassen
Einige Modelle laufen allein mit Text. Andere brauchen ein Referenzbild, ein Video oder eine Audiodatei.
Für API-Integrationen sollten diese Referenzen über Files API laufen. Der Upload erstellt einen verwalteten File Record, der an unterstützte Modellparameter übergeben werden kann.
Die praktische Regel ist einfach:
- wenn ein Modell text-only Input akzeptiert, beginne mit dem Generation Endpoint
- wenn ein Modell Referenzmedien braucht, lade zuerst die Datei hoch
- wenn das Modell ein Chatmodell mit Bildanhängen ist, nutze Chat API und file IDs
Baue deine Integration nicht um browser-only Upload-Flows oder gespeicherte Studio Sessions herum. Die API hat aus gutem Grund ihre eigene öffentliche File-Grenze.
Wo Webhooks Helfen
Polling ist der einfachste erste Integrationspfad. Reiche einen Generation Job ein, speichere die public task ID und polle, bis er erfolgreich ist oder scheitert.
Webhooks werden nützlich, wenn die Integration produktionsnäher wird:
- du willst keinen Worker, der jeden Job pollt
- deine App muss einen Datensatz aktualisieren, wenn Generation abgeschlossen ist
- du willst ein signiertes Event, das sicher erneut versucht werden kann
- fehlgeschlagene Jobs müssen in einen klaren Recovery-Pfad wechseln
Für den signierten Event-Contract nutze API Webhooks. Halte den Webhook Receiver eng: Signaturen verifizieren, Duplicate Events behandeln und vermeiden, Secret Values in Logs zu schreiben.
Ein Gutes Erstes API-Projekt
Das beste erste API-Projekt ist meistens klein und konkret.
Zum Beispiel:
- einen API Key in Settings erstellen
- die Modellliste aufrufen
- ein verfügbares Modell wählen
- einen Generation Job mit Idempotency Key einreichen
- den Status Endpoint pollen
- Credits vor und nachher prüfen
- erst dann Files API, Chat API oder Webhooks hinzufügen
Dieser Pfad gibt dir eine funktionierende Integration, ohne alle API-Features in den ersten Test zu mischen.
Wann Die API Der Falsche Startpunkt Ist
Die API ist wahrscheinlich nicht der richtige erste Schritt, wenn:
- das Team noch keine Modellfamilie gewählt hat
- sich der gewünschte Output bei jedem Durchlauf noch ändert
- der Prompt von manuellem Geschmack und Review abhängt
- die Integration Credit-Nutzung vor den Menschen verstecken würde, die sie verstehen müssen
- das Produkt eine öffentliche Demo braucht, bevor es Automatisierung braucht
In diesen Fällen starte mit Image, Video, Audio, Chat oder AI Models. Sobald der Pfad wiederholbar ist, verschiebe den stabilen Teil in die API.
Wohin Als Nächstes
- Öffne Developers für den öffentlichen API Hub und Debugger.
- Lies Rivya API Quickstart, um den ersten sicheren Request zu machen.
- Lies API Authentication, bevor du einen Key auf einen Server legst.
- Lies API Models, bevor du model IDs wählst.
- Lies When to Use Rivya API Instead of Studio, wenn die Produktgrenze noch unklar ist.
- Lies How to Build a Multimodal AI Workflow with Rivya API, wenn du eine vollständige Image-, Video-, Audio- oder Chat-Integration planst.
