intelligent.pageDocs

Eshopbox

Eshopbox Developers API: OAuth refresh token grant, warehouse level inventory buckets, inward consignments and GRN, orders, returns, payouts and rich webhooks.

Eshopbox is an Indian e-commerce fulfilment and distribution platform: it runs warehouses for brands, connects them to about thirty sales channels including Flipkart, Amazon, Myntra, Ajio, Tata Cliq, Nykaa and Shopify, and reconciles the money afterwards. Unusually for an Indian 3PL, it publishes a full public developer site, and the API is the real warehouse API rather than a shipping wrapper: you can create an inward consignment against a purchase order, read the goods receipt note it produced, read stock split by warehouse into sellable, non sellable, inward in process and outward in process buckets, push orders in, read shipments out, read returns, and read payouts and fee rules. Everything on this page was read from the official documentation on 2026-09-22.

At a glance

Warning

The documentation names the authorization header inconsistently. Most endpoint tables list a header called Authentication with the value Bearer AUTH_TOKEN, while the Authentication chapter and the worked curl examples use the standard Authorization: Bearer .... The curl examples are the ones that were written against a live server, so send Authorization. Several consignment and GRN endpoints additionally require a proxyHost header carrying your account slug, and they fail without it.

What it is

Eshopbox sells itself as an all-in-one distribution platform for Indian brands selling online. The product is packaged in three parts: Eshopbox Ship for delivery, Eshopbox Fulfill for distributed warehousing where Eshopbox stores, packs and ships, and Eshopbox Plus, a managed selling service across channels. Underneath sit four technology surfaces the API mirrors closely: inventory and order management across channels, warehouse management, finance operations for payment reconciliation and fee tracking, and channel and ERP integrations.

Its channel list is marketplace heavy: Flipkart, Amazon, Myntra, Ajio, Tata Cliq and Nykaa are named on the home page alongside Shopify, with the site claiming more than twenty further channels. That shape shows in the API, where an order carries both a customerOrderNumber from the channel and a vendorOrderNumber, where products have channel availability rather than a price, and where payouts are grouped by portal.

For the unified model Eshopbox is a fulfilment provider and an order management system at once. It supplies inventory with a real location_id, orders and order_items, shipments, returns, locations and a partial view of settlements. It is not itself a sales channel, so listings here means availability of a product on a channel, not a priced listing.

API access

  1. Log in to your Eshopbox workspace.
  2. Go to Apps, then Create a custom app, and complete the short form describing the app.
  3. Choose where to install it. Installing into a new development workspace is the documented route to a test environment.
  4. The app is created and pre-installed. Copy client_id, client_secret and refresh_token from the app screen.
  5. Optionally, turn the app into a sales channel app. This is required only if the app is a sales channel integration, and it asks you to choose which product field identifies a product when managing inventory and creating orders. That choice becomes the identifier your order items must use.

There is no published version deprecation schedule. Paths mix v1 and v2 per resource, and two pages are explicitly marked "coming soon", Get Inventories v2 and Update Order. No official SDK is published; the documentation gives curl examples throughout.

Authentication

OAuth 2.0 with a refresh token grant. There is no interactive authorisation code step for a custom app: the refresh token is handed to you when the app is created, and you exchange it for short lived access tokens.

  1. Obtain client_id, client_secret and refresh_token from the custom app screen.
  2. POST them to the token endpoint with grant_type=refresh_token.
  3. Use the returned access_token as a bearer token.
  4. Re-exchange before expires_in elapses. The documented lifetime is 86400 seconds, one day. The refresh token itself does not rotate in the documented response.
curl -s -X POST https://auth.myeshopbox.com/api/v1/generateToken \
  -H 'Content-Type: application/json' \
  -d '{
    "client_id": "...",
    "client_secret": "...",
    "grant_type": "refresh_token",
    "refresh_token": "GEbRxBNyURedwnqAs...edjnXbLPjyWqaxFtr"
  }'

{
  "access_token": "eyJhbGciOiJSUzI1N...InR5cCI6IkpXVCIsI",
  "id_token": "eyyRwffpgDlOyAxcv...OkguyrSHtteckIyueW",
  "scope": "openid profile offline_access",
  "expires_in": 86400,
  "token_type": "Bearer"
}

curl -s -X POST 'https://acme.myeshopbox.com/api/v1/inventoryListing' \
  -H 'Authorization: Bearer eyJhbGciOiJSUzI1N...' \
  -H 'Content-Type: application/json' \
  -d '{"skus": ["0SGAT12SG25F"]}'

The token is scoped to one workspace, so a multi brand operator needs one app and one credential set per workspace. The workspace slug is also the subdomain in most URLs and the proxyHost header value on consignment endpoints, so store it next to the credentials. id_token is explicitly not for API access.

Objects we can read

Orders

