Webhook

The Webhook operation delivers an HTTP POST request to an external URL — a fire-and-forget egress notification. It is a dual-role action+trigger: as a leaf in the caller’s path it issues the delivery asynchronously and returns immediately; when the response (or error) arrives, it sets the Success output and fires the downstream trigger path.

Paid plan required

Egress operations (REST API Call, Webhook) are not available on the Free tier. They require a Plus or Pro plan.

With URL empty and the URL input unconnected every delivery fails, and the Editor shows a warning ring on the URL input saying so.

Inputs

Port	Type	Required	Description
> (Gate)	Any	No	When connected, a false or Nil value stops the path. See Gate Inputs.
URL	String	No	Overrides the URL property when connected.
Payload	String | Binary | Map | Array	No	String and Binary as the body’s bytes; a Map or an Array as JSON with Content-Type: application/json. The failure record on an error output wires straight in.

Outputs

Port	Type	Description
> (Trigger)	Boolean	Fires true when a delivery is answered, whether it was delivered or failed; resets to false after the trigger path runs.
Success	Boolean	true when the server returns a 2xx status. A failed delivery writes nothing here, and the Node’s On Error verb decides what a dependent reads. Fallback false. Nil until a delivery writes it.

Properties

Name	Type	Default	Description
URL	TextLine	""	Delivery URL. Must use http:// or https://. Overridden by the URL input when connected.
Payload	TextBox	""	Static POST body. Overridden by the Payload input when connected.
Request Timeout	Duration (seconds)	30 s	Per-delivery timeout. Deliveries that exceed this are treated as transport errors.
On Error	Combo	Stop this branch	Per-op On Error verb (Stop this branch / Continue with the last value / Continue with the fallback). See the Error Handling guide.

On Error governs the answer

A transport error, and any response outside 2xx, is a delivery that did not happen and so this Operation’s failure. It arrives on the follow-on Path this Operation roots: the Path fires, the failure is reported there, and the Node’s On Error verb resolves it — Stop this branch stops the Path at this Node, while Continue with the last value and Continue with the fallback carry a value on to the dependents, flagged as a failed update. See Operations that answer later.

State on Reload

Webhook does not persist state across restarts. In-flight deliveries at the time of a reload are abandoned; the trigger path for those deliveries will not fire.

---

How It Works

1. Gate check — If the Gate input is connected, a false or Nil value stops the execution path; the delivery is not issued.

2. Egress budget check — The per-slot egress budget is checked: rate limit (requests per minute) first, then concurrency cap. If either is exceeded, the delivery is not issued: the Node fails with an Egress: limit exceeded status and no follow-on Path fires that round.

3. Client check — A delivery leaves through the slot’s shared HTTP client. Where the slot carries none, the reservation taken above is returned and the Node fails with an Egress: this slot has no HTTP client, so the request cannot be issued status.

4. Request build — The URL and Payload are resolved (input overrides win over property values). The method is always POST.

5. Async dispatch — The delivery is issued asynchronously. The caller’s execution path ends here; the trigger path is not launched yet.

6. Completion — The answer fires the follow-on Path either way. A 2xx writes Success true on that Path; a transport error or a response outside 2xx reports the failure there instead, and the Node’s On Error verb decides what the Path sees.

---

Egress Limits

Each slot has a shared egress budget consumed by all REST API Call and Webhook operations in that slot — a concurrency cap, a per-minute rate, and caps on request and response size. The budget is checked before the delivery is issued: a delivery that fails either the rate limit or the concurrency cap is never issued, and the Node fails with an Egress: limit exceeded status.

The keys, their defaults, and the values per plan are in the Extras configuration reference. On the Free tier maxConcurrent is 0, which disables egress operations entirely.

---

Destination Safety

Webhook POSTs to whatever the URL resolves to, and that URL can come from the URL input rather than the property — so the destination is not always one you fixed when you built the Task. A delivery also carries a payload, which makes where it lands worth checking.

