Core concepts

Five objects explain the whole API.

Product

The central catalog item, owned by Nembol. Carries the full merchandising surface: title, description (the one text every channel publishes, HTML allowed; short_description is only a deprecated alias of it), 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, even without images (it stays a local draft until published).

Listing

The projection of a product on one channel account. It is 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 an id never points to a different account. The id is kept when an expired login is reconnected (channel_account_id). Disconnecting removes it: connecting that account again gives a new id, the old one answers 404 channel_account_not_found, and the listings it had now carry the new id in channel_account_id (listings belong to the account's place, not to the id). Store ids, and on channel_account.connected re-read GET /channel_accounts and your listings. 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, so 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, so 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 never touches the channels: while it is still live on one, DELETE /products/{id} answers 422 product_still_listed, so delist each listing first (while a delist is still running it answers 409 listing_operation_in_progress: wait for it, then delete). A deleted product can be brought back with POST /products/{id}/restore; its photos are kept for 30 days, after that it comes back without them. See Delist and clean up.

Last updated on October 22, 2026