intelligent.pageDocs

StoreHippo

StoreHippo exposes a real REST API at /api/1.1/entity/ms.* with access-key or OAuth 2.0 Bearer auth, full read and write on products and orders, and 13 webhook events.

StoreHippo is an Indian enterprise ecommerce platform from Hippo Innovations, sold as a hosted D2C storefront, a B2B portal and a multi-seller marketplace builder on the same core. It matters here because it is one of the very few Indian store builders with a genuine, documented, self-serve REST API: everything in the admin panel is an entity, every entity has the same CRUD surface, and a seller can mint an access key in the panel without talking to anyone. Once you have written the entity client you have written the whole connector. Verified on 2026-09-21 against StoreHippo's help site, its official Node.js SDK source, and live unauthenticated calls to StoreHippo's own store.

At a glance

What it is

StoreHippo is D2C plus marketplace: a single store can run as a straightforward brand storefront, or with the seller module turned on as a multi-vendor marketplace with per-seller catalogues, ledgers, discounts and payment methods. It is India-headquartered, with its help content and phone support in India, and it sells internationally under the same product. Plan tiers gate features rather than the API itself, with two exceptions worth knowing: webhooks are "Business Plan and above", and custom entities beyond the built-in ms.* set are Enterprise. It carries native integration topics for Unicommerce, Shiprocket, FedEx, Xero and Zapier, so a store you meet in the wild may already be fed by an order management vendor.

API access

No approval process and no partner tier is needed for the basic case. A seller generates an access key in the admin panel under Advance Settings and hands it to you.

  • Access key: a "24 character long alphanumeric key that is auto-generated". You pick a user when creating it, and StoreHippo states "The generated access key will have permissions accordingly to the role of the specified user", so the role is the permission boundary, not a scope string. Give the integration its own user with a narrow role. The key must be enabled with a checkbox before it works.
  • OAuth app: for an app that many stores install. StoreHippo issues a client_id and client_secret and you run the authorization code flow per store.

Versioning is in the path: the official SDK builds its base URL as the store host plus /api/ plus a version string, and 1.1 is the version in StoreHippo's own examples. No deprecation dates are published for 1.1. The official SDK is HippoInnovations/storehippo-nodejs-sdk, Node.js, last pushed 2020-09-30. It is thin, and reading its 343 lines is the fastest way to understand the URL construction. No other language SDK is published.

Authentication

Two models. Use the key for a single store you control, OAuth for a product installed into stores you do not.

Access key

  1. The seller creates a user with the role the integration needs.
  2. The seller creates an access key against that user in Advance Settings and enables it.
  3. Send the key on every request in the access-key header. There is no exchange step and no expiry documented.
curl "https://{store}.storehippo.com/api/1.1/entity/ms.orders?limit=20&sort=-created_on" \
  -H "access-key: {24-char-access-key}"

OAuth 2.0, authorization code

  1. Send the merchant to the authorization prompt on their own store host:
GET https://{store}.storehippo.com/admin/oauth/authorization?client_id={client_id}&scope={scopes}&redirect_uri={redirect_uri}&state={nonce}
  1. StoreHippo redirects back to redirect_uri with a code.
  2. Exchange it:
curl -X POST "https://{store}.storehippo.com/admin/oauth/token" \
  -H "content-type: application/json" \
  -d '{
    "client_id": "{client_id}",
    "client_secret": "{client_secret}",
    "code": "{code}",
    "redirect_uri": "{redirect_uri}",
    "grant_type": "authorization_code"
  }'
  1. The response carries access_token and refresh_token. StoreHippo says the "access_token is an API access token that can be used to access the store's data as long as the client is installed", which reads as no fixed expiry while the app stays installed. The token lifetime and the refresh call are not documented; design the credential store to hold the refresh token and to re-run the flow on a 401.
  2. Call with Authorization: Bearer {access_token}. The SDK sends either the access-key header or the Bearer header, never both.

