SHEIN Seller API Integration: Auth, Signing and Sync Design

What the SHEIN seller API covers

SHEIN runs its integration surface as the SHEIN Developer Platform (also called the SHEIN Open Platform). SHEIN describes it as technology-connected business solutions for product, order, return and procurement workflows. In practice, a SHEIN seller API integration means your own system (an ERP, a multichannel tool, a WMS or a custom back office) talks to SHEIN over HTTPS instead of someone working in the seller portal by hand.

The realistic scope of a first integration is small. Most teams need three flows, in this order:

Returns and procurement APIs exist as well, but leave them until orders and stock are reliable. One warning before you plan a schedule: the developer platform's documentation is a single-page app that changes, so treat every endpoint path and field name in this article as a starting point and confirm it in the current SHEIN docs before you code against it.

How SHEIN API authentication works

SHEIN does not give you one static API key. There are two layers of credentials, and mixing them up is the most common reason a first call fails.

The flow, as integrations implement it:

1. The seller opens SHEIN's authorization page with your appid, a Base64-encoded redirectUrl and a state value of your choosing.
2. After the seller approves, SHEIN redirects to your URL with a tempToken and your state echoed back. The token is valid for 10 minutes.
3. Your server POSTs {"tempToken": "..."} to /open-api/auth/get-by-token on the API domain.
4. The response carries openKeyId, supplierId, supplierSource, appid and an encrypted secretKey.
5. You decrypt the secretKey with your app secret key and store the pair against that seller.

SHEIN's official Java SDK mirrors this split: it offers an APPID sign mode (used for the token exchange via getToken(tempToken, authInfo)) and an OPEN_KEY_ID sign mode (used for ordinary API calls). It also lists two API domains, openapi.sheincorp.com and openapi.sheincorp.cn. Details on the exchange are on SHEIN's own page, Exchange openKeyId and secretKey, and the SDK is published at sheinsight/open-sdk-java on GitHub.

Design consequence: the state parameter is your only way to know which of your customers just authorized. Generate it server-side, bind it to the customer record, and reject any callback whose state you did not issue. Skipping this is how one seller's credentials end up attached to another seller's account in multi-tenant tools.

How to sign a SHEIN API request

Every call carries a signature built from the seller's credentials, the request path and a millisecond timestamp. The scheme used by integrations is:

• String to sign: openKeyId&timestamp&path (for example the path /open-api/auth/get-by-token, without the domain).
• HMAC key: secretKey followed by a random 5-character string.
• Digest: HMAC-SHA256, hex-encoded, then Base64-encoded.
• Result: the 5-character random string prepended to the Base64 value, sent in the x-lt-signature header.

Alongside it you send the millisecond timestamp in x-lt-timestamp, the application id in x-lt-appid, a JSON content type and a language header. A runnable Python version:

import base64, hashlib, hmac, secrets, string, time

def shein_signature(open_key_id: str, secret_key: str, path: str, timestamp_ms: int) -> str:
    alphabet = string.ascii_letters + string.digits
    random_key = ''.join(secrets.choice(alphabet) for _ in range(5))
    to_sign = f'{open_key_id}&{timestamp_ms}&{path}'
    hex_digest = hmac.new(
        (secret_key + random_key).encode(),
        to_sign.encode(),
        hashlib.sha256,
    ).hexdigest()
    return random_key + base64.b64encode(hex_digest.encode()).decode()

ts = int(time.time() * 1000)
sig = shein_signature('YOUR_OPEN_KEY_ID', 'YOUR_SECRET_KEY', '/open-api/auth/get-by-token', ts)

Two details trip people up. First, Base64 is applied to the hex string, not to the raw digest bytes, so a language that returns raw bytes by default (Go, Node's digest() with no encoding) needs an explicit hex step. Second, the path in the string to sign must match the path you actually call, query string excluded, so signing in one place and routing in another is a classic source of signature-mismatch errors.

Confirm the exact header names and the path rules for business calls (as opposed to the token exchange) against SHEIN's current documentation. If you write in Java, the official SDK's built-in signing removes this whole class of bug.

How to decrypt the SHEIN secretKey

The secretKey returned by the token exchange is not usable as received. It is AES-128-CBC encrypted and Base64 encoded, decrypted with your application's secret key and a fixed IV documented by integrators as space-station-de. A Python version using PyCryptodome:

import base64
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

def decrypt_secret_key(encrypted_b64: str, app_secret: str) -> str:
    key = app_secret.encode()[:16].ljust(16, b'\0')
    cipher = AES.new(key, AES.MODE_CBC, iv=b'space-station-de')
    return unpad(cipher.decrypt(base64.b64decode(encrypted_b64)), 16).decode()

The key line reproduces what OpenSSL does for AES-128: the key is cut or zero-padded to 16 bytes. If you use a library that insists on an exact key length, this is where it fails. Once decrypted, store the value in a secrets manager or an encrypted column. Never write it to logs, and never send it to the browser.

Designing order and inventory sync that survives production

Getting one signed call to return 200 is the easy part. What decides whether the integration holds up is how you move data over weeks.

Use webhooks for speed and polling for truth

SHEIN documents a webhook mechanism on the developer platform (see its Webhook Instruction page). Push notifications cut latency, but any push channel can drop or delay events. The dependable pattern is a webhook that triggers an immediate fetch of the order, plus a scheduled reconciliation poll that asks for everything changed since the last successful sync. If the poll never finds anything the webhook missed, you have proof the design works; if it does, you found a hole before a customer did.

Make every write idempotent

Retries are guaranteed to happen: timeouts, deploys and duplicate webhook deliveries. Key each order by SHEIN's order identifier in your database with a unique constraint, and make fulfilment and stock updates set-to-value operations rather than increments. A retried "decrease by 1" oversells; a retried "set to 14" is harmless.

Treat the token pair as per-seller state

Store openKeyId, the decrypted secretKey and supplierId per seller, and record the authorization date. If a seller revokes access, your next call fails; surface that in your product as a "reconnect SHEIN" state rather than a silent sync stall.

Watch the clock

The signature includes a millisecond timestamp, so a server with drifting time will produce valid-looking but rejected requests. Run NTP on every host that signs.

Build in-house, use the SDK, or hand it to an integration team

The signing and auth are a weekend of work. The long tail (field mapping between your catalog and SHEIN's category attributes, error handling, monitoring, seller onboarding) is what consumes the weeks. Choose based on how many sellers you serve and whether SHEIN is your only channel.

If you need SHEIN connected alongside Amazon, eBay, Walmart or Etsy in one system, that is the case for a shared internal data model instead of one-off scripts per channel. Netalith builds these as part of its marketplace integration service, and the same design rules above apply whoever writes the code.

Pre-launch checklist for a SHEIN seller API integration

For questions about access to the developer platform itself, SHEIN lists [email protected] as its contact. If you would rather have the integration scoped and built for you, send the details through Netalith's free quote form.