Why Stripe subscriptions do not appear in HubSpot, and what to do about it
Open a Contact or Company record for a paying customer and look for their subscription — plan, status, renewal date, monthly value. On most HubSpot accounts there's nothing there, even though Stripe™ has been billing that customer for months. The cause isn't a broken connection. HubSpot's own first-party Stripe integration can sync subscriptions — but only into Custom Objects, and Custom Objects need an Enterprise hub, a detail stated directly on HubSpot's own listing for the app. Below Enterprise, or without that integration turned on at all, a Stripe subscription has nowhere built-in to live in HubSpot.
Why it happens
HubSpot ships a first-party "Stripe Data Sync" app, built by HubSpot and listed in the HubSpot Marketplace, that can sync Customers, Invoices, Products, Subscriptions and payment transactions out of Stripe. But its own feature table is explicit about where each one lands: Subscriptions and payment transactions go into Custom Objects, and the app's own listing states plainly that syncing Subscriptions requires Enterprise. On Free, Starter or Professional, that row in the sync has nowhere to write to — the field mapping exists, the destination doesn't.
HubSpot also has a native Subscriptions object in its object model — object type 0-69 — used by HubSpot's own payments product. It's built around HubSpot itself processing the payment, not around mirroring one that Stripe manages independently, and HubSpot's own API reference for it says plainly that associations cannot be set through that API — only retrieved. A subscription record nobody can attach to the Contact or Company it belongs to is invisible to anyone browsing the CRM the normal way; nobody scrolls a list of unlinked records looking for context on an account they're about to call.
Custom Objects generally — not just the ones this particular sync creates — are licensed to an Enterprise-tier hub, by HubSpot's own published requirements. That's the ceiling underneath both paths above: the one object type built to hold "a subscription, with its own properties, associable to a Contact or Company, filterable in a list" simply isn't available below it.
None of this is a connection failure. Everything above is what HubSpot's own product does, by design, on the tiers most SaaS companies actually run.
It isn't every Stripe object that's gated this way, which is what makes it easy to miss. In the same first-party sync, Customers, Invoices and Products all land on standard HubSpot objects that exist on every tier — only Subscriptions and payment transactions are routed to Custom Objects. A team that sees invoices and products syncing correctly reasonably assumes the whole integration is complete, and has no reason to go looking for a tier gate hiding behind just two rows of the same sync's own field-mapping table.
What to do about it today
- Stamp subscription state onto existing Contact or Company properties —
stripe_subscription_status,stripe_plan_name,stripe_current_mrr. This works on every HubSpot tier, since ordinary properties aren't Enterprise-gated, only Custom Objects are. - Populate them with a periodic export from the Stripe Dashboard, matched to HubSpot records by email through HubSpot's native import tool. No code required — but it's a snapshot, accurate the moment it's run and stale the moment a subscription changes after.
- Wire it with a small webhook handler: subscribe to
customer.subscription.updatedandcustomer.subscription.deleted, and write the same properties through HubSpot's Properties API. Zapier and Make both offer this as a pre-built pairing if nobody wants to own custom code. - Model each subscription as a Deal instead of a property, if one account can have more than one subscription. Deals are associable and reportable on every tier, and several teams keep this as a permanent pattern rather than a stopgap — a property only ever holds one value.
- If Enterprise is already the plan you're on, turn on HubSpot's own Stripe Data Sync for Subscriptions rather than building a parallel path — it's the first-party option, and it exists specifically for this.
Where this breaks down
Properties hold one value each. A customer with two active subscriptions — common with add-ons, multiple products, or a renewed-after-cancellation history — only shows you the last one written; there's no clean way to represent three subscriptions in three different states on a property sheet.
The webhook path is infrastructure you now own. Stripe's webhook delivery retries for up to three days and doesn't guarantee event order, so a handler that isn't built to de-duplicate can apply an old status after a newer one, silently showing a canceled customer as active.
Deals-as-subscriptions shares space with an actual sales pipeline unless a dedicated one is built for it, and nothing native separates "subscription tracking" from "deals a rep is actively working."
Even on Enterprise with the native sync turned on, it's one direction only — from Stripe into HubSpot. Nothing on either path checks the written record back against Stripe afterward, so a missed update looks exactly like a correct one until someone happens to check.
Upgrading to Enterprise for this one feature is a real cost most teams weigh carefully. The Custom Objects gate isn't specific to subscriptions — it's the same tier requirement across HubSpot's product line — so the decision usually isn't about subscription visibility alone, it's about paying for everything an Enterprise hub unlocks to get that one piece of it.
What Trueness does about it
Trueness's free Drift Report reads your Stripe subscriptions directly and compares them against what your HubSpot portal actually holds — on every tier, Free and Starter included, no Enterprise hub required — and prices any gap in dollars the same day it runs. Writing each subscription into your portal as its own Custom Object record, the way Enterprise's native path does, is on our roadmap; it isn't built yet, so today the report tells you what's missing and you close the gap yourself.