Daraz

Daraz is the Alibaba-owned marketplace group covering South Asia: Pakistan, Bangladesh, Sri Lanka, Nepal and Myanmar. Daraz Open Platform is, to a degree that matters a great deal when building a connector, the same software as Lazada Open Platform with a different brand on it. The signing algorithm is identical, the common parameters are identical, the response envelope is identical, the product and order endpoint paths are identical, and the documentation pages even share nodeId and docId values with the Lazada portal. If you have written a Lazada client, you can point it at a Daraz host and most of it will work. This page records what was verified for Daraz specifically and flags the places where the two diverge or where Daraz documentation could not be read directly. Lazada is covered at /connectors/lazada, and the detail there applies unless contradicted below.

At a glance

What it is

Daraz began in 2012 as a Pakistani fashion retailer under Rocket Internet, grew into a general marketplace across South Asia, and was acquired by Alibaba Group in 2018. The acquisition is why the API looks the way it does: Daraz was migrated onto the same Alibaba open platform gateway that already served Lazada, rather than keeping its own.

It is a marketplace, not a D2C platform. Sellers list onto a shared storefront, compete on a shared catalogue and are paid through a Daraz-held settlement cycle rather than directly by the buyer. Fulfilment is mostly seller fulfilled with a Daraz-arranged carrier, with Fulfilled by Daraz as a warehouse option in the larger markets.

Each country is a separate venture with its own seller centre, its own currency, its own category tree and its own API host. A seller operating in both Pakistan and Bangladesh is two connections. Myanmar is the odd one out: the storefront trades as Shop.com.mm and the API host follows that brand rather than the Daraz one.

API access

Registration follows the Lazada pattern.

1. Register a developer account at open.daraz.com and complete the profile for review.
2. Create an application and choose its category. The console issues an app key and an app secret.
3. Request the API permission groups the application needs. As on Lazada, some groups are granted with the app and others must be applied for with a business justification, and a call to an endpoint outside a granted group is rejected at the gateway.
4. Get each seller to authorise the app through the OAuth redirect below.

The documentation navigation captured from the live portal lists these API sections, which is the best available map of the surface: Product, Order, Finance, System, Logistics API, Instant Messaging API, Fulfillment API, Return and Refund API, Seller API, Seller Voucher API, Free Shipping API, Product Review API, Flexicombo API and 3PV Seller API. The capture carried a "Latest update" stamp of 2023-05-19 on the product pages.

SDKs: Daraz does not publish packages to a registry. The Lazada lazop SDK archives work unchanged against Daraz hosts because the protocol is the same, and most integrations implement the fifty lines of signing directly.

Authentication

Endpoints

This table is verbatim from the official Service Endpoints block on the CreateProduct documentation page and is corroborated by two independent integrations.

Seller authorisation sequence

1. Send the seller to the authorise URL. Note client_id rather than app_key here, and that force_auth=true forces a fresh login rather than reusing a browser session.

GET https://api.daraz.com.np/oauth/authorize
  ?response_type=code
  &force_auth=true
  &client_id={app_key}
  &redirect_uri=https://connectors.example.com/daraz/callback

2. The seller signs in with seller centre credentials and approves. Daraz redirects to redirect_uri with a code parameter.

3. Exchange the code at /auth/token/create on the venture host. Unlike Lazada, which serves token endpoints from a central auth.lazada.com, the working Daraz clients read call /auth/token/create on the same country host as everything else. The call is signed but carries no access_token.

curl -X POST "https://api.daraz.com.np/rest/auth/token/create" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "app_key=123456" \
  --data-urlencode "code=0_TryzT8Vd9T1pwS7VWZ2qlMOS5" \
  --data-urlencode "sign_method=sha256" \
  --data-urlencode "timestamp=1758412800000" \
  --data-urlencode "sign=4190D32361CFB9581350222F345CB77F3B19F0E31D162316848A2C1FFD5FAB4A"

4. /auth/token/refresh on the same host, passing refresh_token, renews the pair.

The response shape was not captured from a Daraz page. On Lazada it carries access_token, refresh_token, expires_in, refresh_expires_in, account, account_platform, country and a country_user_info array of {country, seller_id, user_id, short_code}. Treat that as the expected shape and verify against a real token before relying on country_user_info for multi-venture mapping, because Daraz has no cross border authorisation equivalent to Lazada's "Crossborder" country option that was confirmed.

Request signature

Identical to Lazada, and verified against two independent Daraz implementations.

1. Collect the system parameters (app_key, access_token, timestamp, sign_method) and all business parameters. sign_method is sha256.
2. Drop any parameter whose value is null, undefined or empty, and drop it from both the signature and the request, or the gateway returns a signature mismatch.
3. Sort the remaining parameter names in ASCII order, excluding sign.
4. Concatenate name and value with no separators.
5. Prefix the API path, for example /order/get.
6. HMAC-SHA256 over the UTF-8 bytes with the app secret as key, hex encode, uppercase.

