Skip to content
Book a technical review
Aerial night view of a logistics container yard: long rows of stacked shipping containers under warm orange floodlights, with dark empty ground around them

Connecting ERPNext to e-commerce and logistics: an ERP integration that ended double data entry

Softwise connected a Lyon distributor's ERPNext instance to its e-commerce storefront and third-party logistics provider. Orders, stock, and invoices now flow automatically in both directions. Staff re-keyed every order before the integration; after it, orders move with no manual entry and stock accuracy on the storefront went from day-old to near real time.

Context

The client and the problem

Anonymized by design: industry and city, not names. The shape of the problem is the point.

The client

A B2B distributor near Lyon selling through a web storefront, with ERPNext running purchasing, inventory, and invoicing, and a third-party warehouse shipping the orders.

The problem

The three systems did not talk. Staff copied web orders into ERPNext by hand, emailed pick lists to the warehouse, and re-keyed tracking numbers back. The storefront showed yesterday's stock, so customers ordered items that were already gone. Staff time went into typing data from one screen into another, every week, indefinitely.

The constraints

ERPNext's API is not a happy path. Rate limits, mandatory-field chains that span doctypes, and behavior that shifts between Frappe releases. The integration had to treat ERPNext's constraints as the fixed point everything else adapts around.

No downtime in picking. The warehouse ships daily. Every flow — order in, pick list out, tracking back — had to switch over without the 3PL losing a single shipping day.

The client replaces systems on their schedule. The storefront vendor and the 3PL contract were both under review. Whatever was built could not assume either system stays.

Build

What we built

Decisions, not adjectives. Each one had an alternative we rejected.

An integration layer, not point-to-point glue

A small middleware service owns every flow, instead of each system calling the others directly. ERPNext, the storefront, and the 3PL each integrate once. When the client replaces any of the three, the other two are untouched.

Designed around ERPNext's actual behavior

ERPNext's REST API has real constraints: rate limits, mandatory-field chains that span doctypes, and customs that shift between releases. The connector respects them with queued writes, idempotent retries, and a reconciliation pass that catches anything a webhook missed. Integrations fail in the gaps between happy paths, so the gaps are where the engineering went.

Stock truth in one place

ERPNext is the single source of truth for inventory. The storefront reserves stock at checkout and confirms against ERPNext, ending the oversells that day-old CSV exports caused.

A queue with receipts

Every write into ERPNext goes through a PostgreSQL queue with idempotency keys, so a retry after a timeout can never double-create an order. A reconciliation pass compares what the queue believes was written against what ERPNext reports, and surfaces the difference instead of burying it.

Logistics as a first-class flow

Pick lists, shipment confirmation, and tracking numbers flow to and from the 3PL through the same middleware with the same idempotent guarantees, so the warehouse and the storefront agree on what has shipped without anyone re-keying a tracking number.

ERPNext integration: middleware topology and flowsERPNext, the e-commerce storefront, and the 3PL warehouse each integrate once with a Node.js middleware service. A PostgreSQL queue with idempotency keys carries every write into ERPNext, absorbing rate limits and retries safely. Orders flow in from the storefront, stock flows out, pick lists go to the warehouse and tracking numbers come back, and a reconciliation pass compares what the queue believes was written against what ERPNext reports. ERPNext is the single source of truth for inventory and invoicing. Hover or tap a component to trace its connections.ONE INTEGRATION POINT PER SYSTEMorderswebhook: order placedstock query + reservelive availabilityREST writes (rate-limited)webhooks: doc eventsdrainenqueue writespick listsship confirmationslabelstrackinginvoice triggerdocumentscompare + report driftStorefrontreserves stock at checkoutB2B customersLyon distributorMiddlewareNode.js · connector per systemPostgreSQL queueidempotency keys · retriesReconciliation passqueue beliefs vs ERPNext factsERPNextorders · stock · invoicesSOURCE OF TRUTH3PL warehousepicking · shipping · trackingCarrierslabels + trackingInvoicinggenerated in ERPNexteach system integrates once — replacing the storefront or 3PL touches nothing else
ERPNext integration topology for the Lyon distributor: ERPNext, the storefront, and the 3PL warehouse each integrate once with a Node.js middleware backed by an idempotent PostgreSQL queue and a reconciliation pass, so orders, stock, pick lists, tracking, and invoices move automatically in both directions with no re-keyed data.
Approach

How the engagement ran

Delivery order matters as much as what was built. Each phase had to be safe to stop on.

  1. /001/

    Phase 1 — One flow, end to end

    Orders from storefront to ERPNext, with the queue and reconciliation in place from the first day. The most valuable flow proved the pattern before anything else touched it.

  2. /002/

    Phase 2 — Stock and warehouse

    Added stock sync out to the storefront and the 3PL shipping loop: pick lists out, tracking back, both idempotent and reconciled.

  3. /003/

    Phase 3 — Invoicing and close-out

    Connected invoice generation and handed over runbooks for the failure cases that matter: ERPNext upgrades, webhook gaps, and how the reconciliation report reads.

Outcomes

Results and key facts

Qualitative outcomes and engagement shape, without invented numbers.

Re-keying eliminated

Orders, stock, shipments, and invoices move without manual entry. The staff hours that went into transcription go into the distribution work they were hired for.

Stock the customers can trust

The storefront shows near-real-time availability instead of yesterday's export, and checkout reserves against ERPNext as the source of truth. The oversells stopped.

Swappable systems

Because each system integrates once through the middleware, the client can replace the storefront or the 3PL without re-contracting the other two integrations — which mattered, because both contracts were under review.

Engagement
Build, then a support retainer
Systems
ERPNext (Frappe framework), e-commerce storefront, 3PL warehouse API
Stack
Node.js middleware, PostgreSQL queue, REST webhooks
Flows automated
Orders in, stock sync out, shipments and tracking back, invoices generated
Outcome
Re-keyed orders eliminated, stock on the storefront near real time instead of day-old
FAQs

Questions about this erp integration project.

The questions this project is usually asked about. Still stuck? Ask us directly.

Connecting an ERP system like ERPNext, Odoo, SAP, or Dynamics to the other software a company runs (storefront, warehouse, CRM) so data moves automatically instead of being re-typed by staff.

Point-to-point connections multiply: three systems need three links, five need ten. A middleware layer means each system integrates once, and swapping one system out does not break the others.

Scope drives it: the number of flows and how much cleanup the existing data needs matter more than the ERP brand. ERPNext being open source helps on one front: no licence gates and a documented API mean the integration starts on day one.

The middleware is the only component that speaks ERPNext's API, so an upgrade means adapting one connector, not re-testing every integration. Queued writes with idempotent retries absorb the short API windows during upgrade, and the reconciliation pass catches anything that slipped through.

Yes, and that is the point. Each new system — a marketplace, a carrier, an accounting tool — integrates once with the middleware and immediately reaches everything already connected. Adding the fourth system costs a fraction of the third.