Ajio

AJIO is Reliance Retail's fashion and lifestyle marketplace, and after Myntra it is the second destination an Indian apparel brand has to be on. It carries several storefronts on one seller system: the main AJIO catalogue, AJIO Luxe for premium brands, Trends for value, and Azorte. There is no public developer portal and no published API reference. What exists is a vendor management system, AJIO Commerce Seller Central, and an integration surface that order management vendors reach using the seller's own portal credentials: a POB ID as the username and the portal password. The unusual part of AJIO, and the part that most often breaks a naive connector, is not the API. It is the operating model: demand arrives as pendency rather than as an order you accept, boxes must be scanned at SKU level, manifest closure is mandatory, and returns do not sync at all.

At a glance

What it is

AJIO is a marketplace, not a retailer's webshop, but it inherits Reliance Retail's supply chain vocabulary and controls. Two seller models matter:

• Dropship, also called JIT, just in time. The seller holds the stock, AJIO raises demand against a listing, and the seller packs and hands over. This is the model every order management vendor integrates.
• Sell or Return, SOR. AJIO holds the stock at its own warehouses and returns unsold units. There is no seller side fulfilment API surface here, because AJIO is doing the fulfilling. Fynd's onboarding notes that conversion from Sell or Return to Dropship is possible but that style or EAN overlap and migration between them is not.

A POB, point of business, is AJIO's unit of selling location. A seller with several warehouses gets several POB IDs, each beginning with DV, each with its own portal password. That matters for a connector: the credential is per location, not per seller, so the credential store needs a row per POB and a map from POB to internal warehouse.

Unicommerce restricts its AJIO integration to the Fashion and Luxury segments and to accounts capable of SKU level traceability, which is a statement about AJIO's operating requirements rather than about Unicommerce's own limits.

API access

There is no application form on a developer site. The sequence, assembled from Fynd's onboarding documentation and the order management vendors' setup pages:

1. Get brand approval from AJIO. AJIO reviews the brand and shares terms of trade for the dropship model.
2. Register on AJIO Commerce Seller Central and upload the catalogue using AJIO's category specific templates. Activation takes roughly seven to ten days.
3. AJIO assigns a POB ID per location and tags the account to the integrator. Fynd's documentation shows this literally: the account is tagged under Fynd_VMS. So the integrator is registered on AJIO's side, and the seller is attached to it.
4. The seller resets the password for each POB on the seller portal and shares the credentials with the integrator.
5. The integrator maps SKUs, runs a pre launch test, and validates invoices and shipping labels before going live.

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

Authentication

Two fields, per POB:

• Username, the POB ID, beginning with DV.
• Password, set by the seller in AJIO Seller Central.

Vinculum's setup adds a third configuration value, a B2B flag, which its guide says must always be set to yes for the B2B marketplace channel. That is a routing flag inside Vinculum rather than an AJIO credential.

Where e-invoicing applies under Indian GST rules, the integration also needs GSP e-invoice panel credentials. Those are not AJIO credentials, they belong to the seller's GST Suvidha Provider, but the AJIO flow depends on them because AJIO requires the e-invoice inside a two day window from invoice printing.

No token endpoint, expiry, refresh, or scope model is published. Multi account handling is by POB: one credential pair and one warehouse mapping per POB ID.

Objects we can read

No endpoint, parameter, pagination model or sample response is published for any object. The operations below are the ones that two order management vendors independently confirm.

Orders

AJIO's demand object is pendency, and the integrations run a dedicated pendency sync alongside order sync. Pendency is open demand against a listing that the seller has not yet fulfilled. The practical reading for a connector is that AJIO tells you what is owed rather than handing you a discrete order you accept or reject, and the seller's system creates fulfilment work from it.

Order sync and pendency sync are separate operations in Unicommerce's list, so both exist and they are not the same call.

Sample response not published. Field names not published.

Order items

Lines exist inside the order. No separate order items endpoint is described. Because AJIO mandates SKU level traceability and scanning, the line and the physical unit are tightly coupled: Unicommerce requires the system configuration "Mandate Scanning For SKU Traceability" to be enabled before the channel will work.

Products and listings

Catalogue sync is supported in both directions of reading. Vinculum's guide gives the only published field level detail on AJIO anywhere in this research: SKU pull in moderate mode is mandatory, AJIO's SKU code maps to its ChannelSKUcode field, and AJIO's product identity maps to ChannelProductId in the form ProductId~VariantId. That tells you AJIO has a two level identity, a product and a variant, joined by a tilde in at least one integration's representation.

Listing creation is not an API. It is a category specific template uploaded in Seller Central, followed by a seven to ten day activation wait.

Inventory