timestamp is milliseconds since epoch and must be within 7200 seconds of UTC, verbatim from the Daraz common parameter table. POST endpoints still expect their parameters in the query string or as form encoding, not as a JSON body.

plain = apiPath + concat(sorted(params) as key + value)
sign  = UPPER(hex(HMAC_SHA256(plain, app_secret)))

Response envelope

Success is code of "0" with data and request_id. Anything else is an error carrying code, type, message and request_id. The error codes captured from the Daraz CreateProduct page are the Lazada set: E001 parameter mandatory, E005 invalid request format, E006 unexpected internal error, E030 empty request, the E2xx category and SPU validation family, E500 create product failed, and notably E901: the request is too frequent, or the requested functionality is temporarily disabled, which is the throttling signal. Business validation failures arrive as string codes such as BIZ_CHECK_PRICE_PRECISION_INVALID, BIZ_CHECK_SELLER_SKU_DUPLICATE, CHK_BASIC_REQUIRED and BIZ_CHECK_CAT_PROP_MANDATORY.

Authentication failures to retry with a fresh token, per one integration's classifier: IllegalAccessToken, InvalidSession, AccessTokenExpired, MissingAccessToken.

Objects we can read

Orders

GET /orders/get is confirmed in production integration code and mirrors Lazada exactly. Either created_after or update_after is mandatory, with created_before, update_before, status, sort_by (created_at or updated_at), sort_direction, offset and limit capped at 100. The response head carries countTotal and count; sync by a moving update_after window ordered ascending rather than by deep offsets.

GET /order/get returns a single order by order_id.

The order shape was not captured from a Daraz page. On the shared codebase it carries order_id, order_number, created_at, updated_at, a statuses array, items_count, price, payment_method, shipping_fee with its original and discount components, voucher, voucher_platform, voucher_seller, warehouse_code, customer_first_name, customer_last_name, and address_shipping and address_billing objects with an address1 through address5 ladder, city, post_code and country. Addresses and customer names are PII and arrive partly masked unless the application has passed the sensitive data review. See /connectors/lazada for a full sample; the field names are the same.

Order items

GET /order/items/get takes a single order_id. GET /orders/items/get takes order_ids as a stringified JSON array and is the batch call, documented on the shared codebase at a maximum of 1000 ids. Both are confirmed in Daraz integration code.

Item status lives on the item rather than the order, which is why the order header returns a list of statuses. Each item carries three SKU identities: sku is the seller SKU, shop_sku the marketplace listing identifier and sku_id the numeric variant id used by the write endpoints. tracking_code, shipment_provider, package_id and invoice_number also sit on the item.

Products and listings

The product endpoint list below is verbatim from the captured Daraz documentation navigation, which makes it the most reliable part of this page.

Note /category/brands/query where Lazada documents /brands/get. That is a genuine Daraz difference, not a transcription error: it appears in the captured navigation.

GET /products/get takes a mandatory filter, confirmed in a live client as one of all, live, inactive, deleted, image-missing, pending, rejected, sold-out. limit is capped at 50 and that same client clamps anything larger before sending. The date scroll parameters are create_after, create_before, update_after and update_before, sku_seller_list takes a JSON array of exact seller SKUs, and options=1 adds the extended stock fields. Offset paging exists but is deprecated on the shared codebase in favour of date scrolling.

The response carries total_products and a products array. Each product has item_id, primary_category, status, subStatus, created_time, updated_time, an attributes object and a skus array. Each SKU carries SkuId, SellerSku, ShopSku, Status, price, special_price with special_from_time and special_to_time, quantity, Available, Url, package dimensions and Images.

Inventory

No standalone inventory endpoint. Stock is on the SKU inside /products/get: quantity is the total and Available the sellable figure, with ReservedStock, RtsStock, PendingStock and RealTimeStock appearing when options=1 is passed. Multi-warehouse sellers address warehouses by code on the write side.

Shipments and tracking

The captured navigation has a Logistics API section, but none of its pages were readable and no Daraz logistics path was seen in any integration read. What is confirmed: GET /shipment/providers/get exists as the carrier list, and the order item carries shipment_provider, tracking_code and package_id, which is enough to build a shipment record without an event history.

Do not assume Lazada's /logistic/order/trace exists on Daraz. It plausibly does, since the codebase is shared, but it was not verified and is exactly the kind of endpoint that differs between ventures. Confirm before designing a tracking pipeline.

Returns and cancellations

GET /reverse/order/list is confirmed in production integration code as the Daraz returns list. This differs from the Lazada path /reverse/getreverseordersforseller, so the reverse order surface is one place where the two have genuinely diverged, or where Daraz is on an older revision. The captured navigation names the section "Return and Refund API".

