Sync Stripe subscriptions
Keeps plan, status, revenue and renewal dates on every profile in step with Stripe, so segmentation and churn reporting match billing reality.
Authored by Sid Chaudhary
Founder & CEO at Intempt
Agentic workflow
Coming soon3 steps Blu runs end to end. It drafts a plan and nothing runs until you approve it.
- 1
Hold the billing facts
Coming soonBlu builds a step
- 2
Apply every Stripe event
Coming soonBlu builds a step
- 3
Prove the two agree
Coming soonBlu builds a step
About this recipe
When to use it
Segmentation and retention numbers drift from reality the moment billing state and user profile state fall out of sync. This keeps them synced automatically, event by event.
What it delivers
When Stripe sends a subscription created, updated, cancelled, or payment-failed event, syncs the state to the user profile and account lifecycle stage, so segmentation, retention, and reporting always reflect actual billing reality.
How you prompt this
Describe the outcome in your own words and Blu Agent maps it to this recipe, or run it by name. It drafts a plan first and nothing runs until you approve it.
Tell Blu Agent what you want
“Keeps plan, status, revenue and renewal dates on every profile in step with Stripe, so segmentation and churn reporting match billing reality.”
recipe.md preview
Built from the published catalog. Blu Agent's full step prompts load in your workspace when you run it.
Inputs & outputs
What the recipe needs before it runs, and what it leaves in your workspace.
Inputs
- Nothing declared beyond an Intempt workspace. Blu asks for anything else it needs as it goes.
Outputs
How the recipe runs
Blu follows the steps in order and shows you each one before anything goes live.
- 01Hold the billing factsCreate attributes on the User object: 'subscription_status' (active / trialing / past_due / cancelled / none), 'plan_tier' (free / starter / professional / enterprise / custom), 'mrr' (current monthly recurring revenue), 'subscription_start_date', 'next_renewal_date', 'has_payment_failure' (boolean). Sourced from Stripe events, refreshed on every webhook. These are the source-of-truth fields for lifecycle segmentation.
- 02Apply every Stripe eventCreate a workflow firing on Stripe webhook events. Step sequence: (1) parse the Stripe event payload (Subscription started/updated/canceled/Payment failed/Invoice paid); (2) match to user via stripe_customer_id (create user if doesn't exist: checkout-without-signup case); (3) update all billing attributes; (4) update user lifecycle_stage based on transition: Subscription started to 'customer', Subscription canceled to 'churned', Payment failed to 'at_risk'; (5) emit derived events to the event catalog (subscription_started, subscription_churned, payment_recovered) so journeys can trigger on canonical names not Stripe-specific names; (6) account-level rollup: if this is the only seat on the account and just churned, set account.lifecycle = churned. Use the result of "Hold the billing facts".
- 03Prove the two agreeCompose a billing-data integrity dashboard: % of users with subscription_status synced (against Stripe ground-truth: should be 100%), webhook delivery failure count (signal of integration issues), users with billing-attribute drift (Stripe shows active but profile shows cancelled = sync bug), and MRR computed-from-profile-attributes vs. MRR-from-Stripe-API (should match within 1%). This is the recipe that makes every other recipe's MRR/churn computation trustworthy. Use the result of "Hold the billing facts", "Apply every Stripe event".
Install Intempt and run it
- 1
Sign up
Create a free Intempt workspace.
- 2
Connect your data
Add the sources this recipe reads from.
- 3
Ask Blu
Type /stripe-subscription-sync in Blu once this recipe is live there.
- 4
Review and approve
Blu builds each step and waits for your OK before anything goes live.
