Integration planning guide

Product configurator integrations that carry one configuration into every system.

Connect interactive 3D and product rules with CRM, ERP, ecommerce, PIM, pricing, quotes, analytics and production data. This guide defines what each integration sends, who owns it, how it fails and the evidence that proves it works.

Open the integration planner Discuss your systems

Integration starts with ownership

Connect the product record—not a screenshot of it.

A configuration is a versioned product decision. It can include system and component identifiers, dimensions, selected values, quantities, calculated context, customer identity and lifecycle status. An image or PDF helps people understand that decision, but neither is a reliable replacement for structured data.

Before choosing an API, webhook or middleware product, name the source of truth for every field. The configurator may own compatibility and geometry; PIM may own localized product content; CRM owns the relationship; commerce owns checkout; ERP owns the order; and production systems own released manufacturing data. Integration makes those responsibilities explicit.

The strongest specification begins with a business event and accepted result: “one approved configuration creates the expected order structure exactly once and returns a visible order reference.” That is more useful than “supports ERP integration.”

Architecture patterns

Six ways a configurator can exchange data.

Choose per flow. A customer-visible price request and a nightly catalogue import should not inherit the same latency and availability assumptions.

Embedded experience

The configurator runs inside an existing website, portal or commerce page. Parent and embedded application exchange identity, context, dimensions, lifecycle events and actions through a defined interface.

Best fit

Branded website, dealer portal or product-page journey where the configurator provides its own interface.

Test: Navigation, responsive height, consent, login context, back button, deep link, analytics and recovery after refresh.

API-led or headless

Product logic, data or pricing are exposed through APIs while the customer-facing interface is built separately. The contract must return allowed choices, rule messages and authoritative state after each relevant change.

Best fit

Multiple channels or a highly custom frontend that must share one configuration engine.

Test: Context, identifiers, partial updates, localization, latency, concurrency, versioning and behavior when the engine is unavailable.

Event and webhook

A completed action emits an event and another system processes it asynchronously. This decouples systems but requires verification, duplicate handling, ordering strategy, retries and reconciliation.

Best fit

Lead, quote, order, status and catalogue events where immediate synchronous completion is unnecessary.

Test: Duplicate, delayed, out-of-order, rejected and missing events; signature verification; dead-letter or retry path; periodic reconciliation.

Middleware or integration platform

A shared layer maps, validates and routes data between several systems. It can reduce point-to-point coupling but becomes an operational product with its own monitoring and ownership.

Best fit

Several destinations, enterprise transformation rules, orchestration or an established iPaaS and integration team.

Test: Mapping version, partial failure, observability, replay, environment promotion and ownership when source or destination contracts change.

Scheduled or file exchange

Catalogues, prices, orders or production data move at defined intervals through files, object storage or batch endpoints. It is often appropriate when real-time behavior adds no business value.

Best fit

Legacy systems, large reference datasets or workflows with controlled daily or hourly processing.

Test: Full and delta files, duplicate imports, malformed rows, late delivery, partial acceptance, audit report and recovery from a missed run.

Hybrid architecture

Different flows use different patterns: live price lookup, embedded 3D, asynchronous CRM lead, scheduled PIM catalogue and controlled ERP order release.

Best fit

Most mature implementations where each decision follows its actual latency, ownership and reliability requirement.

Test: End-to-end correlation across patterns and one operational view that shows where the project is waiting or failed.

Interactive integration planner

Define the complete contract for every destination.

Select a system to see the purpose, direction, trigger, ownership, failure test and acceptance result that should appear in scope.

CRM

CRM integration

Turn an anonymous or known configuration into a useful lead, contact, account, opportunity or project without reducing the product to a note field.

ConfigurixCRM

Into Configurix

Customer and account identifiers, owner, market, sales channel, campaign context, opportunity stage and any permissions needed for pricing or catalogue access.

Out of Configurix

Configuration ID and revision, product family, summary, selected options, dimensions, price context, imagery or document links, consent, source and customer next action.

Trigger

Qualified enquiry, save, quote request, salesperson handoff, checkout interruption or another explicitly defined lifecycle event.

Source of truth

CRM normally owns relationship and pipeline status; the configurator owns the structured configuration and should expose a stable reference rather than duplicate uncontrolled product logic.

Failure test

Create a CRM rejection, timeout and duplicate submission. Show operational status, preserve the project, retry safely and prevent multiple opportunities from one intended action.

