«Does Temu have an API?» It does. The useful question is a different one: what you have to request in order to use it, what you can read, what you can write, and what happens when it says no. Those four answers decide whether the integration survives an order spike or falls over on the first busy Friday. In order, then.
The credentials are not a username and a password
Temu works like any serious marketplace: there is a registered application, with its key and secret, and there is an authorisation the shop grants to that application. Out of that comes a token that expires, and the integration has to know when and warn early enough to renew the authorisation before it lapses. In Odoo that means the token lives in a permissioned system parameter, not in a text field somebody pasted once and nobody remembers. And it means that the day the shop revokes the authorisation, the sync has to stop and say so, not keep failing quietly for a week.
The credentials belong to the seller, always. We do not resell access or share one application between clients: if you stop working with us tomorrow, the connection is still yours and there is nothing to hand back.
Which families of endpoints you actually need
The exact names change between API versions; the families do not, and there are five. Order listing by time window, to pull what is new without asking for the entire history. Order detail, which is where lines, variant, amounts and taxes live. Shipment confirmation, with carrier and tracking number, which is the only thing Temu looks at to consider you compliant. Catalogue, to publish and update listings. And stock, which sits apart from the catalogue because it changes a thousand times more often. An integration that covers only the first two is not an integration: it is an importer.
The detail of each family is developed in the two sibling articles: importing orders without losing data and syncing products and prices.
Stock is the call you make most often
A shop with 2,000 references that pushes the whole stock every fifteen minutes makes 192,000 writes a day to change, with luck, two hundred numbers. That is not syncing: it is burning quota. The right approach is to send only what changed since the last push, grouped in batches, plus an immediate update when a sale leaves a reference close to zero. High frequency does not prevent overselling; a safety buffer does.
Limits: the API is not a database you can query at will
Every marketplace API has a ceiling of calls per time window, and sooner or later you hit it. What separates a healthy integration from a broken one is what it does on impact. A rejection for too many calls is not an error to swallow and forget: it is an instruction to wait. The integration must retry with growing backoff, queue what did not fit and pick it up on the next cycle without duplicating anything. All of this belongs in a job queue, not in a loop inside the cron. When that queue jams, the symptom is the one described in blocked queues in Odoo.
Logging every call is not paranoia: it is the only evidence
When an order does not show up, or Temu says it never received the tracking number, the argument is won with the log or not at all. Per call you need: the exact timestamp, the endpoint, the body sent, the status code and the response received, and the order or reference affected. No secrets or tokens in clear text, and with a sensible retention so the table does not eat the disk. This is the first thing we look at when auditing a connector somebody else built, and its absence causes half the cases that cannot be diagnosed, like the ones in common errors against a marketplace API.
What our connector does (and does not)
The Temu connector for Odoo covers the five families: it imports orders by time window, confirms shipments with carrier and tracking number, publishes products and SKUs, and pushes stock per SKU, grouped by item. The shop is authorised with the code Temu issues, and the connector stores when the token expires and shows whether the connection is still alive. It syncs by cron and by webhook, keeps the request and response of every shipment confirmation and the content of every webhook received, and when Temu moves a method to a newer version it repeats the call against the new one.
What it does not do today, plainly: it does not push only the stock that changed, because each run sends every linked reference; it has no job queue with growing backoff; and it does not log every call. A rate-limit rejection lands in the server log and is retried on the next cron run. It runs on Odoo 17, 18 and 19, with migration to Odoo 20 the day it ships. If what you are deciding is this versus a middleware layer on top, it is compared in middleware or native connector: there are cases where the right answer is not us.
Frequently asked questions
Do I need a developer account with Temu?
Your shop needs to authorise the application from its seller panel. The credentials that come out of that are yours and the connector uses them; we do not resell access.
Can I test without risking the live shop?
Yes: bring up an Odoo test database with the real credentials and enable reads only. Reading orders and catalogue changes nothing on Temu; what you leave switched off until validated is listing publication, stock and shipment confirmation.
How often should I call the API?
There is no single number. Orders, every few minutes, because the shipping deadline is running. Stock, on change rather than on the clock. Catalogue, only when a listing genuinely changes. Calling more often than the data changes just burns quota.
Useful links inside FlexigoTech
What we do about this
Taking on the Temu API yourself?
Tell us how many references you move, which countries you sell in and who picks the orders. We will tell you which endpoint families you need and where you will hit the limits. Write to comercial@flexigobe.com or book a call.