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 lives in.

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. The usual way to act on those edits in Stripe is to wire Zapier against Notion on a polling schedule, pay per task, and accept a few minutes of latency between checkbox-flip and refund-fired.

The Inbound Notion trigger handles the watching for you. Inbound subscribes to changes on the databases you allow, dedupes on the row id plus the last-edited timestamp, signs the trigger payload, and fires the matched Stripe Workflow with the full row available via JSONata. The ops team flips a checkbox in Notion; engineering sees a refund issued and a customer email sent from one workflow with one execution log.

How the Notion trigger 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 watches the database for changes (using Notion webhooks where available and a short-interval poll otherwise — typical detection latency is 5–15s). Configure which property change should fire the trigger: an Approved checkbox flipping true, a 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 OutboundPer-task billing
Signed + dedup on Notion row id—
Detection latency5–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 waitlist

Frequently asked questions

How does Inbound watch the database — webhooks or polling?+
Both, depending on what Notion exposes for the database in question. Where webhooks are available, Inbound subscribes; otherwise it polls at a 5–15 second cadence. From the workflow's perspective the trigger semantics are identical — only the detection latency floor differs.
What's the latency from edit to workflow fire?+
On webhook-enabled databases, typical end-to-end latency is under a second. On polled databases it is the poll interval plus a few hundred milliseconds for change detection — roughly 3–8 seconds. Both are fine for refund approvals; neither is great for sub-second use cases.
How does Inbound avoid firing on the same edit twice?+
Inbound stores a per-row last-edited timestamp from Notion. Only rows whose timestamp moved forward are considered, and the dedup key (row id + edited_time) drops any duplicate that slips through. Webhook retries and polling overlap are both handled by the same key.
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