A marketplace integration earns its keep the moment orders stop being retyped by hand. Jumia is the dominant marketplace across much of the region, and the shape of the problem is the same one every marketplace connector solves: pull orders from the seller API, turn each one into a sales order in Acumatica exactly once, keep stock and fulfilment status in sync, and reconcile what the marketplace actually paid you against what you invoiced. The details are where it goes wrong, so this walks the whole flow.
The shape of the integration
Jumia exposes a seller/vendor API (the Jumia Seller Center / marketplace API) that returns orders and their line items and accepts status updates back. Acumatica sits on the other side with its contract-based REST API. The connector in the middle is a scheduled worker that polls Jumia for new and changed orders, maps them, and pushes them into Acumatica as sales orders — and, in the other direction, pushes fulfilment and tracking back to Jumia when the order ships. Keep that worker outside Acumatica (a small service you control) rather than trying to poll an external marketplace from inside a graph; the ERP is the system of record, not the scheduler.
Mapping orders and SKUs
Two mappings decide whether the whole thing works. First, the Jumia SKU to the Acumatica inventory InventoryID — never assume they are the same string; keep an explicit cross-reference (a custom table or the item's cross-reference/alternate ID) so a seller-side rename does not silently create orphan lines. Second, the marketplace customer: most sellers book Jumia sales against a single "Jumia" customer (or one per marketplace) rather than creating a customer per shopper, because the marketplace is the party you invoice and settle with. Carry the Jumia order number into a Usr-prefixed field on the sales order so every imported order is traceable back to its source.
An unmapped SKU should stop that one order and raise an alert, not fail the whole batch and not guess. Silent guesses become mis-shipments. Treat "SKU not found" as a first-class, visible error state in the connector.
Make the import idempotent
You will poll the same order more than once — that is normal, not a bug — so the import has to be safe to run repeatedly. Before creating a sales order, check whether one already exists for that Jumia order number (query on the Usr external-ID field). If it exists, update status rather than creating a duplicate. This single check is the difference between a connector you trust and one that quietly double-ships. The contract-based API's PUT with a lookup key can do the upsert, but an explicit existence check keeps the logic obvious.
PUT /entity/Default/24.200.001/SalesOrder HTTP/1.1
Host: your-tenant.acumatica.com
Content-Type: application/json
{
"OrderType": { "value": "SO" },
"CustomerID": { "value": "JUMIA" },
"ExternalRef": { "value": "JUM-100238471" },
"Details": [
{ "InventoryID": { "value": "ACU-SKU-0091" },
"OrderQty": { "value": 2 },
"UnitPrice": { "value": 1499.00 } }
]
}Map ExternalRef (or your Usr field) to the Jumia order number and query it first. If the query returns a row, skip creation and only patch the status.
Inventory and fulfilment sync
Orders are only half of it. Available quantity should flow the other way so you do not oversell on Jumia stock you have already committed elsewhere — push availability updates on a schedule from Acumatica's inventory. When an order ships in Acumatica, push the fulfilment and tracking number back to Jumia so the marketplace marks it dispatched; Jumia's fulfilment SLAs are unforgiving, and a shipped-but-not-reported order counts against you. Drive that back-push off the shipment confirmation event, not off a nightly full sync, so status is timely.
Reconciliation and returns
The number Jumia deposits is not the sum of your order totals. Commissions, marketplace fees, and returns all come out in the settlement report. Import the settlement as its own reconciliation step: match each settled line to its sales order, book the commission and fees to the right expense accounts, and handle returns as credit memos / RMAs against the original order rather than editing it. Doing this in the ERP — rather than eyeballing a spreadsheet — is what makes the marketplace channel actually auditable at month-end.
Poll on a modest interval and request only orders changed since your last successful run (store a high-water mark), so you stay inside the marketplace's rate limits and never re-scan the entire history. On failure, retry from the last committed high-water mark, not from zero.
The failure modes to plan for
| Failure | Handling |
|---|---|
| Duplicate poll of same order | Existence check on external order number before create — upsert, never duplicate |
| Unmapped SKU | Halt that order, alert, leave the batch running |
| Jumia API unavailable | Retry with backoff from the stored high-water mark |
| Settlement ≠ order total | Reconcile fees/commissions/returns as explicit postings |
| Return after invoicing | Credit memo / RMA against original order, not an edit |
Wrapping up
A Jumia-to-Acumatica connector is not hard because the APIs are hard — it is hard because the boring guarantees are easy to skip: import each order exactly once, never guess at an unmapped SKU, push fulfilment back promptly, and reconcile settlements as real postings. Get those right and the channel runs itself; skip them and you are back to retyping orders and arguing with a spreadsheet at month-end. If you are wiring up a marketplace to Acumatica, reach out or keep reading through the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.