intelligent.pageDocs

Mystore

Mystore is an ONDC seller and buyer app (subscriber prd.mystore.in) run by Hippo Innovations on StoreHippo: reach it through the ONDC protocol or a StoreHippo entity API.

Mystore is an Indian marketplace that sells itself as an ONDC-connected storefront, operated from Gurugram by Hippo Innovations, the same company that makes StoreHippo. That second fact is the one that changes how you build against it, and it is not advertised: mystore.in is a StoreHippo store, its seller-side API is StoreHippo's entity API, and its network-side API is the ONDC protocol. Neither of those is documented on the Mystore site, but both are documented elsewhere, and the ONDC registry publishes Mystore's network identity for anyone to query. This page joins the three sources up.

At a glance

What it is

Mystore is a marketplace, not a store builder, though it sells a D2C storefront product alongside. It describes itself as "a full-stack, AI-powered open network marketplace built in India for sellers and brands of every size", selling across web, app, WhatsApp and bots. Categories run across fashion, grocery, electronics, appliances, beauty and personal care, home and kitchen, health and wellness, auto components, agri input and vehicles. Around the marketplace it sells ShipKaro for shipping, a WhatsApp commerce product and migration tools.

Its seller terms name the operator as "Hippo Innovations", "a company incorporated under the Companies Act, 2013, with its registered office at LG-007-02, LG Floor, MGF Metropolis Mall, MG Road, Gurugram, Haryana-122002, India". No CIN is given on that page. Hippo Innovations is also the publisher of the StoreHippo Node.js SDK on GitHub, which is the link between the two products.

ONDC identity

This is public and you can verify it yourself. The ONDC production registry accepts unauthenticated lookups:

curl -X POST https://prod.registry.ondc.org/lookup \
  -H 'Content-Type: application/json' \
  -d '{"country":"IND","domain":"ONDC:RET10","type":"BPP","city":"std:011"}'

Mystore's record, as returned on 2026-09-22, trimmed:

{
  "subscriber_id": "prd.mystore.in",
  "status": "SUBSCRIBED",
  "ukId": "8e834f09-7186-400b-a531-305ed66d3f6e",
  "subscriber_url": "https://prd.mystore.in/ondc/1.0",
  "country": "IND",
  "domain": "ONDC:RET10",
  "type": "BPP",
  "city": "*",
  "valid_from": "2022-09-21T17:08:23.064Z",
  "valid_until": "2027-09-21T17:08:23.000Z",
  "signing_public_key": "wH1JuZL9RVdl63wJCs8vTpQpVhgd1N03CinKJWElYRE=",
  "encr_public_key": "MCowBQYDK2VuAyEAgqNEabuj9I3/5xkI98sKWsjFLVjnSguoyKCGu7dmQzM="
}

Repeating the lookup across domains and types shows prd.mystore.in registered as both BPP and BAP, that is both a seller app and a buyer app, in ONDC:RET10 (grocery), ONDC:RET12 (fashion), ONDC:RET13 (beauty and personal care), ONDC:RET14 (electronics) and ONDC:RET1A (home and kitchen), all SUBSCRIBED, all with city: "*".

Warning

A separate BAP called mystoreapi.zillybuy.com also matches the string "mystore" in the registry. It is a different participant. Match on subscriber_id exactly, never on a substring.

API access

There are two completely different integrations here. Decide which one you are building before reading further.

Route 1: as an ONDC network participant

If you want Mystore's catalogue and to place orders against its sellers, you become a buyer app (BAP) on ONDC and talk to prd.mystore.in as a BPP. This is the fully documented route, it just is not documented by Mystore. It requires ONDC onboarding: a legal entity, a signed participation agreement, key generation, registry subscription and certification through ONDC's test framework. That is a programme, not a signup form, and it takes weeks.

The protocol is public:

  • ONDC-Official/ONDC-Protocol-Specs holds OpenAPI documents, including protocol-specifications/core/v0/api/retail-hyperlocal.yaml, titled "ONDC Protocol API for retail (grocery, f&b)", version 1.0.33 at the time of reading.
  • ONDC-Official/developer-docs carries the current retail API contracts. Note the quirk: the contracts for "All RET Domains" are published as links to Google Docs, versions 1.2.0 and 1.2.5, rather than as files in the repository, with a category taxonomy in a Google Sheet.
  • ONDC-Official/protocol-base records that the ONDC base layer is the Beckn Protocol specification.

Because the contract of record is a Google Doc rather than a versioned file, pin the version you built against in your own repository and diff it deliberately. Do not assume the spec in the OpenAPI repo matches production.

Route 2: as a seller selling on Mystore

Mystore publishes nothing about a seller API. What can be verified is the platform underneath it:

  • https://www.mystore.in/api/1.1/entity/ms.products?limit=1 returns 401 Unauthorized with an ms-request-id response header. That path, that entity naming and that header are StoreHippo's entity API.
  • Storefront asset URLs use the StoreHippo file base form https://www.mystore.in/s/62ea2c599d1398fa16dbae0a/.
  • The sitemap index uses StoreHippo's sitemap-products-range- and sitemap-sellers-range- prefixed files, including seller sitemaps, which is the StoreHippo multi-seller module.

