Partner program: manage many stores

For software vendors (ERPs, agencies) that run Nembol for their own customers: one company each, one key, one invoice.

The partner program lets you manage many Nembol stores (one per customer company) from a single key. Your customers never log into Nembol and get no email from us: you drive everything through the API, and we bill you once a month for all of them at your negotiated rates.

Partner access is enabled by Nembol after the partner agreement: write to developer@nembol.com. Your key then needs the accounts:manage permission.

Start in the sandbox

Your partner account starts in sandbox: up to 3 open companies, real channels, webhooks and orders, and nothing is billed. Build and test the whole integration there; when you are ready, press Go live in Settings → Partner (a card first, on card terms): billing starts that day and the same key and companies go live. See Test your integration.

Your key and the dashboard

Two dashboard pages matter, in the partner account's own Nembol login:

  • Settings → Developers: create the API key. Choose Live (in sandbox a Live key runs everything for real and nothing is billed; a Test key only simulates calls and can't create real companies). The Read & write preset includes accounts:manage, needed for every partner endpoint; the form lists every permission the key gets.
  • Settings → Partner: your companies (with a Companies / Billing switch), the month's statement per plan, your payment method, and a Sandbox notice while the account is in sandbox. It shows the same data as GET /accounts, GET /partner/statement and GET /partner/billing.

Your merchants never use the dashboard: everything for their companies goes through the API.

1. Create a company

curl -X POST https://api.nembol.com/rest/v1/accounts \
  -H "Authorization: Bearer $NEMBOL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Acme Srl", "plan": "pro", "country": "IT", "reference": "ERP-123"}'
{ "id": "acct_66f0a1", "object": "account", "name": "Acme Srl", "plan": "pro",
  "status": "active", "product_limit": 2000, "channel_accounts": 0, "products": 0 }
  • plan: basic, pro, enterprise or enterprise_plus. The company gets that plan's limits (products, channel accounts, features).
  • Billed from today, prorated. No trial. Change the plan any time with PATCH /accounts/{id} (prorated too).

2. Work inside a company

Add Nembol-Account to any request. The rest of the API works exactly as if the company had its own key:

curl https://api.nembol.com/rest/v1/products \
  -H "Authorization: Bearer $NEMBOL_API_KEY" \
  -H "Nembol-Account: acct_66f0a1"

Rate limits and Idempotency-Keys are counted per company, so one busy company never slows down the others.

3. Connect the company's channels

Create a connection link and send it to the seller. They only log in to their channel account:

curl -X POST https://api.nembol.com/rest/v1/channel_connections \
  -H "Authorization: Bearer $NEMBOL_API_KEY" \
  -H "Nembol-Account: acct_66f0a1" \
  -H "Content-Type: application/json" \
  -d '{"channel": "amazon", "params": {"country": "US"}, "return_url": "https://erp.example.com/nembol/done"}'

Some channels ask which account to connect after the seller logs in (Amazon with several marketplaces, Google Merchant Center, Facebook Catalog with several businesses). The connection then becomes needs_choice with choices: show them in your app (or let an agent pick) and send the choice:

curl -X POST https://api.nembol.com/rest/v1/channel_connections/conn_8a12/choose \
  -H "Authorization: Bearer $NEMBOL_API_KEY" \
  -H "Nembol-Account: acct_66f0a1" \
  -H "Content-Type: application/json" \
  -d '{"value": "A2EUQ1WTGCTBG2"}'

Register your return_url once on your own store (POST /redirect_urls): every company uses it (GET /redirect_urls inside a company lists it with inherited: true).

After the login the seller's browser lands on your return_url, with these added to its query string (yours are kept, so put your own company id there):

ParameterValue
connection_idconn_…; read it with GET /channel_connections/{id}
statusconnected, failed, needs_choice or expired
channel_account_idchac_… when connected
errorthe reason when it failed: channel_login_failed, link_expired, link_already_used, plan_not_eligible, subscription_inactive, slot_no_longer_available, different_channel_account
account_idthe company (acct_…)
https://erp.example.com/nembol/done?company=42&connection_id=conn_8a12&status=connected&channel_account_id=chac_77b0&account_id=acct_66f0a1