Acceptance evidence

One submitted configuration creates or updates the correct person, account and opportunity, attaches the right product revision and remains traceable when the configuration changes.

Source-of-truth matrix

Decide which system is allowed to be right.

Ownership can differ by field. Document the authority, publication path and reconciliation rule instead of copying everything everywhere.

Data domain	Likely owner	Integration rule
Product names, media and market content	PIM or governed catalogue	Configurator consumes published IDs and localized content; configuration-only relationships remain explicit.
Compatibility and geometry rules	Configurator or product-rule service	Every channel receives the same allowed values, messages and resulting structured product.
Price and commercial permissions	Named pricing or CPQ engine	The request includes account, market, currency, effective date and channel; result includes a calculation revision.
Customer and opportunity	CRM	The CRM holds relationship and pipeline status while linking to a stable configuration and revision.
Basket, checkout and payment	Ecommerce	Commerce owns transactional checkout state; configured lines retain a durable configuration reference.
Issued proposal	CPQ, CRM or document service	The owning system preserves the issued version and links it to the exact configuration and price revision.
Order, fulfilment and financial status	ERP or order-management system	The accepted configuration maps to stable order lines and exposes processing status back to the project.
Production BOM or configured order structure	ERP, PLM or production system	Scope defines IDs, units, hierarchy, revision, approval and whether output is sales, engineering or production ready.

Configuration envelope

A useful payload carries identity and context—not just option labels.

This is a planning example, not a fixed Configurix API contract. Use stable system IDs, typed values, explicit units and versioned schemas agreed with each destination.

configured_project

identityconfiguration_id · revision · external_project_id · correlation_id

contextmarket · channel · account · pricebook · currency · language · effective_at

productfamily_id · system_id · selected_components · option_ids · dimensions · quantities

commercialcalculation_id · line_values · tax_context · total · approval_status · valid_until

customercustomer_id · contact_id · consent · owner · delivery_context

lifecyclestatus · event_type · occurred_at · source · destination · retry_count

outputquote_id · document_url · order_id · bom_revision · preview_url

Integration acceptance pack

Ten tests that expose more than a successful happy-path demo.

Run the same tests against Configurix and every alternative. Replace sample values with your approved product, destination and expected result.

Stable identity

Save, reopen, copy and revise one project. Configuration, customer, quote and downstream records keep distinct stable IDs and a traceable relationship.

Context

Run the same product for two markets, currencies, pricebooks, languages and user roles. Every system receives and returns the correct context.

Known payload

Compare a normal and boundary configuration to the agreed field map, types, units, null behavior, controlled values and destination identifiers.

Duplicate submission

Double-click or retry the same intended action. Exactly one lead, quote or order is created, or a defined deduplication result is returned.

Destination rejection

Send an unknown component, invalid account or expired price. Preserve source data and show an actionable status with ownership and correlation ID.

Timeout and retry

Interrupt the destination response after it may have processed the request. Retry safely without guessing or creating an uncontrolled duplicate.

Out-of-order event

Deliver an older event after a newer revision. The destination must not overwrite current state without version or timestamp rules.

Reconciliation

Remove or miss an event, then run the agreed reconciliation process. Both systems converge and expose the corrected status.

Contract change

Add a field, retire an option and change an endpoint version in a test environment. Validate backward compatibility and deployment ownership.

Permission and privacy

Attempt cross-account access, excessive fields and an action without scope. Authorization, field minimization, logging and consent behave as defined.

Reliability and security

Design for the second request and the failed request.

Production integrations need an operating model. Define who sees failures, who can replay them and how personal, account and price data stay inside the intended boundary.

Authentication and authorization

Use appropriate service or delegated identity, least-privilege scopes, account and object access checks, secret rotation and environment separation.

Payload validation

Validate external fields, types, allowed values, size and destination. Minimize personal and commercial data and define retention and logging.

Idempotency and retries

Give one intended operation a stable key or equivalent duplicate rule. Retry only when outcome can be established without creating another business effect.

Webhook handling

Verify sender signatures, record event identity, handle duplicates and out-of-order delivery, acknowledge promptly and process safely in the background.

Correlation and observability

Carry configuration, revision, operation and correlation IDs through logs and statuses so support can locate one project across systems.

Reconciliation

Periodically compare authoritative state and recover missed events or downtime. Webhooks and queues do not remove the need to prove convergence.