Returns use their own identifier space: a reverse_order_id distinct from the order_id, with reverse order lines keyed back to trade order lines. Item level cancellation also surfaces on the order item through return_status and reason.

GET /order/failure_reason/get returns the cancellation reason codes needed before calling /order/cancel.

Payments and settlements

Two endpoints, both confirmed.

GET /finance/transaction/detail/get returns the ledger lines. Note the singular detail: Lazada's equivalent is /finance/transaction/details/get. A Daraz client that reuses the Lazada path will 404. start_time and end_time are mandatory and it can be narrowed by trade_order_id or trade_order_line_id, which is how fees are attributed to a specific order line.

GET /finance/payout/status/get takes created_after and returns the statement headers: statement_number, opening_balance, closing_balance, payout, paid, item_revenue, shipment_fee, fees_total and refunds.

The fee_type strings seen in a real Daraz integration's fee classifier are worth recording, since they are the values that actually arrive on the transaction line: Commission, Payment Fee, Shipping Fee (Paid By Customer), Shipping Fee Voucher (By Daraz), Shipping Fee (Charged by Daraz), Promotional Charges, Free Shipping Campaign (By Seller), Vouchers (By Seller), Item Price Credit, Shipping Fee (Refund), Payout and Bank Transfer. That list is one integrator's mapping table, not an official enumeration, so treat it as a starting point and collect the real distinct values from live data.

Customers

No customer endpoint. Buyer identity is only what appears on the order: a buyer id, a name and an address, masked by default. Treat the buyer as per-order and pseudonymous.

Locations

GET /seller/get and GET /shop/get appear in the captured navigation's Seller API section and return the seller and shop records. Call one at onboarding to confirm the token and capture the seller identity. Warehouse listing was not verified for Daraz.

Writing back: listings, price and stock

Writes are synchronous. There is no feed queue and no processing report.

POST /product/price_quantity/update is the workhorse and carries a single payload parameter containing an XML document. The shared codebase documents a maximum of 50 SKUs per request with 20 recommended, and an inventory write throttle of 50 calls per second per seller. Single warehouse form:

<Request>
  <Product>
    <Skus>
      <Sku>
        <ItemId>6718170187</ItemId>
        <SkuId>12761620980</SkuId>
        <Quantity>200</Quantity>
        <Price>1299.00</Price>
        <SalePrice>999.00</SalePrice>
      </Sku>
    </Skus>
  </Product>
</Request>

Quantity cannot be negative and must stay at or above the quantity locked by any running promotion. Multi-warehouse sellers replace <Quantity> with a <MultiWarehouseInventories> block of <WarehouseCode> and <Quantity> pairs.

POST /product/update edits an existing product by ItemId and can also set dropshipping warehouse quantity for SKUs of that one product. POST /product/create creates one, and must be preceded by /category/tree/get to resolve the category and /category/attributes/get to discover the mandatory attributes, which differ per category and per venture. Images go up through /image/upload or are pulled from an external URL with /image/migrate and /images/migrate, then attached with /images/set; /image/response/get polls the result of an asynchronous image job. /product/deactivate takes a listing off sale and /product/remove deletes a product, some SKUs or all SKUs with seller_sku_list as a JSON array capped at 50.

GET /product/qc/status/get reports whether a newly created or edited product passed quality control, which on Daraz is a real gate: a product can sit in Pending QC for a long time and is not sellable until it clears.

Order-side writes mirror Lazada: POST /order/pack, POST /order/rts, POST /order/cancel with a reason_id, and POST /order/invoice_number/set. GET /order/document/get returns invoices, shipping labels and carrier manifests.

Webhooks and notifications

Not verified. The captured documentation navigation lists fourteen API sections and none of them is a push or notification section. Lazada, on the same codebase, has a full push mechanism with a Message Service tab in the app console, HTTPS callbacks, an Authorization header holding an HMAC-SHA256 of app key concatenated with the raw body, a 500 ms acknowledgement budget and twelve retries at 30 minute intervals. One open source Daraz integration is written as if Daraz order status webhooks exist, with handlers named order_status_update and trade_order_status, which are Lazada's message names.

The honest position is that Daraz almost certainly has the same push mechanism, because it is the same platform, but it was not documented in anything readable. Design the connector to poll, and ask Daraz whether the Message Service tab is enabled for your app before assuming otherwise.

Polling cadence that works without push: /orders/get by update_after every 10 to 15 minutes, /products/get by update_after hourly, /finance/transaction/detail/get daily over the previous 48 hours, /finance/payout/status/get daily, /reverse/order/list hourly.

Rate limits and pagination

No numeric rate limit is published on any Daraz page that could be read. What is known:

