Connecter l'API de Temu à Odoo : ce que l'on demande, ce que l'on lit et ce que l'on écrit

« Temu a-t-il une API ? » Oui. La question utile est autre : que faut-il demander pour l'utiliser, que peut-on lire, que peut-on écrire et que se passe-t-il quand elle répond non. Ces quatre réponses décident si l'intégration tient un pic de commandes ou s'effondre le premier vendredi de soldes. Dans l'ordre.

Les identifiants ne sont pas un utilisateur et un mot de passe

Temu fonctionne comme n'importe quelle marketplace sérieuse : il y a une application enregistrée, avec sa clé et son secret, et une autorisation que la boutique accorde à cette application. On obtient un token qui expire, et l'intégration doit savoir quand et prévenir avec une marge suffisante pour renouveler l'autorisation avant son échéance. Dans Odoo, cela signifie que le token vit dans un paramètre système avec des droits, et non dans un champ texte que quelqu'un a collé une fois et dont plus personne ne se souvient. Cela signifie aussi que le jour où la boutique révoque l'autorisation, la synchronisation doit s'arrêter et prévenir, et non continuer à échouer en silence pendant une semaine.

De quelles familles d'endpoints on a vraiment besoin

Les noms exacts changent d'une version de l'API à l'autre ; les familles, non, et il y en a cinq. Liste des commandes par fenêtre temporelle, pour récupérer le nouveau sans demander tout l'historique. Détail de commande, où se trouvent les lignes, la variante, les montants et les taxes. Confirmation d'expédition, avec transporteur et numéro de suivi, la seule chose que Temu regarde pour considérer la commande comme honorée. Catalogue, pour publier et mettre à jour les fiches. Et stock, à part du catalogue parce qu'il change mille fois plus souvent. Si une intégration ne couvre que les deux premières, ce n'est pas une intégration : c'est un importateur.

Le détail de chaque famille est développé dans les deux articles frères : importer les commandes sans perdre de données et synchroniser produits et prix.

Le stock est l'appel le plus répété

Une boutique de 2 000 références qui renvoie tout le stock toutes les quinze minutes fait 192 000 écritures par jour pour modifier, avec de la chance, deux cents chiffres. Ce n'est pas synchroniser : c'est gaspiller du quota. Le bon fonctionnement consiste à n'envoyer que ce qui a changé depuis le dernier envoi, regroupé par lots, et à déclencher en plus une mise à jour immédiate quand une vente laisse une référence au bord de zéro. Une fréquence élevée n'évite pas la survente ; le stock de sécurité, si.

Limites : l'API n'est pas une base de données que l'on peut interroger à volonté

Toute API de marketplace a un plafond d'appels par fenêtre de temps, et tôt ou tard vous l'atteignez. Ce qui sépare une intégration saine d'une intégration cassée, c'est ce qu'elle fait à ce moment-là. Un rejet pour excès d'appels n'est pas une erreur que l'on avale et que l'on oublie : c'est un ordre d'attendre. L'intégration doit réessayer avec une attente croissante, mettre en file ce qui n'est pas passé et le reprendre au cycle suivant sans rien dupliquer. Tout cela vit dans une file de tâches, pas dans une boucle à l'intérieur du cron. Quand cette file se bloque, le symptôme est celui que nous décrivons dans files bloquées dans Odoo.

Journaliser chaque appel n'est pas de la paranoïa : c'est la seule preuve

Quand une commande n'apparaît pas, ou que Temu dit ne pas avoir reçu le numéro de suivi, la discussion se gagne avec le journal ou ne se gagne pas. Il faut conserver, par appel : l'instant exact, l'endpoint, le corps envoyé, le code et la réponse reçus, et l'identifiant de la commande ou la référence concernée. Sans secrets ni tokens en clair, et avec une durée de conservation raisonnable pour que la table ne dévore pas le disque. C'est la première chose que nous regardons lors de l'audit d'un connecteur réalisé par quelqu'un d'autre, et son absence est la cause de la moitié des cas impossibles à diagnostiquer, comme ceux que nous décrivons dans erreurs fréquentes face à une API de marketplace.

Ce que fait notre connecteur (et ce qu'il ne fait pas)

Le connecteur Temu pour Odoo couvre les cinq familles : il importe les commandes par fenêtre temporelle, confirme les expéditions avec transporteur et numéro de suivi, publie produits et SKU et envoie le stock par SKU, regroupé par article. La boutique est autorisée avec le code que délivre Temu, et le connecteur enregistre la date d'expiration du token et indique si la connexion est toujours active. Il synchronise par cron et par webhook, conserve la requête et la réponse de chaque confirmation d'expédition ainsi que le contenu de chaque webhook reçu, et si Temu passe une méthode à une version supérieure, il refait l'appel avec la nouvelle version.

Ce qu'il ne fait pas aujourd'hui, en toute clarté : il n'envoie pas uniquement le stock qui a changé, car à chaque passage il envoie celui de toutes les références liées ; il n'a pas de file de tâches avec attente croissante, et il ne journalise pas tous les appels. Un rejet pour limite reste dans le log du serveur et est réessayé au passage suivant du cron. Il fonctionne sous Odoo 17, 18 et 19. Si vous hésitez entre ceci et un middleware par-dessus, la comparaison est dans middleware ou connecteur natif : il y a des cas où la bonne réponse n'est pas nous.

Questions fréquentes

Liens utiles chez FlexigoTech

Ce que nous faisons sur ce sujet