Webhooks

Incoming vs. outgoing

"Webhook" usually means two unrelated things people conflate: a URL you give to someone else so they can notify you (incoming), and a URL you call yourself to notify someone else (outgoing). Fimaflow keeps them as separate nodes — Webhook is always the receiving end; calling out uses the same API node you'd use for any HTTP request.

Receiving a webhook

A Webhook node is an entry point, just like an API Endpoint — pick a webhookMethod and, optionally, a webhookSecret used to verify the sender. It gives you a stable, public URL to hand to GitHub, Stripe, or whatever third party is going to push events at you. Connect it to whatever should happen when the event arrives.

Because it's a normal entry point, everything else you know about running and debugging a workflow applies the same way — see Execution.

Verifying the sender

A public URL means anyone who finds it can POST to it — the webhookSecret is what tells you whether a request actually came from the service you expect. Keep it in an Environment Variable rather than hardcoding it on the node — it's masked in logs like any other secret, and easy to rotate without touching the workflow itself. If you need to verify a provider's signature format directly rather than a simple shared secret, do it explicitly with a Code node right after the Webhook node, before anything else runs.

Calling out to another service

To notify an external system instead — post a message to Slack, forward an event to another API — use the API node (also called HTTP Request) anywhere in your workflow. Point it at the target URL, pick a method, and connect whatever data should be sent.

API Endpoint  (POST /orders)
   ↓
SQL           (INSERT INTO orders ...)
   ↓
API           POST https://hooks.slack.com/services/...
              body: { text: "New order: {{sku}} x{{qty}}" }
   ↓
Response      201 { orderId }

A failed outgoing call behaves like any other node failure — connect it to a Try/Catch if the notification shouldn't block the response the caller is waiting on.

Interactions with the rest of the platform

• • A Webhook node's payload flows through Database and Transform nodes exactly like any other input.
• • Once deployed, a webhook keeps working the same way in Runtime — the URL doesn't change between preview and production, only the environment variables it resolves against do.

Limitations

• • The Webhook node's URL is tied to the workflow — duplicating a workflow gives you a new URL, so update any third-party webhook registration after duplicating.
• • There's no built-in retry for a failed outgoing API call — wrap it with a Retry node if the target service is expected to be occasionally unavailable.