Skip to main content

Custom Webhook

The custom webhook is the escape hatch. If a system can send an HTTP request, it can start a Flowera flow — no built-in integration required.

The node reference lives at Custom webhook trigger.

When to use a custom webhook​

Reach for it when the thing you want to connect isn't Instagram, WhatsApp, or Zoho:

  • Form builders — Typeform, Google Forms, your own contact form.
  • Other messaging platforms — Telegram, Slack, a custom in-app chat.
  • Your own backend — an order was placed, a subscription lapsed, a ticket was opened.
  • Automation platforms — Zapier, Make, n8n, as the last step of one of their scenarios.
  • Anything with an "outgoing webhook" setting, which by now is most SaaS products.

If the other side can't send HTTP but can be polled, use a Scheduled Run with an HTTP node instead.

Mapping the incoming payload​

Flowera gives each webhook a unique URL. Whatever JSON arrives at that URL becomes available to the flow, and you pull the fields you care about into named flow variables.

The practical loop is:

  1. Add the webhook trigger and copy its URL.
  2. Send one real request from the source system.
  3. Open the execution and read the payload Flowera actually received — not the one the vendor's docs promised.
  4. Map the fields you need, using the real names.

Step 3 is the one people skip. Payload shapes drift between plans, API versions, and event types; reading the real thing takes a minute and saves an afternoon.

Verification methods​

An open webhook URL is a URL anyone can call. Flowera supports the verification schemes real systems use, so only genuine requests get through:

MethodUse when
NoneLocal development only — never in production
HMAC signature (SHA-256, SHA-1, SHA-512)The sender signs the body with a shared secret. The most common scheme, and the best default
JWTThe sender includes a signed token
Bearer tokenA fixed secret in the Authorization header
Basic authenticationUsername and password
Custom headerA named header must match a fixed value
Query parameterA named query parameter must match a fixed value
ED25519 signatureThe sender signs with an ED25519 key (Discord, among others)

Full configuration for each is on the Custom webhook trigger page.

warning

"None" exists so you can get a flow working before wiring up secrets. Anything left on None in production can be triggered by anyone who learns the URL — and every run costs credits.

Recipe: trigger a flow from your own system​

Turn a lapsed subscription into a save attempt:

  1. Start — custom webhook, HMAC SHA-256 verification with a secret your backend knows.
  2. Your billing system POSTs { "email": "...", "plan": "...", "reason": "..." } when a subscription lapses.
  3. Condition — was it a payment failure or a deliberate cancellation? They deserve different messages.
  4. Agent — write the message, using the plan and reason.
  5. HTTP node — hand it to your email provider, or Tool (WhatsApp) if you have the number.

Limits and gotchas​

  • The URL is a secret. Anyone who has it can call it. Rotate it if it leaks.
  • Verification is per webhook, not per workspace — a flow with several webhooks can use a different scheme on each.
  • Sessions come from the payload. If you want repeat requests about the same customer to share memory, map a stable identifier (a customer ID, an email) into the session. Otherwise every request is a stranger.
  • Retries happen. Many systems resend a webhook if they don't get a fast response. Make the flow safe to run twice, or dedupe on an ID from the payload.
  • Test before you point production at it. The trigger page explains how to send a test request from inside Flowera.