Feature · Event-Driven Automation

Event-driven automation that treats delivery guarantees as a design decision.

Event-driven automation tools are judged on what happens when the event fires at 3 AM and nobody is watching. Does the retry policy actually retry? Does a transient failure in step 7 leave the flow in a half-complete state? Does the dead-letter queue exist, and can on-call find it? Strkr ships event-driven automation with declarative triggers on record events, webhook ingress with signature validation, retry policies with exponential backoff, dead-letter handling, idempotency keys on side-effect calls, and a run page the on-call opens from the alert.

Start free trial See pricing
What event-driven has to cover

The eight capabilities a real tool needs.

Event-driven automation is 20% firing the flow and 80% handling the failure modes. The capabilities below are what separates a tool that holds up for a year from one that gets ripped out after the first production incident where the retry policy did not retry.

Declarative triggers

Record events, webhooks, schedules.

Triggers are declarative: record events (create, update, stage change), webhook ingress (with signature validation), scheduled events (cron, recurring, delay from a timestamp), and external events (Stripe, Slack, inbound email). The trigger is defined in the flow, not hidden in a global config.

Signature validation

Webhooks require HMAC on ingress.

Webhook ingress validates the HMAC signature from the sender (Stripe webhook signature, GitHub HMAC, custom shared secret). Unsigned or wrong-signature requests are rejected at the edge. The common failure where a malicious caller fires the "refund" flow with a crafted payload does not happen.

Retry policy

Exponential backoff, max attempts, jitter.

Transient failures retry with exponential backoff and jitter. Max attempts is configurable per node. A 500 from Stripe at 3 AM retries at 1s, 2s, 4s, 8s and then dead-letters. The retry is at the node level, not the whole flow, so a successful step 1 does not re-run on retry of step 7.

Idempotency

Side-effect calls carry idempotency keys.

Side-effect calls (Stripe charge, email send, Strkr Messaging SMS send) carry an idempotency key derived from the flow run ID and the node ID. A retry does not fire a second charge or a second SMS. The common failure where retries cause duplicate side effects does not happen.

Dead-letter

Failed events land where on-call can find them.

Events that exhaust retries land on a dead-letter queue visible on the admin home. On-call can inspect the payload, replay with modified inputs, or discard. The common failure where "the event just vanished" does not happen because the DLQ is first-class, not an afterthought.

Ordering guarantee

Per-record ordering, cross-record parallel.

Events for the same record are processed in order. Events across records are processed in parallel for throughput. The common failure where "the stage update at 10:00:03 somehow processed before the stage update at 10:00:01" does not happen because the per-record ordering is enforced.

Observability

Run page per event with full trace.

Every event opens a run page with the full step graph, inputs and outputs per node, retry attempts, duration, and final state. The on-call opens the run page from the alert and starts debugging. The common failure where "I cannot tell what happened" does not happen because the run page is primary.

Rate limit protection

Downstream calls respect the API budget.

Downstream API calls (Stripe, Slack, HubSpot sync) respect the downstream rate limit. The flow backs off when the downstream throttles. The common failure where a flow fires 10,000 calls at once and gets banned by the vendor does not happen because the rate-limit is at the flow runtime, not the integration author's responsibility.

Where tools differ

Six axes that predict a production incident.

Event-driven tools look fine until a production incident reveals the delivery guarantees were wishful thinking. The axes below are where the real difference lives. A buyer who scores on these axes avoids the "the retry policy did not retry and we lost 400 charges" post-mortem.

Delivery guarantee

At-least-once vs best-effort.

Tools that guarantee at-least-once delivery (with idempotency keys to prevent duplicates) hold up in production. Tools with best-effort delivery drop events silently and the team finds out at the quarterly reconciliation. The guarantee is a design decision, not a nice-to-have.

Retry granularity

Node-level vs flow-level.

