intelligent.pageDocs

Snapdeal

Snapdeal Seller APIs on apigateway.snapdeal.com: three header tokens, reads orders, returns and payments, writes price, stock, listings and tracking.

Snapdeal is an Indian horizontal marketplace, once one of the big three alongside Amazon and Flipkart, now positioned as a value commerce platform for tier two and tier three India. It is the only platform in this group of Indian and MENA marketplaces with a genuinely open, fully published developer reference: a public portal at sellerapis.snapdeal.com with every endpoint, its parameters, its sample response and an OpenAPI definition. That makes Snapdeal the cheapest integration in the set to build and the easiest to verify. The catch is age. The changelog's most recent entry is dated 1 February 2017, so the surface is stable to the point of being frozen, and some of the operational conventions in it belong to an earlier era of Indian ecommerce.

At a glance

What it is

Snapdeal is a pure marketplace. It holds no inventory of its own in the marketplace model, and its seller base skews towards small and mid sized Indian merchants selling unbranded and value goods. After exiting the premium segment it repositioned around low price points, which shows up in the API as an emphasis on cash on delivery, on IMEI and serial capture for electronics, and on several distinct fulfilment models rather than one.

Five fulfilment modes appear throughout the API as fModes, and they are not cosmetic: they change which handover endpoints apply.

  • VENDOR_SELF, the seller ships with their own courier. This is the only mode where the seller sets tracking details and marks delivery.
  • DROPSHIP, the seller packs and a Snapdeal courier collects against a manifest.
  • ONESHIP and OCPLUS, Snapdeal's own consolidation networks, with handover sheets rather than manifests.
  • FC_VOI, which appears in the allowed values for fModes without further explanation in the public reference.

The identifiers to know. A packageReferenceCode is the package, the thing you print, manifest and hand over. A suborderCode is a single unit: if a buyer orders three of something, that is three suborders under one package. A siReferenceCode is the item level reference you use when writing back at line granularity. A supc is Snapdeal's catalogue identifier for a product, and skuCode is the seller's own SKU. Most write endpoints accept either the supc or the seller sku, and explicitly refuse both at once.

API access

The portal is open to read. To call anything you need two separate grants.

  1. Partner registration. Submit the access key request form on the portal. Snapdeal's API team replies within about two days. On approval you receive an appId and an access token. The token is per environment: sandbox and production tokens are different and are not interchangeable.
  2. Seller authorisation. Every endpoint that touches a specific seller's data needs that seller's authorisation token. The seller gets it by visiting a Snapdeal hosted page, signing in with their Snapdeal seller credentials, and choosing which capabilities to grant. Each endpoint page in the reference states whether it needs the seller token.

Environments:

  • Sandbox: http://staging-apigateway.snapdeal.com/seller-api
  • Production: https://apigateway.snapdeal.com/seller-api

The API is versioned in the documentation as v1.0 and v1.1, selectable in the portal, with v1.1 current. There is no published deprecation calendar. The changelog's newest entry is 1 February 2017.

There is no official SDK. The portal exposes an OpenAPI 3.1 definition inside each endpoint page, which is enough to generate a client, and a Swagger explorer against the sandbox.

Warning

Two practical traps, both observed on 2026-09-21. First, sellerapis.snapdeal.com serves a TLS certificate valid only for *.readme.io, so a strict HTTPS client will refuse the documentation host. That is the docs host, not the API host, but it will break a naive documentation scraper. Second, the sandbox base URL is published as plain http, not https. Do not send real credentials to it over a network you do not control, and do not let the sandbox scheme leak into production configuration.

Authentication

There is no token exchange endpoint. Authentication is three headers, sent on every call.

The OpenAPI definitions declare all three as apiKey security schemes in the header, and list them together in the security requirement, so all three are expected on a seller scoped call.

Getting a seller authorisation token

The seller goes to a Snapdeal hosted page carrying your appId and a return URL.

GET https://authorize.snapdeal.com/authserverui/login?returnURL={RETURN_URL}&appId={appId}

The sandbox equivalent is https://stg-authorize.snapdeal.com/authserverui/login?returnURL={RETURN_URL}&appId={appId}.

The seller signs in with their Snapdeal seller username and password, selects the capabilities they wish to grant, and is redirected to your return URL. This is an authorisation code style consent flow in shape, though the reference describes it as a web UI step rather than as OAuth, and publishes no refresh endpoint.

