Integrations
Store, carriers and printers, actually connected
A module installed on PrestaShop that pushes the order the moment it is placed, stock chasing the storefront, a carrier register with tracking links, a print queue that sends the label to the printer in front of whoever is working, and API keys tied to a single owner. What you connect starts working on day one: the order lands the instant the customer pays, the storefront gets real availability, and the label comes out of the printer standing in front of the operator.
The order arrives as an event the moment it is placed; the scheduled sweep stays on as a safety net.
The body is verified before it is read: without the shared secret nothing gets in, not even by accident.
Availability changes and the variant joins the queue: the store catches up on the next pass, not at end of day.
A key sees one owner’s stock and nothing else, and the filtering is done by the server, not by the caller.
Every integration breaks sooner or later: the store goes down for an hour, a product is deleted, an order line arrives with a code we have never seen. The question is not whether it will happen, it is what happens next. In CargoNode no outside system talks to the warehouse directly: everything goes through two queues — what comes in and what has to go out — where every row carries its key, its attempts and its error. So an order is never lost quietly, and when something jams there is a screen that says so and a button that clears it.
What comes in, what goes out, and by which route
Before the detail, the whole list: what comes in on one side, what goes out on the other, and two queues in the middle that nothing bypasses — every event carrying its own key, a growing wait when the store does not answer, and a way out when something jams. It is the map of a working day: the order lands by itself, the goods leave with their label, and the store falls back in line without anyone pressing “sync”.
- The store: orders, customers, payments and refunds coming in; catalogue, categories, images, price lists, stock and confirmations going out
- The catalogue from a file, with a preview of the change before it is applied
- Supplier delivery notes and invoices read from a PDF or a photograph, and a draft purchase order out of them
- Carriers: register, shipment number, tracking link and load manifests
- Warehouse printers, read-only per-owner API keys, and alerts by email or towards a system of yours
| System | What comes in | What goes out | Today |
|---|---|---|---|
| PrestaShop store | orders, customers, payments and refunds | catalogue, categories, images, price lists, stock, confirmations | connected: a module on the store, signed calls, a recovery sweep |
| Catalogue from a file | items and price lists | — | connected: a preview of the change before it is applied |
| Supplier delivery note or invoice | the lines read from the PDF or the photograph | — | connected: a draft purchase order comes out of it |
| Carriers | — | shipments, numbers and load manifests | connected: carrier register, shipment number and a tracking link that builds itself |
| Printers | — | labels and documents | connected: the label comes out of the printer in front of whoever is working, with nothing to install on site |
| Whoever reads your stock | — | stock and orders, read-only | connected: an API key tied to a single owner |
| Alerts | — | email, or a call to a system of yours | connected: an outbound queue with attempts and errors |
PrestaShop: a module on the store, not a fragile bridge
A CargoNode module is installed on the store and pairing happens with a one-time code: the store earns its credentials once, and from then on the two sides introduce themselves — who I am, which version I run, what you let me do. Every call is signed and the body is verified before it is read. When an order is placed the store says so immediately, so the order lands the instant the customer has paid instead of waiting for the next sweep; the scheduled sweep stays anyway, as a safety net for a store without the module, or one that could not reach us that day. In the other direction go the catalogue, categories, images, price lists, customers, order confirmations, payments and refunds.
- Pairing with a one-time code: the store earns its credentials once
- Every call signed, with the body verified before it is read
- The order arrives as an event, not only when the sweep gets to it
- A periodic catch-up sweep for anything that did not make it
- Catalogue, categories, images, price lists and customers published from warehouse to store
- Store statuses map onto yours: what gets fulfilled and what waits
- The storePRESTASHOPThe module calls the moment the order is placed, and the call is signed.
- Inbound queueWITH ITS OWN KEYEvery event carries its own key: a resend does not create a second order.
- The warehouseLEDGERThe order is in, its lines matched to variants and the customer recognised.
- Outbound queueWITH ITS RETRIESStock, prices, order confirmations, payments and refunds go back out.
- The storefrontPRESTASHOPIt lines up on the next sweep, not at the end of the day.
No outside system touches the warehouse — and when something does not add up
- Unknown lineThe line fails, not the order: that one waits in quarantine and the other lines go through.
- Store unreachableIt retries with growing waits, and past the threshold it is set aside and says so.
- Deleted productA permanent error, recognised as such: it stops at once instead of retrying for days.
Stock chasing the storefront, and prices with it
When a variant’s availability changes — a pick, a receipt, a reservation released — that variant joins a queue of things to realign, and the queue is drained again and again. The number that reaches the storefront is not a copy: it is stock minus active reservations, worked out at the moment it leaves. The same goes for prices, which come from the price lists rather than from a price field on the item: that is the difference between publishing a catalogue and publishing a catalogue with the prices you actually charge. And a reconciliation compares what the store shows with what the warehouse says, so drift is found before a customer finds it.
- A queue of variants to realign, drained again and again
- Availability worked out from active reservations, never a copied number
- Published prices come from the price lists, not from a price field on the item
- Reconciliation between storefront and warehouse, to surface the drift
- Connector scope: which warehouses it publishes from and for which owners
- How many connectors a customer may have is a number on their row, not a tier
- ON HAND40 units on the shelfSKU-4471 · A-12-3
- RESERVED−12 already committed to confirmed ordersactive reservations
- ON SALE28 availablecomputed as it leaves
- QUEUED2 variants to realigndrained over and over
The figure that reaches the storefront is not a copy: it is stock minus the active reservations. And a reconciliation compares what the store shows with what the warehouse says, to catch the drift before a customer does.
When something does not add up: quarantine, not silence
An order line with a code we do not know does not fail the order: the line fails, the order sits in quarantine and the other lines go through. You link the missing variant and replay it, without retyping anything. Deliveries towards the store retry with growing waits and, past a threshold, are set aside instead of going on forever; permanent failures — a product that no longer exists on the store — are recognised as such and stop straight away, because hammering a closed door for days has never fixed anything and it buries the real problems. Jammed syncs sit in a list, with the way out next to them.
- An unmapped line fails the line, not the order
- Quarantine with remapping and replay, no order retyped by hand
- Retries with growing waits, then a declared set-aside
- Permanent failures recognised: no retrying for days against a deleted product
- A list of jammed syncs, with the way out beside each one
- Every event carries its key: a resend never creates a second order
- QUARANTINEorder 2026-1187 · 1 unmapped linethe other lines went through
- RETRYINGorder confirmation · third attemptgrowing waits
- SET ASIDEstock update · past the thresholdset aside, and it says so
- PERMANENTthe product no longer exists on the storeit stops at once
Every row carries its way out next to it: link the variant and resend, or close the sync. Nothing is lost in silence, and nothing retries forever.
Bringing in what you already have
The catalogue can be imported from a file, but you look before you leap: the preview shows the change — what is created, what changes, what stays — and only then do you apply it. Then there is paper, which nobody has abolished yet: a supplier delivery note or invoice is uploaded as a PDF or a photograph and read line by line, matching what it recognises against your catalogue by barcode, supplier code or your own code. Out of that comes a draft purchase order — never a direct stock movement, because an automatic reading must not be able to touch stock — and the supplier price list is updated with the prices just read.
- Catalogue import from a file, with a preview of the change before applying it
- Supplier delivery notes and invoices read from a PDF or a photograph
- Lines matched to the catalogue by barcode, supplier code or your own code
- What comes out is a draft purchase order, never a direct stock movement
- The supplier price list is updated with the prices just read
- You upload the PDF or the photographThe supplier delivery note or invoice, exactly as it arrived.
- The lines get matchedBy barcode, by supplier code or by your own code.
- You look at the ones it did not recogniseThe others are already linked to the catalogue, and you leave them alone.
- A draft purchase order comes outNever a movement: an automatic reading must not be able to touch stock.
Carriers, tracking and load manifests
Carriers are a register, not a free-text field retyped every time: code, name, service and the address template the tracking link is built from. The ones commonly used in Italy are already in it, plus a generic one for the rest. A shipment carries its carrier and its number, and the link builds itself out of those two; the statuses — in transit, out for delivery, delivered, exception, returned — are kept as a history, not as one value overwritten. Load manifests are numbered, closed and if need be reopened, and printed for the driver to sign. You put the statuses in as the carrier updates you, or they come in from the store: each one stays a line with who put it there and when, so what happened to a shipment is read back instead of reconstructed from memory.
- A carrier register with service and the address template for tracking
- Shipment number on the document, with the tracking link building itself
- Transit, delivery, exception and return statuses kept as a history
- Load manifests numbered, closed and reopened, printable for the driver
- Multi-parcel shipments with the real weight, not an estimate
- Every status change is one more line, with who recorded it and when: the history is never overwritten
- CARRIERfrom the register, with its service typenot free text
- NUMBERthe tracking link builds itself from itfrom the URL pattern
- STATUSin transit · out for delivery · deliveredplus exception and returned
- HISTORYevery status change stays a linewith who recorded it and when
The load manifest is numbered, closed and reopened when needed, and printed for the carrier who signs it.
Labels and printers that live in the warehouse
Printing starts from the browser of whoever is working: the queue hands them the label, they send it to the printer in front of them and confirm it came out. There is nothing to install on site, and the queue deduplicates: pressing twice does not produce two labels. With no label printer the label still comes out, on any ordinary printer: there is a built-in 10×7 cm layout, with the field that identifies the parcel set large, a Code128 barcode that genuinely scans, and a page break between one parcel and the next. Anyone who does have a label printer writes their own template in ZPL using the document’s placeholders — consignee, shipment number, parcel, location — so the label comes out the way they want it on their own machine, and the test print says straight away whether it is centred. And if a print agent already runs inside your network, the queue is ready for it: an API key, an atomic claim so two never take the same job, and the print outcome coming back.
- A print queue with a dedupe key: two clicks do not make two labels
- Printing from the browser of whoever is working: nothing to install on site
- A built-in 10×7 layout with a Code128 barcode and a page break between parcels
- Your own ZPL template, with the document’s placeholders and a test print to centre it
- An on-site print agent hooks onto the queue: API key, atomic claim, print outcome returned
- Location, item, carton and shipment labels, and a register of your printers
| Route | Who sends the label to the printer | What you install | When it fits |
|---|---|---|---|
| From the browser of whoever is working | the page open in the warehouse | nothing | the normal road: it prints straight away, from any workstation |
| A program inside your network | an on-site agent that takes the jobs off the queue | your own agent | when you already run a print agent, or printers the browser cannot reach |
The public API and per-owner keys
There is a public read-only surface for stock, orders and the identity of whoever is calling. The key is not generic: it is bound to one owner, and the filtering is done by the server — it never comes from the caller, because wrong scoping would show one owner’s goods to another, which is the worst way there is to lose a client. The key is shown once: what stays with us is its fingerprint, not the key. It has a visible prefix so you can recognise it in a list, an expiry date and the date it was last used, so you can see which ones are alive and which can be switched off.
- Reads of stock, orders and the owner’s own identity
- The key is bound to a single owner, and the server does the filtering
- The key is shown once: the fingerprint stays, the key does not
- Visible prefix, expiry date and last-used date
- A wrong key and a non-existent customer answer alike: nothing can be enumerated
- cn_a4f2…the prefix is visible, the rest is notshown once, and once only
- READSstock, orders, the owner’s own identityread-only
- FILTERSthe server does, never the callerone owner only
- EXPIRESwith the date it was last used next to ityou see which ones are alive
What stays with us is the fingerprint, not the key. And a wrong key and a non-existent customer answer the same way: nothing is enumerable.
Outgoing mail, alerts and handhelds
Alerts are declared as rules — a reorder threshold, a drift between ledger and stock — and go to whoever you choose, by email or towards a system of yours. The mail really goes out: the sender starts as a platform address that works with nothing to configure, and becomes your own domain once you verify it. Every message has a row in the outbound queue, with its attempts, its error and a button to retry: an alert that never left is visible there, instead of being discovered through a complaint. Handhelds work on the same idea, checking in regularly to say who is online, on which version, and what they have been doing.
- Alert rules on thresholds and drift, with recipients per channel
- Real email: a platform sender with no setup, or your own verified domain
- A channel towards a system of yours, for whoever wants the events elsewhere
- An outbound queue with attempts, errors and a manual retry
- Handhelds checking in: who is online, on which version, and what they did
Frequently asked questions
We sell on Shopify or WooCommerce: is there a connector?
The channel that is connected and proven on real data is PrestaShop, with a module installed on the store. What sits underneath — the two queues, the deduplication, the mappings, the quarantine — is the same for any channel, and a second store plugs in there without touching the warehouse: when you need one it is a project with a date, and we look at it together before anyone commits.
Does the carrier update the tracking by itself?
The carrier and the shipment number sit on the document and the tracking link builds itself, so the carrier’s page opens straight from the order. Transit and delivery statuses are yours to record — or they come in from the store — and they are kept as history, with who recorded them and when. A direct connection to a carrier’s own portal is a piece of work in its own right, using your credentials with that carrier: we look at it together when you need it.
The printer is in the warehouse and the software is in the cloud: how does it print?
The browser of whoever is working does the printing: the queue hands them the label, they send it to the printer in front of them and confirm it came out — with nothing to install in the warehouse. If you would rather a program on site collected the jobs, because a cloud service cannot reach into your network, the queue is already built for it: an API key, an atomic claim so two never take the same job, and the print outcome coming back. That agent lives on your side of the network and is hooked up once. Either way the jobs stay in the queue until somebody collects them, and none is lost.
If the store is down for an hour, do I lose orders?
No. Orders the store could not send are picked up by the catch-up sweep, which runs at regular intervals for exactly this reason. In the other direction, whatever we owed the store stays in the queue and goes out when it answers, with growing waits so we do not hammer it the moment it comes back.
Can I let a client see their stock without giving them full access?
Yes: you give them an API key bound to their owner record. They read their own stock and their own orders, from their own system or from a portal of yours, and see nothing else — the filter is applied by the server and cannot be worked around by the caller. Keeping different owners apart is what the third-party logistics module is for.
Let us look at what you already have connected
Tell us which store you sell through, which carrier you ship with and what printers sit in your warehouse. We will show you one of your own orders landing by itself and its label coming out, and what would change in the working day of the people on the floor.
Talk to us