メインコンテンツへスキップ
呼び出しが失敗する箇所は 2 つあります。リクエストが HTTP エラーで即座に拒否される場合と、受理された後に status: "failed" で終了する場合です。失敗またはキャンセルされたジョブには課金されません。課金対象は完了したジョブのみです。ノードアプリでは、アプリ自体のジョブには課金されません。各生成ノードまたは LLM ノードは、そのノード自身のジョブが完了した時点で課金されます。失敗しても並列ノードや他のブランチはキャンセルされないため、アプリがすでに失敗した後に完了したノードにも課金され、その料金は返金されません。失敗した、キャンセルされた、または開始されなかったノードには課金されません。詳しくは API Keys & Billing を参照してください。

リクエスト時のエラーと失敗したジョブ

リクエスト時のエラー は 4xx または 5xx のステータスを返します。ジョブは作成されません。ボディは以下の説明に従って読み取ってください。 失敗したジョブ は、送信時には成功ステータスを返します。GET /jobs/{id} をポーリングするか、Webhook を待ってください。ジョブが終了すると status は "failed" になり、失敗の内容はトップレベルの error オブジェクトに入ります。失敗したジョブでは result を読み取らないでください。result は省略される(または null になる)ためです。result に出力が入るのは status が "completed" の場合のみです。cancelled のジョブには result も error もありません。 error.code で分岐してください。message は省略されることがあり、provider_error と internal ではプロバイダーによる自由形式のテキストです。message をパースしないでください。

レスポンスボディ

generate、jobs、assets、styles、node apps では、ボディが JSON の場合は message ?? error を読み取ってください。この 2 つのフィールドのいずれかに概要が入っています。一部の 5xx ボディは JSON ではありません。たとえば、ボディがプレーンテキスト error code: 502 の 502 などです。防御的にパースしてください。ボディが JSON でない場合は、HTTP ステータスで分岐します。 ほとんどの失敗は { "message": "..." } を使用し、追加のフィールド(limit、jobType、modelAccessDenial)が含まれることもあります。無効な JSON と、以下で説明するいくつかのハンドラーでは、代わりに { "error": "..." } を使用します。 /mcp などの MCP エンドポイントは、このページで説明する HTTP ボディではなく、JSON-RPC エラー { "jsonrpc", "id", "error": { "code", "message" } } を返します。

Accept: application/json を送信する