Implementation sequence

Integrate one accepted lifecycle before every possible system.

Define the business event

Choose one representative product, user, source, destination and observable result. Record normal, boundary and failure cases.

Assign ownership

Create the source-of-truth matrix for identifiers, catalogue, rules, price, customer, quote, order and production data.

Map the contract

Define fields, types, units, controlled values, context, authentication, response, latency and version behavior.

Build with test environments

Use representative source data and destination sandboxes. Preserve correlation and status from the first working flow.

Accept failure as well as success

Run duplicate, timeout, rejection, out-of-order, permission, privacy, retry and reconciliation scenarios.

Operate and change

Name monitoring, support, replay, incident, contract-change, catalogue-change and renewed-acceptance responsibilities.

Questions buyers ask

Product configurator integration FAQ.

Detailed answers about CRM, ERP, ecommerce, headless configuration, pricing, BOM, APIs, webhooks, failures, security and implementation.

A product configurator integration exchanges controlled context, product, commercial or lifecycle data with another system. Examples include loading catalogue content from PIM, receiving account and pricebook context, creating a CRM opportunity, adding a configured line to ecommerce, issuing a quote, creating an ERP order or releasing BOM data. A useful integration defines ownership, identifiers, trigger, payload, response, failure behavior, security, monitoring and acceptance—not only the destination name.

Common destinations include websites, customer or dealer portals, ecommerce, CRM, ERP, CPQ, PIM, document generation, analytics, identity, payment, scheduling, PLM and production systems. The exact connection depends on available APIs or files and the required business outcome. Configurix scopes each integration against the real source and destination contract; an integration logo alone does not prove the required fields or workflow.

The configurator can create or update a lead, contact, account, opportunity or project when a meaningful event occurs. The CRM record should include a stable configuration reference, revision, product summary, customer action, source and permitted commercial context. Define duplicate handling, ownership and what happens when a customer returns and changes the product. Storing the entire configuration only as unstructured notes makes later quoting and reporting fragile.

An ERP integration normally sends an accepted configuration or order structure using stable product, component, account and project identifiers. It may also receive reference data such as price lists, availability or order status. Define the release trigger, exact field map, source of truth, rejection handling, safe retry and revision behavior. Exploratory website changes should not create uncontrolled ERP orders unless that is the explicit workflow.

Yes. A configured product can be added to a basket using a configuration ID, selected summary, authoritative price or token, quantity, preview and fulfilment metadata. Define whether commerce or the configurator owns final price, how long it remains valid, how the buyer reopens the configuration and what happens if the catalogue changes before checkout. Duplicate clicks and network retries must not create multiple intended lines or orders.

A headless configurator exposes product data, allowed choices, rules, validation, state and sometimes pricing through APIs without requiring its own customer interface. A website, dealer portal, mobile app or kiosk builds the presentation and calls the same engine. This can create channel consistency, but it also makes API latency, versioning, authorization, localization, error messages and frontend ownership central requirements.

An API call is usually initiated when one system asks another to read or change something. A webhook is an event delivery sent when something has occurred. APIs suit immediate queries and commands; webhooks suit asynchronous notification. Webhook consumers still need signature verification, duplicate handling, ordering rules, retries, monitoring and reconciliation because deliveries can be repeated, delayed or missed.

Only when the business decision requires it. Product validation and customer-visible price may need an immediate result. A CRM lead, PIM update or production export may be safely asynchronous or scheduled. Real-time coupling increases latency and availability dependencies. Define the maximum useful delay, the user experience during failure and whether eventual reconciliation is acceptable before choosing the pattern.

Use the engine that can authoritatively evaluate the required product, account, market and effective context. That may be the configurator, CPQ, ERP, ecommerce or a dedicated pricing service. The request should carry required context and the response should include calculation identity or revision, detail, warnings and validity. Test known calculations and never treat an unavailable result as zero.

It can produce BOM or configured-order data when source rules and mappings support the exact required output. Distinguish a sales BOM, parts summary, configured order structure, cut-list input and production-ready manufacturing BOM. Define component IDs, quantities, dimensions, units, hierarchy, substitutions, revision and approval. Validate normal and boundary products against expected production data before describing the output as production ready.

Preserve the source project, record destination, operation, correlation ID, attempt and actionable error, and show status to the responsible user or operations team. Define safe retry, deduplication, dead-letter or review path and reconciliation. A success message before the destination confirms processing creates false confidence; a generic error without the saved project creates unnecessary re-entry.

