Overview
The Runner endpoint is public and mostly consumed by email clients, browsers and server-side integrations. Because a broken response would break the page or the email, most execution problems are not returned as HTTP errors: the Runner degrades to a neutral response.200 response can still carry degraded content (see below).
Failure response body
Failures use the same envelope across the Reelevant APIs.code is the HTTP status, error_code identifies the failure, and data carries the failure payload.
Retry
500 responses with a short backoff. Every other failure is deterministic: retrying returns the same result, so render your own fallback instead.
Degraded responses
Node-level errors never fail the request. The Runner returns200 and serves a neutral response, so a broken Data Node or Datasource does not break the integration.
Detect these cases client-side before rendering:
Click mode
mode=click resolves the destination URL of the executed Branch and redirects to it.
Set
rlvt-redirect to override the destination resolved by the Workflow.
Debug mode
mode=debug returns an HTML execution report (per-Node timings, resolved dependencies, silenced errors, fatal error stack) and mode=ui-debug redirects to the Workflow editor with the same report. Both expose Workflow internals and Datasource outputs, so they require a short-lived debug token:
token and expiresAt. Send the token on the Runner request:
error_code 3501 with HTTP 401.
Execution return codes
Degraded runs are reported on the Workflow event rather than on the HTTP response. Each run emits one event carrying an execution return code, exposed as:- the Execution return code dimension in Data Exploration and dashboards
- the
execution_error_codecolumn of the Workflow events dataset in DataHub
These codes are independent of the HTTP
error_code values above, even though 3501 exists in both sets: 3501 on an event means a fatal execution error, 3501 on an HTTP failure means an unauthorised debug request. HTTP failures (3000, 3500, validation, 500) emit no event at all, so they never appear in analytics.
A degraded run is still counted as a display, so these codes are the way to size the impact of a failing Datasource: group your usual display measures by Execution return code in Data Exploration, or filter the dataset on execution_error_code.
Correlating a failed run
Every response carriesx-rlvt-workflow-run-id. Log it next to your own request id: it identifies the run in analytics and in the debug report, and is what support needs to trace an execution.