A catalogue fed from the system that owns the data.
A PIM and product data integration connects your website catalogue to the product information management system or ERP that holds the record, so specifications, part numbers, certifications, lead times and availability on the site reflect the source rather than a copy someone maintains by hand.
The work covers what your source system can expose, a website-side data model that mirrors it, synchronisation at a frequency the source can sustain, defined behaviour when the connection fails, and monitoring so a stalled sync is caught the same day.
Product catalogues maintained by hand on the website drift from the authoritative record in the PIM or ERP, usually within a couple of quarters. A price is corrected upstream and missed on the site, a reference is discontinued in the ERP and still orderable online, a certification lapses and the page still claims it.
The fix is architectural rather than procedural: the website renders product data and does not own a second copy of it. PIM and product data work removes the duplicate instead of trying to keep two copies aligned through discipline alone.
An assessment of what your PIM or ERP can expose, a website data model that mirrors the source structure, field-level mapping with an explicit system of record for every value, synchronisation at an appropriate frequency with error handling, and monitoring that flags a stalled sync.
Alongside that: the presentation layer the data feeds, whether that is a filterable catalogue, a product finder or a distributor-facing view. See B2B product catalogues and product finder development.
The integration pattern follows what the source supports. A modern PIM with a REST or GraphQL API allows scheduled pulls of changed records, or webhook pushes where the source can emit them. An older ERP is often better served by a nightly CSV or XML export to SFTP, a read-only database view, or a middleware layer already deployed in front of it.
Whichever route, the same components apply: a delta strategy so each run moves only what changed, idempotent writes so a repeated run cannot duplicate records, a transformation step that normalises units, currencies and category codes, and a queue so a large catalogue import does not block the site. See industrial website integrations.
Integrations fail, and the design question is what the site does when they do. We cache the last known good dataset so the catalogue keeps serving through a maintenance window, retry transient errors with backoff, and stop rather than publish a partial import when a feed arrives truncated. A record that disappears from a feed is quarantined for review instead of silently deleted from the site.
Every run is logged with counts of records created, updated and rejected, and alerting fires when a run fails or when data freshness passes an agreed threshold, so the failure reaches your team rather than a customer.
We build the connection and the website-side model that consumes what your PIM or ERP already exposes, leaving the system of record where your team manages it rather than duplicating that ownership on the website.
Where fields are legitimately editorial, such as application narratives, imagery or SEO copy, those stay on the site and are protected from being overwritten by the next synchronisation run. The mapping document makes that boundary explicit field by field.
Code Industrial is the industrial B2B practice of Code Barcelona, an agency building corporate websites and digital platforms since 2015. The same strategy, design and engineering team works on every industrial project, from the first scoping session through to life after launch.
Where the record lives differs by company. PIM and product data work starts from that source.
What comes up when connecting an industrial catalogue to its source data.
Yes, usually through scheduled file exports, a read-only database view or middleware already sitting in front of the ERP rather than a direct API connection. That choice changes what update frequency is realistic: daily catalogue synchronisation is normally achievable from a nightly export, while near-real-time stock levels generally need an API or an event feed.
We assess your export capabilities early so expectations on data freshness are set before development starts, and we document which fields will lag and by how much.
The catalogue degrades rather than breaks. Cached product data continues to serve visitors, with a freshness indicator showing when it was last updated, instead of the site failing or rendering blank pages. Transient errors are retried with backoff, and a truncated or malformed feed halts the run rather than publishing a partial import.
The failure is logged and an alert notifies your team, so a source-system outage gets fixed rather than persisting quietly in the background.
It depends on the interface and the field. Specifications and descriptions change rarely and a nightly run is ample. Pricing and lead times often warrant hourly synchronisation. Stock levels are the demanding case: where near-real-time accuracy matters, we usually query the source on demand for that single value and cache it briefly, rather than trying to replicate live stock into the website database.
We agree a target freshness per field group and monitor against it, so the site can be honest with buyers about what the figure represents.
Whichever the mapping document names as the system of record for that field, decided before development rather than during a support ticket. Typically the PIM or ERP owns part numbers, technical parameters, pricing, availability and certification status, while the website owns application narratives, imagery, page structure and search copy.
Fields owned by the site are protected from being overwritten by the next run. Fields owned by the source are read-only in the WordPress editor, so an editor cannot introduce a discrepancy by correcting a value in the wrong place.
Many industrial companies run the site directly from the ERP, and where the ERP holds complete and well-structured product records that is a reasonable architecture. A PIM earns its place when marketing attributes, translated descriptions, digital assets and channel-specific data need to live somewhere the ERP was never designed to hold them.
We assess the current data before recommending either. Introducing a PIM to solve a mapping problem adds a system without removing the underlying gap.
This service covers the underlying data connection: synchronising specifications, commercial attributes and availability signals from the source system into the website. A distributor portal adds authenticated accounts, tiered pricing, ordering and order history on top of that foundation.
The two are usually sequenced, since a portal without a reliable product data feed reproduces the same maintenance problem behind a login. See B2B distributor portals.
Yes, once shared fields such as part numbers, dimensions, pricing and stock are separated from translatable fields such as descriptions and application copy. That structure keeps the underlying data in sync across languages while allowing each version to be translated independently, and it prevents a translator from overwriting a technical value.
See WPML and translation for the field-level configuration and multilingual industrial websites for how we model that separation.
It makes consistent product pages possible at a scale editors could not maintain by hand, which is the precondition for ranking on long-tail specification queries. Structured fields can be emitted as Product schema, used to generate coherent titles and headings, and filtered into category pages that stay stable as the catalogue changes.
Clean data also prevents the failure modes that cost visibility: duplicate variant pages, empty specification tables and references that stay indexed after they are discontinued. See schema markup for industrial websites and how to rank an industrial product page.
PIM and product data integration connects closely with these related technology pages.
A catalogue maintained twice, once on the site and once in the system that owns the data. Tell us your source system and we will set out how we would approach the PIM and product data integration.