Trigger workflows from any webhook. Retried and throttled automatically.

Any external system's webhook can kick off a workflow

Point a third-party service's webhook at a younifyd trigger URL and every inbound call runs your workflow — no queue infrastructure to stand up, no listener to host and monitor yourself. The trigger receives the request, enqueues it, and your workflow steps run exactly as they would from any other entry point: parallel fan-out, transformations, connector calls, all of it.

This is the same execution engine behind the visual builder and the AI Assistant. A webhook trigger isn't a separate, thinner code path — it's a first-class way into the same workflow, so anything you can build for an API route you can trigger from an inbound event.

any workflowcan be triggered by an inbound webhook

Retry schedules matched to your workflow's failure characteristics

When a webhook-triggered workflow run fails, younifyd retries it automatically — the maximum attempts and delay between retries are configurable per trigger, not a single global setting. A workflow calling a flaky third-party API can afford a tighter retry window than one feeding a nightly reconciliation job.

Retries use exponential backoff: each attempt waits longer than the last, giving a struggling downstream service progressively more time to recover instead of hammering it immediately after every failure.

per-triggerretry count and delay configuration

Cap incoming request volume before it overwhelms your workflow

A sudden burst of inbound webhook calls — a batch export from an upstream system, a retried flood after an outage — can overwhelm a workflow that wasn't built to absorb a spike. younifyd enforces a configurable rate limit per trigger: set a maximum number of requests within a rolling time window, and calls beyond that limit are rejected before they ever reach your workflow steps.

The limit is set per trigger, not globally, so a high-volume order-sync webhook and a low-volume admin webhook can each have a threshold that matches their real traffic pattern.

per-triggerconfigurable rate limit window

Stop a job mid-execution — it actually stops

Long-running jobs triggered by a webhook — or by anything else — can be cancelled at any point while they're running, not just before they start. Cancelling isn't cosmetic: the execution engine checks the job's status between steps and halts as soon as it sees a cancellation, instead of running to completion regardless.

This matters most when a job was triggered by mistake, is processing against the wrong data, or is simply taking longer than expected and you'd rather stop and investigate than wait it out.

mid-runcancellation — checked between every step

A webhook-triggered run shows up exactly like any other execution

A run that started from an inbound webhook produces the same execution record as one started from an API call or a scheduled job — searchable and filterable by status, path, date, and outcome. There's no separate, thinner log for webhook traffic that you have to check in a different place.

That means debugging a failed webhook-triggered run uses the same execution timeline you'd already reach for anything else on the platform — see exactly which step failed and why, without correlating a webhook provider's delivery log against your own service's logs by hand.

1 timelinefor every trigger type, webhooks included