GET https://{workspace}.myeshopbox.com/api/v1/orders/erp

This endpoint is unusual: you name the fields you want. Pass a comma separated list in fields, plus search, filters, page and per_page. The same path, with different filters, is documented for invoiced orders, credit note orders and orders cancelled after being marked ready to ship.

Selected field keys from the documented list:

Two structural points matter. Status lives on the order item, not the order, so a partially shipped order has items in different states. And inventoryItemCode is the join between an order line and a specific physical unit, which is rare and valuable if serial or batch traceability is in scope.

Order items

Returned inside the order object. Item fields used on creation, and echoed on read, are lineItemSequenceNumber, itemID, sellerSkuOnChannel, productName, quantity, customerPrice, discount, lineItemTotal, productUrl and customFields.

Products and listings

  • GET /api/v1/product/{esin} and the product list endpoints read the catalogue. Eshopbox's internal product identifier is the ESIN, and products also carry SKU, EAN, UPC, GTIN, HSN code, MRP, unit price, brand, weight and dimensions.
  • Brands are a separate resource with their own create, update and list endpoints.
  • Availability, not price, is the channel level concept: a product is marked available or unavailable per channelCode.
  • Draft products can be merged into an existing product, which matters when a channel feed creates duplicates.

Inventory

This is the reason to integrate. POST https://{workspace}.myeshopbox.com/api/v1/inventoryListing takes a list of SKUs and returns stock per warehouse and summed across warehouses.

{
  "0SGAT12SG25F": {
    "warehouseInventories": {
      "GGN": { "outwardInProcess": 4, "sellable": 3, "inwardInProcess": 2, "nonSellable": 7 },
      "BNG": { "outwardInProcess": 4, "sellable": 5, "inwardInProcess": 1, "nonSellable": 0 }
    },
    "inventories": { "outwardInProcess": 8, "sellable": 8, "inwardInProcess": 3, "nonSellable": 7 }
  }
}

The four buckets map cleanly onto the unified model: sellable is available, outwardInProcess is reserved against orders being picked, inwardInProcess is received but not yet putaway, nonSellable is damaged or quarantined. The warehouse keys are short codes such as GGN and BNG, which are the codes to use as channel_location_id.

A v2 read, GET /api/v2/inventoryListing, is documented with a large filter set covering sku, esin, parentEsin, brand, hsnCode, taxCode, mrp, unitPrice, weight and dimension ranges, availableOn channel codes, custom fields and createdOn and updatedOn date ranges in yyyy-MM-dd hh:mm:ss form, with page and perPage. It is marked COMING SOON at the top of the page, so treat it as unavailable until tested, and drive incremental syncs from webhooks or the v1 call by SKU batch.

Inward consignments and GRN

The inbound leg is fully modelled, which is rare.

GET /api/v1/consignments lists inward consignments:

{
  "total": 100,
  "page": 1,
  "per_page": 2,
  "data": [
    {
      "id": "7630",
      "consignmentNumber": "CON/45/873",
      "fromPartyId": "5",
      "fromPartyName": "Kapas Kraft Fashion Limited",
      "toPartyId": "72",
      "toPartyName": "Eshopbox Gurgaon(Sohana)",
      "type": "INWARD",
      "status": "SCHEDULED",
      "warehouseId": "7",
      "externalWarehouseId": "2022",
      "document": [
        { "document_type": "inv", "document_number": "45243", "document_url": "https://cdn.filestackcontent.com/45243" }
      ],
      "schedule": {
        "scheduledArrivalDate": "2020-03-23T00:03:00.000Z",
        "scheduledArivalFrom": "10:00:00",
        "scheduledArivalTo": "11:00:00",
        "receivedOn": "2020-03-19 17:46:40.0",
        "completedOn": null,
        "cancelledOn": null
      },
      "itemSummary": { "consignmentQty": "45", "receivedQty": 20, "pendingQty": "45" }
    }
  ]
}

GET /api/v1/grnDetails reads goods receipt notes, filtered by status (Created, Completed), grnId, consignmentNumber, referenceNumber, documentNumber and an inwardOnFrom and inwardOnTo date window, with page, per_page, sort_by and sort_order:

{
  "total": 1,
  "perPage": 10,
  "data": [
    {
      "consignmentNumber": "CON/22-23/664563",
      "referenceNumber": "PO/24/A001",
      "documentNumber": "ABC",
      "documentDate": "2022-01-12 00:00:00",
      "totalOrderedQty": 30,
      "totalReceviedQty": 30,
      "pendingQty": 0,
      "shortageQty": "0",
      "overageQty": "7",
      "consignmentType": "Expected",
      "status": "COMPLETED",
      "totalGrnCount": 3
    }
  ]
}

Shortage and overage against an advised quantity are the numbers a brand actually argues about, and they are here. Note the field is spelled totalReceviedQty in the documented response; match the typo rather than correcting it.

