An Amazon order does not close when the parcel leaves the warehouse: it closes when Amazon receives the shipment confirmation with its carrier and its tracking number. Until then the order is still open as far as Amazon is concerned, even if the goods are out for delivery. That notice is an API call, and it is made either by your ERP or by a person retyping numbers.
Amazon sets the deadline, and there is one per order
Every order arrives with its own latest ship date. It is not a recommendation or an internal target: it is the promise Amazon made to the buyer on your behalf. That date has to travel from the order to the Odoo delivery and be visible to whoever picks, because the order that matters in the warehouse is deadline order, not arrival order. Pick first-in-first-out and you are late on the urgent ones and early on the rest.
What happens when you confirm late
Amazon measures two different things and penalises them separately: shipments confirmed after the deadline, and tracking it cannot follow. The exact thresholds are published by Amazon in your account health dashboard and revised from time to time, so check them there rather than in an article. What is stable is the consequence: the metric degrades, the buyer can cancel at no cost and, if it persists, your ability to sell is restricted.
In FBA you read the status; in FBM you write it
This is the most common confusion. With FBA you confirm nothing: Amazon picks and ships, and the tracking number is born in their system, not yours. What you need there is the opposite path — pulling that status into Odoo so the delivery closes and two versions of the truth stop coexisting. With FBM it is the other way round: you ship and you report, within the deadline. A mixed operation does both at once on the same catalog, which is why every order has to know which type it is from the first moment.
If you sell through FBA, shipping status is only one part: stock, returns and reimbursements move inside Amazon's warehouse without you touching them. Developed in Amazon FBA inside Odoo.
The carrier code decides whether the tracking counts
Amazon does not accept arbitrary text in the carrier field: it has its own list of codes and tracks the shipment against the one you declare. Send the right number with the wrong carrier, or with a generic «other», and the tracking exists but Amazon cannot follow it — for metric purposes it is as if you never sent it. That is why the mapping between your Odoo carrier and the Amazon code has to be an explicit, editable table, not a string hard-coded somewhere.
Where the carrier connector meets the marketplace connector
The meeting point is the delivery order. The healthy sequence is: the order arrives with its Amazon reference and its deadline, it gets picked, the delivery is validated, the carrier connector requests the label and returns the tracking number, and only then does the Amazon connector send the confirmation with that number and the right code. Invert the order and you confirm shipments that have no label yet. Leave the two unlinked and somebody retypes numbers, and that somebody gets one wrong on a Tuesday afternoon.
The defect we most often find when reviewing other people's integrations sits exactly there: the confirmation runs in the background, fails — the API returns an error, the token expired, the carrier was slow to issue the number — and nobody notices, because the Odoo delivery is already validated and green. The confirmation has to leave a trace on the order: sent, failed, retried, with whatever Amazon answered. A job that fails silently is worse than no integration at all, because it also gives you confidence.
One order, two parcels
Partial shipments are the case almost nobody prepares for. If an order leaves in two consignments, Amazon expects two confirmations with their lines and quantities, not one carrying the tracking of the first parcel. In Odoo those are two deliveries against the same sales order, so the mapping has to be per line and not per order. Building it properly from the start costs little; fixing it after two hundred orders were confirmed wrongly does not.
When this is worth automating and when it is not
If you ship ten orders a day and confirm them by hand in Seller Central in five minutes, you do not need an integration for this: you need a routine and a reminder. Automation pays off when retyping numbers has become a job, when several carriers are involved, or when the same catalog sells in several places and nobody knows what has gone out. Telling you otherwise would be selling you something you do not need.
The Amazon connector for Odoo covers this lane: a carrier mapping table, per-line confirmation with tracking number, the confirmation status and Amazon's last error shown on the delivery itself, automatic retries and, on FBA, reading status instead of writing it. It runs on Odoo 17, 18 and 19. The carrier connectors are in the module catalog, and how to wire them without surprises is in carrier labels and tracking in Odoo.
Frequently asked questions
How often does Odoo tell Amazon the order has shipped?
At the moment the delivery is validated, and a scheduled action retries the pending ones every few minutes. Leaving retries at one hour is risky: the deadline eats that hour.
Can I confirm a shipment without a tracking number?
Amazon allows it in some cases, but that shipment counts as having no valid tracking, and that is measured too. If the carrier issues a number, send it with its code.
Does it work if somebody else built the carrier connector?
Yes, as long as it leaves the carrier and the tracking number on the delivery. The link is made there; the carrier module does not need touching.
Useful links inside FlexigoTech
What we do about this
Missing Amazon's shipping deadlines?
Tell us how many orders you move a day, which carriers you use and whether you sell FBA, FBM or both. We will find where the chain breaks before touching anything. Write to comercial@flexigobe.com or book a call.