Documented scopes are read and write pairs over: Orders, Customers, Products, Categories, Collections, Brands, Blogs, Pages, Redirects, Script Tags, Startup Controllers and Checkouts. The exact scope string format is not published.

Multi-account is clean because the store name is in the hostname: key your credential store on the store host.

Objects we can read

Everything shares one URL shape. Where {v} is the API version, for example 1.1:

Documented global entities are ms.products, ms.orders, ms.users, ms.categories, ms.brands, ms.collections and ms.wallet_transactions. StoreHippo describes entities as "basic building blocks of the store. There is one entity for the same type of resource e.g. product, order, user etc." with "built-in entity commands (get, list, add, edit, delete etc.) available for all entities", plus per-entity custom commands: it names receivePayment and ship on the order entity.

List query parameters, from the SDK README:

  • filters: array of {field, value, operator}, where operator is equal, less_than or greater_than
  • start: offset
  • limit: page size
  • sort: field name, prefix with - for descending

Pagination is offset based. Every list response carries a paging object, so drive the loop off total and start:

{
  "messages": [{ "name": "ms.entity.products.list", "level": "success" }],
  "fileBaseUrl": "https://www.storehippo.com/s/5667e7d63086b2e718049ad9/",
  "paging": { "limit": 1, "start": 0, "count": 1, "total": 1 },
  "data": []
}

Orders

GET /api/{v}/entity/ms.orders. Requires a credential: unlike products, orders are not public. Filter with filters on a date field and sort with -created_on for an incremental pull. The order entity also carries the named commands receivePayment and ship.

The order field list is not published and could not be read without a store login, so no sample is given here. Capture one real order before mapping. What is safe to assume from the platform's conventions, and should still be verified: a Mongo style _id, created_on and updated_on timestamps, a seller reference on multi-seller stores, and a metafields object for custom fields.

Products and listings

GET /api/{v}/entity/ms.products. On a public storefront this works with no credentials at all, which makes catalogue and competitor reads trivial and is worth knowing about from a security point of view too. Live response from StoreHippo's own store on 2026-09-21, trimmed to the fields that matter:

{
  "_id": "615a9b9babf8f857fba24c0f",
  "name": "Enterprise",
  "alias": "enterprise-3_month",
  "sku": "enterprise-3_month",
  "uniquesku": ["enterprise-3_month"],
  "price": 30000,
  "list_price": null,
  "our_price": null,
  "available": 1,
  "inventory_management": "none",
  "location_availability_mode": "default",
  "publish": "1",
  "approve": "approved",
  "seller": "568108dc449d1d150eaf8c5f",
  "weight": 200,
  "dimension": {},
  "tax": {},
  "variants": [],
  "options": [],
  "categories": [],
  "collections": [],
  "images": [],
  "metafields": { "storehippo_package": "1", "allow_custom_pricing": "1" },
  "created_on": "2021-10-04T06:13:47.891Z",
  "updated_on": "2025-04-16T07:29:09.544Z"
}

Image paths in images are relative: prefix them with the fileBaseUrl returned at the top of the response. available is the stock number, but inventory_management decides whether StoreHippo tracks it at all, so a product with "inventory_management": "none" has a meaningless available.

Inventory

There is no separate documented inventory entity. Stock lives on the product as available, governed by inventory_management, with location_availability_mode pointing at multi-location behaviour. Variant level stock sits inside variants. Treat ms.products as the inventory source.

Customers, wallet and store credit

GET /api/{v}/entity/ms.users needs a credential and its field list is not verified. Treat everything in it as PII. ms.wallet_transactions is the one entity documented with real field names: action, amount, description, posting_type with values Credit or Debit, type with values loyalty or StoreCredits, and user holding a user id. It is a write surface as much as a read one.

Shipments, returns and settlements

Not documented as entities. The panel has order tracking, a return merchandise authorization flow, a seller ledger on multi-seller stores, and CSV import and export for shipments, but the entity names behind those screens are not published. This is the part of the connector that needs a store login to inspect. The order entity's ship command is the only shipping-adjacent API surface named in the docs.

