HubSpot + Pimcore integration

Pimcore is where a manufacturer or distributor decides what a product is. Its data model is built for the business rather than bought ready made: classes for products and categories, assets in the same platform, and workflows that decide when a product is ready to publish. The approved photo sits in Pimcore’s own asset management beside the approved description. The result is usually the best product data the company has, and the sales team never sees it.

Sellers quote from HubSpot, so they work from a product library someone keyed in by hand. Names drift from the approved ones, discontinued items stay quotable, and a price list update reaches the portal weeks after it reached the website. Every mismatch surfaces where it costs most, on a quote the customer has already read.

Connecting the two makes Pimcore the only place product data is edited and HubSpot the place it is sold from. The integration is narrower than the PIM project behind it: the fields a seller needs, the prices HubSpot can hold and an image, delivered on a schedule the product team can predict. Nothing about Pimcore’s enrichment workflow has to change for it, and nobody has to learn a second tool.

Products are the whole of it on the HubSpot side. Pimcore product objects become HubSpot products, the category path lands as a property on each one, and an image asset supplies the image URL. Prices arrive per currency, because HubSpot keeps a price field for each currency the account has configured, and a currency Pimcore holds but HubSpot does not is left out on purpose.

The key is the Pimcore object id, held in a custom unique property. The SKU travels in hs_sku for sellers to search, but SKUs get corrected, and a correction must update a product rather than create a second one. Because each Pimcore implementation designs its own classes, the field list is settled in discovery rather than assumed.

Everything moves one way. Pimcore is where data is enriched and approved, and HubSpot only reads it. Line items on deals are separate records created when a seller adds the product, so the sync never edits a quote.

The runtime is a polling watermark sync against a Datahub GraphQL endpoint. Datahub serves each endpoint from a configuration of its own, at a path named for it and secured with an API key, with workspaces deciding which folders it can read. We ask for a configuration that exposes only the product classes and fields the sync needs.

On each run the service queries the product listing with a filter on the modification date after the stored watermark, sorted by that date and paged with first and after. It requests a thumbnail path for each image, upserts HubSpot products in batches keyed on the Pimcore id, and advances the watermark only after the batch commits. A replay endpoint re-reads a window, and a reconciliation step compares Datahub’s totalCount with the products in the portal.

On an enterprise subscription, Datahub Webhooks can post an object event the moment it happens. Pimcore attempts each delivery once, so the event only tells the service to read sooner.

With nothing packaged in the marketplace, the choice is how much of the catalogue moves and how often. A small catalogue that changes a few times a month can live on an iPaaS, and Pimcore names Zapier, n8n and Power Automate among the tools it integrates with. The per-run cost stays small while edits are rare.

A product library that sales quotes from every day is different. It needs every change, a key that survives an SKU correction, prices per currency and a way to replay a bad hour. That is a custom API integration reading Datahub, and it works the same on the Community, Professional and Enterprise editions, because Datahub is a community project rather than an enterprise bundle.

1. Scope. We walk the class model with the product team and list the fields sales needs, the currencies, the image rules and the edition in use.
2. Architect. We define a Datahub configuration for the sync, fix the Pimcore id as the key, and set the watermark, batch size and currency mapping.
3. Build. The service is written against a non-production Pimcore and a HubSpot sandbox, with a schema check at the start of every run.
4. Validate. We load the full catalogue, reconcile totalCount against HubSpot, and spot check prices and images with the product owner.
5. Operate. We watch run history and schema errors, replay windows on request, and review the mapping whenever a class changes.