• The cloud instance-metadata endpoint is refused by default. A delivery whose host is 169.254.169.254, written in any numeric form, or one of its IPv6 forms fails with blocked: cloud metadata endpoint. The extras.egress.allowCloudMetadata key re-allows it for a deployment that genuinely needs it.
• Every redirect hop is checked, not just the URL you typed. The check sits at the connect seam, so a Location that points at a blocked destination is refused on that hop.
• Credentials do not follow a redirect off-origin. A redirect that crosses to a different origin drops credential-bearing headers before re-issuing.
• A header value cannot split the request. CR, LF and NUL are rejected in the method and in every header name and value, so a value fed from a Task input cannot smuggle a second request onto the wire.
• On a hosted slot the deployment blocks private destinations outright, at the kernel, which is what makes it hold for a hostname that resolves to a private address. A station deliberately does not: reaching devices on the local network is why you run one.

A URL from an untrusted source is a destination you did not choose

When the URL input is fed from a webhook payload, a database row, or anything else that crosses a trust boundary, the payload is delivered wherever that value says. Validate it against an allowed host list before wiring it in.

See Destination safety in the configuration reference for the full picture.

---

TLS Verification

HTTPS connections, every redirect hop included, always verify the server against the system CA bundle. The operation has no setting that turns verification off or supplies another CA.

---

Concurrency

Each in-flight delivery owns its own HTTP client. Overlapping deliveries (e.g. from a high-frequency trigger) do not clobber each other: each fires its own trigger path with its own Success value when it completes, in any order. The shared egress budget (concurrency cap above) limits how many can be in flight at once.

---

After a failure

A transport error, or any response outside 2xx, is reported on the follow-on Path, which the completion fires either way, and the Node’s On Error verb decides what that Path sees:

Verb	What the follow-on Path sees
Stop this branch (default)	Fires, and stops at this Node: nothing downstream runs. Success keeps its value, and the attempt reads as failed.
Continue with the last value	Fires. Success keeps its value, not stamped as new; the attempt reads as failed.
Continue with the fallback	Fires. Success carries its Fallback, false by default, stamped as this run’s value — the one-click “fire and report the failure” answer.

---

Use Cases

• Event notification — a sensor reading crosses a threshold; Webhook POSTs a JSON alert to a Slack/Teams/Discord incoming webhook URL.
• CI/CD trigger — a Scheduler fires after a build completes; Webhook kicks off a downstream pipeline via its webhook endpoint.
• Third-party integration — MQTT messages arrive from a device; Webhook fans them out to an external monitoring platform in near-real time.
• Audit trail — a SQLiteStorage write completes; Webhook notifies a central audit log service.

Webhook sets no authentication headers — the only header it writes is Content-Type: application/json, on a Map or Array body — so an endpoint that authenticates with an API key uses REST API Call, which is also how a Task sends email, through your provider’s HTTP API.

---

Notes

• The URL must use http:// or https://. Other schemes are rejected at task-load time.
• The rest of the URL is checked when the delivery is made. The host is a name of letters, digits, -, . and _, a dotted-quad IPv4 address, or an IPv6 address in brackets (http://[2001:db8::1]:8080/). A port is 1–65535. Credentials in the URL (user:password@) are refused, and a #fragment is not sent. A refused URL fails with invalid URL, which does not repeat the URL: its path or query can hold a secret.
• The method is always POST. Use REST API Call if you need GET, PUT, PATCH, or DELETE.
• The static Payload property is stored in plaintext in the task file. Use the Payload input (fed from a SQLiteStorage or JavaScript node) for secrets or dynamic content.
• Webhook does not retry on failure. For retry logic, use a continuing verb (Continue with the last value or Continue with the fallback) and wire the Success output to a Condition + Counter gate that re-triggers the Webhook after a delay.
• The operation is not suitable for very high-frequency triggers (per-message MQTT streams). Batch or decimate with a Scheduler, Counter, or Hysteresis node first.