intelligent.pageDocs

Nykaa

Nykaa has no public seller API docs: credentials are an API username, password and vendor code issued by Nykaa, integration is through an aggregator.

Nykaa is India's dominant beauty and personal care marketplace, listed on the Indian exchanges since 2021, with a fashion arm (Nykaa Fashion) and a B2B distribution arm alongside the core beauty business. For a seller it is a curated marketplace rather than an open one: you are onboarded by a category team, not by signing up. That curation carries through to the integration story. There is no public developer portal, no published endpoint reference and no self serve credential console. An API exists, it is used every day by EasyEcom, Unicommerce, Vinculum, Browntape and Base to pull orders and push stock, but every one of those vendors documents it the same way: ask the Nykaa team for an API username, an API password and a seller or vendor code. This page records what can be established about the mechanism from those integration guides, and marks clearly where the record stops.

At a glance

What it is

Nykaa is a marketplace and a retailer at once. A large share of what it sells it buys on its own account and ships from its own warehouses, which is why many brands deal with Nykaa through a purchase order rather than a marketplace listing. Sitting alongside that is a genuine marketplace where third party sellers hold their own stock. The seller facing surfaces that aggregators integrate with are usually named as separate channels:

  • Nykaa.com, the core beauty and personal care marketplace.
  • Nykaa Fashion, the apparel and accessories arm, integrated as its own channel with its own vendor code prefix.
  • Nykaa Design, a channel on which the vendor arranges shipping themselves rather than handing to Nykaa.
  • Nykaa Omni, store fulfilment, where orders are routed to a physical store and can hop to another store if the first cannot fulfil within a configured window.

Nykaa's own order and warehouse systems run on Vinculum's Vin eRetail stack. Vinculum publishes a Nykaa case study describing Vin OMS, Vin WMS, the Seller Panel and Omnichannel modules in use, and a Nykaa branded Vin eRetail host is publicly resolvable at api-nykaa.vineretail.com/eRetailWeb/. That is a strong clue about the shape of the seller API, because the Vin eRetail seller panel has its own documented integration surface, but it is a clue and not a confirmation. No Nykaa source says "our seller API is Vin eRetail".

API access

There is no application process you can start from a web page. The documented route is:

  1. Get onboarded as a Nykaa seller or brand through a category manager. Portal credentials are issued to approved brands after category onboarding.
  2. Ask the Nykaa team, usually the account or category manager, for API credentials. Every aggregator knowledge base phrases this the same way. EasyEcom's is blunt: "Please reach out to Nykaa Team for API Username, Password and Seller ID."
  3. Receive the credential set, and a vendor code per selling entity or store.
  4. Give those to the aggregator, or to your own connector if Nykaa allows a direct integration.

Sources disagree on step 2. Base's integration guide says "Your Nykaa API credentials can be found in your Nykaa seller panel under API integration settings", which would make them self serve. EasyEcom and Unicommerce both say the credentials come from the Nykaa team. The likeliest reconciliation is that the panel shows credentials once Nykaa has provisioned them, but that is an inference. Check the panel first, then raise a ticket.

There is no published API version, no deprecation calendar, no changelog and no official SDK in any language.

Warning

Nothing in this page gives you a base URL, a path or a request body, because no public Nykaa source publishes one. Do not scope a direct Nykaa connector from this page. Scope a conversation with the Nykaa team, or scope an integration through EasyEcom, Unicommerce, Vinculum or Browntape, all of which already hold working credentials and expose their own documented APIs.

Authentication

The credential triple is consistent across every vendor that documents it:

  • API username. On Unicommerce this is the vendor code with a numeric prefix, and the prefix identifies the channel: 50 for Nykaa.com and 53 for Nykaa Fashion B2C, per Unicommerce's February 2024 and May 2024 notes. So a vendor code of XYZW is entered as 50XYZW for the beauty channel. For Nykaa Omni the username is the parent vendor code, for the B2C channels it is the child vendor code.
  • API password, supplied by Nykaa.
  • Seller ID or child seller ID, which EasyEcom asks for as a separate field and Base asks for only where a child entity applies.

There is no token endpoint in any published description, no mention of expiry or refresh, and no mention of scopes. The absence of a refresh step in vendor setup forms is itself evidence: aggregators ask for a username and password once and then run for months, which is the signature of basic authentication or a login call that mints a session behind the scenes, not of OAuth.

Multi account handling follows the vendor code. One credential set per selling entity, and a mapping table from Nykaa store codes to your own warehouse codes. Unicommerce stores exactly that as a JSON object of the form store code to warehouse code, which tells you Nykaa identifies fulfilment locations by an opaque store code you receive rather than by anything you choose.

Objects we can read

No endpoint, parameter, pagination model or sample response is published for any object. What follows is the set of operations that multiple aggregators independently confirm work, with their names as the aggregators describe them.

Orders

