Outbound
Notion trigger — Inbound preview

Trigger Stripe Workflow from Notion database edits

A Notion database edit becomes a Stripe Workflow trigger. Refund approvals, plan changes, churn flags — driven from the doc tool the rest of the team already uses.

Join the waitlistBrowse integrations

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

The problem

Notion is where the non-engineering side of the team lives. Customer notes, refund approval queues, churn flags, account-tier reviews — they all sit in a Notion database somewhere. To trigger stripe workflow from notion today, you wire Zapier to Notion's API on a polling schedule (Notion doesn't natively webhook on row edits yet), pay per task, and accept a few minutes of latency.

Inbound's Notion trigger does this properly. We poll Notion at a tight cadence on your behalf, detect changes to whatever database you point us at, sign the resulting trigger, dedupe on Notion's row id plus its last-edited timestamp, and fire the matched Stripe Workflow with the full row payload. The non-engineering side of the team flips a checkbox in Notion. The engineering side sees a refund issue and a customer email go out from one workflow. No glue script, no Zapier middleman, no second bill.

How trigger stripe workflow from notion works

  1. 1

    Connect Notion via OAuth (one click)

    Reuse the same OAuth connection Outbound uses for the Notion action. When Inbound ships, you'll grant page-scoped access to the databases you want to trigger workflows from. Same workspace, same token.
  2. 2

    Pick a database and a change predicate

    Inbound polls Notion at a 5-15s cadence. You configure which database and which property change should fire the trigger — Approved checkbox flipping true, Status moving to Refund, anything readable on the row.
  3. 3

    Filter and chain in the workflow

    The trigger surfaces the full row via JSONata. The Stripe Workflow filters and chains as usual: stripe.refund.create, outbound.resend, outbound.postgres write-back. The non-engineering team's flip becomes an end-to-end automation.
  4. 4

    Audit + roll back

    Every triggered workflow shows the Notion row id, the property that changed, and the prior/next values in the execution log. If someone flips the wrong checkbox, you can trace it back to the page and the user immediately.
# Inbound webhook config (preview)
trigger:
  source: inbound.notion
  database_id: "a1b2c3d4-..."
  when: "{{ properties.\"Refund Approved\".checkbox = true and not previous.properties.\"Refund Approved\".checkbox }}"
workflow:
  - action: stripe.refund.create
    charge: "{{ properties.\"Charge ID\".rich_text[0].plain_text }}"
    reason: requested_by_customer
  - action: outbound.resend
    to: "{{ properties.\"Customer Email\".email }}"
    template_id: refund_confirmed
  - action: outbound.notion
    database_id: "{{ database_id }}"
    row_id: "{{ id }}"
    properties:
      "Refund Processed At": "{{ $now() }}"

Example workflow configuration

Mock-up of the Notion inbound trigger settings inside the Stripe Dashboard. Shows the existing Notion OAuth connection card reused, a database picker dropdown listing available Notion databases, a property-change predicate editor with a JSONata input, and a recent-deliveries table showing detected Notion row edits with the matched workflows and outcomes.

Inbound (pre-launch): a checkbox in Notion fires a refund in Stripe — one workflow, one execution log.

Outbound vs Zapier

OutboundZapier
Lives inside the Stripe Dashboard—
Pricing modelBundled with Outbound$29.99/mo + per-task fees
Signed + dedup on Notion row id—
Polling cadence5-15 seconds15-60 seconds
Setup time≈3 minutes (when live)15-25 minutes
Direct chaining into Stripe + Outbound actionsvia a multi-step zap
Available todayPre-launch — join waitlisttrue

Frequently asked questions

Why polling instead of true webhooks?+
Notion does not currently expose a webhook API for row edits. Until it does, Inbound polls at a tight cadence (5-15 seconds depending on plan) and detects changes locally. The trigger semantics are the same from the workflow's perspective — only the latency floor differs.
What's the latency from edit to workflow fire?+
Worst case is the poll interval plus a couple hundred milliseconds for change detection and dedup. On Pro the poll interval is 5 seconds, so typical end-to-end is 3-8 seconds. Fine for refund approvals; less ideal for sub-second use cases.
How does Inbound avoid firing on every poll?+
We store a per-row last-edited timestamp from Notion. Only rows whose timestamp moved forward are considered. The trigger predicate filters further. The dedup key (row id + edited_time) drops any duplicate that slips through if Notion's pagination repeats a page.
Will Inbound rate-limit my Notion integration?+
Notion's API limit is roughly 3 requests per second per integration. Inbound polls a database with one paginated request per cycle, so a single database with reasonable change volume stays well under the limit. Polling many large databases simultaneously may need pacing — talk to support.
What if I want to trigger only on edits by specific users?+
Notion's row payload includes a last_edited_by user reference. Use it in the trigger predicate (last_edited_by.id != system-bot-id) to ignore your own write-backs and only fire on human edits. Common pattern for closed-loop workflows.

Related integrations

Trigger Stripe from Airtable

Same shape, true-webhook source. Pick Airtable if real-time matters more than the docs experience.

Stripe to Notion database

The outbound side. Close the loop: Stripe events log to Notion, Notion edits trigger Stripe.

Trigger Stripe from Linear

When the approval queue lives in engineering, Linear is the better trigger source than Notion.

Be first when Inbound ships

Join the waitlistBrowse integrations