HTTP Request
Call an external API or service and pass the response back into your workflow.
Audience
Creators building and publishing workflows.
Overview#
HTTP Request makes a network call from inside your workflow: fetch public data, send structured payloads, or integrate with another system.
Edgaze applies URL and network policy checks, but the creator remains responsible for the destination, data sent, authentication, and retry safety.
HTTP Request
Ports#
- Input: Request: Optional upstream payload: a URL string or an object with URL, headers, and body.
- Output: Success: A 2xx response object containing status, status text, headers, and data.
- Output: Error: The same response shape for non-2xx HTTP responses. Network, DNS, policy, and timeout failures still fail the node.
Inspector#
- URL: Endpoint when nothing is connected, or as fallback alongside connected input.
- Method: GET, POST, PUT, PATCH, or DELETE.
- Allowed Hosts: Comma-separated allowlist; when set, only those domains are permitted.
- Denied Hosts: Comma-separated blocklist for unsafe or internal targets.
- Require idempotency: Enable for retry-safe POST, PUT, or PATCH writes.
- Idempotency key: Stable key required when idempotency is on.
- Follow Redirects: Whether to follow HTTP redirects.
- Headers and query parameters: Structured name/value rows. Use
{{credential.NAME}}for secret values. - Body: Validated JSON or plain text.
- Credentials: None, runner-provided for one run, or encrypted creator-shared credentials. Secret values never enter the graph.
Tips#
- Prefer HTTPS public endpoints and restrict hosts when you know the target domains.
- Treat POST, PUT, and PATCH carefully; enable idempotency when retries could duplicate writes.
- Connect a structured object upstream when headers or body vary per run.
- Test with realistic payloads before you publish.
Related#
Was this useful?
Your response helps us improve the documentation.