Node-level retries re-run only the failed node and preserve the state from successful upstream nodes. Flow-level retries re-run the whole flow, which re-fires every side effect in the upstream nodes. The granularity is the single biggest driver of "did we double-charge the customer during retry."

Idempotency

Built-in vs author-provided.

Built-in idempotency keys on every side-effect call protect against duplicates even on retry. Author-provided idempotency requires every integration author to remember to add the key, and they do not always remember. The default is what matters at scale.

DLQ

First-class DLQ vs log file.

A first-class dead-letter queue with inspection, replay, and discard lets on-call recover from the incident in minutes. A log file DLQ hides the failed events and the team finds them weeks later. The DLQ UX is what gets rated at 3 AM.

Ordering

Per-record vs none.

Per-record ordering guarantees prevent the race condition where two updates arrive in reverse order. No-ordering tools require the author to handle the race, which they rarely do. The ordering guarantee is a design decision; it is not something a flow author can patch over.

Rate limit

Runtime-enforced vs per-flow custom.

Runtime-enforced rate limiting respects downstream limits automatically. Per-flow custom rate-limiting requires every author to implement the backoff themselves. The runtime approach survives at scale; the custom approach does not.

What Strkr ships for event automation

The event surface, in detail.

Declarative triggers on record events, webhooks, schedules. HMAC signature validation on webhook ingress. Node-level retry with exponential backoff and jitter. Built-in idempotency keys on every side-effect call. First-class DLQ with inspection and replay. Per-record ordering guarantee. Runtime rate-limit against downstream APIs. Run page per event. Flat $50 per seat with no per-event meter.

Trigger catalog

Record, webhook, schedule, inbound email.

Triggers cover record events (create, update, stage change, field change), webhook ingress (with signature validation), scheduled events (cron, delay, recurring), inbound email (Mailgun, SendGrid, SES), and Stripe events (signed natively). Each trigger is a declarative rule, not code.

Signature validation

HMAC on every webhook.

Webhook ingress validates HMAC on every request. Shared secret is configured per webhook and encrypted at rest with KMS. The common failure where someone discovers the webhook URL and starts firing crafted payloads does not happen because the signature is required.

Retry policy

Node-level backoff with jitter.

Retries are node-level with exponential backoff and jitter. The default policy is 1s, 2s, 4s, 8s, 16s with jitter. Each node can override. State from successful upstream nodes is preserved; only the failing node re-runs.

Idempotency

Built-in on every side-effect node.

Idempotency keys are automatic on Stripe charge, email send, Strkr Messaging SMS, HTTP POST, and inbound provisioning calls. The key is derived from the flow run ID and the node ID, so a retry hits the same key and the vendor dedups. No author work required.

DLQ

Inspect, replay, discard.

The DLQ lives on the admin home with filters by flow, by date, by failure reason. On-call clicks a dead-lettered event, inspects the payload, replays with modified inputs or discards. The DLQ retention is 30 days default, configurable per tenant.

Ordering

Per-record sequential, cross-record parallel.

Events for the same record ID queue in order. Events across record IDs process in parallel. The guarantee protects against the race condition where two stage updates arrive in reverse order and the second one wins incorrectly.

Where teams actually land

Three deployment patterns from real customers.

A SaaS with Stripe billing events, a services firm with inbound email intake, and a healthcare company with HL7-adjacent patient events all run event-driven automation. The runtime guarantees are shared; the trigger shapes flex to the business.

SaaS pattern

Stripe webhooks to CRM state.

A 60-seat SaaS runs Stripe webhook events into CRM state. invoice.paid updates the account health, subscription.cancelled fires the churn save flow, charge.failed opens a support case. Idempotency keys prevent duplicate state transitions on retry.

Services firm

Inbound email to case creation.

A 180-seat services firm runs inbound email events into case creation. support@ emails parse into a case with the sender, the body, the attachment, and the account lookup. The parsing flow deduplicates on message-ID so forwards and retries do not create duplicate cases.

