The configurator has become table-stakes for high-AOV jewelry. Customers expect to pick a setting, choose a centre stone, see the price update, and order. What they don’t expect — and what most builds fail to deliver — is the configurator actually telling the truth about availability. The price is right. The stone they’re configuring is the stone they’ll receive. Both of those things turn out to be hard.
This is the story of building a real-time engagement-ring configurator on Shopify Plus that pulls live diamond inventory from four supplier feeds — IDEX, RapNet, Polygon, and Nivoda — via JewelCloud. It’s the kind of build where the architecture decisions on day one decide whether the project succeeds at month four.
Why “real-time” matters here
Most engagement-ring builders use a static catalog: the merchant uploads a list of stones they have access to, customers pick from that list, the merchant sources the stone after the order is placed. This works until two failure modes hit:
- The customer picks a stone that’s been sold to someone else in the meantime. The merchant has to either source a substitute (rarely well-received) or refund.
- The merchant’s static price doesn’t reflect a recent supplier price change. They eat the margin or have to call the customer for an upcharge.
Both kill conversion at the worst possible point — the customer has already committed to the purchase. The fix is for the configurator to reflect actual supplier-side state, in something close to real time, with pricing that resolves at the moment of order.
The supplier landscape
The four supplier feeds we integrated each have their own personality:
- IDEX — the largest by volume, broadest catalog, generally the cheapest stones at any given spec.
- RapNet — the trade standard for pricing reference; cleaner data, smaller catalog.
- Polygon — niche but with stones the others don’t carry, particularly fancy shapes.
- Nivoda — modern API, good developer ergonomics, growing inventory.
JewelCloud sits in front of all four, providing a more uniform API surface. We integrated through JewelCloud rather than going direct, partly to reduce the integration count from four to one, partly because JewelCloud handles the ugly normalization between supplier-specific data shapes.
The unified diamond model
Each supplier returns slightly different fields, with slightly different conventions. A diamond’s clarity might be “VS1” in one feed and “VS-1” in another. Cut grade enums vary. Fluorescence representations differ. The first job was to define a single internal diamond shape that every supplier feed could be normalised into:
- Shape (round, princess, oval, etc.) — controlled vocabulary.
- Carat (decimal).
- Color grade (D–Z, controlled).
- Clarity grade (FL, IF, VVS1–VS2, SI1–SI2, I1–I3, controlled).
- Cut grade (excellent / very good / good / fair / poor, controlled — applies to round only).
- Polish, symmetry, fluorescence — each on its own controlled scale.
- Measurements (length, width, depth in mm).
- Certification (GIA, IGI, AGS, etc.) with cert number.
- Supplier identity, supplier SKU, supplier-side stock state.
- Wholesale price (from supplier).
This model is the bedrock of the whole project. Everything downstream — the configurator UX, the price logic, the order routing — assumes it. The week we spent locking it down was probably the highest-leverage week of the entire build.
The configurator UX
Customers don’t think in 4Cs language until they’re guided to. The configurator opens with the simplest possible question (what shape ring?), then progressively reveals filters as the customer’s intent crystallises.
The crucial UX rule we held: the customer should never see a stone option that isn’t actually buyable right now. Filters disable as the customer narrows the search. If they pick “round, 1.2 carat, VS1,” and only seven stones in our normalised feed match, they see seven — not 200 with caveats. The pre-emptive disabling builds trust, and trust converts.
Performance with thousands of inventory updates per hour
The naive approach to “real-time” inventory is to call the supplier feed on every page render. This is wrong on two counts: it’s slow (multi-hundred-millisecond latency per call, often), and it racks up supplier API spend.
What we did instead:
- Pull supplier feeds on a schedule (every 10 minutes for full sync, every 60 seconds for high-priority delta updates).
- Store normalised stones in a fast key-value cache (Cloudflare R2 + Workers KV layer).
- Configurator queries hit the cache, not the suppliers — typical p75 response time under 400ms end-to-end.
- At order time, we re-validate the chosen stone against the live supplier feed before charging the customer. If the stone is gone (rare, given the sub-minute delta sync), we surface the issue immediately with three suggested alternatives at the same spec.
Cached reads, validated writes. The customer feels real-time because for browsing it effectively is, and the validation gate at order time catches the rare edge case before it becomes a customer-service ticket.
Pricing that resolves at the moment of order
Diamond wholesale prices change. Gold and platinum prices change. Setting prices change less, but the merchant’s per-category markup rules can change overnight. If we cache prices the way we cache inventory, customers will sometimes see a price that’s already stale by checkout.
The compromise: cache the display price (re-computed every 15 minutes on a worker), but resolve the charged price at checkout time using the latest market rates and merchant markup rules. If the resolved price is within 0.5% of the displayed price, charge it silently. If it’s outside that band, surface the change to the customer before completing the order.
In practice, the surfaced-change path triggers maybe once or twice a week across the entire store. Most customers never know the system is doing this. The merchant doesn’t eat margin on price drift.
Order fulfillment routing
Once the order is placed, the chosen stone has a supplier identity attached to it (from the unified diamond model). The fulfillment worker:
- Splits the order line: ring setting from the merchant’s own inventory, centre stone from whichever supplier owns it.
- Generates a per-supplier purchase order automatically.
- Pushes the PO to the supplier (via JewelCloud where supported, structured email otherwise).
- Tracks the supplier-side fulfillment state and surfaces a unified tracking timeline to the customer.
The merchant’s operations team touches the order only for exceptions. Happy-path orders flow through automatically.
What this kind of project really requires
The supplier integrations are not the hard part. The hard parts are: the unified data model (get this wrong and everything downstream is broken), the cache + validate pattern for performance and integrity, and the UX discipline of never showing options that aren’t actually buyable.
The result is a configurator that converts because it’s honest, performs because it’s cached intelligently, and operates because it’s automated end to end.
Building something similar? Tell me about it — happy to dig in.