GloopAPI-Integrationsleitfaden
Abrechnung
Reservierungen, Abrechnung und Dateispeicherung verstehen.
Modellkatalog, öffentliche Preisübersichten und tatsächliche Aufrufabrechnung sind unterschiedliche Informationen. Vor kostenpflichtigen Vorgängen sollte die Anwendung Modell oder Tool, Eingaben und Budget prüfen; ein ausreichendes Guthaben garantiert keine Aufrufberechtigung.
Reservierung und Abrechnung
Bei Annahme einer Anfrage kann ein geschätzter Betrag reserviert werden. Nach Eingang maßgeblicher Nutzungsdaten wird mit den eingefrorenen Preisen abgerechnet und die Differenz nachbelastet oder erstattet. Nutzungsgestützte Videokostenvoranschläge sind Schätzungen und keine garantierte Ausgabenobergrenze. Die maximale Tool-Reservierung wird anhand der Eingabegrenzen und eingefrorenen Regeln berechnet; das Kostenlimit wird bei der Erstellung geprüft.
status=succeeded beschreibt das Ausführungsergebnis; billing.status=reserved bedeutet weiterhin, dass die Kosten bestätigt werden müssen. Ein leerer Endbetrag ist nicht null. Unbekannte Dienstübermittlung oder widersprüchliche Nutzungsdaten halten die Reservierung bis zur Prüfung aufrecht. Ob ein bestätigter Fehler erstattet wird, hängt vom Endpunkt und den Nutzungsnachweisen ab; nicht alle Fehler sind garantiert kostenlos.
Für synchronen Text ist der endgültige Verbrauch in den Nutzungsaufzeichnungen der Plattform maßgeblich; für asynchrone Aufgaben gilt deren Abrechnungsstatus. Versuchen Sie nicht, die Abrechnung einer alten Aufgabe durch erneute Generierung abzuschließen.
Preisfunktionen der Tools
pricing.mode unterscheidet flat, einen konstanten Preis pro Aufruf, input, eine Vorausberechnung anhand der Eingaben, und usage, eine Berechnung anhand der endgültigen Nutzung. schema_version beschreibt lediglich das Regelformat. amount bei flat ist der vollständige konstante Preis, einschließlich null; input/usage liefern keinen irreführenden konstanten Betrag.
pricing.quote_required legt fest, ob ein neuer Aufruf einen Kostenvoranschlag benötigt; requires_usage gibt an, ob für die endgültige Abrechnung maßgebliche Nutzungsdaten erforderlich sind, einschließlich der Abrechnungsvorgaben der Plattform. Auch bei einem Verkaufspreis mit flat können Kostenvoranschlag und endgültige Nutzung nötig sein; entscheiden Sie anhand dieser beiden Felder. Bei requires_usage=true muss max_cost_usd mindestens maximum_usd abdecken. Warten Sie nach Erfolg auf die maßgebliche Nutzung, bevor abgerechnet wird. input-Regeln ohne Bedarf an endgültigen Nutzungsdaten können nach dem Kostenvoranschlag zum Eingabebetrag abgerechnet werden, ohne auf Dienstnutzung zu warten.
metered_pricing beschränkt nur neue Aufrufe, die endgültige Nutzungsdaten benötigen. Es beschränkt keine konstanten oder eingabebasierten Regeln ohne diese Anforderung und blockiert weder Abfragen angenommener Ausführungen noch idempotente Wiederholungen der ursprünglichen Anfrage oder die Wiederherstellung eingefrorener Abrechnung. Ein Kostenvoranschlag bindet Key, Tool-Version, normalisierte Eingaben sowie Preis- und Quellenkonfiguration. Auch bei konstant bepreisten Tools wird eine übermittelte quote_id immer geprüft. Die niedrigste im Katalog angezeigte Stufe bedeutet nicht, dass das Tool kostenlos ist.
Dateiaufbewahrung und Speicherplatz
Normale archivierte API-Dateien laufen nach der im Deployment eingestellten Aufbewahrungsdauer ab. Persistente Bilder und Videos werden durch Referenzschutz langfristig aufbewahrt; expires_at=0 bedeutet keinen geplanten Ablauf. Speicherbelegung und Generierungskosten werden getrennt berechnet; vor ready ist kein Download garantiert.
Das Löschen persistenter Aufgaben leert die Ergebnisse und löst löschbare Referenzen; nicht geteilte Dateien werden im Hintergrund bereinigt. Geteilte Referenzen sowie Abrechnungs- und Idempotenzdatensätze bleiben bestehen. Das Löschen einer Datei oder fehlgeschlagenes Speichern erstattet bereits entstandene Generierungskosten nicht automatisch. Ein erneuter Speicherversuch fordert freien Speicher an und verwendet das ursprüngliche Ergebnis ohne neue Generierung.
Unzureichendes Kontingent
Prüfen Sie bei 403, 402 oder Kontingentfehlern zuerst Konto- und Key-Limits. Persistente Authentifizierung erlaubt gültigen Keys mit ausgeschöpftem Kontingent das Lesen des Verlaufs, neue Aufgaben benötigen aber weiterhin Budget. Für die Abrechnung einer vorhandenen Aufgabe fragen Sie deren ursprünglichen Datensatz weiter ab; reichen Sie sie nicht mit anderer Key oder anderem Anfrageschlüssel erneut ein. Siehe Authentifizierung und Asynchrone Aufgaben und Idempotenz.