← Back to Resources
GUIDE

Product Configurators Explained: Browser Options to a 3D Viewer

The 5 stage pipeline behind every configure your product button, and the one part engineers always get wrong.


The 5 stage pipeline behind every configure your product button, and the one part engineers always get wrong.

By Prasath | ScriptedCAD | https://scriptedcad.com

Based on 8+ years automating CAD across SOLIDWORKS, AutoCAD and Revit.


🚀
This is Level 4 CAD automation, where CAD leaves the desktop and runs on the web. I break the whole path down at scriptedcad.com

A customer picks a few options in a browser. Seconds later a correct 3D model spins on screen, with live pricing and a downloadable drawing. No CAD license on their machine. Most engineers assume the browser is doing the modeling. It is not. The browser collects choices and shows a picture. Every piece of real CAD work happens on a server they never see. Here is how that pipeline actually works.


What happens when someone clicks Configure

A product configurator is a Level 4 automation system. CAD data leaves the desktop and runs as a web service. The flow is always the same five stages, whether you build it on SOLIDWORKS with DriveWorks or on Inventor with Autodesk Platform Services.

  1. Browser options. The user selects width, height, material, colour. A rules engine only offers valid combinations. This is guided selling. No geometry exists yet.
  2. REST API. The browser sends the chosen option values to the server over a REST call. DriveWorks Live exposes this as its Integration Theme API. Autodesk exposes it as the Design Automation API.
  3. Rules engine. On the server, rules decide which parts belong in the assembly, what the dimensions become, and what the price is. Invalid inputs are rejected before any modeling runs.
  4. Headless model. A CAD engine with no window open drives the master model with the new parameters and rebuilds it. The same run can also produce the drawing, the BOM and a STEP file.
  5. Viewer. The rebuilt geometry is converted to a lightweight web format and streamed back to the browser. The user rotates and inspects it with no CAD software installed.
💡
The browser is a form and a picture viewer. The engineering happens on a server running a real CAD kernel. Get that mental model right and the rest is plumbing.

The REST call is smaller than you think

Engineers picture huge files flying over the wire. The request is tiny. You send option values, not geometry. You get back a status, a price, and a link to a viewable.

POST /api/specification/updateConstant
{
    "width": 1200,
    "height": 900,
    "material": "Steel",
    "finish": "Powder Coat"
}

DriveWorks lets you set values with URL query parameters, query a running specification with OData, and trigger a Specification Macro remotely. CORS controls which sites are allowed to call it. Autodesk wraps the same idea as work items posted to the Design Automation API. Either way, the browser never touches the native CAD file.

⚠️
Do not stream the native SLDPRT or IPT file to the browser. It is large and licence locked. Stream a derived viewable instead.

The two real ways this gets built

There are two mainstream stacks, and the difference decides your hosting, your licensing and your budget.

  • SOLIDWORKS path: DriveWorks Live. The browser form posts parameters to a server-side SOLIDWORKS instance that generates the CAD data, then outputs derived formats including glTF for the 3D viewer. DriveWorks has automated SOLIDWORKS since 2001 and ships as Xpress (free inside SOLIDWORKS), Solo and Pro.
  • Autodesk path: Autodesk Platform Services. The Design Automation API runs headless Inventor, Revit, AutoCAD or Fusion in Autodesk's cloud. Model Derivative converts the result to SVF2, and the APS Viewer renders it in WebGL with no plugins.
🔥
SOLIDWORKS has no managed cloud engine. You must run SOLIDWORKS yourself on a Windows server. Autodesk gives you Inventor and Revit as a hosted headless service. This one fact separates a weekend plan from a real infrastructure budget.

Where engineers get it wrong

  • They keep a live CAD session open per user for instant updates. It does not scale and it burns licences. Batch round trips scale, with a small responsiveness tradeoff. Autodesk retired Configurator 360 for this reason and moved users to the batch Automation API.
  • They confuse the viewer with the model. The viewer shows a derived SVF2 or glTF file. Users cannot edit geometry. They can only request a new configuration.
  • They think the UI or the LLM is the hard part. The moat is the rules engine and the CAD API layer that turns a valid option set into correct geometry, a BOM and a quote.

What good looks like

A finished configurator does not stop at a pretty viewer. The same run pushes a BOM into ERP and generates a quote in CPQ. DriveWorks connects to Salesforce, QuickBooks, SYSPRO and DELMIAWorks for exactly this. One real example: Knapheide used DriveWorks to automate thousands of product configurations and cut manual engineering work sharply.

A sales rep or a customer configures a valid product in minutes. Engineering stops getting pulled in to quote every variant. The drawing, the BOM and the quote generate themselves.

What To Do Next

Before you build anything, map your product's option-to-rule logic on paper. Most configurator projects fail on unclear rules, not on the web stack. If you use SOLIDWORKS, open DriveWorksXpress free inside SOLIDWORKS to feel how rules drive a model. If you use Inventor, run the Autodesk Design Automation walkthrough. Set expectations too: a basic 3D viewer integration takes a few weeks, a full configurator with design automation and ERP integration takes a few months.

🎯
Action item: write down 10 options a customer would pick, then write the rule for each one. That rule list is the real product. The web stack is just how you ship it.

🚀
Want the full path from desktop CAD to a web configurator, without the guesswork? Start at scriptedcad.com