An authenticated call

curl 'https://apigateway.snapdeal.com/seller-api/orders/new?fModes=VENDOR_SELF,DROPSHIP&pageSize=10&pageNumber=1' \
  -H 'X-Auth-Token: <partner-access-token>' \
  -H 'clientId: <partner-id>' \
  -H 'x-seller-authz-token: <seller-authz-token>'

Multi account handling is clean and is the best feature of this API: one partner credential pair, and one seller authorisation token per seller. Store the seller tokens keyed by seller and swap the third header. Token lifetime and revocation behaviour are not published, so treat a 401 as "re-run the seller through the authorisation page".

Every response carries a metadata object with requestId, clientId, responseTime and requestedURI, plus a message on errors. Log the requestId, it is the only handle Snapdeal support will accept.

Status codes in use are 200, 202, 400, 401, 403, 404, 420 Method Failure, 422 Unprocessable Entity, 500 and 503. The 420 is unusual and worth handling explicitly.

Objects we can read

Orders

Three separate collections by state, rather than one collection with a status filter.

Key parameters on /orders/new: fModes is a mandatory comma separated list of fulfilment modes from VENDOR_SELF,ONESHIP,OCPLUS,DROPSHIP,FC_VOI. orderStatus is optional and accepts PFF and PRNT, defaulting to both. Pagination is pageNumber and pageSize, defaulting to 1 and 10.

{
  "metadata": {
    "requestId": "efb4b66f-2949-4de5-a030-5aa9933f4316",
    "clientId": "partnerId",
    "responseTime": 115,
    "requestedURI": "GET /orders/new"
  },
  "payload": {
    "packages": [
      {
        "packageReferenceCode": "SLP556018",
        "fulfillmentModelCode": "DROPSHIP_MODEL",
        "awbNo": "SLP311284",
        "courierCode": "FEDEX",
        "manifestByDate": 1451209090000,
        "shippedDate": 1467357580000,
        "slaBreach": "breached",
        "created": 1453889682000,
        "invoiceNumber": "",
        "courierName": "FEDEX",
        "centreCode": "DC-OC",
        "items": [
          {
            "suborderCode": "57767687",
            "siReferenceCode": "SI622093",
            "orderCode": "37690465",
            "packageReferenceCode": "SLP891519",
            "orderDate": 1450949891000,
            "productName": "NOKIA",
            "supc": "SDL062513333",
            "skuCode": "YAS-3c-prod-3-staging",
            "price": 8000,
            "siStatusCode": "PRNT",
            "paymentMode": "STD",
            "deliveryMode": "STANDARD",
            "serializable": "IMEI",
            "serializedUniqueId": "153451234512345",
            "cancellationReason": "NONE",
            "customerDetail": {
              "pincode": "560021",
              "city": "Bangalore",
              "state": "Karnataka",
              "area": "Delhi",
              "subArea": "Okhla Phase 3, #246, 1st Floor",
              "mobile": "944444477",
              "email": "alok12345.sinha@example.com"
            }
          }
        ]
      }
    ]
  }
}

The customerDetail block is PII and it is not masked: full address, mobile and email arrive in the clear. All timestamps are epoch milliseconds.

Order items

Items are the items array inside a package, and each element is one suborder, meaning one physical unit. The three identifiers on an item serve different purposes: suborderCode identifies the unit, siReferenceCode is the key for line level writes such as marking out of stock or splitting, and orderCode is the buyer's order.

Products and listings

A full catalogue toolchain, not just a read. The reads walk the category tree (categories, children for a category, search for a category), fetch the attributes required to list in a category, search the seller's own products, and search all products on Snapdeal so the seller can list against a product another seller already created. Track listing accepts either an uploadId or a sku, and a listing image configuration call returns the basic image rules.

The writes are image upload, which returns a reference the listing calls consume, listing of a new product, listing of a new product with external image URLs from a CDN or Dropbox instead of an upload, listing of an existing product, and edit listing. There is also a prelisting financials call, which is genuinely useful and rare: it computes the commission and net realisation for a set of proposed attribute values before the listing exists.

Inventory

GET /seller-api/products/{supc}/inventory
GET /seller-api/products/inventory/bulk

The bulk read takes up to 10 SUPCs per call.

