Intégration de l’API vendeur Temu : guide complet

Ce qu’est réellement l’API vendeur Temu

Une intégration de l’API vendeur Temu consiste à développer une application sur la documentation de la Partner Platform, à obtenir l’autorisation d’un vendeur, puis à appeler les points de terminaison de Temu en son nom. La documentation présente cette plateforme comme l’espace dédié au développement des partenaires et à la gestion des applications. Les deux principaux cas d’usage sont les applications d’ERP et de gestion d’entrepôt : des logiciels qui permettent aux vendeurs de gérer leurs produits, commandes et stocks sur Temu et d’autres canaux.

Trois faits déterminent toutes les décisions de conception qui suivent :

• Tout passe par une requête POST. Temu a supprimé les autres méthodes de requête. Chaque appel est donc un POST signé vers une URL de routage unique, et le point de terminaison visé est indiqué par une valeur type dans le corps, par exemple bg.order.list.v2.get.
• L’autorisation est propre à chaque vendeur. Sans l’accord du vendeur, l’application ne peut pas appeler les API de gestion de sa boutique.
• L’API est versionnée dans le nom de la méthode. La documentation annonce Add Products API V3.0, tandis que la recherche de commandes et l’expédition sont passées en V2. La référence répertorie également des méthodes bg.* et temu.*. Vous devez donc figer les noms de méthodes et les vérifier à nouveau lorsque Temu annonce des changements.

La référence regroupe les méthodes liées aux produits, aux commandes, à l’expédition, au service après-vente, aux promotions, à la conformité, à la publicité et aux entrepôts partenaires. Ce guide couvre le parcours que toute intégration doit suivre : accès, autorisation, choix de l’hôte, signature, limites de débit, commandes, produits et webhooks.

Qui peut obtenir l’accès : application interne ou application partenaire ?

Deux possibilités existent. Le bon choix dépend des boutiques que vous souhaitez connecter.

La différence concrète concerne la détention des identifiants. Avec une application interne, le vendeur crée l’application, choisit les autorisations et reçoit directement le token d’accès dans Seller Center. Avec une application partenaire, vous détenez la clé et le secret de l’application, tandis que chaque boutique cliente vous fournit son propre token. Ce second scénario pose un problème de gestion des secrets dans un environnement multi-tenant, qui réapparaît dans la section consacrée aux limites de débit.

Comment fonctionne l’autorisation de l’API vendeur Temu

Le guide d’autorisation vendeur de Temu précise que l’accord du vendeur doit être obtenu avant d’utiliser les API de la plateforme. Il définit deux méthodes :

1. Autorisation manuelle. Le vendeur autorise l’application dans Seller Center et sélectionne les permissions à accorder, ce qui détermine le périmètre d’accès de l’API. Le token d’accès est ensuite affiché au vendeur, qui vous le transmet.
2. Autorisation par callback. Le consentement suit la même étape, mais Temu redirige le navigateur du vendeur vers votre URL de callback avec un code d’autorisation. La redirection ne contient pas de token : vous échangez le code contre un token avec la méthode bg.open.accesstoken.create.

Pour le parcours par callback, vous dirigez le vendeur vers le Seller Center correspondant à son site, avec votre clé d’application, votre URI de redirection et une valeur state. Pour une boutique américaine, le format documenté est https://seller.temu.com/open-platform/client-manage/authorization?appKey=YOUR_KEY&redirect_uri=YOUR_CALLBACK&state=YOUR_STATE. Les vendeurs transfrontaliers et locaux se connectent à des backends différents pour autoriser l’application. Le lien doit donc pointer vers le bon environnement.

Ce qu’il faut construire autour de ce parcours

• Utilisez la valeur state comme clé de tenant. Placez-y une valeur signée et utilisable une seule fois, qui associe le code retourné au bon client et à la bonne boutique. Vérifiez dans le sandbox qu’elle est bien renvoyée dans la redirection avant de vous y fier.
• Stockez le token avec son hôte. L’autorisation étant liée au Seller Center d’un site, l’enregistrement d’une boutique doit conserver ensemble le token, la région et l’hôte.
• Traitez une erreur de permission comme une demande de réautorisation. Comme le périmètre d’accès est choisi lors du consentement, une application qui doit ensuite ajouter, par exemple, l’expédition des commandes à l’accès aux produits devra demander une nouvelle autorisation au vendeur. Prévoyez dès le départ un parcours de reconnexion de la boutique.

Quel hôte de l’API Temu utiliser selon la région ?

Temu publie trois hôtes de production, qui utilisent tous le même chemin /openapi/router. Le guide des points de terminaison précise qu’une boutique américaine utilise l’hôte US et qu’une boutique européenne utilise l’hôte EU.

