Concepts

This page explains the six ideas behind the buyer API and the merchant API. Read it once before you build an integration: each idea explains a decision you will meet in the reference pages, from why a price call is cheap to why a buyer never sees your margin.

Analyse once, price many

When a file arrives, Quotometry analyses its geometry once and stores the result as immutable GeometryFacts: volume, surface area, bounding box, oriented bounding box, thin walls, overhangs, holes and so on. Nothing in that record knows about money, machines or materials.

Everything after that is arithmetic over those facts. Changing a material, a quantity, a layer height or the whole configuration re-prices in milliseconds and never reads the mesh again. That is why a buyer can drag a quantity slider and watch the price move, and why POST /v1/price is cheap enough to call on every change (debounced).

What this means for you: upload a file once and keep its model_id. Price it as many times as you like.

A configuration is versioned data

A configuration is one shop’s complete answer to “how do we price this process?”: machines, materials, rates, margins, options, lead times, DFM rules and formulas. It is data, not code, and it is versioned.

You edit a draft. Publishing validates the draft, compiles it and stores it as a numbered, immutable config version. Every quote records the config version that priced it, so a quote you sent last Tuesday still explains itself after you have raised your PETG price twice. A published version is never changed.

Every process is a plug-in

Each process Quotometry prices (FDM, resin (SLA, DLP and LCD), SLS, MJF, metal powder-bed fusion, material jetting, binder jetting, CNC milling, CNC turning, laser, waterjet and plasma cutting, injection moulding and vacuum casting) is implemented as a process plug-in with its own settings schema, estimator and DFM rules. Some share a core: SLS and MJF one powder-bed module, milling and turning one CNC core, the three cutting processes one 2D cutting core. The pricing pipeline knows none of their physics. That is why the settings a machine exposes differ by process, and why the API returns a settings schema rather than a fixed structure.

Widgets are the public face

A widget is a publishable key plus a policy: which configurations it offers, which origins may use it, how it looks, whether it is live or test, and how much of the price breakdown a buyer may see. A shop can have several, for example one per brand, site or landing page, each with its own analytics.

The widget key is publishable. The Origin allow-list is what makes it safe.

Quotes and orders

Call	What it does	Stored?
POST /v1/price	Calculates a price for one or more lines. It commits the buyer to nothing.	No
POST /v1/quotes	Saves a priced set of lines with a number and a validity period.	Yes
POST /v1/orders	Converts a quote into an order: the thing your shop actually makes.	Yes
POST /v1/rfqs	Sends a request for quote that a person at the shop answers.	Yes

A request for quote (RFQ) is the escape hatch. When a line cannot be priced automatically (too big, a DFM problem, a quantity past your review threshold), the buyer sends a request and a person answers it from the Inbox.

The first successful price of a part in a buyer session counts as one quote request, the unit your plan is metered in. Re-pricing that part, for example with another material or quantity, is not counted again.

Test mode goes all the way down

Test mode is not a sandbox with different code. It uses the same engine, the same configurations and the same database, and marks everything a test widget produces as test:

• excluded from analytics and from billing;
• filtered out of the Inbox by default;
• delivered only to webhook endpoints created in test mode;
• rate-limited at a quarter of the live budget.

What a buyer is never told

Rates, costs, margin, overhead and risk never appear in a buyer-facing payload. They are not hidden behind a flag; they are absent. A separate function decides what a buyer may see, and every buyer-facing response goes through it. If you integrate a cart, you cannot leak a margin by accident, because the number is not in the response you received.

Next steps

• Quick start: put the widget on a page.
• Widget reference: attributes, events, methods and theming.
• Errors: the difference between a failed request and a line that needs review.
• Drafts, versions and publishing: how config versions work in the console.