Idempotency means repeating the same intended operation does not create a second business effect. It matters when a buyer double-clicks, a network response is lost or a background job retries. Use stable operation or idempotency keys where supported, define the duplicate window and return the original result or current status. HTTP method semantics alone do not make a business workflow safe from duplication.

Define authentication, authorization by role and account, scopes, secret storage and rotation, transport, field minimization, consent, retention, logging and incident ownership. Validate object-level and property-level access, rate and resource limits, webhook signatures and every external payload before use. Security requirements apply to internal integrations too because they expose business logic and potentially personal or commercial data.

Name the source, destination, owner, trigger, direction, data fields, identifiers, context, response, latency, authorization, failure, retry, duplicate and reconciliation requirements. Attach a representative payload and expected destination result. Replace 'integrates with ERP' with an observable scenario such as one approved configuration creating the expected order structure exactly once and returning a visible order ID or actionable rejection.

Technical references

Primary documentation behind the architecture guidance.

These sources illustrate general API, event, reliability and security patterns. They do not prove a Configurix connector or replace the source and destination specifications for your project.

SAP: Headless CPQ Configurator

Official example of an API separating configuration and pricing logic from external ecommerce, dealer, mobile and other interfaces.

Open official source

Salesforce: Composite REST requests

Official documentation for dependent CRM API operations, reference IDs, response status and rollback behavior.

Open official source

Shopify: Webhooks

Official operational guidance covering signatures, duplicate deliveries, event ordering and reconciliation after missed events.

Open official source

IETF RFC 9110: HTTP semantics

The HTTP specification definition of idempotent methods and conditions around automatic retries.

Open official source

OWASP API Security Top 10

An industry reference for API authorization, resource, business-flow and unsafe-consumption risks.

Open official source

Map your real workflow

Bring one product, one destination and one expected result.

Configurix can scope the complete flow from product choices and rules to pricing, quote, CRM, ERP, ecommerce or optional production output. We will identify the source of truth, payload, trigger, failure behavior and acceptance cases before treating the integration as complete.

Discuss your integration

Continue your planning

Product configurator integrations that carry one configuration into every system.

Connect the product record—not a screenshot of it.

Six ways a configurator can exchange data.

Embedded experience

API-led or headless

Event and webhook

Middleware or integration platform

Scheduled or file exchange

Hybrid architecture

Define the complete contract for every destination.

CRM integration

Into Configurix

Out of Configurix

Trigger

Source of truth

Failure test

Acceptance evidence

Decide which system is allowed to be right.

A useful payload carries identity and context—not just option labels.

Ten tests that expose more than a successful happy-path demo.

Stable identity

Context

Known payload

Duplicate submission

Destination rejection

Timeout and retry

Out-of-order event

Reconciliation

Contract change

Permission and privacy

Design for the second request and the failed request.

Authentication and authorization

Payload validation

Idempotency and retries

Webhook handling

Correlation and observability

Reconciliation

Integrate one accepted lifecycle before every possible system.

Define the business event

Assign ownership

Map the contract

Build with test environments

Accept failure as well as success

Operate and change

Product configurator integration FAQ.

What is a product configurator integration?

Which systems can a 3D product configurator connect to?

How does a configurator integrate with CRM?

How does a product configurator integrate with ERP?

Can a configurator integrate with ecommerce checkout?

What is a headless product configurator?

What is the difference between an API and a webhook?

Should configurator integrations be real time?

Where should product rules live?

Where should configurator pricing be calculated?

Can a configurator generate an ERP bill of materials?

How should integration failures be handled?

What is idempotency and why does it matter?

How should integration security be evaluated?

How do multilingual configurator integrations work?

How should an integration be specified for an RFP?

How long does a configurator integration take?

Does Configurix provide every integration described here automatically?

Primary documentation behind the architecture guidance.

SAP: Headless CPQ Configurator

Salesforce: Composite REST requests

Shopify: Webhooks

IETF RFC 9110: HTTP semantics

OWASP API Security Top 10

Bring one product, one destination and one expected result.

Connect architecture to product, workflow and vendor evidence.

Product configurator CRM integration

Product configurator PIM integration

Product configurator PLM integration

Product configurator ERP integration

Product configurator order management

Product configurator SSO and identity

Product configurator vs digital twin

Product configurator MES integration

CAD product configurator