{
  "metadata": {
    "requestId": "331f18ca-d6ce-461d-bf05-e897559fb129",
    "clientId": "partnerName",
    "responseTime": 31,
    "requestedURI": "GET /products/SDL047974386/inventory"
  },
  "payload": {
    "supc": "SDL047974386",
    "sellerSku": "search2.2-09-04-2013mp131",
    "live": true,
    "liveDisableMsg": null,
    "availableInventory": 992
  }
}

There is no location dimension. Inventory is a single number per SUPC per seller, so a seller shipping from several warehouses has to pool before pushing.

Shipments and tracking

Shipment handling is organised by fulfilment mode, and each mode has its own handover document family with the same four verbs.

Each prefix carries the same six calls: GET the list for a date range, GET /{code}/orders for its contents, POST to create a handover from a list of order codes, PUT /{id} to add orders to an existing one, and POST /print and POST /reprint.

The read endpoints take a date range and a status of ALL, PRINTED or UNPRINTED. Creation takes a list of orderCodes, which the reference notes means packageReferenceCode values. Print and reprint handle one document at a time.

Packslips and invoices come from POST /orders/print and POST /orders/reprint, again keyed on package reference codes, with reprint limited to one at a time.

Returns and cancellations

GET /returns/pending
GET /returns/pending/suborder/{subOrderId}
GET /returns/completed
GET /returns/completed/suborder/{subOrderId}
GET /oneship/rtv/{rtvListCode}/packs
GET /ocplus/rtv/{rtvListCode}/packs
GET /disputes/issuecategories

Pagination on the return lists defaults to pageNumber 1 and pageSize 10, with a maximum page size of 20. Return modes are BUYER and COURIER. The date range means different things by mode, and this is easy to get wrong: for buyer returns the range filters on customerReturnInitiated date, for courier returns it filters on the updated date.

{
  "metadata": {
    "requestId": "b06e91c1-747c-4cc3-8346-94327d9f8ebd",
    "clientId": "partnerId",
    "responseTime": 76,
    "requestedURI": "GET /returns/pending"
  },
  "payload": {
    "returnDataSROList": [
      {
        "productName": "Samsung Galaxy Duos 03 (Size: M, Color: Red)",
        "supc": "SDL158699373",
        "skuCode": "Est-05-04-01",
        "suborderCode": "43053937",
        "customerReturnInitiatedOn": "1450690411000",
        "returnInitiatedOn": 1456345479000,
        "fulfillmentMode": "ONESHIP",
        "awbNumber": "794677744579",
        "sellingPrice": 4753,
        "paymentMode": "COD",
        "orderCreatedDate": 1456345462000,
        "shippedOn": 1456345478000,
        "packageId": 62888,
        "status": "PENDING"
      }
    ]
  }
}

Note that customerReturnInitiatedOn is a string of digits while every neighbouring timestamp is an integer. Parse defensively.

Payments and settlements

GET /payments
GET /payments/commissioninvoice
GET /payments/transactions
GET /payments/transactions/reports/{reportId}

GET /payments returns settled payments for a date range, with startDate and endDate in epoch milliseconds, default page size 10 and maximum 20.

{
  "metadata": {
    "requestId": "50085714-eda1-47d8-be9b-1a439795e63a",
    "clientId": "ePaisa",
    "responseTime": 19,
    "requestedURI": "GET /payments"
  },
  "payload": {
    "totalResults": 5,
    "settledPaymentsList": [
      {
        "paymentId": 775048,
        "paymentDate": 1452882600000,
        "paymentAmount": 992.95,
        "transactionType": "COD",
        "bankName": "ICICI",
        "accountNumber": "1258329"
      }
    ]
  }
}

The bank account number is PII and arrives unmasked. The per order fee breakdown is not in this response: for that you request the transactions report with GET /payments/transactions, which returns a report id, then fetch a download link with GET /payments/transactions/reports/{reportId}. That is a two step asynchronous job, so build it as a job rather than as a request.

Customers

There is no customer endpoint. Customer data arrives inside the order as customerDetail and is unmasked PII.

Locations

There is no location or warehouse object anywhere in the API. Inventory is a single pool per seller. The nearest thing is GET /seller/config, which returns the seller's configuration values.

Seller onboarding