Writing back: listings, price and stock

Yes, and by the same entity calls.

curl -X PUT "https://{store}.storehippo.com/api/1.1/entity/ms.products/615a9b9babf8f857fba24c0f" \
  -H "access-key: {24-char-access-key}" \
  -H "content-type: application/json" \
  -d '{"data": {"price": 28500, "available": 42}}'

The SDK confirms the envelope: create and update both wrap the record in a data key and both send content-type: application/json. Anything that is not one of the six built-in commands is a PUT to /_/{command}.

For volume, use the panel's CSV import rather than the API. StoreHippo's own rate limit page recommends it: the bulk import handles up to 10,000 add, update or delete operations, processed sequentially, without being throttled, and there are dedicated import and export flows for products, brands, coupons, linked products and shipments. It runs as an asynchronous job whose status you watch in the panel. There is no published endpoint to submit an import file or poll its status.

Webhooks and notifications

Available on the Business plan and above. Configure them in the admin panel under Advanced Settings, Webhooks, with Add New. Each webhook is one event plus a URL, an optional set of key and value headers that StoreHippo will send, and on multi-seller stores a seller selection.

The 13 documented events:

  • Customers: Customer Creation, Customer Update, Customer Delete, Customer Enquiry
  • Orders: Order Creation, Order Update, Order Delete
  • Products: Product Creation, Product Update, Product Delete, Product Enquiry
  • Other: Marketing user list, Wallet Transaction Add

Deliveries carry StoreHippo's own headers, which is what you route and deduplicate on:

  • x-ms-store: store name
  • x-ms-entity: entity type
  • x-ms-command: the operation performed
  • x-ms-recordid: record id, on edit and delete
  • x-ms-filebaseurl: file path prefix for relative media paths in the body

The body follows the same structure as the API's own representation of that entity.

Warning

No signature, no shared secret and no retry policy are documented. The custom headers field is the only lever you have: put a long random secret in a header there and reject deliveries that do not carry it, and treat the body as untrusted until you refetch the record through the API by x-ms-recordid. Because retries are undocumented, assume at-most-once delivery and keep a reconciliation sweep.

Rate limits and pagination

StoreHippo documents "2 API requests per second" per store. That is roughly 120 per minute and it is the whole budget, shared across every integration hitting that store. No plan differentiation is published, no quota headers are documented, and the page does not say what the response looks like when you exceed it, so handle a 429 and an opaque error equally. StoreHippo's own advice is to insert a one second delay after every two consecutive calls, and to use CSV bulk import instead of the API for anything large.

A practical cadence: pull orders incrementally with sort=-created_on and a greater_than filter on the last seen timestamp at limit=100, every five minutes. A full catalogue refresh of 10,000 products at limit=100 is 100 calls, so nightly is comfortable. Do not run two syncs against the same store at once.

Mapping to the unified model

Gaps and open questions

  • The ms.orders field list is the biggest gap. Everything else on this page came from first-party sources; the order schema needs one authenticated call against a real store.
  • The entity names behind shipments, returns and the seller ledger are not published. Neither is the OAuth token lifetime, the refresh grant, or the scope string format: StoreHippo only says the token works "as long as the client is installed".
  • Webhook signing, retries and delivery timeouts are all undocumented.
  • The public reachability of ms.products without any credential is presumably deliberate, since storefronts are public, but it means a competitor can read the full catalogue including metafields in one request. Worth flagging to any StoreHippo merchant you work with.
  • help.storehippo.com also serves some of StoreHippo's internal engineering notes. They are not seller-facing and should not be treated as an integration contract even though they are publicly reachable.
  • The Unicommerce integration is configured from the Uniware side using the StoreHippo seller's panel email and password against {storename}.storehippo.com/unicommerce, not with an access key. If a store is already on Unicommerce, reading from Unicommerce may be less work than a second connector.

Sources