error_code; the original
provider code stays in error_params.upstreamCode. The HTTP status and existing
error envelope are preserved. Unknown codes keep
provider.request_failed, with the original code and a usable detailed explanation.
Descriptions prefer upstream detail, then message, then title.
Explicit authentication credentials and internal accounting values are redacted.
Accounting includes upstream balances, reservation amounts, costs, prices,
credits, markup, and multipliers. The reason for a failure, parameter names,
input limits, request IDs, and business URLs remain available. Business download
and session query parameters retain their original encoding; URL usernames and
passwords are removed. Empty, non-text, HTML, or non-JSON explanations fall back
to a generic message. Other providers keep their existing policies.
Upstream account, balance, permission, and configuration errors are operational
issues for GENGEN administrators. API users should contact GENGEN support;
adding funds to their GENGEN wallet does not resolve upstream account errors.
Error codes
The HTTP column is the upstream reference status, not a rule for rewriting responses. For example, a successfully retrieved failed task still has HTTP 200.Request errors
An upstream balance rejection keeps HTTP 402 and is distinct from a GENGEN wallet rejection usingseedance.insufficient_balance.
Asynchronous task failures
The official asynchronous task guide places failures inerror.error_code; model OpenAPI definitions also use
task_info.error.code. GENGEN reads both, including their title and detail.
Common terminal codes are 3001-3005, 4002, and 4008.
A task lookup returns HTTP 200 with status: failed, a detailed failureReason,
and an optional structured error containing the mapped code, original
upstreamCode, and sanitized message. Successful and pending tasks do not
receive a manufactured failure object. The standard fields remain first.