Unusually for a marketplace, Snapdeal exposes seller onboarding to partners: primary categories, lead registration to start a seller signup, seller registration to complete it once a lead exists, and seller profile to read email, phone and company name for a seller who has authorised you. An aggregator can therefore originate sellers rather than only serve existing ones.

Writing back: listings, price and stock

Price and stock share one shape: a list of feed objects, a hard limit of 1000 records per call, and an asynchronous result.

POST /seller-api/products/price
POST /seller-api/products/inventory

A PricingFeed carries supc or sku, plus mandatory mrp and sellingPrice, both Long. An InventoryFeed carries supc or sku, plus mandatory availableInventory, an Integer. In both cases the reference is explicit: send either the supc or the sku for a record, never both.

The response is an upload id, not a result.

{
  "metadata": {
    "requestId": "ae452762-9fa5-49c8-9858-7184f410d70b",
    "clientId": "partnerName",
    "responseTime": 111,
    "requestedURI": "POST /products/price"
  },
  "payload": { "uploadId": "UUID0a82ecc5-9ed7-4267-9288-ca860d125d7f" }
}

Poll GET /feed/result/{uploadId} for the per record outcome, paginated with pageNumber and pageSize defaulting to 1 and 10. There is also a seller level result endpoint that returns listing, price and inventory upload outcomes over a time range in chronological order, which is the right tool for a nightly audit of everything you pushed.

Other writes, with their constraints as published:

Listing creation and editing are full write paths, covered above. There is also a separate ads surface, covering campaign creation for a set of SUPCs, campaign reporting, campaign status, NEFT details and a payment summary with funds available and cash on delivery limits.

Webhooks and notifications

Snapdeal pushes two notification types: new order and new return, the latter covering both buyer and courier returns.

The transport is Amazon SNS delivering over HTTPS, and the reference links to the AWS documentation for sending SNS messages to HTTP endpoints. That has a concrete consequence for your receiver: you will get two message types, a one time SubscriptionConfirmation that you must confirm before anything else flows, and Notification messages thereafter. Implement the SNS confirmation handshake and verify the SNS message signature, since the reference does not define a separate Snapdeal signing scheme.

Setup is in four steps: make the HTTPS endpoint ready, ask Snapdeal by email to subscribe it, confirm the subscription, then register individual sellers.

POST   /seller-api/notification/subscribe/seller
DELETE /seller-api/notification/subscribe/seller

Per seller registration and de-registration are API calls and need the seller's authorisation token. Endpoint registration is not self serve, it is an email to the Snapdeal API team.

Retry policy is Amazon SNS's rather than Snapdeal's, and no delivery ordering guarantee is published. Be idempotent on packageReferenceCode and suborderCode.

Rate limits and pagination

No request rate limit, quota header or burst policy is published anywhere in the reference. The published limits are all batch sizes, and they are the real constraint:

Pagination everywhere is page number and page size, not a cursor, so a list that changes under you can skip or repeat rows. For order polling, prefer the state scoped collections over deep paging: read /orders/new from page 1 until you reach packages you have already seen.

A cadence that fits: poll /orders/new every five minutes as a safety net behind the notifications, push price and inventory in 1000 record batches and poll /feed/result/{uploadId} a minute later, pull returns hourly, and request the transactions report daily.

Mapping to the unified model

Gaps and open questions

  • The changelog stops at 1 February 2017. Either the API has been stable for nine years or the changelog is not maintained. Confirm the current version with Snapdeal's API team before building.
  • No request rate limit is published anywhere. Only batch sizes are documented. Ask for the rate limit.
  • Seller authorisation token lifetime, expiry and revocation are not documented. Plan for re-authorisation on 401.
  • The seller authorisation page is described as a web UI step, not as OAuth, and no refresh endpoint exists. Whether the token is long lived is unverified.
  • FC_VOI appears as an allowed fulfilment mode with no explanation in the public reference.
  • There is no location or multi warehouse concept. A seller with several warehouses must pool inventory before pushing, and cannot express per location availability.
  • Return handling through the API can only accept. Disputes have a categories endpoint but no dispute creation endpoint.
  • The documentation host's TLS certificate does not match its hostname, and the sandbox base URL is published as plain HTTP.
  • Snapdeal appears to run two seller domains: sellers.snapdeal.com redirects to setu.snapdeal.com, which returned a 404 for the old /apidoc path on 2026-09-21. sellerapis.snapdeal.com is the live reference.

Sources