How to see Stripe subscriptions in HubSpot without HubSpot Enterprise
You've connected Stripe™ to HubSpot. Contacts show up. Maybe a few invoices show up. But open any contact record and try to answer "is this person on a paid subscription, and which plan?" — and there's nothing there. You end up with Stripe open in one tab and HubSpot in the other, cross-checking by hand.
This isn't a setup mistake. It's what HubSpot's own Stripe integration actually does, and the reason has a name: subscriptions have nowhere to live in HubSpot below a certain tier, and the free path fills that gap with individual properties, not with a record you can filter, report on, or trigger a workflow from.
Why it happens
HubSpot's built-in Stripe Data Sync doesn't map subscriptions at all. It syncs Customers, Invoices and Products into HubSpot's standard objects. A Stripe Subscription — plan, status, renewal date, MRR — has no destination in that sync. HubSpot's own published summary of its Stripe integration says as much: it describes the app as transferring basic contact information without natively syncing subscription details.
HubSpot does have a native Subscriptions object — but it isn't built for this. It's object type 0-69, and it exists in the API. Two things keep it from solving the problem for a Stripe-first company. First, it's designed around HubSpot processing the payment itself, through HubSpot Payments or Stripe connected as HubSpot's payment processor — not around mirroring a subscription that Stripe manages independently. Second, and more damaging: per HubSpot's own API reference, you can retrieve a Subscription's associations, but you cannot set associations using this API. A subscription record you can't attach to a Contact or Company is invisible to anyone using the CRM the normal way — nobody browses a list of unlinked records looking for context on an account they're calling.
The durable, filterable version of "a Stripe subscription as its own HubSpot record" needs a Custom Object — and Custom Objects require an Enterprise-tier hub. HubSpot's developer documentation gates custom objects to Marketing, Sales, Content, Service or Data Hub Enterprise. That's the ceiling this article's title refers to. If you're on Free, Starter or Professional, the object type that would normally hold "a subscription, with its own properties, filterable in a list, usable in a workflow" isn't available to you at all — not because HubSpot can't technically do it, but because it's licensed to the top tier.
Every workaround below exists because of that gap.
| Where subscription data could live | Available on Free/Starter? | Associable to Contact/Company? | Filterable & reportable? |
|---|---|---|---|
| Contact/Company custom properties | Yes | N/A — lives on the record itself | Yes, but one value per property |
Native Subscriptions object (0-69) |
Yes | No — associations cannot be set via the API | Partially — exists, but effectively orphaned |
| Custom Object | No — Enterprise only | Yes | Yes |
| Deal, repurposed | Yes | Yes, natively | Yes, including pipeline reporting |
| App Object | Yes, for marketplace apps | Yes | Yes |
What you can do about it today
1. Stamp subscription state onto the Contact (or Company) as custom properties
Create properties like stripe_subscription_status, stripe_plan_name, and stripe_current_mrr on the Contact object — or the Company, if you bill B2B (see our companion piece on associating invoices to companies). This works on every HubSpot tier: writing to standard object properties isn't Enterprise-gated, only Custom Objects and HubSpot's Sensitive Data scopes are.
If you have Data Hub Starter, Professional or Enterprise, you can define these as custom field mappings directly inside the native Data Sync tool's mapping screen. Below Data Hub Starter, the mapping UI isn't available, but the properties themselves still work — you just have to populate them another way.
2. Populate them with a periodic export/import
Export your subscription list from the Stripe Dashboard (Billing → Subscriptions, or the API) with customer email, status, plan and current period end. Match it to HubSpot contacts by email using HubSpot's native import tool, mapping each Stripe field to the property you created. This works with no code and no paid add-on. It's a snapshot, not a sync — accurate the moment you run it, stale the moment a subscription changes after.
3. Wire it live with a small webhook handler
If someone on the team can write or maintain a short script, subscribe to customer.subscription.updated and customer.subscription.deleted from Stripe, and on each event call HubSpot's Contacts API (PATCH /crm/v3/objects/contacts/{contactId}) to update the same properties. This needs only a standard private-app access token with contact write access — available on every tier, no Enterprise required. Zapier and Make both offer this as a pre-built subscription-event trigger paired with a HubSpot "Update Contact" action, if nobody wants to own custom code.
4. Use HubSpot's native reporting once the properties exist
Once subscription status lives as a property, it's usable everywhere HubSpot properties normally are: list segmentation, workflow enrollment triggers ("subscription status changed to canceled → notify CS"), and standard reports. This part works well regardless of which population method you chose above.
5. Model each subscription as its own Deal, if one contact can have more than one
Properties only hold one value each, but a Deal is available on every tier, natively associable to both Contacts and Companies, and can carry its own custom properties — stripe_subscription_id, MRR, renewal date. Create one Deal per Stripe subscription, move it through a simple pipeline (trialing, active, past due, canceled), and you get HubSpot's native deal reporting and forecasting without needing a Custom Object at all. Several teams use this as a permanent pattern rather than a stopgap, precisely because it's the one option on this list that's both associable and reportable on every tier.
Where this breaks down
One subscription per contact, implicitly. Properties hold one value each. A contact with two active subscriptions — common with usage add-ons, multiple products, or a renewed-after-cancellation history — can only show you the last one written. There's no clean way to represent "this account has three subscriptions in three different states" on a Contact property sheet.
No B2B story. If you sell to companies rather than individuals, subscription properties on the Contact don't answer "what is this account paying us, in total" — you'd need the same pattern duplicated and rolled up onto the Company, and Stripe has no native concept of "company" to hand you a matching record for that rollup automatically.
Repurposing Deals blurs sales and operational reporting. A subscription-as-Deal pipeline works, but it now shares space with your actual sales pipeline unless you build a dedicated one for it — and a rep filtering "my open deals" may not expect to see a churned subscription sitting in a stage that reads like a sales stage. It solves the association and filtering problem; it doesn't solve who's responsible for keeping each Deal's stage in sync with Stripe.
The webhook approach is now a piece of infrastructure you own. Stripe's webhook delivery retries for up to three days and explicitly does not guarantee event order. A script that isn't built to de-duplicate and handle out-of-order delivery will occasionally apply an old status after a newer one, silently showing a canceled customer as active or vice versa. Someone has to notice when the script stops running.
Nothing tells you when it's wrong. Every option above is a one-way write with no verification step. If an import is run against a stale export, if a webhook is missed, or if a property gets overwritten by an unrelated workflow, the HubSpot record keeps showing whatever it last had — confidently, and incorrectly — until someone happens to check Stripe directly.
What Trueness does about it
Trueness's free Drift Report already tells you where these gaps exist in your portal today — on every HubSpot tier, including Free and Starter, no Enterprise licence required — by reading your Stripe subscriptions and your HubSpot CRM every day and pricing the difference in dollars. Writing each subscription into HubSpot as its own filterable, reportable App Object record is on our roadmap; it isn't built yet, so nothing here writes into your CRM.