Temu Seller API Integration: Auth, Signing, Orders, Webhooks

What the Temu seller API actually is

A Temu seller API integration means building an app on the Temu Open Platform, getting a seller to authorize it, and then calling Temu's endpoints on that seller's behalf. Temu's Partner Platform documentation describes the platform as the place for partner development and app management, with ERP and warehouse-management apps as the two headline use cases: software that lets sellers manage products, orders and stock across Temu and other channels.

Three facts shape every design decision that follows:

• Everything is a POST. Temu removed other request methods, so each call is a signed POST to a single router URL, and the endpoint you want is a type value in the body, for example bg.order.list.v2.get.
• Authorization is per seller. Without the seller's permission, the app cannot call the shop-management APIs at all.
• The API is versioned by method name. The documentation banner announces Add Products API V3.0, order query and shipment moved to V2, and the reference lists both bg.* and temu.* methods. You pin to method names, and you re-check them when Temu announces changes.

The reference groups methods into products, orders, shipping, after-sales, promotions, compliance, ads and cooperative warehouse. This guide covers the path every integration must walk in order: access, authorization, host selection, signing, rate limits, orders, products and webhooks.

Who can get access: self-developed app or partner app

There are two routes, and the right one depends on whose shops you will connect.

The practical difference is who holds the credentials. With a self-developed app the seller creates the app, chooses the permissions and receives the access token directly in Seller Center. With a partner app you hold the app key and secret, and every customer shop hands you its own token. That second case is a multi-tenant secrets problem, and it shows up again in the rate-limit section.

How Temu seller API authorization works

Temu's Seller Authorization Guide states that the seller's permission must be obtained before the open platform's APIs work, and it defines two ways to get it:

1. Manual authorization. The seller authorizes the app inside Seller Center and picks the permissions to grant, which defines the API scope the app can reach. The access token is then shown to the seller, who passes it to you.
2. Callback authorization. The same consent step, but Temu redirects the seller's browser to your callback URL with an authorization code. The redirect does not carry a token; you exchange the code for one with the bg.open.accesstoken.create method.

For the callback flow you send the seller to the Seller Center of their site with your app key, redirect URI and a state value. For a US shop the documented shape is https://seller.temu.com/open-platform/client-manage/authorization?appKey=YOUR_KEY&redirect_uri=YOUR_CALLBACK&state=YOUR_STATE. Cross-border and local sellers log into different backends to authorize, so the link has to point at the right one.

What to build around it

• Use the state value as a tenant key. Put a signed, single-use value there that maps the returning code to the right customer and shop. Confirm in the sandbox that it is echoed back on the redirect before you depend on it.
• Store the token with its host. Authorization is tied to a site's Seller Center, so a shop record should hold token, region and host together.
• Treat a permissions error as a re-authorization event. Because the granted scope is chosen at consent time, an app that later needs, say, order shipping on top of product access needs the seller to grant it again. Build a "reconnect shop" path into the product from day one.

Which Temu API host to call for each region

Temu publishes three production hosts, all using the same /openapi/router path. The rule in the endpoints guide is that a US store uses the US host and an EU store uses the EU host.

Do not hardcode one host. Resolve it from the shop record, and keep the mapping in configuration so a new site does not need a deploy. Product payloads also differ by site and currency, so a listing built for one site should not be assumed valid on another.

How to sign a Temu API request

Every call carries a signature, and requests with an invalid one are rejected. The documented method is MD5 over a deterministic string, built like this:

1. Collect every parameter of the request: the common ones (type, app_key, access_token, data_type, timestamp) plus the method's own fields. All of them sit at the top level of the JSON body.
2. Sort the parameter names in ascending ASCII order.
3. Concatenate name and value for each parameter with no separator. Nested objects and arrays go in as JSON text.
4. Put your app_secret at both the head and the tail of that string.
5. MD5 the result and uppercase the hex digest. That is the sign field, added to the body before sending.

Here is a working implementation. It reproduces the signature from the worked example in Temu's own signature guide (4CCF219942D4180C6DDA3CE36C1B838F for the documented shipment payload), which is the check you should run before trusting any signer, yours included.

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()

Where signing goes wrong

