- HTTP errors come from the Peel host itself, such as a wrong API key, a bad request shape, an API not found, or an endpoint that is not ready.
- Runtime execution errors come from a
:callrequest where the compiled endpoint ran but failed to produce a successful result. These return the same normalized runtime envelope as successful calls. The outer HTTP status usually mirrors the envelope’sstatus_code, so runtime errors can be403,422,429,502,503,504, or another target/upstream status rather than always200. - Build failures appear on
GET /v1/apis/{api_id}when an API hasstatus: "failed"and onGET /v1/apis/{api_id}/healthwhen health returnsstatus: "build_failed". These usefailure_reason_codeplus a structuredfailure.artifact, not the runtime response envelope.
status, status_code, and error_code if the response body is a runtime envelope. Host/setup errors may only include error or code; runtime errors include the normalized envelope. For failed builds, inspect failure_reason_code and failure.artifact on the API detail or failed-health response.
HTTP errors
Runtime error codes
When:call returns a runtime envelope with status: "error" or status: "timeout", the error_code field tells you what happened inside the compiled runtime. These are domain-specific errors: Peel reached the compiled endpoint execution path, but the compiled contract failed to produce data.
Each runtime error also sets the outer HTTP status to the value in the table above, so you can branch on either layer.
Build failures
Errors during build are visible inGET /v1/apis/{api_id} when status is failed. The same failure object is also present in GET /v1/apis/{api_id}/health when that route returns status: "build_failed":
failure_reason_code for compact branching, failure.non_publishable_reason for the stable reason no API was published when one is available, and failure.artifact for support, billing, and retry decisions.
failure.artifact.failure_class normalizes many lower-level codes into stable classes such as captcha_or_botwall, auth_required, unsupported_action, no_matching_data, compile_policy_violation, runtime_verification_failed, build_timeout, and internal_error. failure.artifact.billing_disposition tells you whether the build is not billable, needs refund review, or needs operator review.
Action-flow gates keep publication closed until Peel has compiled a deterministic, policy-checked request sequence. These failures use failure.non_publishable_reason: "unsupported_action" and failure.artifact.failure_class: "unsupported_action".
When the build reaches the custom artifact publish gate, Peel has already compiled a deterministic runtime artifact and is deciding whether it is safe to publish. These failures keep failure_reason_code: "compile_unpublishable_output" and usually normalize to failure.non_publishable_reason: "artifact_publishability_failed". Inspect failure.artifact.technical_reason and failure.artifact.support_debug_id for the precise operator diagnostic:
Response envelope
All:call responses, successful or failed, share the same top-level envelope:
status_code inside the envelope mirrors the outer HTTP status so clients that only surface the body still have the code.
For deterministic replay endpoints, upstream HTTP failures keep their target status and include structured upstream details in data instead of projecting through the endpoint output schema:
data, the envelope also includes a raw_output field: a truncated preview of the upstream response body. Use it to debug extraction_failed and transport_error outcomes:
raw_output is always clipped and is not a substitute for a proper re-parse. When it appears consistently on a previously healthy endpoint, rebuild the API.
When an error means rebuild
Three signals usually point to rebuild as the right action:GET /v1/apis/{api_id}/healthreturnsrecommended_action: "rebuild".error_codeisextraction_failedorendpoint_not_foundon a previously healthy endpoint.- Multiple endpoints on the same API start returning
transport_errorin a short window.