HTTP Request

Conversion Operation

HTTP Request is a widget flow node that allows you to make HTTP requests to external APIs and services.

Description

The HTTP Request node enables your widget to communicate with external services, APIs, or webhooks. This is useful for integrating with third-party services, fetching data from external sources, or sending data to external systems.

Configuration

Method

Method – the HTTP method to use for the request. GET, POST, PUT, PATCH, DELETE are supported.

URL

URL – the destination URL for the request. You can use context values and secrets in the URL to make it dynamic. Only HTTP and HTTPS protocols are allowed. However, HTTP protocol is not recommended.

Body

Body – the request body for POST, PUT, and PATCH requests. You can use context values and secrets in the body.

Headers

Headers – custom HTTP headers to include with the request. Each header has a key and value. You can use context values and secrets in header values.

Sync

Sync – when enabled, the widget flow waits for the HTTP request to complete before continuing. When disabled, the request is made asynchronously and does not affect flow execution in case of error.

Timeout

Timeout – the maximum time to wait for the response in seconds. Maximum allowed timeout is 15 seconds.

Response Map

Response Map – a mapping of response data to context values. This allows you to extract specific fields from the response and make them available to subsequent nodes.

By default, when you receive a JSON response for example

{
    "hello": {
        "world": "widged"
    }
}

the entire response is stored in a context value as a stringified JSON. You can create a response map to extract only the data you need. For example with a response map set to hello.world, you will get widged.

To access array elements, you can use either of the following forms: a.b[0] or a.b.0.

WARNING

Response map is only supported for JSON responses.

Cross origin data safety

We allow you to use context values in URLs for flexibility, but you should keep in mind that making the origin dynamic is generally a BAD IDEA. The origin of a URL is the part before the path — for example, the origin of Widged is https://widged.io.

Imagine we have a URL with a dynamic origin. This would mean any origin could be substituted in place of the context value, allowing data intended for you to be sent to another server. This is especially dangerous if you attach secrets to your request.

We strongly recommend that you do not make the origin of your URL dynamic, and we disclaim any responsibility for potential leaks.

Why do we allow dynamic URLs at all? Because the use case where only the path is dynamic is perfectly valid, and we don’t want to limit you unnecessarily.

Remember:

{{1.origin}}/users/123        // ❌ Bad — dynamic origin
https://my-server.com/users/{{1.id}}   // ✅ Good — static origin with dynamic path

Limitations

Name	Value
Max headers count	50
Max header name input length	128
Max header value input length	2048
Max compiled header value length	2048
Max URL input length	2048
Max compiled URL length	2048
Max body input length	10240
Max compiled body length	10240
Max timeout	15 seconds
Max response map input length	2048
Inputs	Exactly one
Outputs	Exactly one

Context values

• If sync is enabled, this widget flow node provides one context value result which contains either the full response (if no response map is set) or the mapped response using the response map;
• If sync is not enabled, nothing provided.