Links that can't be used come back here too (expired, already used, or refused), so the seller always ends in your app, never on a Nembol error page.

The return link carries Nembol ids only, never the channel's codes or tokens. The marketplace sends its authorization code to Nembol, which exchanges and keeps the tokens and talks to the channel for you. You keep working with your key and Nembol-Account.

The query string only tells the browser what happened: anyone can open your return_url with made-up parameters. Before marking the channel connected in your app, confirm from your server with GET /channel_connections/{connection_id} (and Nembol-Account) that status is connected, or wait for the channel_account.connected webhook.

A connection link works once and for one hour. Opened again or after the hour, it sends the seller back to your return_url with error=link_already_used or error=link_expired (without a return_url the seller sees a Nembol page), so create a new connection. Channels connected with API keys (Kaufland, OnBuy, PrestaShop, Subito) don't need a link: POST /channel_connections with the keys in params answers connected at once, or channel_credentials_rejected with the channel's reason.

After connecting

  • Nothing is imported unless you asked (import_products, import_orders on POST /channel_connections); your ERP publishes its own products.
  • Disconnected an account and connecting the same shop again? The next connection of that channel brings it back (reconnects_shop); for a different shop send new_account: true. See Connect a channel.
  • Every sync switch starts off: set the ones the merchant wants with PATCH /channel_accounts/{id} (e.g. sync.quantity_from_orders: true so a sale on the channel lowers the stock everywhere).

4. Webhooks or polling

Register your endpoints once, on your own store: they receive the events of all your companies, each with account_id.

Prefer polling, or want a safety net? GET /events?created_after=… with your key and no Nembol-Account returns your own events and all your companies' in one feed (each with account_id); add account=acct_… for one company. Events are kept 30 days.

A typical ERP integration

  1. Company: POST /accounts when a customer signs up in your ERP; keep the acct_… next to your own customer id (reference holds yours).
  2. Channels: POST /channel_connections → send the link → the seller comes back to your return_url (above).
  3. Products: look a product up by SKU (GET /products?sku=…), then PATCH /products/{id} or POST /products. Each variant needs its own SKU, and products with options need every combination (S/M × Red/Blue = 4).
  4. Publish: POST /listings (or /listings/batch for many) with the channel account. A product needs at least one image. Follow the status with the listing.status_changed webhook.
  5. Stock: POST /inventory/batch with SKU + quantity (up to 100 items).
  6. Orders: order.created webhook, with GET /orders as the safety net (see below). One order holds all its lines.
  7. Shipping: POST /orders/{id}/fulfillment with the tracking.

Rules the integration should know are collected in Rules and limits.

5. Billing

  • One invoice a month for all your companies: each on its plan, at your rate (a discount on our list price or a flat price per plan).
  • GET /partner/statement?month=2026-10 lists each company, its plan, the days it was billable and the amount. It matches the invoice.
  • Pay by card (charged automatically) or by invoice (30 days). You can also pay months in advance (e.g. by bank transfer): the credit is used by the next invoices, and GET /partner/billing shows what is left (credit_balance).
  • 14 days after an unpaid invoice your companies become read-only (orders and stock keep syncing, nothing is deleted) until it is paid.

6. Close a company

POST /accounts/{id}/close stops its billing today. Its listings stay on the channels and its data is kept, like any Nembol user who leaves. It can't be reopened.

Closing can't be undone, so it asks for a confirmation first:

  1. The first request answers 409 confirmation_required with a description of the consequences and a confirmation.token.
  2. Show the consequences to the person. If they agree, repeat the same request with the header Nembol-Confirmation: <token>. The token works once and expires after 10 minutes.

See Confirmations and undo.

What companies can't do

  • /billing on a company answers 409 billed_by_partner.
  • Writes on a suspended or closed company answer 409 account_suspended / account_closed; reads still work, so you can export a closed company's products, orders and customers.
  • The Nembol-Account header only works with a key that has accounts:manage. Any other key gets 403 insufficient_scope on every request that carries the header, before anything is read: give a reporting or single-purpose key no accounts:manage and it can't reach any company.
  • Creating products beyond the plan's limit answers 409 product_limit_reached.

Last updated on October 22, 2026

Need help?

Email us and a human replies, usually within one business day.

On this page