HTTP error handling ​

The HTTP connector surfaces enriched error data that helps you identify, manage, and resolve issues when a request fails. It displays the HTTP status, a standardized error message, and structured response details such as headers and body. These details improve clarity and support automation. This feature currently applies to the HTTP connector.

How to view the error message ​

The connector raises an error when the Send request action receives a non-2xx response.

The job report's Error tab displays the following:

• A structured error message
• HTTP response status
• Response headers
• Response body (when applicable)

Each value appears in a dedicated field. You can use these in Monitor blocks, logs, or other error-handling logic.

HTTP connector error datapills for Monitor and On error blocks.

Error structure ​

The HTTP connector includes the following fields in job errors:

HTTP error categories ​

The HTTP connector raises an error for non-2xx responses. This includes 3xx HTTP redirection errors, 4xx client errors, and 5xx server errors.

HTTP errors returned by the connector follow structured error_type_id patterns based on HTTP status code classes. This structured catalog of HTTP error type IDs is currently supported only by the HTTP connector.

You can use error_type_id prefixes in Monitor or On error blocks to group related HTTP failures.

The Retry succeeds column indicates whether the same request may succeed if the recipe retries the request without modifying the parameters. This applies to the following tables in this section.

HTTP redirection error type IDs ​

The HTTP connector returns the following error_type_id values for HTTP 3xx responses:

HTTP client error type IDs ​

The HTTP connector returns the following error_type_id values for HTTP 4xx responses:

HTTP server error type IDs ​

The HTTP connector returns the following error_type_id values for HTTP 5xx responses:

Successful HTTP response codes treated as errors ​

The HTTP connector may treat certain successful HTTP responses as errors for backward compatibility.

These responses use successful HTTP status codes but may still surface as errors in the HTTP connector.

Unsupported RFC HTTP response codes ​

The HTTP connector may return fallback error_type_id values when it receives an HTTP status code that doesn't map to a supported RFC-defined response code. These identifiers represent unsupported or non-standard HTTP response codes:

Structured HTTP error output ​

The HTTP connector returns a structured error object you can use for debugging, filtering, and automation. This object includes fields such as the HTTP status code, response body, headers, and a machine-readable error type ID. For example:

{
  "error_type_id": "err.http.response.client_error.not_found",
  "error_type": "Not Found",
  "error_id": "ad6a...b3c",
  "error_message": "HTTP 404 error",
  "http_response": {
    "code": 404,
    "status_text": "Not Found",
    "body": "{\"error\": \"Resource not found\"}",
    "headers": {
      "Content-Type": "application/json"
    }
  }
}

You can access this structured error data through the following:

• Job reports
• Monitor blocks (error datapills)
• On error blocks (error datapills)

Workato recommends using error_type_id for automation. This field is stable and supports reliable programmatic checks.

Best practices for error handling ​

Use error_type_id and http_response fields in Monitor or On error blocks to build reliable recipes:

• Catch and handle specific errors using error_type_id
• Retry requests based on HTTP status codes or response headers
• Send structured error data to logs or alerting systems

These fields eliminate the need for string parsing or fragile pattern matching.