Order processing errors

This page covers orders that Relu accepted successfully but that later reached main_job.job_status: "Failed". For non-2xx responses while calling the API, see API errors and retries.

When an order fails, the response carries a few fields you can surface to your users.

What to show to your users

Two fields are designed for you to render directly in your UI:

• main_job.display_title — short headline (e.g. "Couldn't read input files")
• main_job.display_message — fuller human-readable explanation

A flag tells you whether the failure is something the user can fix:

• main_job.is_user_error — true when the failure is caused by user input (invalid files, missing inputs, validation errors). false for unexpected internal failures. Use it to colour the badge differently — a "User error" warning vs. a generic "Error".

Both display_* fields can be null. Always fall back to a generic "Order failed, please try again" message if they're missing.

{
  "id": "...",
  "main_job": {
    "job_status": "Failed",
    "display_title": "Invalid mesh",
    "display_message": "The uploaded lower jaw file could not be read as a valid 3D mesh. Please check the file format.",
    "is_user_error": true
  }
}

Examples

A few representative pairs you'll see in the wild:

Keep your UI flexible — Relu adds new classified errors over time. Render the display_title and display_message verbatim and use is_user_error to pick the visual treatment (warning vs. system-error styling) rather than branching on specific titles.

Per-output-file errors

When some outputs succeed and others fail, each entry in output_files has its own status and may carry a per-file error message:

{
  "output_files": [
    { "name": "lower_jaw_model", "status": "Available", "download_url": "..." },
    { "name": "upper_jaw_model", "status": "Failed", "error_message": "..." }
  ]
}

Surface the per-file message to the user when only part of the order succeeded — it's usually more specific than the order-level display_message.

Webhook callbacks on failure

The order.job_status callback fires for terminal states including Failed. Fetch the full order with GET /orders/{id} (no extra flags needed) to read display_title, display_message, and is_user_error. See Callbacks for the full delivery model.

Platform-wide failures

If failures arrive in bulk rather than for a single order, check Service status before digging into your integration. If the API itself returns a non-2xx response, follow API errors and retries.