3D embeds

Showing the piece itself, not only its data — and why that uses a different credential.

Two credentials, two directions

This API is server-to-server and returns product data. The 3D viewer is the opposite: it runs in your visitor’s browser and returns product geometry. They therefore authenticate differently, and the secret key must never appear in the page.

The embed uses your public dyj_live_ key, which is safe to ship to a browser because it only works on the domains you have authorised in your DYJ account. Add every storefront domain there before going live, including staging.

Placing a viewer

Each product in a search response carries a stable id. That is the handle the viewer takes. The embed snippet for a given feed is generated on the feed’s Integration tab in your dashboard — it is a single script tag plus an element, with no build step and no framework requirement.

Cross-customer 3D embedding ships in the next stage. Feeds and this read API are live now; serving another business’s 3D model on your domain is Stage 3 of the marketplace rollout. Until then, use the product photographs in the search response, which are yours to display today.

When a product goes away

A viewer whose product has left your feed does not error and does not show a broken frame. It renders a neutral, quiet unavailable state — because the person looking at it is your customer, not ours, and a stack trace on your product page helps nobody.

Your own page should do the same: if a sync no longer returns a product, take the buy button away before you take the picture away.