HTTP Request FormID 11031

When to Use

• External API integration: Your workflow needs live data from a third-party system — a CRM, payment gateway, ERP, or SaaS platform. The HTTP Request node lets you call any REST endpoint with dynamic headers, body, and URL path segments built from workflow expressions. No custom connector required; any service with an HTTP interface is immediately reachable.
• Webhook delivery: After completing a processing step, you need to notify a partner system, fire a downstream automation in another platform, or push a structured event payload to an external webhook URL. Configure the method as POST, compose the body from workflow variables, and optionally include an HMAC signature header computed via expressions.
• REST API CRUD operations: Your workflow manages records in an external system — creating contacts in a CRM, updating order status in an OMS, or deleting expired sessions in an identity service. Use PUT or PATCH to send targeted updates, with the resource ID interpolated directly into the URL path.
• Internal microservice communication: In a microservices architecture, workflows may need to invoke internal service endpoints — inventory checks, pricing engines, recommendation APIs. Use custom headers (e.g. X-Internal-Token, X-Trace-ID) for service-to-service authentication and distributed tracing correlation.
• Mid-workflow data enrichment: Call an enrichment API such as an IP geolocation service, address validation API, or identity verification provider at the exact point in a workflow where the data is needed. The response is automatically parsed and available as structured fields for downstream logic.

Configuration

Request

Behaviour

Sample Configuration

{
  "Url": "https://api.example.com/customers/{{ $json.customerId }}",
  "Method": "GET",
  "Headers": {
    "Authorization": "Bearer {{ $credentials.externalApiKey }}",
    "Accept": "application/json"
  },
  "TimeoutSeconds": 30
}

Validation Errors

Output

Success Port — 2xx Responses

Routes here when the server responds with a 2xx HTTP status code. All fields below are present on the success port output object.

Error Port — Non-2xx & Network Failures

Routes here for all 4xx and 5xx HTTP status codes, network errors (DNS failure, TCP timeout, TLS handshake error), and validation failures. The node does not automatically retry — implement retry logic using a TryBlock + loop pattern if needed.

Sample Output

{
  "status": "success",
  "statusCode": 200,
  "success": true,
  "body": "{\"id\":\"cust-001\",\"name\":\"Acme Corp\",\"email\":\"info@acme.com\",\"plan\":\"enterprise\"}",
  "content_type": "application/json",
  "content_length": 74,
  "headers": {
    "x-ratelimit-remaining": "94",
    "x-request-id": "req_abc123"
  },
  "parsed_json": {
    "id": "cust-001",
    "name": "Acme Corp",
    "email": "info@acme.com",
    "plan": "enterprise"
  },
  "resource": "http",
  "operation": "request"
}

Expression Reference

Assuming this node is named callApi in the workflow. Replace callApi with your actual node name.

Node Policies & GuardRails

Workflow Examples

Example 1 — Fetch Customer from CRM (GET with Bearer Auth)

Retrieve a customer record from an external CRM API using a dynamic customer ID from the workflow context. The Authorization header is supplied from the Credentials Manager.

{
  "nodeType": "http-request",
  "name": "fetchCustomer",
  "Url": "https://api.crm.example.com/v2/customers/{{ $json.customerId }}",
  "Method": "GET",
  "Headers": {
    "Authorization": "Bearer {{ $credentials.crmApiToken }}",
    "Accept": "application/json"
  },
  "TimeoutSeconds": 15
}

// Downstream expression to read the plan tier:
// {{ $output.fetchCustomer.parsed_json.subscription.plan }}

Example 2 — POST Webhook with JSON Body

Deliver a structured event notification to a partner system's webhook endpoint after completing a fulfilment step. The payload is assembled from multiple workflow variables.

{
  "nodeType": "http-request",
  "name": "notifyPartner",
  "Url": "https://hooks.partner.example.com/events/fulfilment",
  "Method": "POST",
  "Headers": {
    "Content-Type": "application/json",
    "X-API-Key": "{{ $credentials.partnerWebhookKey }}",
    "X-Trace-ID": "{{ $context.workflowRunId }}"
  },
  "Body": {
    "event": "order.fulfilled",
    "orderId": "{{ $json.orderId }}",
    "fulfilledAt": "{{ $now }}",
    "trackingNumber": "{{ $json.tracking.number }}",
    "carrier": "{{ $json.tracking.carrier }}"
  },
  "TimeoutSeconds": 10
}

Example 3 — PATCH Update with Error Handling

Update a record status in an external order management system. The error port connects to an alert node that notifies the operations team on failure.

{
  "nodeType": "http-request",
  "name": "updateOrderStatus",
  "Url": "https://oms.example.com/api/orders/{{ $json.orderId }}",
  "Method": "PATCH",
  "Headers": {
    "Authorization": "Bearer {{ $credentials.omsToken }}",
    "Content-Type": "application/json"
  },
  "Body": {
    "status": "{{ $json.newStatus }}",
    "updatedBy": "{{ $context.triggeredBy }}",
    "note": "Automated update via BizFirst workflow"
  },
  "TimeoutSeconds": 20
}

// On error port — check what went wrong:
// {{ $output.updateOrderStatus.statusCode }}  → e.g. 409 (conflict)
// {{ $output.updateOrderStatus.errorCode }}   → e.g. "HTTP_4XX"
// {{ $output.updateOrderStatus.message }}     → human-readable description

Example 4 — Data Enrichment: IP Geolocation Mid-Workflow

Look up the geographic location of a user's IP address mid-workflow to personalise content or flag suspicious access attempts. Uses a public API with a simple GET call.

{
  "nodeType": "http-request",
  "name": "geoLookup",
  "Url": "https://ipapi.example.com/json/{{ $json.userIpAddress }}",
  "Method": "GET",
  "Headers": {
    "X-API-Key": "{{ $credentials.geoApiKey }}"
  },
  "TimeoutSeconds": 8
}

// Downstream expressions:
// {{ $output.geoLookup.parsed_json.country_code }}  → "US"
// {{ $output.geoLookup.parsed_json.city }}          → "New York"
// {{ $output.geoLookup.parsed_json.is_vpn }}        → false