Bijoux d'occasion, WooCommerce store and Jewely ERP connector

Bijoux d'occasion sells second-hand jewelry in its shop and online. I have worked on its WooCommerce store since 2019, and in 2026 I built the connector that links it to Jewely, the shop's ERP, for stock, prices, product pages and orders.

Since 2019

I built the store's first WooCommerce site in 2019 on an Understrap child theme and kept it running until 2024. The site was then rebuilt as a block theme by the Sumotori team, which I am part of. For that new version I built the plugin that discounts products based on how long they have been in stock, since published on wordpress.org as Auto Discounts for WooCommerce, and the local-to-production sync tool that became Miroir Local Sync.

The double stock problem

Every piece is one of a kind. When a ring is sold in the shop, it has to leave the website as quickly as possible, otherwise an online customer may pay for an item that no longer exists. The other way round, an order placed online has to lock the piece in the ERP before a seller offers it at the counter.

The connector

The sumotori-jewely-connector plugin handles three flows. I first described them in a specification sent to the Jewely technical team, revised three times as I tested their API.

Stock and prices. The site receives ERP changes through webhooks. Since a notification can get lost, a nightly job picks up every entry changed since the last run, filtering on its update date, and only writes when a value differs. A full catalogue rebuild can be started from the admin, and runs automatically every Sunday.

Product pages. When a piece is flagged as "visible on the website" in the ERP, the connector creates the WooCommerce product, imports its photos and records it in a mapping table. Existing products are matched by their reference, with no duplicates.

Orders. A web order creates the customer in Jewely if needed, then a reservation, a sale or a deposit depending on the case. When the API rejected a payment format, the sale is created on hold and the payment is recorded as a deposit, which leaves the seller a complete trail to reconcile.

What the API imposes

The Jewely API is capped at 60 requests per minute and returns prices in cents. The OpenAPI documentation did not always match the real API, so I checked each point against the production API before writing it into the code (which stock field to use, filters ignored server-side, static key authentication).

Every write goes through Action Scheduler, the job queue bundled with WooCommerce. A failed call is retried three times with an increasing delay, every exchange is logged in the WooCommerce logs, and the seller gets an email if the failure is final.

Where the project stands

The connector is at version 0.4. The shop and the website rely on the same source, the ERP, and an online order reaches Jewely in the form sellers already use at the counter. A few points still depend on Jewely, such as the list of events sent by webhook or recording the payment on a sale. They are tracked in the specification, and the plugin documents the workaround in place for each of them.