Inventory sync is supported. Because the credential is per POB and a POB is a location, inventory is naturally per location: each credential pushes the stock for its own point of business. No batch size, cadence or reconciliation endpoint is published.

Shipments and tracking

This is where AJIO is most prescriptive, and the constraints are documented precisely:

• Orders must be processed through a picklist. Manual invoice generation is disabled.
• Boxing with a packing slip is enabled, and the invoice label print type is off, so the label comes from AJIO rather than from the seller's system.
• A seal ID is fetched automatically from AJIO at box closure. The box is the shipping unit and AJIO issues its identity.
• Manifest closure is mandatory. Unicommerce states it as a required step in processing AJIO orders, with closure needed within two days of invoice printing where e-invoicing applies.
• Tracking comes back: AWB number and courier partner name are both synced.
• Status sync covers cancelled and dispatched.

A connector that treats AJIO like Amazon, generating its own invoice and label and skipping the manifest, will produce shipments AJIO does not recognise.

Returns and cancellations

Cancellation status syncs. Returns do not. Unicommerce is explicit that there is no auto sync for AJIO returns and that they are handled manually through the putaway process. This is a real gap: returned units arrive physically and have to be reconciled by hand or from a panel report.

Payments and settlements

No settlement or payout API is described. Panel reports only.

Customers

Customer details necessarily arrive with dropship demand, since the seller packs and the label is generated for a delivery address. Nothing is published about masking. Treat everything received as PII.

Locations

Locations are POBs. There is no location listing API: you learn your POB IDs when AJIO issues them.

Writing back: listings, price and stock

Stock is the confirmed write path, through inventory sync, per POB.

Price has no described API path. AJIO's commercial model, with brand terms of trade negotiated up front and platform run discounting events, makes price a portal and account management matter. Plan for Seller Central.

Listings are created and updated with AJIO's category specific bulk templates in Seller Central. No listing creation, attribute update or activation API is described. The seven to ten day activation delay after a catalogue upload should be built into any onboarding flow.

Invoices are the one unusual write. Invoice details sync back to AJIO, and where the seller is under e-invoicing rules the GST e-invoice has to be generated through a GSP and closed out within two days of invoice printing. That deadline is an operational constraint a connector has to enforce, not just report.

Webhooks and notifications

None published. No source describes AJIO pushing anything to a seller endpoint. The integrations poll, and pendency sync is the poll that matters, since it is how new demand appears.

A reasonable cadence, absent published limits: pendency and order sync every ten to fifteen minutes during business hours, inventory sync on change with a daily full reconciliation, catalogue sync daily. Returns need a manual or report driven process regardless of cadence, because they do not sync.

Rate limits and pagination

Not published. No numbers, no headers, no pagination model. Ask AJIO's integration contact for these at the same time as the POB credentials.

Mapping to the unified model

Gaps and open questions

• No base URL, path, method, header or body is public for any call. This page describes a mechanism and a set of operating constraints, not a reference.
• The distinction between pendency and order is not defined in any source read here. Which one carries the customer address, and which identifier is stable across the two, is unresolved and is the first thing to establish.
• Returns have no API path at all, on a fashion marketplace where returns are a large share of volume. Confirm whether an AJIO returns API exists and is simply unused by the vendors, or whether it genuinely does not exist.
• Authentication is the seller's portal password, so there is no rotation story and no scoping. Ask whether AJIO issues a dedicated API credential to integrators.
• The ProductId~VariantId form is a Vinculum representation. Whether the tilde is AJIO's or Vinculum's is unclear.
• No settlement API, no rate limits, no sandbox, no versioning, no changelog.
• Unicommerce's restriction to Fashion and Luxury segments may be a vendor limit or an AJIO one. Verify before assuming other categories can integrate.

Sources

• AJIO Commerce Seller Central, official, login only
• Unicommerce: integration with AJIO, aggregator, source of the POB ID and password credential pair, the DV prefix, the pendency, catalogue, inventory, order and invoice sync list, the SKU traceability and picklist requirements, the mandatory manifest closure, the seal ID behaviour and the statement that returns do not auto sync
• Unicommerce: integration with AJIO B2B, aggregator, source of the boxing and invoice label print settings, the AWB and courier partner tracking sync and the two day e-invoice window
• Vinculum Vin eRetail: AJIO JIT, aggregator, source of the mandatory SKU pull in moderate mode, the ChannelSKUcode mapping and the ProductId~VariantId form of ChannelProductId
• Fynd: onboarding on AJIO Commerce Seller Central, aggregator, source of the Seller Central URL, the POB assignment and password reset flow, the integrator account tagging, the seven to ten day activation and the Sell or Return to Dropship conversion rule