Healthcare pattern

Patient event webhooks under BAA.

A 300-seat healthcare company receives patient events from a HL7-adjacent system via signed webhooks. Each event triggers a care plan update flow under the BAA. PHI routes through the compliant audit path with sealed logs.

Rate limit scenario

Downstream API bans averted.

A 100-seat company fires 10,000 enrichment lookups a day against a third-party API with a 10 req/sec limit. The runtime rate-limit smooths the fan-out to 10 req/sec, retries 429s, and respects the Retry-After header. The common failure where the vendor bans the IP for an hour does not happen.

DLQ recovery

Transient outage recovered in 20 min.

An integration partner had a 15-minute outage. Events during the outage landed on the DLQ after exhausting retries. On-call opened the DLQ, selected all 240 affected events, and replayed them. Full recovery in 20 minutes with zero data loss.

Exit posture

Event history is portable.

Every event, every run, every retry attempt is accessible via the open API. A team that rebuilds the event layer externally can export the full history in hours. The exit cost is measurable.

Event-driven automation that survives production.

Strkr ships event-driven automation with HMAC signature validation, node-level retry, built-in idempotency, first-class DLQ, per-record ordering, and runtime rate-limiting. Flat $50 per seat with no per-event meter.

Start free See pricing
Common questions

What buyers ask about this feature.

What makes a tool event-driven versus just automated?

Automation tools fire flows on triggers. Event-driven tools treat events as first-class messages with delivery guarantees: at-least-once, with idempotency to prevent duplicate side effects, with retry policies that survive transient failures, with dead-letter handling for events that exhaust retries, and with per-record ordering so race conditions do not corrupt state. The difference matters because production incidents happen at 3 AM and the delivery guarantees are what determines whether the team wakes up to a problem or to a recovered DLQ.

How does Strkr handle retries without double-charging?

Idempotency keys on every side-effect node. The key is derived from the flow run ID and the node ID. A retry hits the same key and the downstream vendor (Stripe, Strkr Messaging, Mailgun) deduplicates. Node-level retry only re-runs the failing node; state from successful upstream nodes is preserved. The common failure where a flow retries and fires a second Stripe charge or a second SMS does not happen because the idempotency is automatic, not an author responsibility.

What happens when retries are exhausted?

The event lands on the dead-letter queue (DLQ). The DLQ lives on the admin home with filters by flow, date, and failure reason. On-call inspects the payload, replays with modified inputs, or discards. DLQ retention is 30 days by default, configurable per tenant. Alerts fire on DLQ accumulation (e.g., >50 events in an hour) via Slack, email, or PagerDuty.

Can we rate-limit downstream API calls?

Yes. The runtime enforces rate limits against downstream APIs declared on the integration config. A flow that calls a 10 req/sec API gets throttled to 10 req/sec automatically, respects 429 responses, and honors Retry-After headers. The common failure where a flow fires 10,000 calls at once and gets the IP banned does not happen because the rate-limit is at the runtime, not the integration author's responsibility.

How does ordering work across concurrent events?

Events for the same record ID process sequentially. Events across record IDs process in parallel. If two stage updates arrive for the same opportunity, the earlier one processes first. The guarantee prevents race conditions where two concurrent updates would otherwise produce a nondeterministic final state. For high-throughput workloads, the parallelism across records provides enough concurrency to meet the throughput target.

How is this priced versus per-event event-driven platforms?

Strkr is flat $50 per seat on every tier. Events do not meter per fire, per retry, or per webhook received. Teams that process 10 million events a quarter pay the same per seat as teams that process 10,000. The pricing shape matters because per-event meters penalize the teams that build event-driven architecture, which is the behavior the platform should reward.

Related features

Pair this with...

Automation Workflows API and Webhooks AI Automation Platforms Automation Platforms Automated Workflow Software Automated Workflow Management Automated Workflow Solutions

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing