Skip to main content

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.
Always keep a fallback rendering path: a 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 returns 200 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:
The response contains token and expiresAt. Send the token on the Runner request:
Tokens live 15 minutes and are scoped to the company that owns the Workflow. A missing, expired or out-of-scope token returns 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_code column 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 carries x-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.