Shopify knows what your customers bought. HubSpot knows who they are, what they opened, and which campaign brought them in. Keeping those two facts in the same place is the whole job, and the native integration does more of it than most people expect for something that costs nothing.
It also stops in places that are easy to miss until three months in, when someone notices that the abandoned cart flow is emailing people who already bought, or that reported revenue includes an order that was refunded in February. This guide covers what the HubSpot Shopify integration actually syncs, how to connect it, the limits both documented and not, and how to tell when your store has outgrown it. It sits alongside the broader guide to HubSpot integrations, focused on the one connection ecommerce teams ask about most.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
Does HubSpot Integrate With Shopify?
Yes. HubSpot ships a free native Shopify integration, installed from the HubSpot App Marketplace and built on the same data sync engine that powers HubSpot's other managed connectors.
Once it is authenticated it does three things. It keeps customer and product records in agreement between the two systems. It pulls Shopify orders and abandoned checkouts into HubSpot as deals in a prebuilt ecommerce pipeline. And it creates a set of Shopify-specific properties on your contacts and deals so segmentation and reporting can use purchase data without anyone touching a spreadsheet.
For a single store selling straightforward products, that is a strong free offer and the right place to start. The interesting question is not whether it works. It is which parts of your store it can see.
What the Native HubSpot Shopify Integration Syncs
The integration is a mapping between four object pairs, and the direction is set per pair. This table is the most useful thing to internalise before you scope anything, because the one-way rows are where most surprises live.
| HubSpot | Shopify | Direction | Notes |
|---|---|---|---|
| Contacts | Customers | Two-way | Near real time via webhooks |
| Products | Products | Two-way | Parent products only, no variants |
| Companies | Companies | Two-way | Shopify Plus stores only |
| Orders | Orders | One-way into HubSpot | Read-only in HubSpot |
| Carts | Abandoned checkouts | One-way into HubSpot | Drives the abandoned cart flow |
After the initial historical import, contact changes propagate almost immediately and order changes land within roughly ten minutes. That is fast enough for marketing automation and reporting, and not fast enough for anything a customer is waiting on while they watch a screen.
The ecommerce pipeline you get for free
Orders arrive as deals in a pipeline HubSpot creates for you, with six prebuilt stages: Checkout Abandoned, Checkout Pending, Checkout Complete, Processed, Shipped, and Cancelled. A shopper reaching checkout creates a deal in Checkout Pending, and after 24 hours without completing, it moves to Checkout Abandoned.
That single behaviour is the most valuable free thing in the integration, because it turns cart abandonment into a workflow trigger. One caveat: those workflows run on deal enrolment, so you need a tier that includes deal workflows to use them. On a free or Starter CRM the deals will move stages faithfully and nothing will happen when they do.
Customer and contact sync
Shopify customers become HubSpot contacts, with purchase properties attached, and edits can flow back the other way. This is the part that makes ecommerce data usable for segmentation.
Product catalogue
Shopify products sync into HubSpot's product library so line items on deals reference the same catalogue you sell from. Parent records only, which matters more than it reads.
Orders as deals
Every order becomes a deal with an amount, line items, and a stage tied to fulfilment status, which is what puts ecommerce revenue into HubSpot reporting without an export.
Abandoned checkouts
Carts sync as abandoned checkout records and drive the recovery flow, the single highest-ROI automation most stores run.
How to Connect HubSpot and Shopify
Setup is configuration rather than code, which is why it is quick and also why it can only ever do what its makers built.
1. Install from the App Marketplace
Find the Shopify app in the HubSpot App Marketplace and install it. You need to be a super admin or hold App Marketplace permissions in HubSpot.
2. Connect the store
Enter your Shopify store URL, log in to Shopify in the popup, and approve the scopes so HubSpot can read customers, products, and orders.
3. Choose objects, direction, and history
Decide which object pairs sync, set each one to one-way or two-way, and choose how far back to import existing customers and orders. Be deliberate here rather than importing everything, for reasons covered below.
4. Map your fields
Review the Shopify properties HubSpot creates and map anything custom that matters to your business. Custom field mappings require at least a Data Hub Starter subscription, sold until recently as Operations Hub Starter.
5. Build on the ecommerce pipeline
Confirm the pipeline stages match how you actually fulfil, then attach the workflows you want, starting with abandoned checkout recovery.
Step 3 deserves more thought than it usually gets. Importing every Shopify customer you have ever had sounds like the thorough choice, and it is also how stores land in a higher HubSpot contact tier for records that will never open an email. Sync the segment you plan to market to.
Where the Native Shopify Integration Stops
Some of these limits are in HubSpot's documentation. The rest you find in production. Both lists matter, and the second one is longer.
The documented limits
Product variants cannot sync. Only the parent product comes across. The specific size, colour, or SKU that sold does not exist as a separate HubSpot product item. If your catalogue is a variant matrix, your HubSpot product library is a summary of it, not a copy.
Shopify metafields are not supported. Anything you have modelled in metafields, which for most mature stores is the interesting data, stays in Shopify.
Orders are read-only in HubSpot. They flow in and never out. HubSpot cannot create or modify a Shopify order, which rules out any process where the CRM is meant to act on the store.
Company sync needs Shopify Plus. If you sell B2B on a non-Plus plan, the company side of the object model is simply unavailable.
Custom mappings and cart workflows are gated. Field mappings need Data Hub Starter, and abandoned checkout automation needs deal workflows. The app is free, using it properly is not always.
The native app maps records between a store and a CRM. It does not reason about them. Every requirement that contains the word "unless" lands outside it.
The limits nobody warns you about
Subscriptions are invisible. If recurring revenue runs through a Shopify app like Recharge or Bold, none of it comes through the native integration. HubSpot has no idea a customer is on a monthly plan, which means no renewal reporting, no churn risk signal, and no accurate lifetime value for your best customers.
Refunds do not reverse anything. An order creates revenue and advances a lifecycle stage. A refund in Shopify does not cleanly undo either. Reports keep counting the money and the CRM keeps treating a returning customer as a loyal one.
Guest checkout splits identity. Someone buys with a personal email, then again with a work email. Shopify sees two customers, HubSpot creates two contacts, and the purchase history is split across both. No amount of field mapping merges them.
Lifecycle stages advance too early. Order created maps to Customer, which is right in a spreadsheet sense and wrong in a marketing sense. First-time buyers skip the nurture they were about to receive, and a cancelled order leaves them stranded at Customer anyway.
Attribution gets flattened. Activity arriving through the sync can log against an integration source rather than the channel that actually drove the purchase, which quietly undermines the reporting the integration was bought to produce.
Multiple stores work, shared customers do not. HubSpot does support connecting several Shopify stores, each with its own settings and a source store property for filtering. It does not reconcile the same human buying from two of them into one contact with a combined value.
None of this makes the app bad. It is a free, general-purpose connector that has to work for every Shopify store on earth, and it does the common case well. The point is that the common case is a single store, simple products, no subscriptions, and reporting nobody makes decisions from. Stores grow out of all four.
HubSpot Shopify Integration: Native vs iPaaS vs Custom
There are three ways to bridge a store and a CRM, and they are layers rather than rivals. If the middle term is unfamiliar, the guide to iPaaS covers it properly, and the Operations Hub guide explains where HubSpot's own sync layer draws its line.
Free, fast, maintained by HubSpot, and it hands you an abandoned cart pipeline out of the box. Start here always. If your catalogue has no variant logic and your revenue is one-time purchases, you may never need anything else.
Good for reaching a Shopify app the native sync ignores, or for proving that a piece of automation earns its keep. Costs scale per task and reliability degrades as the logic branches, so treat it as a prototype layer rather than the thing your revenue reporting depends on.
Built against the Shopify Admin API and HubSpot's API directly, so variants become real records, subscription state lands on the contact, refunds reverse what they should, and HubSpot can write back into the store. Fixed cost, no task meter, monitored like infrastructure.
When to Build a Custom HubSpot Shopify Integration
Almost nobody should start with a build. The native app is free and the correct first move. The skill is recognising the moment you have crossed its line, and these are the five signals that show up most.
Signs your store has outgrown the native app
Variants drive your business. If which size or SKU sold is the basis of your segmentation, merchandising, or replenishment campaigns, the parent-product-only limit is a structural block, not a configuration you missed.
You sell subscriptions. Recurring revenue that HubSpot cannot see means renewal dates, plan changes, and churn signals live nowhere your team works. This is the single most common reason ecommerce brands commission a build, and it pairs with the same problem on the billing side covered in the HubSpot Stripe integration guide.
HubSpot needs to write back into Shopify. Tagging a customer, applying a discount, updating fulfilment, or pushing a value your team set on the deal. Orders being read-only makes every one of these impossible natively.
Refunds and cancellations have to reverse state. If reported revenue needs to be net rather than gross, and lifecycle stage needs to reflect what actually happened, something has to apply that logic in flight.
Ecommerce revenue is a number leadership trusts. The moment a board deck or a forecast reads off HubSpot, the sync needs deduplication, validation, retries, and alerting rather than a connector that fails quietly until a month-end discrepancy finds it.
If several of those are true, the next step is not shopping for a different connector. It is scoping the specific gaps and leaving everything the native app handles exactly where it is. Most stores that commission a build keep the free Shopify app running for contacts and the cart pipeline, and add a custom layer for variants, subscription state, and write-back. That is the same pattern the HubSpot QuickBooks integration guide describes on the finance side.
What a Custom HubSpot Shopify Integration Costs
The native app is free, so the cost conversation only opens once it cannot do the job. When it does, the honest comparison is not build versus free. It is build versus the running cost of the workarounds you already have: the per-task iPaaS bill, the weekly export, the person who reconciles refunds by hand, and the reporting nobody quite acts on because it might be wrong.
A custom integration is a one-time build plus ongoing maintenance, priced by scope. One-way variant-level order sync into HubSpot is a smaller build than bidirectional sync with subscription state, refund reversal, and cross-store deduplication. The cost teams underestimate is never the build. It is maintenance, because Shopify's API versions on a schedule, apps change their webhooks, and an unowned sync drifts until it is confidently wrong about revenue.
A custom build inverts the cost curve of a no-code patch. You pay more up front and then nothing per order, so the more you sell, the more the economics favour building it properly.
That inversion is why we productised it. StackTie builds the connection against both APIs directly for a fixed fee and maintains it on a flat monthly retainer, so a sync carrying your order data keeps working without a task meter running or an owner going missing.
Native Shopify app not reaching your variants, subscriptions, or refunds?
When variants drive your segmentation, when recurring revenue is invisible to HubSpot, when refunds need to reverse state, or when HubSpot has to write back into Shopify, that is a build. StackTie builds custom HubSpot Shopify integrations for a fixed fee and maintains them on a flat monthly retainer, alongside the free app you already have. Live in 14 days or it's free. Book a free audit and we'll map exactly which gaps are worth closing.
The Bottom Line
HubSpot integrates with Shopify through a free native app that syncs contacts and products two-way, pulls orders and abandoned checkouts one-way into an ecommerce deal pipeline, and hands you cart recovery automation for nothing. Install it first. For a single store selling simple products it is the right answer and a custom build would be waste.
It stops in two tiers. The documented limits are variants, metafields, read-only orders, and Shopify Plus for companies. The undocumented ones are the expensive ones: subscription revenue it cannot see, refunds it cannot reverse, guest checkouts it duplicates, and lifecycle stages it advances too eagerly. Every one of those is logic, and mapping is not logic. Keep the free app for everything it covers well, and build the specific layer it structurally cannot reach, because for an ecommerce brand that layer is usually the one your revenue reporting depends on.
