Core concepts

Five objects explain the whole API.

Product

The central catalog item, owned by Nembol. Carries the full merchandising surface: title, description, short_description, brand, category, tags, mpn, vat_rate, weight/dimensions, images[] (up to 20) and variants[] — each with SKU, price, msrp (strikethrough price on channels that support it), quantity, barcode, grams (per-variant shipping weight) and variant-specific images. Prices are decimal strings in the store's base currency (GET /store → currency).

Variants with options (e.g. Color/Size) must cover every combination of the option values — channels generate the full matrix, so sparse sets are rejected upfront instead of publishing broken listings.

A product can exist locally without being on any channel — including without images (it stays a local draft until published).

Listing

The projection of a product on one channel account — a first-class resource with its own id (list_…), status (listed, imported, ongoing, error, delisted), id_on_channel, url_on_channel and issues[] carrying the channel's own error message when something fails.

POST   /rest/v1/listings              {product_id, channel_account_id}   # publish
PATCH  /rest/v1/listings/{id}         {}                                 # re-sync
DELETE /rest/v1/listings/{id}                                            # delist

Publishing is idempotent per (product_id, channel_account_id) pair, and GET /listings?status=error is the query your retry logic should run.

Two channel-side behaviors worth knowing: some sellers configure per-channel price rules (a percentage or fixed adjustment), so the price on the channel can legitimately differ from the product price; and on WooCommerce the seller may have chosen to create products as drafts, in which case a listed listing exists on the store but its URL is not public yet.

Channel account

A connected account on a sales platform. GET /channel_accounts lists them with stable, opaque ids (chac_…) — if a seller has two eBay accounts, each is its own channel account, and the id never silently changes meaning even if accounts are disconnected and reconnected. The channel field carries the base platform (shopify, amazon, ebay, etsy, woocommerce, tiktok, …) — new ones appear as Nembol adds integrations, so tolerate unknown values.

Order

A normalized order ingested from any channel: per-order currency, normalized status and fulfillment_status, tracking, line items and buyer info including the full ship-to address (behind the orders:read scope). With orders:write, POST /orders/{id}/fulfillment marks it shipped, attaches tracking and (by default, when tracking is present) notifies the source marketplace.

Operation

The tracker for asynchronous channel work. The key thing to understand about Nembol writes:

1. The local write is synchronous. POST/PATCH return the updated resource immediately — what you wrote is what you get back.
2. Channel propagation is asynchronous. It runs through Nembol's channel workers, which respect each channel's own rate limits. The response's sync block gives you an operation_id; GET /operations/{id} reports per-channel results[] (succeeded, failed, channel_rate_limited, simulated), and an operation can end partial.

Instead of polling operations, subscribe to the operation.completed webhook.

How sync behaves

• Writes from the API are queued behind order-driven updates and dashboard actions — an integration can never starve order sync.
• When a channel throttles, Nembol backs off and retries; the operation shows channel_rate_limited in the meantime.
• Deleting a product delists it everywhere first, then soft-deletes locally. Irreversible.

Last updated on July 30, 2026