So the machinery for an authenticated seller API exists on Mystore. What is unverified is whether Mystore will issue a seller an access key, or whether the Advance Settings screen that generates one is hidden from marketplace sellers. Ask, and if the answer is yes, everything on /connectors/storehippo applies unchanged: the access-key header, the /api/{version}/entity/{entity} URL shape, the filters, start, limit and sort query parameters, the paging envelope, the 2 requests per second limit and the 13 webhook events.

Authentication

Network side

ONDC uses signed HTTP requests. Each participant publishes an Ed25519 signing_public_key and an X25519 encr_public_key in the registry, and signs request bodies with the corresponding private key; the receiver looks the sender up in the registry by subscriber_id and verifies. Mystore's current public keys are in the record quoted above, which is also how you confirm you are talking to the right participant. The exact header construction is in the ONDC specification and in the reference implementations; do not hand-roll it, use ONDC's reference code.

Seller side

StoreHippo's two models, an access-key header or an OAuth 2.0 Bearer token. Full sequences are on /connectors/storehippo. One Mystore-specific observation: https://www.mystore.in/admin/oauth/authorization returns HTTP 400 rather than a login prompt, which suggests the OAuth app flow is either not enabled on this store or needs a registered client_id before it will respond, so the access key is the more likely route.

Objects we can read

Through ONDC, as a buyer app

The retail contract defines the request actions search, select, init, confirm, status, track, cancel, update, rating and support, each with a matching asynchronous callback: on_search, on_select, on_init, on_confirm, on_status, on_track, on_cancel, on_update, on_rating and on_support. Alongside those the spec carries reference data endpoints and their callbacks: get_cancellation_reasons and cancellation_reasons, get_return_reasons and return_reasons, get_rating_categories and rating_categories, get_feedback_categories and feedback_categories, and get_feedback_form and feedback_form.

Mapped to the objects this catalogue cares about:

Everything is asynchronous. You post an action, get an ACK, and receive the real content later on your own callback endpoint. Budget for that in the connector design: a correlation store keyed on transaction_id and message_id is mandatory, not optional.

Through the StoreHippo entity API, as a seller

Subject to being granted a credential: ms.orders, ms.products, ms.users, ms.categories, ms.brands, ms.collections. See /connectors/storehippo for the URL shapes and the verified product field list. Mystore's seller sitemaps confirm the multi-seller module is on, so expect a seller reference on records.

Writing back: listings, price and stock

No documented Mystore endpoint. Three practical routes, in descending order of reliability:

  1. StoreHippo entity writes, if Mystore issues you an access key. PUT /api/{version}/entity/ms.products/{recordId} with a {"data": {...}} body, and the panel's CSV bulk import for volume.
  2. Mystore's migration importers. The channel integrations page offers to "Import products from your Amazon, Shopify, WooCommerce or Magento account using a seamless migration tool". This is a one-off catalogue load, not a sync. No field mapping or credential model is published.
  3. The seller panel, by hand.

As an ONDC buyer app you cannot write listings at all. That direction does not exist in the protocol: catalogue flows from BPP to BAP.

Webhooks and notifications

On the network side, callbacks are the protocol. Your BAP registers a subscriber_url in the ONDC registry and every on_* action is posted to it. Verification is the ONDC signature check against the sender's registry key, not a shared secret. Retry behaviour is set by the network policy and the counterparty, not by Mystore.

On the seller side, StoreHippo's 13 webhook events would apply if Mystore exposes the Advanced Settings webhook screen to sellers. Unverified.

Rate limits and pagination

One real, Mystore-specific limit is published, in its seller app policy for buyer apps: "The city based catalog seach requests should have a gap of at least 2 hours between requests" (the typo is theirs). Treat that as a hard constraint on full-catalogue pulls: a city-wide search against Mystore no more than once every two hours. For incremental work, use targeted searches rather than repeating the city sweep.

ONDC itself has no single published numeric rate limit; limits are per participant and per network policy. StoreHippo's documented 2 requests per second would apply to the seller-side entity API.

ONDC pagination is not offset based. The catalogue arrives in on_search callbacks and can be split across multiple callbacks for one transaction_id, so accumulate by transaction rather than by page number.

Mapping to the unified model

Two mappings, depending on the route.

For the seller-side route, use the StoreHippo mapping table on /connectors/storehippo unchanged, with orders.channel set to mystore.

Gaps and open questions

  • Whether Mystore issues seller access keys for the StoreHippo entity API is the single unanswered question that decides whether Route 2 exists at all.
  • Whether Mystore's seller panel exposes StoreHippo's webhook configuration to marketplace sellers.
  • Which ONDC retail contract version prd.mystore.in actually serves. The subscriber_url ends in /ondc/1.0 while the current published contracts are 1.2.0 and 1.2.5, and a path segment is not a version declaration.
  • Mystore's settlement and payout model for sellers is not documented on any page we read.
  • The migration importers' credential model, field mapping and whether they can be re-run as a sync.
  • Mystore's ONDC registrations beyond the five retail domains checked here, for example food and beverage, agriculture or logistics, were not enumerated.

Sources