Order sync is supported on every Nykaa channel that the aggregators integrate. Base states that it fetches new orders from Nykaa every ten minutes, which is a poll, not a push. On the Omni channel orders land in an acceptance queue: the seller accepts or rejects, and Unicommerce notes that partial acceptance or rejection of an order is not permitted, so the decision is per order and not per line. Order hopping between stores is configured in hours, with observed ranges of 72 to 144 hours before an unfulfilled Omni order is reassigned.

Sample response not published. Field names not published.

Order items

Lines exist inside orders, since orders carry SKUs and quantities, but no separate order items endpoint is described and no line level field names are published. The prohibition on partial acceptance on Omni suggests the line is not independently actionable at the order acceptance step.

Products and listings

Catalogue sync is supported. EasyEcom offers a "Create Products Automatically" option that generates master SKUs directly from Nykaa listings, so listings are readable in enough detail to seed a product master without a manual upload. What the listing record contains, and whether price and stock come with it, is not published.

Inventory

Inventory sync is supported and is directional in both senses: aggregators both read current levels and push updates. The important configuration detail is facility scope. Unicommerce requires facility wise inventory to be set to yes for Omni, where stock sits in stores, and to no for normal dropship, where a single pool is pushed. So the inventory model on Nykaa is per location for store fulfilment and single pool otherwise.

Shipments and tracking

On the channels where Nykaa arranges shipping, which are Nykaa.com and Nykaa Fashion B2C, the invoice and the shipping label are generated by Nykaa and fetched by the integration rather than produced locally. Unicommerce documents fetching the invoice code and tax details from the channel and offers a "Skip Invoice URL" option to suppress its own invoice printing. On Nykaa Design the vendor ships, so no Nykaa label exists and the carrier is the seller's own.

Tracking event feeds are not described in any source. Status sync is coarse: cancelled, dispatched and return statuses are the states the aggregators say flow back.

Returns and cancellations

Return status sync is supported and is listed together with cancelled and dispatched as the statuses that move between systems. No return object schema, reason code list or refund amount field is published. Whether returns can be read as their own collection, or only observed as a status change on an order, is unresolved.

Payments and settlements

No settlement or payout API is described anywhere. Settlements are taken from the seller portal's reports.

Customers

Customer details necessarily arrive with the order for the channels where the seller ships. Nothing is published about masking, virtual phone numbers or whether email is included. Assume any address field you receive is PII and handle it accordingly.

Locations

Locations are Nykaa store codes, issued by Nykaa, and mapped to your own warehouses by a JSON mapping held in the integration. No location listing endpoint is described.

Writing back: listings, price and stock

Stock is the one write path with independent confirmation. Inventory sync pushes quantities to Nykaa, facility by facility for Omni and as a single pool for dropship. No batch size or rate is published.

Price has no described API path. On a curated marketplace like Nykaa, list price and discount are usually governed by the brand agreement and the category team, and changes go through the seller panel. Plan for panel driven pricing until Nykaa's team says otherwise.

Listings are created through the seller panel and the category onboarding process. EasyEcom's automatic product creation reads listings out of Nykaa, it does not write them in. No listing creation, attribute update or activation API is described in any public source.

The practical fallback for all three is the seller panel bulk upload template, and for stock, an aggregator that already holds credentials.

Webhooks and notifications

None published. No source describes Nykaa pushing anything to a seller endpoint, and the only observed cadence is a poll: Base fetches new orders every ten minutes, Unicommerce runs syncs triggered from its channel summary page on a schedule.

A sensible polling design, absent better information: orders every five to ten minutes over a rolling window with overlap, inventory reconciliation daily, catalogue weekly or on demand. Checkpoint on a window boundary rather than on a cursor, because no cursor is documented.

Rate limits and pagination

Not published. No quota numbers, no headers, no pagination model, no burst policy. The ten minute order poll used by a production aggregator is the only observable data point, and it sets a floor for what is tolerated rather than a ceiling.

Mapping to the unified model

Gaps and open questions

  • No base URL, path, method, header or request body is published for anything. The page is a mechanism description, not a reference.
  • Sources conflict on where credentials come from. Base says the seller panel under API integration settings, EasyEcom and Unicommerce say the Nykaa team. Verify in the panel first.
  • The Vin eRetail lead is unconfirmed. Vinculum's case study and the api-nykaa.vineretail.com host make it likely that the seller API is a Vin eRetail surface, which would mean a documented integration shape exists. Ask Nykaa directly rather than assuming it.
  • Whether a direct seller to Nykaa API integration is permitted at all, or whether Nykaa only provisions credentials to approved aggregators, is not stated anywhere. This is the first question to ask.
  • The username prefixes 50 and 53 come from Unicommerce notes dated February and May 2024. They may be Unicommerce conventions rather than Nykaa's, and they may have changed.
  • No settlement, no webhook, no sandbox, no rate limit, no versioning information exists in public.

Sources