Fehler und Debugging

Ein Aufruf kann an zwei Stellen fehlschlagen. Die Anfrage kann sofort mit einem HTTP-Fehler abgelehnt werden, oder sie wird angenommen und endet später mit status: "failed". Fehlgeschlagene und abgebrochene Jobs werden nicht abgerechnet. Du zahlst nur für abgeschlossene Jobs. Bei einer Node-App wird der eigene Job der App nie abgerechnet. Jeder Generierungs- oder LLM-Node wird berechnet, wenn sein eigener Job abgeschlossen ist. Ein Fehler bricht parallele Nodes oder andere Zweige nicht ab, daher wird auch ein Node berechnet, der abgeschlossen wird, nachdem die App bereits fehlgeschlagen ist, und diese Kosten werden nicht erstattet. Ein Node, der fehlschlägt, abgebrochen wird oder nie startet, wird nicht berechnet. Siehe API-Keys & Abrechnung.

Fehler zum Anfragezeitpunkt und fehlgeschlagene Jobs

Fehler zum Anfragezeitpunkt geben einen 4xx- oder 5xx-Status zurück. Es wird kein Job erstellt. Lies den Body wie unten beschrieben. Fehlgeschlagene Jobs geben beim Einreichen einen Erfolgsstatus zurück. Frage GET /jobs/{id} ab oder warte auf einen Webhook. Wenn der Job beendet ist, lautet status "failed" und der Fehler steht im error-Objekt auf oberster Ebene. Lies result bei einem fehlgeschlagenen Job nicht: Es fehlt (oder ist null). Es enthält die Ausgabe nur, wenn status "completed" ist. Ein cancelled-Job hat weder result noch error. Verzweige anhand von error.code. message kann fehlen, und bei provider_error und internal ist es freier Text des Anbieters. Parse message nicht.

if (job.status === "failed") {
  switch (job.error?.code ?? "internal") {
    case "content_policy":
    case "model_unavailable":
      // Dieselbe Anfrage wird höchstwahrscheinlich erneut fehlschlagen. Ändere die Eingabe oder das Modell.
      break;
    case "insufficient_balance":
      // API-Guthaben aufladen und dann erneut einreichen.
      break;
    default:
      // timeout, auto_cancelled, provider_error, internal, node_app_node_failed
      // oder ein unbekannter Code: mit Backoff erneut einreichen.
  }
}

Antwort-Bodies

Bei Generate, Jobs, Assets, Styles und Node-Apps liest du message ?? error, wenn der Body JSON ist. Eines dieser beiden Felder enthält die Zusammenfassung. Manche 5xx-Bodies sind kein JSON, darunter ein 502, dessen Body der reine Text error code: 502 ist. Parse defensiv: Wenn der Body kein JSON ist, verzweige anhand des HTTP-Status. Die meisten Fehler verwenden { "message": "..." }, manchmal mit zusätzlichen Feldern (limit, jobType, modelAccessDenial). Ungültiges JSON und einige der unten genannten Handler verwenden stattdessen { "error": "..." }. MCP-Endpoints wie /mcp geben JSON-RPC-Fehler zurück, { "jsonrpc", "id", "error": { "code", "message" } }, nicht die HTTP-Bodies auf dieser Seite.

`Accept: application/json` senden

Ohne Accept: application/json kommen manche Fehler als HTML-Seite zurück, und ein JSON-Parser schlägt fehl.

