Temu Integration – Feature & Process Guide
Temu is a self-hosted, non-Mirakl marketplace that Pentagon Connect connects to directly through Temu's own seller API. Sellers authorize a Pentagon Connect (Hemi) application in their Temu seller account, and each region a seller sells into (EU, US, or the shared Mexico/Japan/global territory) is treated as its own connected account with its own access credentials and its own access token.
The integration covers product creation, price updates, stock updates, shipping template retrieval, order retrieval, order shipment (including partial shipment) by self-shipment, and read-only visibility of customer-initiated refunds and returns. Temu's own warehouse fulfilment option is not part of this integration. Temu does not allow sellers to initiate cancellations or refunds themselves — that information is retrieved and stored once Temu confirms it, but no cancellation or refund action can be sent back to Temu. General content updates (title, description, images, attributes) and listing deactivation are not currently covered.
Quick Reference
Product Management
| Capability | Supported | Notes |
|---|---|---|
| Create new products | Yes | Multi-step: images are uploaded to Temu first, then (where the category needs it) custom attribute values are registered, then the product itself is created. Single products and multi-variant listings are both supported. |
| Update price | Yes | Dedicated price-only update, per product variation group. Only the base/supplier price can be changed this way — not the RRP. |
| Update stock/quantity | Yes | Dedicated stock-only update, per product variation group |
| Update general content (title, description, images, attributes) | Not documented | No general content-update flow exists in the current source material — only creation, price and stock are covered |
| Deactivate / remove a listing | Not documented | No pause, close or delete flow is described for Temu listings |
| Product variants (colour/size etc.) | Yes | Via Temu's own sales attributes; attribute value combinations form variants automatically |
Pricing & Stock
| Capability | Supported | Notes |
|---|---|---|
| Update price after a listing is live | Yes | Base/supplier price only; Temu does not allow the RRP to be changed through this flow |
| Update stock/quantity | Yes | See Product Management above |
| RRP / strike-through pricing | Partial | Can be set when a product is created; automatically left out of the creation request if there's no RRP or the price isn't lower than it. No ongoing sync of RRP is documented. |
| Multi-currency pricing | Yes | Price and RRP are each set per listing with an explicit currency |
Orders & Fulfilment
| Capability | Supported | Notes |
|---|---|---|
| Automatic order import | Yes | Continuous; full order detail requires multiple sequential lookups per order |
| Ship orders (tracking + mark shipped) | Yes | Self-shipment by the merchant only |
| Partial shipment | Yes | Multiple packages/tracking numbers for one order, submitted together in a single call |
| Temu-fulfilled orders (Temu's own warehouses) | No | Out of scope for this integration |
Refunds, Returns, Cancellations & Claims
| Capability | Supported | Notes |
|---|---|---|
| Seller-initiated cancellation | No | Temu only allows the customer to cancel; there is no seller-facing cancellation action |
| Seller-initiated refund | No | Temu only allows the customer to start a refund; sellers cannot submit one through this integration |
| Refund & return visibility | Yes | Customer-initiated refunds are retrieved and stored automatically, read-only |
| Partial refund visibility | Yes | Refunded quantity is tracked back to the specific order line/SKU it applies to |
| Claims / incidents | Not documented | No claims or incident mechanism is described for Temu |
Product Management
Creating products
Creating a Temu listing is a multi-step process: product images are uploaded to Temu first, then — only for categories that allow free-text/custom attribute values — those custom values are registered with Temu, and finally the product itself is created. A shipping template (downloaded from Temu, one per product) must already be selected on the product before it can be created, and determines the maximum dispatch time Temu is told to expect for that product.
- Images have different size and aspect-ratio requirements depending on whether the category is Apparel or Non-Apparel, and are uploaded one at a time. If even one image in the set fails to upload, the whole product is blocked from creation.
- Category attributes (colour, size, brand, and so on) come from Temu's own product taxonomy and must be resolved before a product can be created. Every category has its own required/optional attribute set, and some categories only allow picking from Temu's predefined attribute values, while others also allow custom, free-text values that have to be registered with Temu first before they can be used.
- Where a product identifier is available, EAN is sent with priority, then UPC, then ISBN — whichever one is populated is what's sent.
- Both single products and multi-variant listings (e.g. the same item in different colours/sizes) are supported. A variant listing groups multiple SKUs under one product record, formed from the combination of Temu's own colour/size-style "sales attributes".
- Brand can optionally be set; when a brand is sent, the matching Temu trademark reference is resolved and included automatically behind the scenes.
- A size-chart image can be attached to a product. Temu doesn't disclose which categories require one before sales are allowed, so this is a silent risk for restricted categories — sales can be quietly limited even though creation itself succeeded.
Updating products
Price and stock can each be updated independently once a product is live — see Pricing & Stock Sync below. There is no documented flow for updating general content — title, description, images or category attributes — once a product has been created; only creation, price and stock are covered. This is a real gap compared with other marketplaces in this integration family and is called out again in Known Limitations.
Deactivating / removing products
Not documented in the current source material. No pause, close or delete action for a Temu listing is described in what has been scoped.
Pricing & Stock Sync
Price sync is supported. Price changes are grouped by product variation group and sent one group at a time, with only the specific items whose price actually changed needing to be included. Only the base/supplier price can be changed this way — Temu does not allow the RRP (the strike-through reference price) to be changed once a product exists; RRP can only be set at product-creation time. If Temu reports that the price sent is already the same as what's on file, that's treated as a successful update rather than an error. A "price update already pending" response from Temu is treated as a temporary, retryable condition rather than a hard failure.
Stock sync is supported. Stock changes are grouped by product variation group in the same way and sent a group at a time. Temu's own confirmation of whether a stock update actually worked is not always reliable — some partial-failure responses come back with no usable error detail at all, so a stock update can occasionally look inconclusive even when it has gone through, or vice versa.
RRP / strike-through pricing: can be set when a product is first created, and is shown by Temu as a discount when the RRP is higher than the price. It's automatically left out of the creation request if there's no RRP set, or if the price isn't actually lower than it. No mechanism for updating RRP on a live listing is documented.
Multi-currency: both price and RRP are set per listing with an explicit currency at the time they're sent.
Order Management
Getting orders
Orders are pulled from Temu automatically and continuously. Getting the full picture of an order requires gathering the order and its line items, a pricing breakdown, and the shipping address as separate lookups — an order isn't considered complete until all of these have been attempted. The first sync after connecting an account pulls the last 90 days of order history; after that it runs on a rolling, overlapping window so nothing is missed between runs.
Already-shipped or already-cancelled orders don't come back with a shipping address from Temu at all — that's expected behaviour, not a fault, and it doesn't stop those orders from being stored. If pricing can't be retrieved for an order, everything else that could be gathered is still stored and the order is flagged as incomplete rather than dropped.
Order information we store
- Marketplace order ID, order status, currency, created/updated times, and the latest date the order must ship by
- Buyer's shipping and billing details: name, address lines, region/country, postcode, phone number, and a Temu-anonymised relay email address rather than the buyer's real email
- Per line item: which of our products/SKUs it matches to, item title, quantity, and item price
- Order and line-level money detail: subtotal, shipping cost, tax, discounts and order total
Shipping orders
Pentagon Connect supports self-shipment by the merchant only — Temu's own warehouse fulfilment option ("Logistics Online Shipment") is not part of this integration. Both full shipment (one package, one tracking number covering the whole order) and partial shipment (multiple packages/tracking numbers for the same order, submitted together in a single call) are supported.
Before a shipment can be sent, the carrier used has to be matched against Temu's own registered courier list for that seller's region — see Carriers Supported below. If there's no matching courier and no default courier set on the account, the shipment update is blocked until one is set, rather than being guessed at. Temu tracks couriers separately per region, so the list used is scoped to the regions where the seller actually has a connected account, not Temu's full worldwide list of 100+ regions.
Cancellations
Temu does not allow sellers to cancel an order — cancellations can only be initiated by the customer through Temu themselves, so there is no seller-facing cancellation action in this integration, and none is available from Temu's own API to build one from. The only related behaviour is indirect: when a buyer cancels part of an order before it ships, Pentagon Connect briefly holds that order to give time for the corresponding refund to be picked up and recorded through the refund sync described below.
Refunds & returns
As with cancellations, Temu only allows the customer to initiate a refund — Pentagon Connect cannot submit a refund or return request back to Temu. What the integration does is read and store the refund information Temu confirms, keeping our own order and payment records up to date, read-only.
- Refunds are pulled in on a rolling basis (the first sync covers the last 90 days, then a rolling, overlapping window after that) and matched back to the original order.
- Each refund record distinguishes between two types — Refund Only and Return and Refund (i.e. the customer also sent the item back). This is the closest thing to a reason Temu exposes to sellers — see Return & Refund Reason Codes below.
- A refund can cover one or more order lines/quantities; each refunded quantity is tracked back to the specific line and SKU it applies to, so partial refunds are captured accurately even when several lines are refunded separately.
- Temu has confirmed that shipping is always refunded on a full-order refund; when that happens, the order is also marked as cancelled in our records. Partial refunds do not include a shipping refund.
- Temu doesn't provide a cost breakdown for a refund directly — the refunded amount is calculated from the order's own line-level pricing already on file, rather than being supplied by the marketplace.
Carriers Supported
As with other marketplaces, carriers aren't a fixed list Pentagon Connect maintains — they're read live from Temu, per the region of each connected seller account (only for regions where an account actually exists, not Temu's full list of 100+ regions worldwide). Couriers seen in the source material include: DHL, DHL Paket, UPS, FedEx, TNT, GLS, GLS (IT), GLS Spain (National), Chronopost, Colissimo, Mondial Relay, Colicoli, PPL, Hermes, Hermes (DE), Correos, Colis Privé, La Poste, Paack, Poste Italiane, Packeta, DPD (FR, DE, PL, CZ, IE, NL), Hellmann, Kuehne+Nagel, DSV, Raben Group, Dachser, SDA, GEODIS, BRT Bartolini, CAINIAO, Rhenus Logistics (IT), DB Schenker, YunExpress, GEL Express, CIRRO PARCEL, swiship (DE, FR), Amazon Shipping (IT, FR), and PostNL International Mail — the exact list available depends on the seller's connected region. If the courier used on a shipment isn't in that list and no default courier is set on the account, the shipment can't be sent until one is resolved.
Return & Refund Reason Codes
Temu doesn't expose a descriptive reason code to sellers the way some other marketplaces do. The only classification available on a stored refund is its type:
- Refund Only
- Return and Refund (the customer also sent the item back)
Known Limitations
- No general product-update flow. Updating title, description, images or attributes on a live listing is not covered — only creation, price and stock updates are.
- No listing deactivation/removal flow is documented.
- No RRP update after creation. Only the base/supplier price can be changed via the price-update flow; RRP can only be set when a product is first created.
- No seller-initiated cancellations or refunds. Temu's own API only allows the customer to start these. Pentagon Connect can read and store what Temu confirms, but cannot submit a cancellation or refund itself.
- No claims/incidents mechanism is described for Temu in this integration.
- Self-shipment only. Temu's own warehouse fulfilment model ("Logistics Online Shipment") is not covered.
- Region routing matters. Every call has to go to the right regional endpoint (EU, US, or the shared Mexico/Japan/global one) based on the seller's country — getting this wrong for a given action affects only that action, which can make problems hard to spot.
- Shared rate limit. Temu's request-rate limit (20 requests per second per app credential) is shared across every seller connected through Pentagon Connect, not given per seller, so timing across many sellers needs to be coordinated.
- Access token lifecycle is unresolved. Tokens expire every 3 months and only manual token entry is currently supported; automatic renewal is not yet built.
- Courier data is limited to connected regions. A seller shipping into a region with no connected account may have no courier mapping and no fallback beyond an optional default courier.
- Size-chart requirements aren't disclosed by category — Temu can silently restrict sales in categories that need one without saying which ones.
- Stock-update confirmations aren't always reliable — some partial-failure responses come back with no usable error detail, so an update can occasionally look inconclusive even though it went through.
Source Materials
This guide was built from Pentagon Connect's internal Temu integration scoping and specification documentation covering authorization, product taxonomy, product creation, pricing and stock synchronisation, shipping templates, order retrieval, order shipment, and refund handling.