Zum Hauptinhalt springen
Jeder Task hat einen Preis in Credits. Der Preis wird beim Einreichen reserviert, bei Abschluss abgebucht und bei einem Fehlschlag freigegeben. Ihr Tarif legt fest, wie viele Tasks Sie gleichzeitig in der Warteschlange oder in Ausführung haben können. Die aktuelle Liste der Engines und Preise liefert der öffentliche Capabilities-Endpunkt. Er benötigt keinen API-Schlüssel:
Fügen Sie ?taskType=GEMINI hinzu, um eine einzelne Engine zu lesen. Aliasse wie GOOGLE_AIO werden akzeptiert. Siehe Capabilities abrufen.

Credits pro Task

Die Preise hängen nicht vom Tarif ab, wohl aber der Dollarwert eines Credits. Credits können zwei Nachkommastellen haben, etwa 1.25.

Abrechnung von Citation Analysis

Ein CITATION_ANALYSIS-Task reserviert beim Einreichen 20 + 12 × citations + 80 × ⌈answer characters ÷ 1,000⌉ Credits. Bei Abschluss werden 1 + ⌈input tokens ÷ 500⌉ + ⌈output tokens ÷ 100⌉ + 2 × source fetches berechnet, nie mehr als die Reservierung. Der Rest der Reservierung wird freigegeben. Siehe Citation Analysis.

Reservieren, abbuchen, freigeben

1

Einreichen: reservieren

Der Preis des Tasks (bei WEB_CRAWL, GEO_SCORE und CITATION_ANALYSIS der Höchstbetrag) wird von Ihrem verfügbaren Guthaben in eine Reservierung verschoben. Deckt das Guthaben ihn nicht, liefert die Einreichung 402 INSUFFICIENT_CREDITS. Die Antwort beim Einreichen zeigt credits als 0.
2

Abgeschlossen: abbuchen

Der Betrag wird aus der Reservierung abgebucht. Polling im Endzustand und Webhook zeigen ihn in creditsCharged.
3

Fehlgeschlagen: freigeben

Die Reservierung kehrt auf Ihr Guthaben zurück. Ein fehlgeschlagener Task kostet 0.
Ein neues Konto erhält bei der Registrierung 500 Credits.

Guthaben abfragen

GET /v1/credits liefert die Credits Ihres Kontos. Die Abfrage kostet nichts, ein Programm kann sie also vor jedem Batch ausführen. Siehe Credit-Guthaben.
  • remaining ist, was Sie jetzt ausgeben können. Bereits eingereichte Tasks reservieren ihren Preis in reserved; ziehen Sie ihn nicht noch einmal ab.
  • perCycle ist, was Ihr Tarif pro Zyklus gutschreibt, und cycleResetsAt, wann der aktuelle Zyklus endet. Ohne aktiven Tarif sind beide null.
  • topUpBalance nennt die aufgeladenen Credits in remaining, das Datum, an dem die nächsten davon verfallen, und wie viele es sind. Ohne aufgeladene Credits ist es null. Aufgeladene Credits gelten drei Monate ab Kauf, bleiben bei Verlängerungen erhalten und werden nach den Credits Ihres Tarifs verbraucht.
Der Schlüssel eines Unterkontos erhält 403 SUB_ACCOUNT_FORBIDDEN, weil ein Unterkonto Ihre Credits verbraucht. Siehe Unterkonten.

Verbrauch abfragen

