Product configurator integration starts with an agreed handoff. The customer picks a product and its options. The system that receives the choice needs three things: a valid specification, IDs it recognises and a clear next step. The same choice might become a CRM enquiry, an ERP quote or a basket item. A CRM (customer relationship management) system holds customer and sales records. An ERP (enterprise resource planning) system runs stock, pricing and orders.
Discuss your product rangeTry the demos
I agree the receiving contract before I connect the viewer. A successful HTTP response should say exactly what happened. Was a specification received? Was a quote created? Was an order accepted? Each of those is a different business event.
Assign a source of truth to each decision
| Information | Integration decision |
|---|---|
| Product and option IDs | Which IDs link the chosen width, finish and parts to records the receiving system knows? |
| Compatibility | Which service confirms that the chosen combination can be supplied? |
| Price and availability | Which system owns current account prices, currency, tax, delivery and stock or manufacturing rules? |
| Customer identity | Which account can ask for this quote or place this order, and what are its permissions? |
| Acceptance | Which reference and status show that the receiving system saved the record you meant? |
The product-data guide covers how to structure the catalogue. This guide is about the request that crosses into another application. It covers checks, retries and the proof you need to know what happened. Use quote versus checkout to choose the commercial destination first.
A working HTTP handoff you can inspect
The downloadable example starts a real HTTP receiver on your own computer. It builds on the fictional cabinet from the rules-testing guide. Each request carries a contract version, a catalogue version, a product ID, a width, a door choice and a finish. The receiver checks those fields. It then works out the example amount again from its own catalogue.
Take the wide cabinet with double doors and an Oak finish. The amount is 65,000 GBP minor units, or £650. This is fictional product data. It is not a real product offer or a price for development services. The receiver only creates a specification reference in memory. It has no link to a CRM, ERP, stock service, payment system or live order.
| Submitted request | Observed result |
|---|---|
| Valid specification | 201: a new reference and the amount the server worked out. |
| Identical retry | 200: the same reference and the original response, while its replay record is still kept. |
| Changed choices with an accepted request key | 409: the key was reused for different data, so no second specification was accepted. |
| Changed displayed price or stale catalogue | 409: a clear request for review. |
| Unknown option or incompatible combination | 422: the choice is rejected, with a reason. |
The automated checks send real HTTP requests on the local machine. All 28 passed on 23 September 2026 using Node.js 24.19.0. They include five concurrent submissions with the same key. They also cover malformed JSON, unsupported fields, and oversized bodies, both declared and chunked. The pack includes the source and commands.
The responses keep a received specification apart from a commercial acceptance. A production application should show the customer a status that the receiving system backs up.
Make retries deliberate
A timeout leaves a hard question. Did the receiving system accept the request before the connection failed? If you send it again as a new request, you may create a duplicate. A key made by the caller can mark a retry of the same intended action. This is called an idempotency key.
In this example, an Idempotency-Key header identifies one submission. If you repeat an accepted payload, you get the original result. If you reuse the key with changed fields, you get a conflict. Adding the header alone gives no guarantee from an arbitrary API.
The teaching server keeps at most 1,000 records for 15 minutes in one process. If you restart it, or wait longer than that, the duplicate protection is gone. A production system needs a lasting record tied to the caller’s identity. It also needs that record to be linked, in one step, to the downstream action. I would agree retention, concurrent processing and reconciliation with the team that owns the receiving system.
Handle failure at the receiving boundary
Keep the customer journey usable when a request cannot finish. Keep their selection. Say whether it needs a fix or a review. Give them a safe way to check an unclear result. Do not show a success message just because the browser sent the request.
OWASP’s REST security guidance covers input validation, content types and access controls on endpoints. The example shows a few of these checks. A real deployment also needs authentication, authorisation, HTTPS, suitable privacy controls, monitoring, and tests against the actual receiving service. The passing tests do not show production security or platform compatibility.
Write down what happens when the catalogue changes between selection and submission. The catalogue maintenance guide covers controlled changes and older selections. For reporting, the configurator measurement guide keeps interaction events apart from accepted commercial outcomes.
Choose the destination: checkout, quote or saved specification
A configurator can end with an order, a quote request or a saved specification. Decide which one before you build the interface. It depends on one question. Can you confirm the product, price and delivery terms without a person reviewing the request? You can offer more than one route, but make the difference clear. “Request a quote” should not look like placing an order. “Add to basket” should not hide that a shown price is only an estimate.
| Situation | Suitable starting point | What must be resolved |
|---|---|---|
| Known options, price, stock and delivery | Add a validated configuration to the basket. | Stable product IDs and commercial values that the server confirms. |
| Site measurements or installation affect the offer | Request a quote with the saved specification. | What needs review, who reviews it and what the customer gets back. |
| Dealer or trade-account terms | Authenticated pricing or a quote approval route. | Account permissions, discounts and which system owns pricing. |
| Customer is exploring an early idea | Save or share the configuration, with an optional enquiry. | How long it is stored, when it expires and what happens when the catalogue changes. |
Whichever route you pick, keep the specification whole. A quote route should add the missing commercial questions. It should not make the customer describe their choices again in an empty message box. Pass the IDs, catalogue version, quantity, dimensions, a readable summary and a request reference. Treat all of it as untrusted. Check the options, dimensions, current prices and availability again on the receiving server. Never accept a total from the client just because the page showed it correctly.
Shopify’s Cart API accepts product IDs and line-item properties. Descriptive properties do not create valid stock or trusted pricing. See the Shopify integration guide. A component-based WooCommerce approach may suit a choice of existing products. It will not solve every made-to-measure rule. CPQ (configure, price, quote) covers pricing and proposal work beyond visual selection. Name approvals, revisions and account terms as separate jobs.
Test the hard cases. An old saved selection may use an option that has been withdrawn. A price may have changed. A request may be interrupted and must not create duplicates. The viewer may be missing. Your sales team should also be able to fetch the exact specification without rebuilding it from an image. Count accepted orders apart from viewer opens.
Plan a rollout across retailer websites
A manufacturer can offer a configurator through retailers without running a separate product system for each site. The shared parts are the product definitions, models and rules. Each retailer may need its own branding, range, enquiry destination and commercial integration. The aim is to keep those differences under control.
| Shared manufacturer information | Retailer-specific decisions |
|---|---|
| Stable product IDs, dimensions and compatible options. | Which approved products and finishes the retailer offers. |
| Reviewed models, materials and product images. | Branding, intro text and the page around the viewer. |
| Versioned application and catalogue releases. | Launch date, pilot role and support contact. |
| Specification format and validation rules. | Where enquiries go and how local pricing or ordering works. |
Download the receiver and contract worksheet
Download the HTTP handoff example. The ZIP holds the receiver, fictional catalogue logic, a request example, a 28-test suite, a three-request demonstration and an editable integration-contract worksheet. It runs on loopback with no package installation. The test and demonstration commands close their server afterwards.
For a WooCommerce storefront, the configuration-reference example checks a different boundary. It follows cart data into saved order lines, and I tested it in both order-storage modes.
For a project, bring a typical product, the destination system and a sample of the record it needs to receive. Explore product configurator development or enquire about an integration.
For a sector example of quote, survey and order workflows, see the kitchen configurator guide. For the sales side, see the glossary entries on CPQ and configurator embeds.
Related reading: Magento and Adobe Commerce configurators and BigCommerce and WordPress configurators.
Product configurator integration FAQ
What does a configurator need to send to an ERP or CRM?
It should pass the product and option IDs, the catalogue version, the quantity and any relevant dimensions. It should add a readable summary and a request reference. The receiving server should check all of it again, including current prices and availability.
Should a configurator send prices?
Treat any price from the browser as untrusted. Never accept a total from the client just because the page showed it correctly. In the example, the receiver works out the amount again from its own catalogue.
What happens if the request times out?
You will not know if the receiving system accepted the request. A key made by the caller can mark a retry of the same action. In the example, repeating an accepted payload returns the original result. Keep the customer’s selection and give them a safe way to check the outcome.
When the buyer is a business, approval and payment terms add more steps. The B2B checkout and approvals guide covers those trade-specific states.
Before the hand-off, buyers often save or share a choice. See the guide to saving and sharing configurations.