HubSpot + Shopify integration

Most Shopify merchants arrive at this question from the marketing side. They are already sending campaigns, and the segment they want does not exist: people who bought a particular product, once, more than ninety days ago, and have not been back. The store knows all of that. The email tool knows an address and a signup date. Bridging the two is the whole job.

The second group arrives from service. A customer writes in about an order, and the agent has two tabs open, copying an order number from one to the other. It is a small tax, paid many times a day, and it grows with the catalogue. Once order history sits beside the conversation, most of those lookups disappear and the answers get faster.

The third group has outgrown something. They started on the free app, and then the business changed shape: a second storefront for a different region, a wholesale channel with negotiated pricing, a subscription product whose renewal date needs to drive a workflow. These merchants know the integration exists, because they are using it, and they have found the specific thing it will not do. The answer for them is rarely replacing the app and usually extending it.

Customers become contacts, orders become deals or a custom object, line items become line items, product variants become products, and business to business companies become companies.

The keys are all platform identifiers held in custom HubSpot properties. Email is not a key. Guest checkouts, account merges and shared household addresses all produce cases where the same email is two shoppers or one shopper is two emails, and a sync keyed on email will quietly pick the wrong one. Products key on the variant id rather than the stock keeping unit, because merchants reuse and retype stock keeping units between seasons, and a reused code overwrites the previous product’s history.

The choice worth arguing about is orders. A deal is a pipeline record that closes once, which suits a business with a real sales process. A high volume direct to consumer store with thousands of orders a month usually wants a custom object instead, so the forecast is not buried under completed baskets.

Traffic runs one way. Shopify owns the order.

The pattern is a webhook queue with a reconciliation sweep. Shopify webhooks fire on the events that matter, a small endpoint accepts them, and the work happens off the request so a slow HubSpot call never causes a delivery failure. Writes into HubSpot are batch upserts keyed on the Shopify identifier, followed by a separate associations pass, with API paths pinned to version 2026-03.

Shopify’s own documentation says webhook delivery is not always guaranteed and advises a reconciliation job that periodically refetches, so the sweep is part of the build rather than an extra. A scheduled query pulls everything changed since the last watermark and fills the gaps. The Admin API supports that directly: the customers and orders queries both filter on an updated timestamp, which is what makes a watermark cheap here and expensive on systems that lack it.

Reads use the GraphQL Admin API, where cost is calculated per query against a point bucket rather than counted per request, so a backfill is paced by query shape rather than by a request per second figure.

Start with the app. It is free, HubSpot publishes it, and for a single store that wants customers, orders and products visible, it is finished work. Connecting it properly, including the field mapping and the first reconciliation, runs 8 to 24 hours. The question is only what happens at the edges. A second storefront, business to business companies and locations, a custom object for orders, or a field the app’s mapping does not carry: each of those is a reason to add a service beside the app rather than instead of it. As a fallback, that service is a further 40 to 60 hours. An automation platform is the route to avoid here, because it bills per order to do less than the free app already does.

Missed webhooks, duplicate contacts, reused stock keeping units and multi store identity are the failures that come up repeatedly.

1. Scope. We start by asking what the app already does for you, then write down only the things it does not, because that list is the actual project.
2. Architect. We fix the order model first, deal or custom object, then the keys, then whether business to business companies are in play.
3. Build. A webhook endpoint that acknowledges quickly and queues, batch upserts keyed on Shopify identifiers, a separate associations pass, and a watermarked sweep from day one rather than after the first gap.
4. Validate. Development store on one side, sandbox portal behind a fail closed allowlist on the other, then a production cutover that swaps credentials against proven code.
5. Operate. The sweep reports what it had to repair each run, which is the earliest warning that something upstream has changed.