Ne codez pas un hôte en dur. Déduisez-le de l’enregistrement de la boutique et conservez cette correspondance dans la configuration afin de pouvoir ajouter un nouveau site sans déploiement. Les données produit et les devises varient également selon le site : une fiche conçue pour un site ne doit pas être considérée comme valide sur un autre.

Comment signer une requête de l’API Temu

Chaque appel contient une signature ; les requêtes dont la signature est invalide sont rejetées. La méthode documentée utilise MD5 sur une chaîne déterministe construite comme suit :

1. Rassemblez tous les paramètres de la requête : les paramètres communs (type, app_key, access_token, data_type, timestamp) ainsi que les champs propres à la méthode. Ils se trouvent tous au niveau supérieur du corps JSON.
2. Triez les noms de paramètres par ordre ASCII croissant.
3. Concaténez le nom et la valeur de chaque paramètre sans séparateur. Les objets et tableaux imbriqués sont ajoutés sous forme de texte JSON.
4. Placez votre app_secret au début et à la fin de cette chaîne.
5. Calculez le MD5 du résultat et convertissez la valeur hexadécimale en majuscules. Il s’agit du champ sign, à ajouter au corps avant l’envoi.

Voici une implémentation fonctionnelle. Elle reproduit la signature de l’exemple détaillé du guide de signature de Temu (4CCF219942D4180C6DDA3CE36C1B838F pour le payload d’expédition documenté). C’est le test à exécuter avant de faire confiance à un signataire, y compris au vôtre.

import hashlib
import json
import time

import requests

HOSTS = {
    "us": "https://openapi-b-us.temu.com/openapi/router",
    "eu": "https://openapi-b-eu.temu.com/openapi/router",
    "global": "https://openapi-b-global.temu.com/openapi/router",
}


def to_str(value):
    """Serialize one parameter value for the signing string."""
    if isinstance(value, str):
        return value
    if isinstance(value, bool):
        return "true" if value else "false"
    if isinstance(value, (dict, list)):
        return json.dumps(value, separators=(",", ":"), ensure_ascii=False)
    return str(value)


def sign(params, app_secret):
    """Sort by key, join key+value, wrap in app_secret, MD5, uppercase."""
    body = "".join(key + to_str(params[key]) for key in sorted(params))
    raw = app_secret + body + app_secret
    return hashlib.md5(raw.encode("utf-8")).hexdigest().upper()


def call(region, method, app_key, app_secret, access_token=None, **payload):
    params = {
        "type": method,
        "app_key": app_key,
        "data_type": "JSON",
        "timestamp": int(time.time()),
        **payload,
    }
    if access_token:  # absent only when exchanging the auth code for a token
        params["access_token"] = access_token
    params["sign"] = sign(params, app_secret)
    response = requests.post(HOSTS[region], json=params, timeout=30)
    response.raise_for_status()
    return response.json()

Les erreurs fréquentes lors de la signature

• Les payloads imbriqués. L’exemple détaillé sérialise le tableau imbriqué de manière compacte, et l’ordre des clés de sa chaîne de signature diffère de celui du payload original présenté quelques lignes plus tôt. Ne partez pas du principe que l’ordre n’a aucune importance. Si un appel avec des paramètres simples est correctement signé mais qu’un appel contenant des listes imbriquées échoue, vérifiez d’abord la sérialisation et l’ordre des clés, puis validez un appel imbriqué dans le sandbox avant de généraliser.
• Les valeurs non couvertes par l’exemple. L’exemple détaillé utilise des chaînes, des entiers et un tableau imbriqué. Les booléens et les nombres décimaux ne sont pas illustrés : testez-les dans le sandbox au lieu de vous fier à une supposition.
• L’échange ne contient pas encore de token. Lorsque vous échangez un code d’autorisation contre un token d’accès, vous ne disposez pas encore de token. Signez avec les paramètres disponibles, raison pour laquelle l’aide ci-dessus rend access_token facultatif.
• L’horloge et le format. L’exemple utilise un timestamp Unix en secondes. Utilisez la même unité.

Le guide développeur fournit également un exemple de requête Python et un guide Postman, tandis que la plateforme propose des boutiques de test dans le sandbox. Testez chaque nouveau point de terminaison dans le sandbox avant de l’utiliser.

Limites de débit de l’API Temu et bonnes pratiques

Le guide consacré aux limites indique que la limite initiale est généralement de 20 requêtes par seconde pour chaque clé d’application. Ces limites peuvent être ajustées dynamiquement ; si vous avez besoin de davantage de trafic, Temu vous demande de contacter l’équipe partenaire par e-mail en expliquant votre besoin.