Accept: application/json を指定しないと、一部のエラーが HTML ページとして返され、JSON パーサーが失敗します。
401 や 404 を含む { "message" } エラーは、Accept が application/json または */* の場合に JSON になります。Accept がない場合、または text/html の場合、これらのステータスは HTML ページ(Content-Type: text/html)となり、JSON パーサーが失敗します。 これは Accept ヘッダーを送信しないクライアントで問題になります。Python の urllib もその 1 つです。curl はデフォルトで Accept: */* を送信し、Node の fetch も同様であるため、Accept を上書きしない限り、どちらも JSON を受け取ります。 認証されていない POST /generate/...、GET /jobs/{id}、GET /styles、GET /assets は、*/* と application/json では 401 {"message":"Unauthorized"} を返し、Accept がない場合や text/html の場合は HTML ページを返します。認証済みの GET /jobs/{id} で存在しない ID を指定した場合も、ステータスについて同じ挙動になります。Accept で JSON を要求すると 404 JSON {"message":"Job not found or unauthorized"} が、Accept がない場合は 404 text/html が返されます。 無効な JSON(400)とバリデーション(422)は { "error" } を使用し、Accept がない場合でも JSON のままです。削除されたフィールドによる 422、サンセットによる 410、Zero Data Retention の 402、ノードアプリの { "error" } レスポンス、そしてマッピングされた Agent オペレーション API のエラーも同様です。POST /generate/... のジョブ受け付け時に返される 402 と 429 も、ブラウザの Accept の場合を含めて JSON です。 413 と 500 は { "message" } を使用し、401 や 404 と同様に Accept に従います。

バリデーション(422)

details にはすべての問題が列挙されます。field はパスを . で連結したものです("image_style_references.0.url")。オブジェクトレベルのエラーでは、上記の不明なキーのように空文字列が使われます。複数の不明なキーがある場合は Unrecognized keys: ... となり、field は同じく空になります。expected は code が "invalid_type" の場合にのみ追加されます。 無効な X-Webhook-URL ヘッダーにも、これと同じ 422 が使われます。 無効なクエリパラメータを指定した GET /jobs も、この 422 を返します。400 ではありません。 ツール内部で Zero Data Retention の入力チェックに失敗した場合は、message に説明を含む 422 が返されます({ "message" } 形式のため、Accept が影響します)。詳しくは Zero Data Retention を参照してください。

削除済みおよび非推奨のフィールド(422)

削除された batchSize / batch_size フィールドには、別の 422 が使われます。details 配列はありません:
batch_size も同じように削除されています。field には送信した方の名前が入ります。 非推奨のフィールドエイリアスでは、reason に "deprecated_field" または "conflicting_fields" が使われ、該当する場合は replacement、sunset_date、migration_url も含まれます。error と reason で分岐してください。ユーザーに表示する文は message です。

サンセットされたモデル(410)

サンセット日を過ぎたモデルは、Deprecation: true と Sunset ヘッダー(RFC 1123 形式の日付)を付けて 410 を返します:
error は固定値 "model_unavailable" です。推奨される代替モデルがない場合、replacement と migration_url は省略されます。同じモデルでリトライしても 410 が返され続けます。replacement が設定されている場合はそちらに切り替え、非推奨情報 を参照してください。 非推奨ではあるもののまだ利用可能なモデルは、エラーを含むすべてのレスポンスで Deprecation と Sunset を送信します。非推奨のフィールドエイリアスを使用した場合も、その 422 を含めて同様です。移行ガイドが存在する場合は、Link: <migration_url>; rel="deprecation" ヘッダーも送信されます。

ステータスコード

400

generate での無効な JSON は、Accept ヘッダーがなくても常に JSON です:
ノードアプリの execute では、使用できない入力 URL に対して { "error" } を使用します:Invalid URL for input "<key>"、または Failed to download URL for <key>: … です。このダウンロードのメッセージは一時的な失敗も含むため、generate(入力のダウンロード を参照)とは異なり、ノードアプリのダウンロード失敗は常に 400 になります。URL が有効であれば、一度リトライしてください。 POST /node-apps/{id}/execute での無効な JSON は、上記の generate の 400 にはなりません。例外のテキストを含まない 500 { "message": "Internal Error" } となり、Accept に従います。 アセットとノードアプリにおけるその他の 400 レスポンスは、短い説明を含む { "message": "..." } です。たとえば、署名付きアップロードでの No file provided や、ノードアプリのバージョンでの Invalid pagination parameters などです。アセットのアップロードに失敗した場合は、アップロードサービスのステータス(400、401、404、500)がそのまま返され、そのレスポンステキストが message に入ることがあります。このテキストは JSON 文字列の場合もあります。GET /jobs での無効なクエリパラメータは 400 ではなく 422 です。

401

generate、jobs、assets、styles、node apps:
署名付きアップロードでは、{ "message": "Presigned upload URL expired" } または { "message": "Invalid presigned upload URL" } が返されます。

402 支払いが必要

API 課金のクライアント(API キー、または API キーを使用する MCP)で、API 残高がジョブの費用に満たない場合:
krea.ai/app/api/ ↗ でチャージしてください。実行中のジョブは最後まで完了します。詳しくは API Keys & Billing を参照してください。 公開 API におけるその他の 402 の message の値: Zero Data Retention が有効になっていないワークスペースで Zero Data Retention を指定して generate を呼び出すと、次のボディが返されます(常に JSON):
Agent オペレーション API は独自の 402 ボディを使用します。こちらは API 残高ではなく、ワークスペースのコンピュート残高を消費します。

403

404

すべての 404 は { "message" } です。たとえば、存在しないジョブ ID の場合:
Accept ヘッダーがない場合、これらは HTML になります。ただし、キーまたはプランで使用できないモデルに対する Endpoint not found は例外で、常に JSON です。認証済みの GET /jobs/{id} で存在しない ID を Accept なしで指定すると、404 text/html になります。 不明な Agent オペレーションも、Agent の { "error", "code" } 形式ではなく、404 { "message": "Endpoint not found" } になります。

405

ボディは JSON ではなく、Content-Type ヘッダーのないプレーンテキストです。Accept が application/json の場合も同様です。テキストはメソッド名に method not allowed を付けたもので、たとえば GET method not allowed です。Allow ヘッダーに、そのパスで受け付けるメソッドが列挙されます。

413 ペイロードが大きすぎる

大きすぎるリクエストボディは 413 で拒否されます。API 自体から返される場合、ボディは Accept に従います:
非常に大きなボディは、API に到達する前に HTML の 413 ページで拒否されることがあります。ファイルをインラインで送信しないでください。POST /assets でファイルをアップロードし、返された URL を generate リクエストに渡してください。

入力のダウンロード

ホストが 404 または 410 を返した場合は、恒久的な 422 になります。ボディは JSON で、Accept が影響します:
ホストが 410 を返した場合も、410 を含む同じ文になります。その他の恒久的な拒否では Input file rejected: … が使われます。 リトライ可能なダウンロード失敗は 502 または 504 です。ボディではなくステータスコードで分岐し、リトライしてください。 同じ URL に対して 502 が繰り返し返される場合は、その URL がブロックされているか壊れている可能性があります。URL を変更してください。 3D エクスポートの変換失敗も 502 です。このパスは実環境では未検証のため、ボディが Cloudflare のプレーンテキスト error code: 502 として届く場合もあります。ステータスコードで分岐してリトライしてください。同じモデル URL に対して 502 が繰り返し返される場合は、その URL がブロックされているか壊れている可能性があります。

429 同時実行数

ジョブをバックログに追加できない場合、同時実行数の上限を超えたリクエストは Content-Type: application/json 付きの 429 で拒否されることがあります:
limit は、この種類のジョブに対するあなたの同時実行数の上限です。ワークスペース単位ではなくユーザー単位でカウントされます。この値はおおよそのものです。短時間のバーストは上限を超えて受理されることがあるため、limit + 1 番目のリクエストが必ず失敗するとは考えないでください。jobType は内部的なジョブのカテゴリであり、公開されているモデルパスではありません。これで分岐しないでください。 Krea 2 では、共有キューが満杯の場合に、limit や jobType を含まない { "message": "CONCURRENCY_LIMIT_REACHED" } のみが返されることもあります。これはあなたの上限によるものではありません。バックオフしてリトライしてください。 バックログが有効になるのは、プランにバックログが含まれ(Pro 以上)、モデルがバックログに対応しており、かつリクエストが Zero Data Retention ではない場合のみです。現在、Krea 2 のリクエストはどのプランでもバックログに追加されないため、上限を超えると 429 が返されます。バックログが有効な場合、追加のジョブは status: "backlogged" として受理され、空きができ次第開始されます。バックログ専用の上限はありません。詳しくは レート制限 を参照してください。 API は Retry-After や X-RateLimit-* を送信しません。レスポンスには cf-ray が含まれます。429 を受け取った場合は、実行中のジョブが完了してから(GET /jobs/{id} をポーリングするか、Webhook を使用)、指数バックオフを用いてリトライしてください。 後から完了したジョブによって残高が尽きた場合、バックログに残っているジョブは error.code "insufficient_balance" で失敗します。これは HTTP の 402 ではなく、失敗したジョブです。これらのジョブは Webhook を送信しないため、バックログに入ったジョブは GET /jobs/{id} でポーリングしてください。

Agent オペレーション API

POST /agent/{operation} と GET /agent/session/{sessionId} は { "error", "code"?, "allowedModels"? } を返します。必須なのは error のみです。allowedModels はキャメルケースです。受理された後に失敗したターンは、これらの HTTP エラーとしてではなく、セッション上の status: "failed" として表示されます。詳しくは Agent を参照してください。 認識されない Agent のエラーコードも、{ "error", "code" } を含む 422 になります。不明なオペレーションによる 404 と処理されていない 500 は { "message" } を使用し、Accept に従います。

失敗したジョブの error.code

GET /jobs と GET /jobs/{id} は、status が "failed" の場合にのみ error を設定します。使用できる result はありません:
error.code で分岐してください。message は絶対にパースしないでください。message は省略されることがあります。provider_error と internal のメッセージは自由形式で、internal のメッセージは failed to download media from the provided URL のようなプロバイダーの生のテキストである場合があります。認識できない code はすべて internal として扱ってください。
失敗したジョブの Webhook 配信では、error を含む同じジョブオブジェクトが使われます。キャンセルの配信には error はありません。256 KiB を超えるペイロードは送信されず、そのジョブについてはそれ以降の配信も行われないため、代わりに GET /jobs/{id} をポーリングしてください。ボディを信頼する前に署名を検証してください。詳しくは Webhooks を参照してください。

デバッグ

Krea 独自のリクエスト ID ヘッダーはありません。ただし、すべてのレスポンスに Cloudflare の cf-ray ヘッダーが含まれます。Retry-After や X-RateLimit-* ヘッダーは送信されません。 support@krea.ai に問い合わせる際は、以下を含めてください:
  • 呼び出しがジョブを作成した、またはジョブを対象とした場合は job_id
  • 日時とエンドポイント
  • リクエスト時のエラーの場合は cf-ray の値
Access-Control-Allow-Origin は * です。generate、jobs、assets、styles、node apps では Access-Control-Expose-Headers が設定されていないため、ブラウザの fetch では cf-ray、Deprecation、Sunset を読み取れません。cf-ray はネットワークログ、またはサーバーサイドのクライアントからコピーしてください。 モデルが呼び出しを受け付けなくなる前に気付けるよう、すべてのレスポンスで Deprecation と Sunset を確認してください。詳しくは 非推奨情報 を参照してください。

次のステップ

ジョブライフサイクル

ジョブが完了、失敗、またはキャンセルされるまでステータスをポーリングする

Webhooks

失敗したジョブの配信で署名を検証する

レート制限

追加のジョブがバックログに入るケースと 429 が返されるケース

API Keys & Billing

402 を受け取った後に API 残高をチャージする