Integrating Shopee and Tokopedia Seller APIs

Almost every Indonesian SME seller I work with lists the same products on both Shopee and Tokopedia, plus maybe their own web store. The moment two orders for the last unit land within seconds of each other on different marketplaces, you get an oversell, a cancellation, and a hit to your seller rating. The only real fix is a backend that treats your own database as the truth and continuously reconciles stock outward to each channel.

On a recent project I built exactly this kind of omnichannel middleware. Below is the practical shape of both APIs, the parts that trip people up, and how I structure the sync so stock never drifts.

Two platforms, two auth models

The single most important thing to internalize before writing code: Shopee and Tokopedia authenticate completely differently, and Tokopedia is no longer its own API. After the merger, Tokopedia sellers are managed through the TikTok Shop Open API and the Tokopedia Partner Center. You register one app, but the two integrations barely share code beyond your business logic.

• Shopee Open Platform (API v2): register at open.shopee.com to get a partner_id and partner_key. Every request carries an HMAC-SHA256 signature and a timestamp. Access tokens live about 4 hours; refresh tokens about 30 days.
• Tokopedia via TikTok Shop Partner Center: register an app to get app_key and app_secret, sign requests with a sign parameter, and use the same Open API for both the Tokopedia and Shop apps. Access tokens last about 24 hours; refresh tokens up to 365 days.

OAuth authorization: getting and keeping tokens

Both platforms use the same broad OAuth shape: you redirect the seller to an authorization page, they approve access to their shop, and the marketplace redirects back with a short-lived code. Your server exchanges that code for an access token plus a refresh token. The details differ in how requests are signed.

For Shopee, the signature for a shop-level call is an HMAC-SHA256 of the concatenated partner_id, API path, timestamp, access_token, and shop_id, keyed with your partner_key. Get the field order wrong and every call returns a signature error, so I wrap it in a single helper and never build it inline.

// Shopee Open Platform v2 — shop-level request signature
import { createHmac } from "crypto";

function shopeeSign(params: {
  partnerId: number;
  partnerKey: string;
  apiPath: string;      // e.g. "/api/v2/product/update_stock"
  accessToken: string;
  shopId: number;
}): { sign: string; timestamp: number } {
  const timestamp = Math.floor(Date.now() / 1000);
  const base =
    `${params.partnerId}${params.apiPath}${timestamp}` +
    `${params.accessToken}${params.shopId}`;
  const sign = createHmac("sha256", params.partnerKey)
    .update(base)
    .digest("hex");
  return { sign, timestamp };
}

// Token refresh runs on a schedule, NOT lazily on 401.
// Shopee access_token ~4h, refresh_token ~30d — refresh early,
// persist BOTH returned values, they can rotate.

Order and stock synchronization

There are two directions to sync. Inbound: new orders flow from each marketplace into your system, ideally via push notifications or webhooks so you react in seconds, with a scheduled poll as a safety net for missed events. Outbound: whenever stock changes for any reason, you push the new quantity to every channel that lists that SKU.

1. Receive an order webhook from Shopee or TikTok Shop and immediately acknowledge it — treat delivery as at-least-once and dedupe by order ID.
2. Fetch full order detail via the order API, then decrement the master stock in your own database inside a transaction.
3. Enqueue a stock-update job for every other channel that sells the same SKU so the new quantity propagates outward.
4. Run a periodic reconciliation that pulls each channel's reported stock and corrects any drift against the master.

The mapping table between your internal SKU and each marketplace's item and model identifiers is the heart of the system. Shopee separates an item_id from a model_id (its variation), and TikTok Shop separates a product_id from a sku_id. If that mapping is wrong, you update the wrong variant and quietly oversell the popular size while the unpopular one shows phantom stock.

Product upload, rate limits, and pagination

Product creation is the most schema-heavy part of either API. Each marketplace enforces its own category tree, required attributes per category, image rules, and logistics options. I do not try to build a lowest-common-denominator product model. Instead I keep a rich internal product and write a per-channel adapter that maps it onto each marketplace's exact category and attribute requirements.

Rate limits are where naive integrations fall over. Shopee limits calls per partner over time windows; TikTok Shop allocates quota dynamically per shop per app and returns HTTP 429 when you exceed it. Both are far more forgiving if you batch, back off, and paginate correctly rather than hammering. Route every outbound call through a queue with a token-bucket limiter per shop, and honor 429 with exponential backoff.

Designing the single source of truth

The architecture that has never let me down is boring on purpose: one inventory service owns the master quantity, and marketplaces are downstream consumers, never authors, of that number. Every change to stock, whether from a sale, a return, a manual edit, or a warehouse count, updates the master first and then fans out to channels through a queue.

With that in place, adding a third channel later — Lazada, TikTok Shop standalone, your own store — is just another adapter and another row in the SKU mapping table. The core inventory logic never changes, which is exactly what you want when the marketplaces themselves keep changing under you.