Le point essentiel concerne l’unité de limitation : elle s’applique à la clé d’application, et non à une boutique. Dans une application partenaire, tous les vendeurs connectés partagent donc le même budget. Trente boutiques qui lancent une synchronisation complète de leur catalogue au même moment vont se limiter mutuellement.

• Placez un seul limiteur devant tous les appels à Temu, associé à la clé d’application, plutôt que de laisser chaque worker limiter son propre trafic.
• Répartissez les planifications. Attribuez à chaque boutique un décalage différent et ajoutez une part d’aléa afin que les synchronisations ne démarrent pas toutes simultanément.
• Privilégiez les événements au polling. Les webhooks ci-dessous vous évitent de lister les commandes chaque minute pour chaque boutique.
• Réessayez avec un backoff et une limite maximale, et journalisez séparément les appels limités afin de détecter la pression avant que le client ne la subisse.

Synchroniser les commandes et l’expédition avec l’API Temu

Le parcours des commandes repose sur une courte liste de méthodes. Ces noms proviennent de la référence actuelle. L’espace Postman public de Temu a annoncé le passage en V2 des interfaces de recherche de commandes et d’expédition : vérifiez donc la référence avant de figer un nom, car l’exemple du guide de signature utilise encore un nom de méthode d’expédition plus ancien.

Modélisez soigneusement trois éléments :

• L’identification. Temu distingue une commande parente (parentOrderSn) d’une commande (orderSn). Utilisez les deux pour identifier vos imports et rendez-les idempotents afin qu’un nouvel essai de la liste ne crée jamais de doublon.
• Les colis. Les guides d’intégration incluent des exemples d’expéditions fractionnées : une commande ne correspond donc pas toujours à un seul colis. Conservez les colis comme des enregistrements distincts.
• Les données personnelles. Les informations d’expédition sont chiffrées et disposent de leur propre méthode de déchiffrement. Déchiffrez-les au moment de créer l’étiquette, excluez l’adresse en clair des journaux et supprimez-la dès qu’elle n’est plus nécessaire.

Gérer les produits, les stocks et les prix via l’API

La création des fiches est la partie la plus lourde de l’API. Les modèles de catégories, les attributs, les images et les données de conformité alimentent tous une même opération de création.

• Définissez d’abord le code SKU externe. Il sert de clé de rapprochement entre votre catalogue et les identifiants Temu. L’ajouter après la création de milliers de fiches est une opération pénible.
• Considérez la publication comme asynchrone. Une méthode dédiée au statut de publication existe : envoyez la fiche, vérifiez ensuite son statut et transmettez les raisons d’échec au marchand.
• Ne considérez pas le prix comme un simple champ. L’API comprend des méthodes de proposition et de recommandation de prix en plus des modifications directes. Consultez le guide de gestion des prix avant d’écrire une logique de repricing.
• Gardez la synchronisation des stocks simple et rapide. Le surstockage est l’échec le plus coûteux : envoyez les changements dès qu’ils surviennent et effectuez un rapprochement planifié.

Webhooks Temu : événements disponibles et utilisation

Temu documente quatre types d’événements. Les payloads sont courts : ils contiennent des identifiants et un statut, pas la commande complète.

• L’événement déclenche une action, mais ne contient pas les données. À sa réception, placez-le dans une file et répondez rapidement, puis appelez la méthode de détail de la commande pour obtenir la source de vérité.
• Faites attention aux unités de temps. Les événements de commande utilisent les secondes, tandis que les événements après-vente utilisent les millisecondes. Normaliser les deux unités dès la réception évite les erreurs d’ordre chronologique.
• Récupérez à nouveau l’adresse lorsqu’un événement de changement d’adresse survient avant d’imprimer l’étiquette.
• Conservez un polling de rapprochement. Des webhooks peuvent être manqués lorsque votre endpoint est indisponible. Un appel planifié de liste pour détecter les écarts constitue une précaution peu coûteuse.

Intégration directe de Temu ou couche multicanale ?

Vous pouvez appeler Temu directement ou passer par une couche qui centralise plusieurs marketplaces derrière une API unique. Aucune solution n’est toujours préférable.

Le compromis concerne les abstractions uniformes. Un schéma commun à plusieurs marketplaces masque précisément les comportements qui rendent chacune différente. C’est particulièrement visible dans les flux après-vente, de conformité et de gestion des prix de Temu.

Si vous préférez confier le développement Temu à une équipe ayant déjà livré des intégrations marketplace pour les fiches, les stocks, les commandes et le suivi, le service d’intégration marketplace de Netalith couvre Temu ainsi qu’Amazon, eBay, Walmart, Etsy, Shein et Shopee.

Checklist de mise en production d’une intégration Temu

Si vous souhaitez faire vérifier le périmètre avant d’engager du temps de développement, demandez un devis gratuit à Netalith en indiquant les canaux et les workflows à connecter.