Custom configurators and connected business software
Headless product configurators. Your interface. Connected product logic.
We specialize in complex products. Configurix builds custom configurators and business software with an API-led product model for your website, ecommerce store or dealer portal, keeping valid choices and saved projects connected across the agreed channels.
Plan your integrationYour customer interface
Shared product evaluation
Saved project and output
A product journey your team can continue.
Shape the customer experience
Build the website, store or portal journey around your buyers. Keep the interface connected to the same product definitions and permitted choices.
Agree the API contract
Define evaluation, saved-state, pricing and output responsibilities. Keep credentials and protected operations in the appropriate server-side services.
Connect the next business step
Carry the accepted configuration into the agreed cart, quote, CRM or manufacturing handoff. Test revisions, permissions and failure recovery across channels.
Interactive architecture planner
Design around authority and outcome.
Select the channel model, source of product and commercial truth, and final business outcome. The planner returns the minimum architecture concerns to turn into specific contracts and acceptance tests.
Suggested pattern
Connected headless architecture
Put a storefront orchestration layer between public clients, configuration services and private commerce operations.
Market, currency, customer, inventory and cart context
Configured-line identity, reopen behavior and checkout handoff
Price-token validity and recovery from changed product state
Explicit boundary between valid product state and contextual commerce price
Reconciliation when configuration, promotion, tax or checkout context changes
One final transaction price authority
Configured cart line, checkout and order identity with safe retry
Expired state, repricing and customer-confirmation policy
Order acknowledgement and duplicate reconciliation
Channel
Ecommerce
Authority
Split with commerce
Outcome
Cart + order
Custom software for manufacturers
A configurator up front. Your business connected behind it.
We specialize in complex, configurable and made-to-order products. We build custom software around your catalogue, calculations, permissions, sales process and factory workflows.
Connected software
Headless delivery separates the interface from product services. Define API capabilities, versioning, authorization and operational ownership for the implementation you need.
CRM and qualified leads
Capture the selected product, dimensions and options with each enquiry. Qualify by product fit, project requirements and commercial readiness, then assign the next action to the right salesperson.
New enquiry
Connected configuration service
Product fitQualified
Connected configuration service
RequirementsProposal
Connected configuration service
Next actionCalendars and appointments
Let a configured project continue into a sales consultation, technical review, survey or installation appointment. Connect calendars, responsibilities and reminders to the same customer record.
- 09:00Project review
- 11:30Technical review
- 14:00Production planning
Bill of materials and factory data
Map product selections to component codes, quantities, materials and cut lengths. Build the sales or manufacturing BOM your team needs, with revisions and production review rules defined for your products.
| Component | Quantity |
|---|---|
| FRM-01Configured components | 1 |
| PNL-02Materials and quantities | 1 |
| KIT-03Agreed operations | 1 |
Mapped to your product codes
Live prices and branded quotes
Apply your own formulas, price lists, dealer margins and approval rules. Generate a quote containing the saved specification, product images, commercial terms and a clear customer approval step.
Quote revision
Orders, jobs and production
Carry accepted choices into order lines and assigned jobs. Keep product revisions, required approvals, documents and delivery tasks together so sales and the factory work from the same specification.
- Accepted quote01
- Configured order02
- Production job03
- Installation04
Invoicing and accounting
Connect accepted orders to deposits, invoice drafts, payment terms and your accounting workflow. Agree which system issues the invoice and how references and confirmed payment status return to the project.
Connected configuration service
Built for your website. Connected to your systems.
Launch a branded configurator in your existing website or a custom sales portal. Connect CRM, ERP, PIM, ecommerce, calendars and accounting through available APIs, webhooks or agreed imports. We define the data, permissions and responsibilities for each connection with your team.
- 01Your website
- 02Configurator
- 03CRM & calendar
- 04ERP & accounting
Choose the workflows your implementation needs. We build and validate them against your products, documents and target systems.
Plan your integrationYour product. Your systems. A connected workflow.
Bring one complex product, your current systems and the result your team needs. We will define the configurator, custom software, responsibilities and acceptance checks together.
Questions and answers
Technical integration guide
Clear definition
Headless means the interface is replaceable. Product truth is not.
A headless configurator exposes product configuration capabilities independently of one fixed user interface. The service receives product, market, language, account and channel context; creates or loads a configuration; evaluates intended changes; and returns authoritative state, allowed choices, derived values, validation and revision identity. The channel decides how to present that result.
This differs from a product API that merely lists attributes. Configurable products contain dependencies, exclusions, dimensional boundaries, calculated values and sometimes review conditions. If each frontend reconstructs those relationships, the architecture is headless in appearance but fragmented in behavior. A buyer can then create a product in one channel that another channel, price engine or factory rejects.
Headless is valuable when several experiences need the same product engine or when a company needs complete frontend control. It also creates responsibility: channel teams own accessibility, content, SEO, performance and interaction quality; platform teams own contracts, versions, authorization, limits and observability; product owners still own the meaning of a valid and sellable product.
Reference architecture
Six layers. One traceable configuration.
The layers can be separate services or responsibilities inside a smaller system. What matters is that ownership and contracts are explicit, while every downstream action keeps the same configuration identity.
Channel experience
Owns
Layout, interaction, accessibility, content, localization, account entry points and channel-specific calls to action.
Contract
Consumes permitted options, validation, visual state, price status and save or transact actions.
Avoid: Reimplementing dependency rules in every frontend because the API returns only raw option lists.
Configuration service
Owns
Session state, defaults, dependencies, exclusions, dimensions, derived values, validity and canonical configuration identity.
Contract
Accepts context plus intended changes; returns authoritative state, allowed next choices, messages and revision.
Avoid: Letting the client declare a configuration valid instead of validating every relevant mutation server-side.
Commercial service
Owns
Price source, currency, market, customer group, quantity, discounts, tax responsibility, validity and approval status.
Contract
Calculates from configuration revision plus commercial context and returns explainable lines or a price token.
Avoid: Copying formulas into a frontend, configurator and commerce platform with no named authority or reconciliation.
Visual delivery
Owns
Runtime assets, scene bindings, materials, camera states, optional AR assets, thumbnails and configured snapshots.
Contract
Maps stable product IDs and configuration state to versioned visual assets and deterministic scene instructions.
Avoid: Returning an image without enough structured state to reproduce, price or continue the configured product.
Business workflow
Owns
Lead, quote, cart, order, approval, project, document and optional production transition responsibilities.
Contract
Consumes an accepted configuration revision exactly once and returns durable destination identity and status.
Avoid: Treating a timed-out request as failed, retrying blindly and creating duplicate leads, quotes or orders.
Governance and operations
Owns
API versions, schemas, credentials, rate limits, observability, audit, catalogue release, migration, deprecation and recovery.
Contract
Publishes supported behavior and makes every request traceable across service and destination boundaries.
Avoid: Shipping an undocumented private API whose behavior changes whenever the original frontend changes.
Configuration API contract
Ten capabilities cover the complete configured journey.
These are logical responsibilities, not mandatory endpoint names. A contract can combine or separate them, but consumers should know what they send, what authority responds and which guarantee survives retries, releases and downstream handoffs.
Catalogue context
Request
Market, language, channel, account or role and effective time
Response
Product families, availability, entry points, labels, assets and catalogue revision
Guarantee
Only published and permitted products are exposed for the supplied context
Initialize configuration
Request
Product ID, channel context and optional known template or saved revision
Response
Configuration ID, defaults, current state, allowed actions, messages and version set
Guarantee
The returned state is valid or explicitly marked incomplete with resolvable requirements
Evaluate a change
Request
Configuration revision plus user intent such as option, dimension or quantity change
Response
Accepted canonical state, consequences, allowed values, validation and new revision
Guarantee
Clients cannot bypass dependencies, exclusions or dimensional constraints
Calculate price
Request
Configuration revision and authoritative commercial context
Response
Status, currency, lines, total, provenance, validity and approval requirements
Guarantee
The result identifies its configuration and calculation source revisions
Resolve visual state
Request
Configuration revision, target device or visual mode and requested viewpoint
Response
Asset manifests, node or material bindings, transforms, camera and snapshot capability
Guarantee
The visible scene maps to the same structured selection used by price and output
Save and continue
Request
Configuration revision, permitted identity, label and optional customer context
Response
Durable project reference, share policy, expiry and continuation URL or token
Guarantee
Reloading identifies whether the saved revision is current, historical or needs migration
Create quote or cart line
Request
Accepted configuration, price result or token, customer and channel action context
Response
Quote, cart or review reference plus status and destination link
Guarantee
Retries do not create unintended duplicates and the destination retains configuration identity
Release operational output
Request
Approved configuration and named release status
Response
Order structure, BOM class, files, documents, destination acknowledgement or review hold
Guarantee
Output is revisioned, attributable and cannot silently change after release
Publish lifecycle events
Request
Meaningful completed action with event, object and tenant identity
Response
Acknowledgement, delivery status or subscriber processing result
Guarantee
Events are authenticated, deduplicated, replayable by policy and observable
Administer catalogue
Request
Authorized draft change, validation action, publication or rollback
Response
Draft and published revisions, affected objects, checks and release status
Guarantee
Customer APIs cannot perform privileged catalogue or price administration
Canonical response
Return product meaning, not only fields.
A useful response connects product identity, accepted selections, derived values, validity, available next steps, commercial status and version history.
{
"configurationId": "cfg_01J8P4A2",
"revision": 14,
"status": "valid",
"context": {
"product": "pergola_bioclimatic_04",
"market": "NL",
"language": "nl-NL",
"channel": "dealer-web",
"account": "dealer_account"
},
"selection": {
"widthMm": 4200,
"projectionMm": 3500,
"roof": "louvered",
"finish": "anthracite",
"sideScreen": true,
"ledLighting": true
},
"derived": {
"postCount": 4,
"roofBays": 2,
"areaM2": 14.7
},
"allowed": {
"projectionMm": { "min": 2500, "max": 5000, "step": 100 },
"finish": ["anthracite", "black", "white", "bronze"]
},
"messages": [],
"commercial": {
"status": "priced",
"priceResultId": "price_7K2",
"currency": "EUR",
"total": "10440.00",
"validUntil": "2026-08-26T23:59:59Z"
},
"versions": {
"api": "2026-08",
"catalogue": "PERG-EU-12.4",
"rules": "rules_perg_8.2",
"price": "DEALER-NL-8",
"visual": "scene_pergola_04@3.2.0"
},
"links": {
"self": "/configurations/cfg_01J8P4A2/revisions/14",
"continue": "/projects/cfg_01J8P4A2",
"snapshot": "/configurations/cfg_01J8P4A2/revisions/14/snapshot"
}
}Transport and delivery patterns
Choose by interaction, not fashion.
REST, GraphQL, webhooks and embedded bridges solve different communication problems. A mature architecture can use more than one while preserving the same canonical product and transaction identity.
REST or resource API
Good fit
Clear resources and commands such as configurations, evaluations, prices, quotes and orders.
Strength
Familiar HTTP semantics, cacheable reads, explicit operation contracts and broad tooling.
Watch: Avoid turning every option change into an unrelated resource mutation with no canonical state response.
GraphQL
Good fit
Channel teams need typed access to related catalogue, configuration and presentation data with different field needs.
Strength
Strong schema, introspection and client-selected response shape can support varied frontends.
Watch: Query flexibility does not replace configuration commands, authorization, cost limits, revisioning or business-flow protection.
Events and webhooks
Good fit
Lead, quote, order, catalogue or status transitions that other systems can process asynchronously.
Strength
Decouples the interactive response from slower destinations and supports multiple subscribers.
Watch: Sign payloads; define ordering, retry, deduplication, replay, dead-letter and reconciliation behavior.
Embedded UI with bridge
Good fit
A faster branded launch where the configurator owns its interaction but the parent site supplies context and receives events.
Strength
Less frontend reconstruction while still connecting identity, analytics, resize, save and transaction actions.
Watch: This is not fully headless. Define parent-child origin, message schema, navigation, consent and failure behavior.
State and revision design
Six principles keep channels from creating different products.
Intent in, canonical state out
A client submits the intended change. The configuration service applies rules and returns the accepted state plus consequences. The frontend does not become an alternative rule engine.
Optimistic concurrency
Mutations reference the state revision they were based on. If another actor or process changed the project, the API rejects or reconciles deliberately instead of overwriting silently.
Stable object identity
Products, options, components, assets, price sources, configurations and outputs use durable identifiers. Labels, ordering and translations can change without breaking saved projects.
Version set, not one version
A result may depend on application, catalogue, rules, price, asset, document and integration contracts. Capture the relevant set so the state can be explained later.
Explicit incomplete and invalid states
The contract distinguishes valid, incomplete, invalid, review-required, unpriced and unavailable states. A missing price must never become zero and a warning must not become an approval.
Historical continuation policy
Saved configurations declare whether they reopen exactly, migrate to a new catalogue, remain view-only or require review. The policy is a product decision, not an accidental API side effect.
API security model
Protect product logic and every business object.
Headless expands the number of consumers and exposed operations. Authorization must follow tenant, object, property and action boundaries while resource and sensitive workflow controls protect more than credentials alone.
Object authorization
Check tenant, account, project and configuration access on every object request—not only at login.
Property authorization
Return only fields permitted for the role; dealer margin, internal cost and production notes must not leak through broad schemas.
Function authorization
Separate public configuration from price administration, catalogue publication, exports and privileged workflow actions.
Resource controls
Bound payload, dimensions, query cost, rendering work, file size, request rate, session count and expensive business operations.
Sensitive flow protection
Protect quote creation, checkout, invitation, account-price lookup and large export flows from scripted abuse.
Credential boundaries
Keep private service tokens server-side, scope permissions, rotate secrets and distinguish browser, workforce and service identities.
Input and output validation
Validate requests and upstream responses against explicit contracts; never trust integrated APIs merely because they are internal.
Inventory and lifecycle
Maintain an endpoint and event inventory with owners, versions, exposure, data classes, consumers and deprecation dates.
Implementation sequence
Ten steps from channel intent to operated platform.
Start with business authority and one real vertical slice. A long endpoint inventory built before the canonical product and outcome are clear usually creates more integration work, not a reusable platform.
Define channel outcomes
Name the customer journeys, identities, markets and final business outputs. Headless is an architecture choice, not a requirement by itself.
Assign authority
For catalogue, rules, state, price, assets, customer, cart, order and production, name the system that owns the accepted value.
Model canonical identity
Define stable IDs and revisions before endpoint shapes. Include configuration state, context, provenance and historical behavior.
Write consumer journeys
Describe the calls required to start, change, validate, price, save, reopen and transact for each channel and failure condition.
Publish contracts
Use machine-readable API and payload schemas, examples, error models, permissions, limits and lifecycle policy.
Build one vertical slice
Connect one real product from channel UI through rules, price, saved state and one destination. Do not prove architecture with mock data alone.
Add recovery semantics
Define timeouts, retries, idempotency, concurrency, partial failure, event replay and reconciliation before load or outage testing.
Verify security and performance
Test object, property and function authorization plus payload limits, query cost, latency and dependency failure.
Run contract and journey tests
Make provider and consumer checks part of releases; test historical configurations and destination acknowledgements.
Operate the lifecycle
Monitor service objectives, traces, errors, event lag, schema use and deprecations. Publish migration paths before removing behavior.
Architecture failure patterns
Eight ways API-first becomes API-fragmented.
The failure is rarely the protocol itself. It is missing authority, weak identity, duplicated rules, unsafe retry or a contract that describes syntax but not business meaning.
A thin CRUD wrapper
The API exposes products and options but not allowed transitions, derived values or authoritative validation.
Control: Return canonical evaluated state and consequences for every configuration mutation.
Rules copied into clients
Website, dealer portal and mobile app each hide or disable options differently, creating channel-specific truth.
Control: Keep validation authoritative in the service and return presentation-ready permission and message data.
One giant payload
Every request transfers the complete catalogue, all assets, private commercial fields and unrelated state.
Control: Design bounded resources, field permissions, pagination or query limits and staged asset loading.
Stateless price guesses
A client sends selected labels and expects a total without configuration revision, account context or source identity.
Control: Calculate from canonical IDs, exact state revision and explicit commercial context.
Retry means duplicate
A network timeout causes the client to resubmit and creates multiple leads, quotes, cart lines or orders.
Control: Define idempotent business commands, durable action identity and destination reconciliation.
Headless without observability
The browser reports an error but no team can follow the request across configuration, pricing and destination services.
Control: Propagate correlation identity, structured events, service timing and actionable failure codes.
Versioning by surprise
A response field or behavior changes in place and silently breaks one of several independent channel teams.
Control: Publish compatibility rules, consumer usage, deprecation notice, migration examples and removal gates.
Public API, private assumptions
Documentation omits tenant rules, rate limits, lifecycle, authorization or historical state because the first consumer shared tribal knowledge.
Control: Treat each contract as an independent product with owners, examples, limits and acceptance evidence.
API-first vendor evaluation
Twenty questions before selecting the architecture.
Ask each provider against one real product, channel and outcome. Require schemas, examples, limits, failure demonstrations and versioned evidence instead of accepting “API available” as a complete answer.
Which services are genuinely API-first, and which capabilities require the vendor's own frontend?
Can the API return allowed next choices, rule consequences and validation—not only product attributes?
What is the canonical configuration object, and which revisions identify it completely?
How are incomplete, invalid, review-required, unavailable and unpriced states represented?
Can website, dealer, mobile and showroom channels share saved projects without sharing unauthorized fields?
Which system owns list, account, market, discount, tax and final transaction pricing?
How are concurrent changes to one saved configuration detected and resolved?
Can historical configurations reopen after catalogue, rule, price or asset changes?
What REST, GraphQL, webhook, SDK or embedded-bridge contracts are available and documented?
Are OpenAPI, GraphQL schema, JSON Schema, examples and error models available for automated checks?
How are contracts versioned, deprecated, measured for use and eventually removed?
What latency, availability, payload and rate limits apply to each interactive call?
What happens in the channel when configuration, pricing, asset or destination services are unavailable?
How are create operations protected from duplicates after client retries or destination timeouts?
How are webhook signatures, ordering, retries, replay and dead-letter cases handled?
How are tenant, object, property and function permissions enforced and tested?
Which tokens may exist in a browser, and which credentials must remain in a server-side layer?
Can traces connect a customer action to configuration, price, quote, cart, order and destination records?
What consumer contract, load, security and end-to-end tests are included in release evidence?
Who owns frontend accessibility, SEO, analytics, upgrades and support when the experience is custom-built?
Primary architecture references
Use open contracts and current platform documentation.
These sources define widely used API descriptions, payload validation, query schemas, API security, headless commerce and composable principles. They do not define your product rules or ownership; those remain business-specific requirements.
OpenAPI Specification 3.2.0
The language-agnostic standard for describing HTTP API capabilities so people and software can understand a service without reading its source code.
JSON Schema 2020-12
The current published JSON Schema specification for describing and validating JSON instance structure and constraints.
GraphQL
The official GraphQL resource explains its strongly typed schema, predictable responses, introspection and query model.
OWASP API Security Top 10
The OWASP API Security Project covers object and property authorization, resource consumption, sensitive flows, inventory and unsafe API consumption.
Shopify Storefront API
Shopify's official headless documentation shows how commerce capabilities can serve web, app and other custom storefront experiences through an API.
MACH principles
The MACH Alliance describes open, composable and connected architecture through transparent APIs, headless capabilities and independently evolvable components.