HTTP Request

Contextual's outbound HTTP request nodes share a common request runtime for sending HTTP calls and returning parsed responses to the flow.

Use this page as the shared reference for the HTTP GET, POST, PUT, PATCH, and DELETE nodes.

Common inputs

The request nodes share a common set of core inputs:

• retries - number of retry attempts on eligible failures

• output - the message property that receives the parsed response body

• returnType - how the response body should be parsed

• path - the path to call, including path variables when configured

• pathVariables - values substituted into the configured path

• headers - request headers

• query - query-string parameters

Depending on the HTTP method, the node editor may also expose request-body configuration in addition to the shared fields above.

Response handling

Each request writes two kinds of output back to the message:

• the parsed response body to the configured output property

• response metadata to the configured response property

The response metadata includes:

• statusCode

• headers

• responseUrl

• retryCount

Return types

When the return type is set to auto, the runtime parses the response based on content-type:

• application/json -> parsed JSON when possible

• text/* and XML content types -> string

• other content types -> Blob

You can also request explicit string, json, blob, or buffer output.

Retry behavior

The Retries setting applies to network failures and to any response status codes listed in Retry On.

When a retry is triggered, the request runtime uses exponential backoff with jitter between attempts and updates the node status to Retrying while more attempts remain.

The final response metadata includes retryCount, so downstream nodes can tell whether the request succeeded immediately or after one or more retries.

Auth refresh behavior

For connection types that support token refresh, a 401 response can trigger a forced token refresh and one additional retry even outside of the normal retry list. This is separate from the user-configured retry behavior above.

Practical guidance

• only enable retries for calls that are safe to retry or that the remote system can safely de-duplicate

• inspect the configured response property when you need the final status code, headers, URL, or retry count

• keep timeout and retry settings conservative for user-facing HTTP flows so failures surface quickly