Outbound
Generic webhook trigger — Inbound preview

Trigger Stripe Workflow from Webhook endpoints

A signed, deduplicated HTTPS POST from any external system kicks off a Stripe Workflow. The generic Inbound trigger, for systems that don't have a named integration yet.

Join the waitlistBrowse integrations

Inbound is in early access — join the waitlist for early invites.

The problem

There will always be one service without a named Inbound integration: an internal admin tool, a vendor's webhook, a teammate's side project, a cron job somewhere. Today, plumbing one of those into a Stripe action means standing up a webhook receiver, verifying the signature, deduping on something, and calling Stripe's API. All hosted, monitored, and patched by you.

The generic Inbound webhook trigger does this natively. You get a signed URL scoped to your Stripe account. External systems POST JSON to it with an HMAC signature header. Inbound verifies the signature against the shared secret you configured, dedupes on a JSONata-extractable id from the body, and fires the matched Stripe Workflow with the full payload available to the downstream steps. Retries follow Stripe Workflows' own semantics, so the workflow sees exactly-once delivery. Inbound is pre-launch and waitlist signups get sandbox access first.

How the generic webhook trigger works

  1. 1

    Provision an inbound endpoint

    When Inbound ships, you'll click New Inbound Trigger in the dashboard. We mint a unique HTTPS URL scoped to your Stripe account, generate a shared secret, and show you both. Configure the source system to POST to that URL with the secret as an HMAC signature.
  2. 2

    Configure dedup + signature

    Pick the signature scheme (HMAC-SHA256 over the raw body, or matching Stripe's signature shape if the source already speaks that). Set the dedup key as a JSONata expression against the payload — usually an event id field. Same id twice in a window means one trigger.
  3. 3

    Match payloads to workflows

    Inbound surfaces the full payload to the Stripe Workflow context. The workflow's filter step decides whether to fire — by event type, by tenant, by amount. Multiple workflows can match a single inbound event if you want a fan-out.
  4. 4

    Audit everything

    Every inbound POST shows up in the execution log with signature pass/fail, dedup result, matched workflows, and the downstream actions' outcomes. When something doesn't fire, the log shows exactly why.
# External system POSTs to your Inbound URL
curl -X POST https://inbound.outboundforworkflows.com/v1/in/acme_abc123 \
  -H "Content-Type: application/json" \
  -H "X-Inbound-Timestamp: $(date +%s)" \
  -H "X-Inbound-Signature: $(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$SECRET" -binary | xxd -p -c 256)" \
  -d '{
    "event_id": "evt_847",
    "type": "refund.requested",
    "customer_email": "a@acme.com",
    "amount": 4900,
    "reason": "product defect"
  }'

Example workflow configuration

Mock-up of the generic Inbound webhook config inside the Stripe Dashboard. Shows a newly-minted signed webhook URL with a copy button, a shared-secret field with reveal toggle, a signature-scheme selector, a JSONata input for the dedup key, and a live deliveries table with signature-status, dedup-status, and matched-workflow columns.

Inbound (pre-launch): the generic trigger for everything that isn't on the named-integrations list.

Outbound vs custom webhook handler

Outboundcustom webhook handler
Hosted infrastructure to maintain—
Signature verification built-inyou build it
Idempotent + dedup windowyou build it
Setup time≈5 minutes (when live)Half a day to a week
Direct chaining into Stripe + Outbound actionsyou build it
Pricing modelBundled with OutboundHosting + dev time
Available todayPre-launch — join waitlist

Frequently asked questions

What signature schemes are supported?+
HMAC-SHA256 over the raw body is the default, with the signature in X-Inbound-Signature and the timestamp in X-Inbound-Timestamp. We also support the Stripe-style signature header shape so existing webhook senders can reuse signing code. Bring-your-own-scheme is on the roadmap.
How does the dedup window work?+
You configure a dedup key (a JSONata expression against the payload, e.g., {{event_id}}) and a window (default 24h). Inbound stores the keys it has seen in that window and drops repeats with a 200 OK. If the source legitimately sends two distinct events with the same id, change the key.
What if my external system can't sign requests?+
Then don't use the generic trigger. Use a named integration that handles signature on the source side (Linear, Typeform, Airtable). Inbound rejects unsigned requests by default. You can disable signing for testing, but production endpoints must be signed — no exceptions.
How is this different from Stripe's native webhook endpoints?+
Stripe's webhook endpoints are for Stripe to push events to you. This is the inverse: an external service pushes an event to Stripe Workflows. Different direction, different trust model. Inbound provides the signed receiver and the dedup layer Stripe's own endpoints already give you for outbound events.
Is there a rate limit?+
Yes — generous, but real. 100 requests per second per endpoint, 10,000 per hour. Above that, we 429 with a retry-after header, same as any well-behaved API. Talk to support if you need a higher limit; we can lift it for verified accounts.

Related integrations

Trigger Stripe from Linear

The named Linear integration handles signature and dedup with no config — use it when you can.

Stripe webhook to any URL

The mirror image, available today: outbound HTTPS requests from Stripe events to any URL.

Write Stripe events to Postgres

Pair with an inbound webhook: external system POSTs, workflow writes to your own database.

Be first when Inbound ships

Join the waitlistBrowse integrations