A Temu order does not close when you pick it: it closes when Temu knows you picked it. Until the tracking number reaches their platform the order is still open on their side, and the clock running is not yours. That is the whole difference between an integration that works and one that only knows how to import orders.
The deadline comes with each order, not with your warehouse
Temu gives each order its own dispatch deadline. It is not a recommendation or an internal service target: it is a field that travels with the order (in Temu's API, expectShipLatestTime) and it is different for every line in your work queue. A warehouse that picks first-in-first-out will miss deadlines sooner or later, because arrival order and expiry order are not the same order. The rule is short: if the deadline is not inside Odoo, it does not exist, and what does not exist never gets prioritised.
The deadline has to reach the delivery note
Storing it on the sales order is not enough. The person picking does not look at sales orders: they look at delivery notes. The deadline has to travel from the order to the delivery, into a field the list can be sorted by, so the picking view is ordered by expiry and not by reference. It is the same work we covered in importing Temu orders into Odoo: if the field does not come in with the import, no later automation can invent it.
Confirming a shipment is two fields, and both have to be right
Temu is not waiting for a “shipped” flag: it is waiting for a carrier and a tracking number its system can actually follow. And the carrier must be identified by the code Temu recognises, not by whatever you named the delivery method in Odoo. A shipment confirmed with a carrier Temu cannot identify is a shipment their platform cannot track, and it ends up treated almost the same as one you never confirmed. The number comes from the carrier when the label is generated; the integration work is making that number go up on its own, the moment the delivery is validated, rather than when somebody remembers. How those labels are produced is in carrier labels and tracking in Odoo.
Classic trap: multi-parcel shipments. If the delivery produces three tracking numbers and the confirmation only pushes the first, the buyer sees one parcel and waits for three. Decide up front which number represents the shipment, and write it down.
What actually gets penalised when you miss it
It is not a line on an invoice: it is your account. An order dispatched late counts as a late shipment, and that metric is what Temu uses to decide your visibility and, if it repeats, to apply restrictions. An order with no valid tracking can end up cancelled, with the sale lost and the goods already on the road. The exact thresholds live in your seller terms: we are not going to quote you a percentage we have not measured. What is constant is the direction of travel: it is measured per order, it accumulates per account, and it recovers slowly.
The failure nobody sees: the confirmation that never went up
The dangerous case is not the visible error. It is the call that fails — the API does not answer, the token expired, the carrier is unmapped — and nobody notices, because the Odoo delivery was validated anyway. Internally the order is shipped; on Temu it is still open and the clock is still running. A serious integration stores the confirmation state on the delivery itself, tries again, and keeps the queue of what has not gone up in plain sight. Without that queue, the first warning arrives as an email from Temu. It is the same pattern we describe in when tracking never reaches Amazon.
What our connector does, and when you do not need it
If you ship five orders a day and never miss one, copying the number into the Temu panel is cheaper than any integration: do not hire us for that. It starts to pay off when several people are picking, when there are several carriers, or when the volume is enough for an order to get lost unnoticed. The Temu connector for Odoo brings each order's dispatch deadline into Odoo, pushes carrier and tracking number when the delivery is validated, maps your delivery methods to the carriers Temu recognises, and stores the state of every confirmation on the delivery itself (synced, pending or error, with the reason), with a button to resend it. The deadline sits on the Temu order record; sorting the delivery list by it is a custom adjustment we build on request. It runs on Odoo 17, 18 and 19, with migration to Odoo 20 the day it ships.
Frequently asked questions
When does the tracking go up?
On validating the delivery, and again if the tracking number is added or changed afterwards. If the call fails, the delivery is flagged with the error and can be resent with one button. Leaving it to an hourly cron gives away an hour of a deadline that is already tight.
What if the tracking number changes afterwards?
It can be pushed again while Temu still accepts changes on that order. Past that point the correction stops being a technical matter and becomes a seller-support case.
Does it work if a 3PL validates the deliveries?
Yes, as long as the tracking number ends up on the Odoo delivery. What changes is where the number comes from: instead of Odoo producing it with the label, it arrives from the 3PL. The confirmation towards Temu is exactly the same.
Useful links inside FlexigoTech
What we do about this
Missing Temu deadlines?
Tell us how many orders you move a day, which carriers you work with and who validates the deliveries. We will check whether the problem is a deadline that never reaches the warehouse, a badly mapped carrier or confirmations failing silently. Write to comercial@flexigobe.com or book a call.