Recall consignments are the mirror image, stock leaving a fulfilment centre back to the brand, with their own create, update, list and appointment endpoints.

Shipments and tracking

GET https://wms.eshopbox.com/api/order/shipment, with page, perPage, status and expectedShipDate. The response carries externalShipmentID, externalWarehouseID, defaultWarehouseCode, externalChannelID, invoiceNumber, picklistCode, boxType, externalManifestNumber and channelManifestNumber alongside the order references. There are also endpoints to create a shipment, update shipment status, create label and AWB, fetch AWB and courier name, dispatch a shipment, and a wrapper API for shipper integrations with tracking by polling or by customerOrderId, plus a dedicated webhook registration for tracking.

Returns and cancellations

GET http://wms.eshopbox.com/api/return-shipment/{customerReturnNumber} reads one return. Documented fields include customerReturnNumber, customerOrderNumber, orderItemID, originalOrderItemId, returnType, returnReason, isExchange, status, refundAmount, shippingCharges, courierName, trackingID, pickupType, pickupAddress, dropAddress and an items array with quantity and line totals. Customer name, contact number and email are present, so treat the object as PII. There are also create, list and complete return endpoints. The documentation writes this base URL as http; use https.

Payments and settlements

Three resources cover the money: payouts, fees and transaction rules.

GET https://{workspace}.myeshopbox.com/payments/api/v1/payout:

{
  "data": [
    {
      "ledgerGroupId": "4",
      "fundTransferDate": "2018-09-25 05:30:00.0",
      "portalName": "Limeroad",
      "fundTransferAmount": 819901.72,
      "transactionId": "lime3",
      "reportUrl": "https://storage.cloud.google.com/.../paymentReport.csv",
      "requestId": "1581925490280",
      "requestStatus": "processing",
      "portalId": "8",
      "active": "1"
    }
  ]
}

The detail sits in the CSV behind reportUrl, not in the JSON, so a settlements pipeline here is a file ingestion job triggered by an API poll. Fees have create, update, list and get endpoints plus a fee details resource, and transaction rules describe how charges are applied. This is the marketplace reconciliation product, so the fee set is broader than storage and picking.

Locations and fulfilment centres

  • GET /api/v1/warehouse lists fulfilment centres with warehouseName, warehouseId, externalWarehouseId, facilityId, gstin, full address, operatingModel, operatingDays, operatingHours, enrollmentStatus and isDefault.
  • POST /api/v1/party creates a location, meaning any place you move inventory from or to. refPartyId must equal the location code in your ERP, which is the field consignment creation matches on.
  • Fulfilment centre subscriptions have their own create, get, list and update endpoints.

Writing back: listings, price and stock

Eshopbox is not a marketplace, so there is no price write. What is writable:

Channel availability

POST https://{workspace}.myeshopbox.com/product-engine/api/v2/productListing

{ "esin": "0SGAT12SG25F", "channelCode": "CH1234", "availability": false }

This is the nearest thing to a listing update: it makes a product sellable or not on one channel. The documentation's own curl example on the same page calls /product-engine/api/v1/productListing, so the two versions coexist and the version in the heading is the newer one. Errors come back in a Google style envelope, for example a 503 with reason "Required information is not available for the product" when a required attribute such as a custom field is missing.

Stock

There is no set-quantity endpoint, and that is deliberate: quantity is a consequence of warehouse events. To increase stock you create an inward consignment and the warehouse receives it; to decrease it you create a recall consignment or ship orders.

POST https://{workspace}.myeshopbox.com/api/v1/createConsignmentApi, with headers Authorization: Bearer ... and ProxyHost: <accountSlug>:

{
  "documentNumber": "INV/001",
  "referenceNumber": "PO/24/A001",
  "documentDate": "2022-12-18 00:00:00",
  "fromLocationCode": "XXLG",
  "toLocationCode": "ERAY",
  "productDetails": [
    { "productId": "testing5", "quantity": 3, "manufacturing_date": "", "expiry_date": "", "batch_code": "" },
    { "productId": "testing1", "quantity": 9, "manufacturing_date": "02-Jun-22", "expiry_date": "", "batch_code": "" }
  ]
}

documentNumber is your invoice number, referenceNumber your purchase order, fromLocationCode and toLocationCode are ERP location codes that must already exist in the workspace, and productId is any scannable identifier of the product, ESIN or SKU. Batch code, manufacturing date and expiry date are accepted when batch tracking is enabled, with the field used depending on the tracking method configured. The response returns a consignmentNumber and a status of CREATING, plus box counters.

Two date formats appear in the same request, 2022-12-18 00:00:00 for documentDate and 02-Jun-22 for manufacturing_date. Follow the examples exactly.

Orders

