De Temu API koppelen aan Odoo: wat je aanvraagt, wat je leest en wat je schrijft

"Heeft Temu een API?" Ja. De nuttige vraag is een andere: wat moet je aanvragen om hem te gebruiken, wat kun je lezen, wat kun je schrijven en wat gebeurt er als hij nee zegt. Die vier antwoorden bepalen of de integratie een piek aan bestellingen aankan of de eerste drukke vrijdag omvalt. Op volgorde.

De credentials zijn geen gebruikersnaam en wachtwoord

Temu werkt als elke serieuze marketplace: er is een geregistreerde applicatie, met sleutel en geheim, en er is een autorisatie die de winkel aan die applicatie verleent. Daaruit komt een token dat verloopt. De integratie moet weten wanneer en ruim op tijd waarschuwen, zodat je de autorisatie kunt vernieuwen voordat die afloopt. In Odoo betekent dat: het token staat in een systeemparameter met rechten, niet in een tekstveld waar iemand ooit iets in plakte en waar niemand meer aan denkt. En het betekent dat de synchronisatie op de dag dat de winkel de autorisatie intrekt moet stoppen en een melding geven, en niet een week lang stilletjes blijft falen.

Welke families van endpoints je echt nodig hebt

De exacte namen verschillen per versie van de API; de families niet, en het zijn er vijf. Bestellijst per tijdvenster, om het nieuwe op te halen zonder de hele historie op te vragen. Besteldetail, waar regels, variant, bedragen en belastingen in zitten. Verzendbevestiging, met vervoerder en trackingnummer, het enige waar Temu naar kijkt om je als nagekomen te beschouwen. Catalogus, om productpagina's te publiceren en bij te werken. En voorraad, die los van de catalogus staat omdat hij duizend keer vaker verandert. Een integratie die alleen de eerste twee dekt, is geen integratie: het is een importer.

Elke familie wordt uitgewerkt in de twee zusterartikelen: bestellingen importeren zonder gegevens te verliezen en producten en prijzen synchroniseren.

Voorraad is de aanroep die je het vaakst doet

Een winkel met 2.000 referenties die elke vijftien minuten alle voorraad opnieuw doorstuurt, doet 192.000 schrijfacties per dag om met wat geluk tweehonderd cijfers te wijzigen. Dat is geen synchroniseren: dat is quotum verbranden. Het juiste is alleen te sturen wat sinds de vorige verzending is veranderd, gegroepeerd in batches, en daarnaast direct bij te werken wanneer een verkoop een referentie bijna op nul brengt. Een hoge frequentie voorkomt oververkoop niet; een veiligheidsmarge wel.

Limieten: de API is geen database die je naar believen kunt bevragen

Elke marketplace-API heeft een plafond aan aanroepen per tijdvenster, en vroeg of laat raak je het. Wat een gezonde integratie van een kapotte scheidt, is wat ze doet als het gebeurt. Een weigering wegens te veel aanroepen is geen fout die je negeert en vergeet: het is een opdracht om te wachten. De integratie moet opnieuw proberen met oplopende wachttijd, wat niet paste in een wachtrij zetten en in de volgende cyclus oppakken zonder iets dubbel te doen. Dit alles hoort in een jobwachtrij, niet in een lus binnen de cron. Als die wachtrij vastloopt, is het symptoom dat wat we beschrijven in geblokkeerde wachtrijen in Odoo.

Elke aanroep loggen is geen paranoia: het is het enige bewijs

Als een bestelling niet verschijnt, of Temu zegt dat het trackingnummer nooit is ontvangen, win je de discussie met het log of helemaal niet. Per aanroep moet je bewaren: het exacte tijdstip, het endpoint, de verzonden body, de statuscode en het ontvangen antwoord, en het betrokken bestelnummer of de betrokken referentie. Zonder geheimen of tokens in leesbare tekst, en met een redelijke bewaartermijn zodat de tabel de schijf niet opvreet. Dit is het eerste waar we naar kijken bij het auditen van een connector die iemand anders heeft gebouwd, en het ontbreken ervan is de oorzaak van de helft van de gevallen die niet te diagnosticeren zijn, zoals die we beschrijven in veelvoorkomende fouten bij een marketplace-API.

Wat onze connector doet (en wat niet)

De Temu-connector voor Odoo dekt de vijf families: hij importeert bestellingen per tijdvenster, bevestigt verzendingen met vervoerder en trackingnummer, publiceert producten en SKU's en stuurt de voorraad per SKU, gegroepeerd per artikel. De winkel wordt geautoriseerd met de code die Temu uitgeeft, en de connector bewaart wanneer het token verloopt en toont of de verbinding nog leeft. Hij synchroniseert via cron en via webhook, bewaart het verzoek en het antwoord van elke verzendbevestiging en de inhoud van elke ontvangen webhook, en als Temu een methode naar een nieuwe versie brengt, herhaalt hij de aanroep met de nieuwe versie.

Wat hij nu niet doet, zonder omwegen: hij stuurt niet alleen de voorraad die is veranderd, want bij elke run stuurt hij die van alle gekoppelde referenties; hij heeft geen jobwachtrij met oplopende wachttijd en hij logt niet elke aanroep. Een weigering wegens de limiet komt in het serverlog terecht en wordt bij de volgende cron-run opnieuw geprobeerd. Hij werkt op Odoo 17, 18 en 19. Als je aan het afwegen bent of dit past of een middleware erbovenop, vind je de vergelijking in middleware of native connector: er zijn gevallen waarin het juiste antwoord niet wij zijn.

Veelgestelde vragen

Handige links binnen FlexigoTech

Wat wij hieraan doen