{ "message" }-Fehler, einschließlich 401 und 404, sind JSON, wenn Accept application/json oder */* ist. Fehlt Accept oder ist es text/html, sind diese Status eine HTML-Seite (Content-Type: text/html), und ein JSON-Parser schlägt fehl. Das betrifft Clients, die keinen Accept-Header senden. Pythons urllib ist einer davon. curl sendet standardmäßig Accept: */*, ebenso Nodes fetch, daher erhalten beide JSON, sofern du Accept nicht überschreibst. Nicht authentifizierte Aufrufe von POST /generate/..., GET /jobs/{id}, GET /styles und GET /assets geben bei */* und application/json 401 {"message":"Unauthorized"} zurück, bei fehlendem Accept oder text/html eine HTML-Seite. Ein authentifiziertes GET /jobs/{id} mit unbekannter ID verhält sich beim Status genauso: 404 JSON {"message":"Job not found or unauthorized"}, wenn Accept JSON anfordert, und 404 text/html, wenn Accept fehlt. Ungültiges JSON (400) und Validierung (422) verwenden { "error" } und bleiben JSON, auch wenn Accept fehlt. Dasselbe gilt für 422 bei entfernten Feldern, 410 bei Sunset, den 402 für Zero Data Retention, { "error" }-Antworten von Node-Apps und die gemappten Fehler der Agent-Operation-API. 402 und 429 bei der Annahme eines POST /generate/...-Jobs sind ebenfalls JSON, auch bei einem Browser-Accept. 413 und 500 verwenden { "message" } und richten sich wie 401 und 404 nach Accept.

Validierung (`422`)

{
  "error": "Validation failed",
  "details": [
    {
      "field": "width",
      "message": "Too small: expected number to be >0",
      "code": "too_small"
    },
    {
      "field": "",
      "message": "Unrecognized key: \"foo\"",
      "code": "unrecognized_keys"
    },
    {
      "field": "prompt",
      "message": "Enter a prompt.",
      "code": "custom"
    }
  ]
}

details listet jedes Problem auf. field ist der mit . verbundene Pfad ("image_style_references.0.url"). Fehler auf Objektebene verwenden einen leeren String, wie beim unbekannten Schlüssel oben. Mehrere unbekannte Schlüssel erzeugen Unrecognized keys: ... und dasselbe leere field. expected wird nur hinzugefügt, wenn code "invalid_type" ist. Ein ungültiger X-Webhook-URL-Header verwendet denselben 422. GET /jobs mit ungültigen Query-Parametern gibt ebenfalls diesen 422 zurück. Es ist kein 400. Eine Zero-Data-Retention-Eingabeprüfung, die innerhalb des Tools fehlschlägt, gibt 422 mit der Erklärung in message zurück (das { "message" }-Format, daher spielt Accept eine Rolle). Siehe Zero Data Retention.

Entfernte und veraltete Felder (`422`)

Das entfernte Feld batchSize / batch_size verwendet einen anderen 422. Es gibt kein details-Array:

{
  "error": "invalid_request",
  "reason": "removed_field",
  "field": "batchSize",
  "message": "Generation batch size is no longer supported. Submit one request per output.",
  "value": 2
}

batch_size ist auf dieselbe Weise entfernt. field ist der Name, den du gesendet hast. Ein veralteter Feld-Alias verwendet reason "deprecated_field" oder "conflicting_fields", zusätzlich replacement, sunset_date und migration_url, sofern zutreffend. Verzweige anhand von error und reason. Der Satz, den du einer Person anzeigen kannst, ist message.

Sunset-Modelle (`410`)

Ein Modell nach seinem Sunset-Datum gibt 410 mit Deprecation: true und einem Sunset-Header (ein Datum nach RFC 1123) zurück:

{
  "error": "model_unavailable",
  "reason": "deprecated",
  "message": "The model '<path>' was deprecated on <sunsetDate>. <reason> Use '<replacement>' instead.",
  "sunset_date": "YYYY-MM-DD",
  "replacement": "<optional>",
  "migration_url": "<optional>"
}

error ist der stabile Wert "model_unavailable". replacement und migration_url fehlen, wenn es keinen empfohlenen Ersatz gibt. Ein Retry mit demselben Modell gibt weiterhin 410 zurück. Wechsle zu replacement, wenn es gesetzt ist, und siehe Deprecations. Ein Modell, das veraltet, aber noch aktiv ist, sendet Deprecation und Sunset bei jeder Antwort, auch bei Fehlern. Die Verwendung eines veralteten Feld-Alias bewirkt dasselbe, auch bei seinem eigenen 422. Wenn ein Migrationsleitfaden existiert, wird zusätzlich ein Link: <migration_url>; rel="deprecation"-Header gesendet.

Statuscodes

Status	Bedeutung
`400`	Ein Generate-Body ist kein gültiges JSON, eine Eingabe-URL einer Node-App konnte nicht verwendet werden, oder Asset- bzw. Node-App-Parameter sind ungültig. Ungültiges JSON bei Node-App-Execute ergibt `500`.
`401`	Die Zugangsdaten fehlen oder sind ungültig.
`402`	Die Anfrage wurde abgelehnt, bevor ein Job gestartet wurde. Siehe 402.
`403`	Der Aufrufer ist authentifiziert, darf diese Ressource aber nicht verwenden.
`404`	Keine Route passt, der Modellpfad ist unbekannt oder für dich nicht verfügbar, oder ein Job, Asset, Style oder eine Node-App fehlt.
`405`	Die HTTP-Methode ist für diesen Pfad nicht erlaubt.
`410`	Das Modell hat sein Sunset erreicht. Siehe Sunset-Modelle.
`413`	Der Request-Body ist zu groß. Siehe 413.
`422`	Die Validierung ist fehlgeschlagen, ein entferntes oder veraltetes Feld wurde gesendet, oder eine Eingabe wurde dauerhaft abgelehnt.
`429`	Über dem Concurrency-Limit, und der Job kann nicht in den Backlog gestellt werden. Das Limit ist ungefähr.
`500`	Unbehandelter Serverfehler. `{ "message": "Internal Error" }`. Kein Exception-Text. Richtet sich nach `Accept`.
`502`, `504`	Wiederholbar. Ein `502` kommt als Cloudflare-Klartext `error code: 502`, nicht als JSON, verzweige also anhand des Statuscodes. Auch `504` kann Klartext sein. Siehe Eingabe-Downloads.

`400`

Ungültiges JSON bei Generate ist immer JSON, ohne dass ein Accept-Header nötig ist:

{
  "error": "Invalid JSON: Expected property name or '}' in JSON at position 1 (line 1 column 2)"
}

Node-App-Execute verwendet { "error" } für eine Eingabe-URL, die nicht verwendet werden kann: Invalid URL for input "<key>" oder Failed to download URL for <key>: …. Die Download-Meldung umfasst auch vorübergehende Fehler, daher ist ein Download-Fehler bei Node-Apps, anders als bei Generate (siehe Eingabe-Downloads), immer 400. Wiederhole ihn einmal, wenn die URL gültig ist. Ungültiges JSON bei POST /node-apps/{id}/execute ist nicht der oben beschriebene Generate-400. Es wird zu einem 500 { "message": "Internal Error" } ohne Exception-Text und richtet sich nach Accept. Andere 400-Antworten bei Assets und Node-Apps sind { "message": "..." } mit einer kurzen Erklärung, zum Beispiel No file provided bei einem Presigned Upload oder Invalid pagination parameters bei Node-App-Versionen. Ein fehlgeschlagener Asset-Upload reicht den Status des Upload-Dienstes durch (400, 401, 404 oder 500) und kann dessen Antworttext in message einfügen. Dieser Text ist manchmal ein JSON-String. Ungültige Query-Parameter bei GET /jobs ergeben 422, nicht 400.

`401`

Generate, Jobs, Assets, Styles und Node-Apps:

{ "message": "Unauthorized" }

Presigned Uploads geben { "message": "Presigned upload URL expired" } oder { "message": "Invalid presigned upload URL" } zurück.

`402` Zahlung erforderlich

Für einen über die API abgerechneten Client (ein API-Key oder MCP mit API-Key), dessen API-Guthaben den Job nicht deckt:

{
  "message": "Your API balance is separate from your workspace compute balance. Please top up your API balance to continue using the API."
}

Lade unter krea.ai/app/api/ ↗ auf. Laufende Jobs werden abgeschlossen. Siehe API-Keys & Abrechnung. Weitere 402-Werte für message in der öffentlichen API:

`message`	Wann
`This tool is not available on your current plan.`	Dein Plan oder Workspace erlaubt für dieses Modell keine gleichzeitigen Jobs.
`MEMBER_USAGE_LIMIT_REACHED`	Der Plan erzwingt Nutzungslimits pro Mitglied, und das Budget dieses Mitglieds würde überschritten.
`WORKSPACE_USAGE_LIMIT_REACHED`	Der Plan erzwingt Nutzungslimits pro Mitglied, und das Budget des Workspaces würde überschritten.
`MEMBER_LIMIT_VIOLATION`	Der Workspace hat mehr Mitglieder, als sein Plan erlaubt.
`K3_ULTRA_ACCESS_REQUIRED`	Krea 3 mit `thinking_mode` `"ultra"` (oder dem alten `"max"`) und Bildreferenzen, bei einem Plan ohne Krea 3 Ultra. Ohne Bildreferenzen läuft Ultra als `"fast"`.
`ENHANCER_RESOLUTION_LIMIT_REACHED`	Ein Upscale ist größer, als der Free-Plan erlaubt.

Ein Generate-Aufruf mit Zero Data Retention in einem Workspace, für den es nicht aktiviert ist, gibt diesen Body zurück, immer als JSON:

{ "error": "Zero data retention is not enabled for this workspace." }

Die Agent-Operation-API verwendet eigene 402-Bodies. Diese beziehen sich auf das Compute-Guthaben des Workspaces, nicht auf das API-Guthaben.

`403`

`message` oder `error`	Wann
`Use an API key or a plugin session`	Realtime, aufgerufen ohne API-Key oder OAuth- bzw. Plugin-Session. `{ "message" }`.
`This endpoint needs a workspace service API key`	Usage API, die Zugangsdaten sind kein Workspace-Service-API-Key. `{ "message" }`.
`Your plan is not entitled to the usage API`	Usage API, der Plan ist nicht berechtigt. `{ "message" }`.
`FEATURE_RESTRICTED`	Ablehnung durch die Modell-Richtlinie. Der Body enthält zusätzlich `modelAccessDenial`. `{ "message" }`.
`MODEL_ACCESS_REQUIRED`	Das Modell ist nur intern verfügbar. `{ "message" }`.
`This node app cannot be used via the API.`	Node-App-Execute. `{ "error" }`, immer JSON.
`Free users cannot run node apps`	Node-App-Execute in einem Workspace mit Free-Plan. `{ "message" }`.
`You do not own this style`	Ändern oder Teilen eines Styles, der dir nicht gehört. `{ "message" }`.

`404`

Jeder 404 ist { "message" }, zum Beispiel bei einer unbekannten Job-ID:

{ "message": "Job not found or unauthorized" }

Ein fehlender Accept-Header macht diese Antworten zu HTML, außer Endpoint not found für ein Modell, das dein Key oder Plan nicht verwenden kann – das ist immer JSON. Ein authentifiziertes GET /jobs/{id} mit unbekannter ID ohne Accept ergibt 404 text/html.

`message`	Wann
`Not Found`	Keine Route passt zum Pfad.
`Endpoint not found`	Ein Modellpfad unter `/generate`, der unbekannt ist oder den dieser API-Key oder Plan nicht verwenden kann.
`Job not found or unauthorized`	Fehlende oder ungültige Job-ID, einschließlich `DELETE /jobs/{id}`.
`Asset not found`	Fehlendes Asset.
`Style not found`	Fehlender Style. Das Ändern oder Teilen eines Styles, der dir nicht gehört, ergibt `Style not found or you are not the owner`.
`Node app not found`	Fehlende Node-App.
`Workspace not found`	Usage API, der Workspace fehlt.

Eine unbekannte Agent-Operation ergibt ebenfalls 404 { "message": "Endpoint not found" }, nicht das Agent-Format { "error", "code" }.

`405`

Der Body ist Klartext ohne Content-Type-Header, kein JSON, auch wenn Accept application/json ist. Der Text ist die Methode plus method not allowed, zum Beispiel GET method not allowed. Ein Allow-Header listet die Methoden auf, die der Pfad akzeptiert.

`413` Payload zu groß

Ein zu großer Request-Body wird mit 413 abgelehnt. Von der API selbst richtet sich der Body nach Accept:

{ "message": "Payload Too Large" }

Ein sehr großer Body kann abgelehnt werden, bevor er die API erreicht, mit einer HTML-Seite für 413. Sende Dateien nicht inline. Lade die Datei mit POST /assets hoch und übergib die zurückgegebene URL in der Generate-Anfrage.

Eingabe-Downloads

Ein Host, der 404 oder 410 zurückgibt, führt zu einem dauerhaften 422. Der Body ist JSON, und Accept spielt eine Rolle:

{ "message": "Input file rejected: fetching <url> returned HTTP 404" }

Ein 410 des Hosts verwendet denselben Satz mit 410. Andere dauerhafte Ablehnungen verwenden Input file rejected: …. Ein wiederholbarer Download-Fehler ist 502 oder 504. Verzweige anhand des Statuscodes, nicht des Bodys, und wiederhole die Anfrage.

Status	Was du erhältst	Retry?
`422`	JSON `{ "message": "Input file rejected: fetching <url> returned HTTP 404" }`, wenn der Host `404` zurückgibt. Ein `410` des Hosts verwendet denselben Satz mit `410`.	Nein. Der Fehler ist dauerhaft.
`502`	Cloudflare-Klartext `error code: 502` mit `Content-Type: text/plain; charset=UTF-8`. Bestätigt, wenn der Datei-Host `503`, `500` oder `429` zurückgibt und wenn die Domain nicht aufgelöst werden kann.	Ja. Verzweige anhand des Statuscodes.
`504`	Nicht live getestet. Kann ebenfalls als Cloudflare-Klartext ankommen.	Ja. Verzweige anhand des Statuscodes.

Ein 502, der sich für dieselbe URL ständig wiederholt, bedeutet wahrscheinlich, dass die URL blockiert oder defekt ist. Ändere die URL. Fehler bei der Konvertierung im 3D-Export sind ebenfalls 502. Dieser Pfad wurde nicht live getestet, daher kann der Body auch als Cloudflare-Klartext error code: 502 ankommen. Verzweige anhand des Statuscodes und wiederhole die Anfrage. Ein 502, der sich für dieselbe Modell-URL ständig wiederholt, bedeutet wahrscheinlich, dass die URL blockiert oder defekt ist.

`429` Concurrency

Wenn der Job nicht in den Backlog gestellt werden kann, kann eine Anfrage über dem Concurrency-Limit mit 429 und Content-Type: application/json abgelehnt werden:

{
  "message": "CONCURRENCY_LIMIT_REACHED",
  "limit": 4,
  "jobType": "k2"
}

limit ist dein Concurrency-Limit für diese Art von Job. Es wird pro Nutzer gezählt, nicht pro Workspace. Es ist ungefähr: Ein kurzer Burst kann darüber hinaus angenommen werden, verlass dich also nicht darauf, dass genau die Anfrage limit + 1 fehlschlägt. jobType ist eine interne Job-Kategorie, nicht der öffentliche Modellpfad. Verzweige nicht anhand davon. Krea 2 kann auch nur { "message": "CONCURRENCY_LIMIT_REACHED" } ohne limit oder jobType zurückgeben, wenn seine gemeinsame Warteschlange voll ist. Das ist nicht dein Limit. Warte mit Backoff und versuche es erneut. Backlogging ist nur aktiv, wenn der Plan es enthält (Pro und höher), das Modell es unterstützt und die Anfrage nicht Zero Data Retention verwendet. Krea-2-Anfragen werden derzeit in keinem Plan in den Backlog gestellt und geben daher über dem Limit 429 zurück. Wenn es aktiv ist, wird der zusätzliche Job mit status: "backlogged" angenommen und startet, sobald ein Slot frei ist. Es gibt keine separate Obergrenze für den Backlog. Siehe Rate Limits. Die API sendet weder Retry-After noch X-RateLimit-*. Die Antwort enthält jedoch cf-ray. Wiederhole die Anfrage bei 429 mit exponentiellem Backoff, nachdem laufende Jobs abgeschlossen sind (frage GET /jobs/{id} ab oder verwende einen Webhook). Wenn ein später abgeschlossener Job das Guthaben aufbraucht, schlagen Jobs, die noch im Backlog stehen, mit error.code "insufficient_balance" fehl. Das ist ein fehlgeschlagener Job, kein HTTP-402. Diese Jobs senden keinen Webhook, frage also GET /jobs/{id} für Jobs im Backlog ab.

Agent-Operation-API

POST /agent/{operation} und GET /agent/session/{sessionId} geben { "error", "code"?, "allowedModels"? } zurück. Nur error ist erforderlich. allowedModels ist in camelCase. Ein Zug, der nach seiner Annahme fehlschlägt, erscheint als status: "failed" in der Session, nicht als einer dieser HTTP-Fehler. Siehe Agent.

Status	Body
`400`	`{ "error": "Invalid JSON body" }`
`401`	`{ "error": "Unauthorized" }`
`402`	`{ "error": "Insufficient compute balance for an Agent turn", "code": "compute_limit" }` oder `{ "error": "Free plan Agent message limit reached. Upgrade to keep using the Agent", "code": "free_message_limit" }`.
`403`	`{ "error": "Model is not included in the workspace plan", "code": "model_not_entitled", "allowedModels": ["..."] }`.
`404`	Unbekannte Operation: `{ "message": "Endpoint not found" }`. Andernfalls `{ "error": "Session not found or not accessible", "code": "not_found" }` oder `{ "error": "<file reference error>", "code": "attachment_not_found" }`.
`409`	`{ "error": "...", "code": "conflict" }`.
`422`	Fehlerhafte Eingabe: `{ "error": "Validation failed", "details": [...] }` wie unter Validierung. Andere gemappte Fehler sind `{ "error": "<message>" }` plus `code`, falls vorhanden. Eine nicht verbundene Desktop-App hat keinen `code`; die Meldung beginnt mit `That desktop app is not connected`.

Ein unbekannter Agent-Fehlercode ist trotzdem 422 mit { "error", "code" }. Der 404 für unbekannte Operationen und ein unbehandelter 500 verwenden { "message" } und richten sich nach Accept.

`error.code` fehlgeschlagener Jobs

GET /jobs und GET /jobs/{id} setzen error nur, wenn status "failed" ist. Es gibt kein verwendbares result:

{
  "status": "failed",
  "error": {
    "code": "content_policy",
    "message": "An external provider's moderation systems rejected the generation."
  }
}

Verzweige anhand von error.code. Parse niemals message.message kann fehlen. Meldungen bei provider_error und internal sind freier Text, und eine internal-Meldung kann roher Anbietertext sein, etwa failed to download media from the provided URL. Behandle jeden code, den du nicht kennst, als internal.

`code`	`message`	Was zu tun ist
`content_policy`	`Krea's moderation systems rejected the generation.` oder `An external provider's moderation systems rejected the generation.`	Ändere den Prompt oder die Eingaben. Dieselbe Anfrage wird höchstwahrscheinlich erneut abgelehnt.
`timeout`	`An external provider did not complete the generation in sufficient time.`	Wiederhole den Job.
`insufficient_balance`	Fehlt. Eine Node-App kann stattdessen `You are out of compute units. Add more compute units to continue running this node app.` zurückgeben.	Lade auf und reiche erneut ein. Dieser Job wurde zuvor angenommen; der HTTP-Aufruf hat kein `402` zurückgegeben.
`auto_cancelled`	`Job repeatedly failed healthchecks and was automatically cancelled.`	Reiche den Job erneut ein.
`model_unavailable`	Meist der eigene Text des Anbieters. `The provider retired this model. It no longer accepts new generations.`, wenn es keinen gibt.	Rufe dieses Modell nicht mehr auf. Verwende den Ersatz unter Deprecations, falls es einen gibt.
`provider_error`	Meist der eigene Text des Anbieters.	Wiederhole mit Backoff.
`internal`	Freier Text oder fehlt.	Versuche es später erneut. Gib die `job_id` an, wenn du den Support kontaktierst.
`node_app_node_failed`	`Node "<type>" failed: <detail>` oder `Node "<type>" failed.`	Lies `message`. Wenn der Node auf ein vorübergehendes Problem gestoßen ist, etwa einen Timeout, führe die App erneut aus. Andernfalls behebe zuerst das Problem mit diesem Node. Der eigene Job der App wird nie abgerechnet. Jeder Generierungs- oder LLM-Node wird berechnet, wenn sein eigener Job abgeschlossen ist. Ein Fehler bricht parallele Nodes oder andere Zweige nicht ab, daher wird auch ein Node berechnet, der abgeschlossen wird, nachdem die App bereits fehlgeschlagen ist, und diese Kosten werden nicht erstattet. Ein Node, der fehlschlägt, abgebrochen wird oder nie startet, wird nicht berechnet. Node-ID und Node-Typ sind im öffentlichen Job nicht enthalten.

Webhook-Zustellungen für einen fehlgeschlagenen Job verwenden dasselbe Job-Objekt, einschließlich error. Eine Zustellung für einen abgebrochenen Job hat kein error. Ein Payload größer als 256 KiB wird nicht gesendet, und für diesen Job erfolgen keine weiteren Zustellungen, frage also stattdessen GET /jobs/{id} ab. Verifiziere die Signatur, bevor du dem Body vertraust. Siehe Webhooks.

Debugging

Es gibt keinen Krea-Request-ID-Header. Jede Antwort enthält jedoch den cf-ray-Header von Cloudflare. Es werden keine Retry-After- oder X-RateLimit-*-Header gesendet. Wenn du an support@krea.ai schreibst, gib Folgendes an:

job_id, wenn der Aufruf einen Job erstellt oder angesprochen hat
Zeitpunkt und Endpoint
Bei einem Fehler zum Anfragezeitpunkt den cf-ray-Wert

Access-Control-Allow-Origin ist *. Bei Generate, Jobs, Assets, Styles und Node-Apps ist Access-Control-Expose-Headers nicht gesetzt, daher kann Browser-fetch cf-ray, Deprecation oder Sunset nicht lesen. Kopiere cf-ray aus dem Netzwerk-Log oder aus einem serverseitigen Client. Prüfe bei jeder Antwort Deprecation und Sunset, bevor das Modell keine Aufrufe mehr annimmt. Siehe Deprecations.

Nächste Schritte

Job-Lebenszyklus

Frage den Status ab, bis der Job abgeschlossen ist, fehlschlägt oder abgebrochen wird

Webhooks

Verifiziere die Signatur bei der Zustellung eines fehlgeschlagenen Jobs

Rate Limits

Wann zusätzliche Jobs in den Backlog kommen und wann sie 429 zurückgeben

API-Keys & Abrechnung

API-Guthaben nach einem 402 aufladen

Erste Schritte

Krea 3

Krea 2

Grundkonzepte

Codebeispiele

Tutorials

Fehler und Debugging

Fehler zum Anfragezeitpunkt und fehlgeschlagene Jobs

Antwort-Bodies

`Accept: application/json` senden

Validierung (`422`)

Entfernte und veraltete Felder (`422`)

Sunset-Modelle (`410`)

Statuscodes

`400`

`401`

`402` Zahlung erforderlich

`403`

`404`

`405`

`413` Payload zu groß

Eingabe-Downloads

`429` Concurrency

Agent-Operation-API

`error.code` fehlgeschlagener Jobs

Debugging

Nächste Schritte

Job-Lebenszyklus

Webhooks

Rate Limits

API-Keys & Abrechnung

​Fehler zum Anfragezeitpunkt und fehlgeschlagene Jobs

​Antwort-Bodies

​Accept: application/json senden

​Validierung (422)

​Entfernte und veraltete Felder (422)

​Sunset-Modelle (410)

​Statuscodes

​400

​401

​402 Zahlung erforderlich

​403

​404

​405

​413 Payload zu groß

​Eingabe-Downloads

​429 Concurrency

​Agent-Operation-API

​error.code fehlgeschlagener Jobs

​Debugging

​Nächste Schritte

Job-Lebenszyklus

Webhooks

Rate Limits

API-Keys & Abrechnung

Fehler zum Anfragezeitpunkt und fehlgeschlagene Jobs

Antwort-Bodies

`Accept: application/json` senden

Validierung (`422`)

Entfernte und veraltete Felder (`422`)

Sunset-Modelle (`410`)

Statuscodes

`400`

`401`

`402` Zahlung erforderlich

`403`

`404`

`405`

`413` Payload zu groß

Eingabe-Downloads

`429` Concurrency

Agent-Operation-API

`error.code` fehlgeschlagener Jobs

Debugging

Nächste Schritte