• Error E901, verbatim from the official Daraz error table, is the throttle signal: "The request is too frequent, or the requested functionality is temporarily disabled." Treat any E901 as a back-off instruction, not a retry-immediately failure.
• The shared codebase limits inventory writes to 50 calls per second per seller.
• Batch limits inherited from the shared codebase and confirmed where a live client enforced them: 100 orders per /orders/get page, 1000 order ids per /orders/items/get, 50 products per /products/get page, 50 SKUs per inventory write, 50 seller SKUs per remove.
• The app console exposes call volume and average QPS per application, which is the only way to learn the real ceiling.

Pagination is offset based throughout, with offset and limit. Because offsets shift while records are created, use the date window parameters as the primary cursor and offset only within a window.

Mapping to the unified model

The field names are the Lazada ones, so /connectors/lazada carries the full tables. The Daraz-specific notes:

orders

order_items, listings and inventory

order_items: order_item_id is one row per unit rather than per line, so two of the same SKU is two rows and quantity is always 1. sku from sku, channel_sku from shop_sku, listing_id from sku_id with product_id as the parent, unit_price from item_price and paid_price after discount.

listings: channel_listing_id is SkuId with item_id as the parent product, sku is SellerSku, list_price is price, sale_price is special_price inside its date window, stock is quantity, status needs both the product status and the SKU Status, and url is Url.

inventory: quantity_available is Available, quantity_reserved is ReservedStock with options=1, and location_id is the warehouse code.

shipments, returns and settlements

shipments: with no verified tracking endpoint, build the shipment from the order item alone. shipment_id from package_id, awb from tracking_code, carrier from shipment_provider, and leave events[], shipped_at, delivered_at and ndr_reason empty until the Logistics API is confirmed.

returns: return_id from reverse_order_id, order_id from the trade order id, status from the reverse status, and initiated_at from the reverse order line creation timestamp. Field names come from /reverse/order/list, which was not sampled, so verify the exact keys on first call.

settlements: settlement_id from statement_number, net_amount from payout with its trailing currency code stripped, order_id from the transaction line's order number, and fees[] one row per transaction line with type from the fee type string and a signed amount. There is no payment date field; paid_status only says paid or not paid.

Gaps and open questions

• Which authorise host is correct. Two working integrations use different ones, the venture host and a central auth.daraz.com. This blocks onboarding until settled and is the first thing to test.
• No readable documentation for eleven of the fourteen API sections. Order, Finance, Logistics, Return and Refund, Fulfillment, Seller, Instant Messaging, Seller Voucher, Free Shipping, Product Review, Flexicombo and 3PV Seller were all visible in the navigation but not readable. Order and Finance are covered here from integration code; the rest are unknown.
• Webhooks entirely unverified. See above. This is the difference between a 10 minute poll and near real time capture, so it is worth a support ticket early.
• The returns path differs from Lazada (/reverse/order/list against /reverse/getreverseordersforseller). Whether Daraz also exposes the Lazada style reverse order endpoints, or whether the two have diverged permanently, is unknown.
• The finance path differs by one character (detail against details). Assume other single-word divergences exist and test every path rather than porting a Lazada client wholesale.
• No sample responses were captured from a Daraz page. Every JSON shape described here is inferred from the shared codebase. The field names are very likely right; the presence or absence of individual fields per venture is not.
• Rate limits are unpublished beyond the existence of E901.
• A widely circulated machine-generated Daraz API catalogue is wrong. The daraz-api-skill repository publishes roughly 98 endpoints across categories such as Free Shipping, Flexicombo and 3PV, none of which appear in its own raw capture of the portal, alongside an authentication guide describing an Authorization: Bearer header that contradicts the signed-query-string scheme this platform actually uses. If a team hands you that document, do not build from it.

Sources

• open.daraz.com, the official Daraz Open Platform portal. Confirmed on 2026-09-21 to render client side and return no documentation to a plain fetch.
• pratikkuikel/daraz-api-skill, specifically its raw text capture of the rendered portal (daraz-full-content.txt), which carries the documentation navigation, the five service endpoint hosts, the common parameter table, the full product endpoint list and the CreateProduct error code table verbatim. The derived JSON catalogues and reference markdown in the same repository were checked against that capture, found to be machine generated, and not used.
• ghostrunner-0/kick_lifestyle, a production Next.js storefront whose lib/darazMini.js implements the venture hosts, the signing algorithm, the authorise URL construction, /auth/token/create, /auth/token/refresh, /order/get, /order/items/get and /products/get with its real parameter constraints.
• Sulaimaani/daraz-sellerhub2.0, a Daraz seller dashboard whose sync layer calls /products/get, /orders/get, /orders/items/get, /finance/transaction/detail/get and /reverse/order/list.
• Sulaimaani/daraz, whose configuration file records the venture host table, the central auth.daraz.com authorise URL, the re-authentication error codes and the fee type strings.
• /connectors/lazada, for the shared platform's documented behaviour where Daraz's own pages were not readable.