List every shop under the authenticated Vendor Center account.

List brand codes/names known to the catalog (paginated).

List categories. Each category includes attributeSet.sid, which you need before create_products/update_products for a product in that category - pass it to get_attribute_set to see required/optional attributes and their allowed values.

List the attributes (required or not, allowed values/options, validation rules) for a category's attribute set. Get attribute_set_id from list_categories()'s attributeSet.sid field.

Scan the catalog for products that look outdated: QC-rejected and never fixed, ACTIVE with zero stock for a long time, or ACTIVE and untouched for a very long time. This is a HEURISTIC - the Vendor Center API has no "outdated" concept - so treat the result as a review list, not an automatic deletion queue. Nothing is changed by calling this; pair it with deactivate_products() after a human (or you, deliberately) has looked at the list.

Returns {scanned, flagged: [{listing, reasons}], truncated}. Each listing is a flattened (variation, businessClient) row that already carries variation_id (== productSid), seller_sku and business_client_code - i.e. exactly what deactivate_products needs, with no extra lookup required.

The closest thing to "removing" a product from Jumia: sets status to INACTIVE per business client. THIS DOES NOT DELETE THE LISTING - there is no delete endpoint in the published API; INACTIVE just makes it unsellable/hidden. If you actually need a listing permanently gone, that's a request to your Jumia account manager, not something this tool (or any seller-facing API call) can do.

products: [{"id": "<productSid, i.e. variation_id>", "sellerSku": "...", "business_client_codes": ["jumia-ng", ...]}] (accepts a singular "business_client_code" string too, for convenience when acting on one find_outdated_products listing at a time - those rows already have "variation_id"/"seller_sku"/"business_client_code" under exactly those names, just rename variation_id -> id).

Logs every call to the local audit log before returning.

Create new products (async feed). Poll the returned feedId with get_feed_status() until status is COMPLETED, then call it again (or list_products by sellerSku) to learn each product's real productSid and QC status - both are required before you can update stock, price or status on a newly-created product.

Each item in products (per the published schema): name: {"value": "...", "translations": [{"language": "en", "value": "..."}]} description: {"value": "...", "translations": [...]} sellerSku: str (required, your own unique SKU) parentSku: str (REQUIRED, despite the published schema marking it optional - confirmed live: omitting it on a standalone, non-variant product fails with "Required field [Product.ParentSKU] is missing or null." For a single listing with no size/color variants, just set this equal to sellerSku. Only set it to something else when you actually want to group size/color variants together - every product sharing a parentSku must then pass the SAME images.) variation: str (required if parentSku groups variants; for a standalone product, set it equal to sellerSku/name too) brand: {"code": ..., "name": "..."} category: {"code": ..., "name": "..."} (from list_categories) images: [{"url": "https://...", "primary": true}, ...] (>= 1 primary required) price: {"currency": "NGN", "value": 12000, "salePrice": {"value": 9000, "startAt": "2026-09-10", "endAt": "2026-09-20"}} stock: 50 attributes: [{"name": "color", "value": "Black"}, ...] (from get_attribute_set - call it first to see which attributes this category marks mandatory, e.g. product_weight/short_description are required for AC Chargers) businessClients: [{"businessClientCode": "jumia-ng", "price": {...}}, ...] (needed for a global/multi-country seller selling in local currency)

Before calling this for a real-world branded product, SEARCH for the manufacturer's actual spec sheet, description copy, and product image URLs (their regional store site) rather than inventing name/description/spec/image content - Jumia's own content guidelines expect accurate listings, and a fabricated spec (wrong wattage, invented weight, wrong included accessories) risks a QC rejection or a listing that doesn't match what ships. If the manufacturer's site blocks a plain fetch (403), a real browser session (e.g. claude-in-chrome) often gets through where a headless fetch doesn't. Only fields you truly cannot find published anywhere (e.g. shipping weight) should be flagged to the user as an unverified estimate rather than silently guessed.

