​

HTTP Request Step

​

Required Fields

​

Optional Fields

​

Response Schema

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "email": { "type": "string" }
  },
  "required": ["name", "email"]
}

​

Common Patterns

• Webhook after notification: POST to "{{payload.webhookUrl}}" with event details in body.
• REST API call: POST / PUT to a fixed URL with subscriber or payload data.
• Data fetch: GET from an external service with responseBodySchema to make response available to subsequent steps.

​

Guidelines

• Never hardcode secrets or API keys — use payload or subscriber variables instead.
• Set Content-Type: application/json header when sending a JSON body.
• Use continueOnFailure: true when the HTTP call is non-critical to the workflow.
• For headers and body: use an empty array [] when not needed. Never include entries with empty keys or values (e.g. [{"key":"","value":""}] is invalid).
• Always define responseBodySchema when any later step references this step’s response.

​

See Also

• step-conditions.md — branch on HTTP response values ({ "==": [{ "var": "steps.<http-step-id>.status" }, "active"] })
• email-step.md — read HTTP response fields from a Block Editor variable node or HTML Liquid expression
• design-workflow/references/workflow-templates.md — templates 8 and 9 show webhook and fetch-then-notify patterns