POST https://wms.eshopbox.com/api/order pushes an order into the warehouse. Mandatory fields are externalChannelID, customerOrderNumber, isCOD, paymentType, taxAmount, subtotal, orderTotal, balanceDue, thirdPartyShipping, shippingAddress and billingAddress with name, address line 1, postal code, contact phone and email on each, and an items array where itemID, productName, quantity, customerPrice, discount, lineItemTotal and productUrl are required. sellerSkuOnChannel becomes mandatory if the products do not already exist in Eshopbox. thirdPartyShipping true means you are arranging the carrier and Eshopbox only picks and packs.

Update Order is documented as coming soon, so plan on cancel and recreate rather than amend. Cancellation and invoice detail endpoints exist, and a separate B2B order set covers create, get, items, invoice update and confirm.

Bulk

Import and export jobs are first class resources with create, get and list endpoints, and both emit webhook events on processing, completed and failed. Use them for the initial catalogue load rather than looping the single create.

Webhooks and notifications

Self serve and unusually detailed. POST https://{workspace}.myeshopbox.com/api/v1/webhook registers one:

{
  "resource": "channel_inventory",
  "eventType": "POST",
  "eventSubType": "updated",
  "version": "v1",
  "externalChannelID": "CLARKS",
  "webhookUrl": "https://example.com/hooks/eshopbox",
  "webhookMethod": "POST"
}

Get, list, update and a logs endpoint are also published. The delivered body carries resource, eventType, eventSubType, version, accountSlug and accountId alongside the object.

The 24 observable resources are: channel inventory, channel subscription, consignment, consignment boxes, consignment items, expense, export job, FC subscription, fee rule, gate pass, gate pass items, GRN, GRN items, GRN summary, import job, invoice, party, payment, product, putaway, recall consignment, recall consignment items, transaction rule and user invitation.

The warehouse relevant subtypes are worth listing, because they are the event stream a stock ledger should be built on:

Note

No signature, shared secret or verification header is documented for webhook delivery, and no retry policy is published. Until Eshopbox confirms otherwise, treat the receiver as unauthenticated: use an unguessable URL, allowlist by source if they will give you addresses, and re-read the affected object through the API rather than trusting the body. One event subtype, uniware_failed, reveals that consignments are synced to Unicommerce behind the scenes for some accounts, which is worth knowing when a consignment fails for no visible reason.

Rate limits and pagination

No rate limit, quota header or burst allowance is published anywhere in the documentation. Do not assume generosity: keep sweeps serial or at low concurrency, and back off on 5xx.

Pagination is a page envelope, not a cursor, and the key names vary by resource: page with perPage and total on most, page with per_page on consignments and GRN, current_page with data on shipments. Always read the envelope rather than assuming.

Filtering is limited. The Filtering chapter states that the only supported operator is = and only on /receivalbles (spelled as shown in the documentation), /payables, /payout, /fee, /transactionRules and /brand. Everything else filters through endpoint specific query parameters, which is why date windows appear as comma separated ranges on the inventory v2 and GRN endpoints.

Errors use a Google Cloud Endpoints style envelope with error.errors[].domain, .reason, .message, plus a top level code and message. The documented 401 example carries a top level code of 412, so branch on the HTTP status, not on the body's code.

Practical sync cadence: subscribe to consignment, GRN, putaway and product webhooks for change detection, pull inventoryListing for the SKUs those events touched, sweep all SKUs once nightly as a reconciliation, poll orders every 10 to 15 minutes on an updatedOn window, and pull payouts daily, fetching each new reportUrl.

Mapping to the unified model

Gaps and open questions

  • No published rate limits. Nothing in the documentation states a quota, and no quota headers are described. This has to be agreed or discovered empirically before a large catalogue sync.
  • No webhook verification. No signature, secret or verification header is documented, which makes the webhook endpoint the weakest link in the design.
  • Inventory v2 is marked coming soon. The filtered, paged inventory read is documented in full but flagged as unavailable. If it is live, incremental stock sync gets far cheaper; test it first.
  • Update Order is coming soon. Amending an order is not possible through the API today.
  • Documentation inconsistencies. Authentication versus Authorization headers, productListing v1 in an example under a v2 heading, http rather than https on the returns base URL, and misspelled fields (totalReceviedQty, recieved, scheduledArivalFrom, /receivalbles). Each of these is a real integration hazard; code against the examples and verify on first call.
  • Where a fee comes from. Fees and transaction rules are readable and writable, but the mapping from a warehouse event to a fee line is not described, so fulfilment cost per order cannot be derived from the API alone without the CSV reports.
  • Unicommerce coupling. A uniware_failed consignment event implies some accounts sync through Unicommerce. Which accounts, and what it means for latency and for the authority of the stock figure, is not documented.
  • Scale. Eshopbox does not publish a fulfilment centre count, square footage or order volume on its public pages, and the warehouse list is per account, so network size cannot be verified from public sources.

Sources