Cap ~1000 products per call - this tool does not auto-chunk larger lists for you (chunk them yourself and call this repeatedly, tracking each feedId, so a failure in batch 6 doesn't force you to redo 1-5).

Update the MUTABLE subset of product fields (async feed): additional category, brand, config attributes, GTIN barcode, simple attributes, variation. This CANNOT change the main image, main category, parent SKU, price, or initial stock - use update_price / update_stock for price and stock, and be aware main image/category/parent SKU aren't changeable via this API at all once a product is created.

Each item needs the product's id (productSid) plus whichever fields you're changing.

Update price (async feed). Each item: {"sellerSku", "id", "category", "price": {"currency", "value", "salePrice": {"value","startAt","endAt"}}, "businessClients": [...]}. To clear a sale price, send salePrice's value/startAt/endAt as null rather than omitting salePrice entirely.

Update stock (async feed). Each item: {"sellerSku", "id", "stock"}.

Poll an async feed (returned by create_products/update_products/update_price/update_stock/deactivate_products) until status is COMPLETED or FAILED. For a PRODUCT_CREATION feed, this is also where you get each new product's productSid and QC status.

Reconcile your source of truth (an ERP export, a spreadsheet you've already parsed to JSON, etc) against what's live on Jumia right now, and push only the fields that actually changed - instead of you hand-writing separate create/update/price/stock calls.

desired: [{"sellerSku": "...", "price": 12000, "currency": "NGN", "stock": 50, "status": "ACTIVE"}, ...] (extend with brand/category/attributes if you also want update_products diffing - this baseline covers the highest-churn fields: price, stock, status.)

Looks up each sellerSku via list_products, diffs against desired, and by default (dry_run=true) returns the planned actions WITHOUT calling anything - review the plan first. Set dry_run=false to actually submit the price/stock/status feeds (batched, respecting the documented ~1000-item-per-feed cap) and get back the resulting feedIds.

Returns {matched, not_found: [sellerSku...], plan: {price: [...], stock: [...], status: [...]}, feed_ids: {...} (only when dry_run=false)}.

One page of GET /catalog/products with the documented filters. Use token from the previous response to get the next page.

One page of GET /catalog/stock.

Flag products that look like the same real-world item listed more than once: exact GTIN/EAN/barcode match, or same brand+category+images with a near-identical name. Jumia's seller API has NO merge endpoint, so this only reports clusters with a suggested canonical listing (live somewhere - ACTIVE + QC APPROVED on any business client - then oldest wins) - resolving it means you decide, then call deactivate_products() on the ones you're dropping. Narrow with category_code for large catalogs; this does a full paginated scan which gets expensive across an entire multi-country catalog.

One page of GET /orders. status/country accept comma-separated lists; omit status to get every status (there's no "ALL" value). Valid country codes: CI, DZ, EG, GH, KE, MA, NG, SN, TN, UG, ZA.

GET /orders/items for a specific order.

Cancel one or more order items. Requires the VC - Order Manager role on the calling application/user. No cancellation-reason field exists in this endpoint's schema - the audit log records who/when this tool was called, but not a business reason, so capture that elsewhere if you need it for SLA reporting.

List shipment providers available for an order item, including whether each requires a caller-supplied tracking code (use pack_orders_v2 if so).

Pack order items (v1). order_items: [{"id": "", "shipmentProviderId": "..."}]. Use pack_orders_v2 instead for any provider where get_shipment_providers reports trackingCodeRequired=true.

Pack order items (v2) - required when the shipment provider needs a caller-supplied tracking code. packages: [{"orderItems": [...], "shipmentProviderId": "...", "trackingCode": "..."}].

Mark packed order items ready to ship.

Get printable shipping labels for order items. Returns success.labels[] with a label field per item - inspect a real response to confirm its exact shape (raw bytes/base64/URL) before building anything that assumes one; the published schema doesn't say.

Create a consignment (inbound stock shipment to a Jumia warehouse). products: [{"sku": "...", "quantity": 10, "labelCode": "..."}]. shipping_date format is 'YYYY-MM-DD HH:mm:ss' (not ISO-8601, despite looking like it). Returns {purchaseOrderNumber}.

Update a consignment's shipping status. Dates are 'yyyy-MM-dd'.

Check received/quarantined/defective/canceled/returned/failed counts for stock sent to a Jumia warehouse.

List payout statements (for reconciling what Jumia has paid out against your own books). NOT financial/tax advice - just the raw statement data.