• Nested payloads. The worked example serializes the nested array compactly, and the key order in its signing string differs from the order in the original payload shown a step earlier. Do not assume order is irrelevant. If a call with flat parameters signs correctly but a call with nested lists fails, look at serialization and key order first, and verify one nested call in the sandbox before you generalize.
• Values the example does not cover. The worked example uses strings, integers and one nested array. Booleans and decimals are not shown, so test them in the sandbox instead of trusting a guess.
• The exchange call has no token. When you trade an authorization code for an access token, you have no token yet. Sign with the parameters you do have, which is why the helper above makes access_token optional.
• Clock and format. The example uses a Unix timestamp in seconds. Send the same unit.

The developer guide also ships a Python request example and a Postman guide, and the platform provides sandbox test shops. Run every new endpoint against the sandbox first.

Temu API rate limits and how to design around them

The rate-limiting guide says the initial limit is typically 20 requests per second for each app key. The limits are dynamically adjustable, and if you need more traffic Temu asks you to contact the partner team by email with the reason.

The detail that matters is the unit: the limit is attached to the app key, not to a shop. If you build a partner app, all your connected sellers draw from the same budget. Thirty shops each running a full catalog sync at the top of the hour will throttle each other.

• Put one limiter in front of all Temu calls, keyed by app key, instead of letting each worker throttle itself.
• Spread schedules. Give every shop its own offset and add jitter, so syncs do not all start at the same moment.
• Prefer event-driven work over polling. The webhook events below exist so you do not have to list orders every minute for every shop.
• Retry with backoff and a cap, and log throttled calls separately so you see the pressure building before a customer does.

Syncing orders and shipping with the Temu API

The order flow maps to a short list of methods. These names come from the current reference, and Temu's public Postman workspace announced the order query and shipment interfaces moving to V2, so check the reference before you pin a name (the signature guide's own example still uses an older shipment method name).

Model three things deliberately:

• Identity. Temu separates a parent order (parentOrderSn) from an order (orderSn). Key your import on both and make it idempotent, so a retried list call never creates a duplicate order.
• Packages. The integration guides include split-shipment examples, so one order does not always mean one package. Keep packages as their own records.
• Personal data. Shipping details come back encrypted and have their own decrypt method. Decrypt at label time, keep the plain address out of logs, and delete it when you no longer need it.

Managing products, stock and prices through the API

Listing is the heaviest part of the API. Category templates, attributes, images and compliance data all feed one creation call.

• Set the external SKU code first. It is the join key between your catalog and Temu's IDs. Retrofitting it after thousands of listings exist is painful.
• Treat publishing as asynchronous. A dedicated publish-status method exists, so submit, then poll the status and surface the reasons back to the merchant.
• Do not treat price as a plain field. The API includes price-proposal and suggested-price methods alongside direct price changes. Read the price management guide before you write any repricing logic.
• Keep stock sync dumb and fast. Overselling is the expensive failure, so send stock changes as they happen and reconcile on a schedule.

Temu webhooks: which events exist and how to use them

Temu documents four event types. The payloads are small: identifiers and a status, not the full order.

• The event is a trigger, not the data. On receipt, write the event to a queue and answer quickly, then call the order detail method to get the truth.
• Mind the time units. Order events carry seconds and after-sales events carry milliseconds. Normalizing both to one unit at the door avoids ordering bugs.
• Re-fetch the address on an address-change event before you print a label.
• Keep a reconciliation poll. Webhooks can be missed while your endpoint is down, so a scheduled list call that catches gaps is cheap insurance.

Direct Temu integration or a multichannel layer?

You can call Temu directly or connect through a layer that fronts many marketplaces with one API. Neither is always right.

The trade-off is flat abstractions. A common schema across marketplaces hides exactly the behavior that makes each one different, and Temu's after-sales, compliance and price flows are where that shows first.

If you would rather hand the Temu build to a team that has shipped marketplace integrations for listings, inventory, orders and tracking, Netalith's marketplace integration service covers Temu alongside Amazon, eBay, Walmart, Etsy, Shein and Shopee.

Production checklist for a Temu integration

If you want a second pair of eyes on scope before you commit engineering time, request a free quote from Netalith and describe which channels and workflows you need to connect.