API keys

Two credentials, two very different jobs. Sending the wrong one to this API fails closed.

The secret key

dyj_sk_ followed by 48 hex characters. It authorises reading an entire feed — your cost prices and your margins — so it belongs on your server and nowhere else.

DYJ stores only a SHA-256 hash of it. That is not a policy we could relax later: there is no column in our database that could reproduce your key, so nobody at DYJ can read it back to you, and a database breach does not yield working credentials. It is displayed exactly once, when you generate it.

The public key

dyj_live_ is a different kind of credential entirely. It is designed to sit in your page’s JavaScript, where anyone can read it, and it is protected by the list of domains you authorise rather than by secrecy. It drives the 3D viewer embed and is rejected by this API.

Rotation

Generating a new secret key replaces the old one immediately. There is no overlap window and no second active key, which means:

• deploy the new key to every server that uses it, then rotate; not the other way round;
• a rotation during a catalogue sync will fail that sync — run it between syncs.

After rotating, the dashboard shows only the last four characters and the date. Use those to confirm which key a server is presenting: our request logs record the same four characters and never any more of the key.

Revoking

Revoking removes the key without minting a replacement. Every request stops on the next call — there is no cache to expire.

If your storefront is static

A fully static site has no server to hold the key, and there is no safe way to put it in the browser: anyone viewing source would have your cost prices. Two workable options:

• A small proxy. One function on your host that holds the key, calls this API, and returns only what your page needs. Twenty lines, and your key never leaves the server.
• Build-time fetch. Pull the catalogue during your site build and commit the output. Prices are then as fresh as your last deploy, which is fine for a slow-moving catalogue and wrong for a fast one.

Stage 6 will add hosted integrations for the common platforms so neither is necessary.