GET /v1/usage liefert die Credits, die Ihrem Konto über einen Zeitraum in UTC-Datumsangaben berechnet wurden, aufgeteilt nach Tag, Engine und API-Schlüssel, wie Sie es wählen. Die Abfrage kostet nichts. Siehe Credit-Verbrauch.
  • from und to sind UTC-Datumsangaben, beide Tage sind eingeschlossen. Standard sind der erste Tag des laufenden UTC-Monats und heute. Ein Zeitraum umfasst höchstens 366 Tage.
  • groupBy nimmt day, engine und key, durch Kommas getrennt, und steht standardmäßig auf day,engine. Eine Zeile enthält die Felder der gewählten Aufteilungen, und eine Kombination ohne Berechnung hat keine Zeile. credits und tasks oben addieren alle Zeilen.
  • groupBy=key zeigt, wer die Credits verbraucht hat. Ein mit einem API-Schlüssel gesendeter Task hat "source": "api" und ein apiKey mit id, keyPrefix, name und subAccountId. Verbrauch ohne API-Schlüssel hat source als monitor (die Läufe eines Monitors), playground oder dashboard, und apiKey ist null.
  • Der Verbrauch addiert, was Tasks berechnet wurde, und ein fehlgeschlagener Task kostet 0. Die Wettbewerberauswertung eines Monitors wird ohne Task berechnet, senkt also Ihr Guthaben, erscheint aber nicht im Verbrauch.
  • Die Tasks Ihrer Unterkonten sind in Ihrem Verbrauch enthalten, und apiKey.subAccountId nennt das Unterkonto, dem ein Schlüssel gehört. GET /v1/sub-accounts/{id}/usage liest ein einzelnes Unterkonto. Der Schlüssel eines Unterkontos erhält 403 SUB_ACCOUNT_FORBIDDEN.

Warteschlange abfragen

GET /v1/async/status liefert Ihre wartenden und laufenden Tasks neben dem Parallelitätslimit, auf das sie angerechnet werden. Die Abfrage kostet nichts. Siehe Warteschlangenstatus.
  • concurrency.used ist queuedTasks plus processingTasks, die beiden Zahlen, die das Parallelitätslimit Ihres Tarifs addiert. max ist dieses Limit, also ist max - used der verbleibende Platz für neue Tasks.
  • priorityBreakdown listet die wartenden Tasks nach der beim Einreichen angegebenen priority, höchste zuerst.
  • Die Zähler enthalten die Tasks Ihrer Unterkonten, die Ihr Limit teilen. Der Schlüssel eines Unterkontos erhält 403 SUB_ACCOUNT_FORBIDDEN und liest seine eigenen Zähler unter GET /stats.

Tarife

Vergleichen Sie die Tarife auf der Preisseite.

Parallelität des Tarifs

Das Parallelitätslimit zählt die Tasks Ihres Kontos in QUEUED und PROCESSING zusammen. Es begrenzt nicht, wie schnell Sie einreichen. Eine Einreichung, die es überschreiten würde, liefert 429 PLAN_CONCURRENCY_LIMIT mit details.limit, details.active und Retry-After. Ein Vertrag kann für Ihr Konto ein anderes Limit festlegen, und ein übergeordnetes Konto kann eines für ein Unterkonto festlegen.

Limits pro Schlüssel und Unterkonto

Das Tageslimit des Schlüssels zählt die Reservierung, die ein Task benötigt; ein Task wird also abgelehnt, wenn used + price das Limit überschreiten würde.

Anfragerate und Gegendruck

429-Antworten der Edge entstehen vor der API und tragen weder den JSON-Fehlerumschlag noch Retry-After. Warten Sie bei einer solchen Antwort mit exponentiell wachsender Verzögerung. Ein 429 oder 503 der Task-Einreichungs-Endpunkte trägt einen Retry-After-Header in Sekunden. Codes und Empfehlungen zur Wiederholung finden Sie unter Fehler.

Große Einreichungen takten

1

Batch statt Schleife

Ein POST /v1/async/task/batch mit 500 Einträgen ist eine Anfrage gegenüber dem Edge-Limit. Für mehr Tasks als Ihr Parallelitätslimit verwenden Sie POST /v1/batches: Der Server gibt Einträge frei, sobald Platz frei wird. Siehe Batches und Raster.
2

Retry-After beachten

Warten Sie die Sekunden aus Retry-After ab, bevor Sie einen abgelehnten Task erneut einreichen. Verwenden Sie denselben idempotencyKey, damit eine Wiederholung nie ein Duplikat erzeugt.
3

Abhängige Arbeit nacheinander ausführen

Die Ausführungsreihenfolge ist nicht garantiert. Warten Sie, bis ein Task abgeschlossen ist, bevor Sie Arbeit einreichen, die von seinem Ergebnis abhängt.
4

Zähler beobachten

GET /v1/async/status liefert Ihre wartenden und laufenden Tasks neben Ihrem Tariflimit, damit Sie darunter bleiben. GET /stats ergänzt die Tasks, die in den letzten 24 Stunden abgeschlossen wurden.