RESOURCES

We don't keep the
technical details vague.

How the API works, how assets are built, which formats are supported — the questions worth asking during evaluation are answered here.

FILE FORMATS

Whatever files you already have,they can usually be the starting point.

CAD / engineering source

Input formats for asset production, preserving assembly structure and part naming.

  • STEP (.stp / .step)
  • IGES (.igs / .iges)
  • SolidWorks (.sldprt / .sldasm)
  • Rhino (.3dm)
  • Parasolid (.x_t)

General 3D interchange

Intermediate formats commonly used in design and rendering workflows.

  • FBX (.fbx)
  • OBJ (.obj)
  • Alembic (.abc)
  • USD / USDZ
  • Collada (.dae)

Realtime web (output)

What the engine front end actually loads, after optimisation and compression.

  • glTF 2.0 (.gltf)
  • GLB (.glb)
  • Draco-compressed meshes
  • KTX2 / Basis textures
  • USDZ (iOS AR Quick Look)

API OVERVIEW

Four endpoint groups,covering configuration through to order.

Available over both REST and GraphQL, authenticated with API keys and request signing. Full field definitions and sample requests are in the integration guide.

GET

Products & options

Retrieve product structure, available modules, material and colourway lists, and the option groups currently in effect.

POST

Configuration validation

Submit a set of options and get back whether it is valid, which items conflict, and the auto-corrected result after constraints are applied.

POST

Pricing & BOM

Calculate a price breakdown and a structured bill of materials in real time, including quantities, part numbers and the source of each surcharge.

POST

Order write-back

Commit a confirmed configuration to an order, sync it to ERP / MES, and return a traceable configuration snapshot ID.

FAQ

The six questions we get asked most during evaluation.

We only have factory CAD drawings, no 3D models. Can you work with that?

Yes, and CAD is the ideal starting point because dimensions and assembly relationships are already accurate. We optimise the geometry for the web and rebuild materials, keeping part naming intact so it can be mapped to your part numbers later.

Our option rules are complex, with thousands of combinations. Will performance hold up?

Rules are evaluated at runtime through constraint solving, so combinations are never pre-enumerated. The number of combinations does not affect performance. What affects load time is model weight, and that is handled through optimisation and LOD tiers.

Can the configurator be embedded in our existing site or store?

Yes. The engine is headless, so the front end can be embedded into your existing site, or you can call the API and build your own interface. Shopify and WooCommerce integration paths are already supported on the commerce side.

Will the colour on screen match the physical product?

We calibrate materials with PBR and provide a workflow for checking screen output against physical swatches. To be clear: an end user’s display is not colour-calibrated, so an exact match cannot be guaranteed. For critical colours we recommend showing the physical colour reference alongside.

Do new products require redevelopment?

No. Adding products of an existing type means adding data and assets within the established rule system, and your team can maintain options and pricing directly. Development is only involved when a genuinely new structural type appears.

Where is the data stored, and how is it secured?

Deployment is flexible: hosted in our environment, or on your own servers or private cloud. Endpoints touching pricing and customer data require authentication. The specific setup is confirmed during project scoping.

Still have a question?

Send us the technical question directly. Our engineering team will give you a specific answer rather than a generic brochure.