How the Endpoint Response is Decided

Each task produces its own result and status code, but the endpoint's HTTP response isn't simply the last task's. After the tasks have run, the response is chosen in this order - the first match wins:

1. HTTP Redirect task - the caller is redirected.
2. Task with Retain status code enabled - that task's status code is returned, with the HTTP Response task's body and headers if there is one, otherwise that task's own body.
3. HTTP Response task - its configured status code, body and headers.
4. Otherwise:
   • if Stop on Task Failure stopped the endpoint, the failed task's status code and body.
   • if not, 200 with the results of every task. This includes when tasks failed but Stop on Task Failure is off.

Which tasks count

• Tasks that were never reached, because Stop on Task Failure stopped the endpoint first, are ignored.

• Skipped tasks still count, and return a 200 with a result that says why they were skipped:

  • Disabled by filter - behaviour was not run: one of the task's filters evaluated to false. For JSONPath filters, this means the path didn't match anything in the data.
  • Disabled - behaviour was not run: the task is disabled in the endpoint editor.

  So if a skipped task has Retain status code enabled, the endpoint returns 200, even if an earlier task that ran returned something else. And if the endpoint has no HTTP Response task, these messages appear in the results it returns.

As Stop on Task Failure is on by default, a failing task's status code is usually what's returned - it halts the endpoint before any later HTTP Response task runs.

Other cases

• An endpoint with no HTTP Request, HTTP Response, HTTP Redirect, SMS, Fax or PDF tasks (e.g. only Mapping or Email tasks) always returns the results of every task, even when Stop on Task Failure stopped it.
• If a task raises an error rather than failing (for example an HTTP Response Handler schema validation failure), an error response is returned instead.