OZI

OZi is an Indian quick-commerce retailer selling baby, kids and mother care products with a delivery promise measured in minutes, live across Gurugram, Noida, South Delhi, Dwarka, West Delhi, East Delhi and Central Delhi. It is not a store builder and not a cart platform: it is a curated first-party retail app that buys from brands and authorised distributors and resells. That matters for this catalogue, because a brand does not "integrate with OZi" the way it integrates with a marketplace. It sells to OZi. There is no seller API, no seller documentation and no public developer surface, and the one machine interface OZi exposes is the app's own buyer API, which is not an integration contract.

At a glance

What it is

From OZi's own about page: "The Ozi platform, created and owned by Ozi Technologies Private Limited (U47912KA2020PTC134973), is licensed for commercial use by select B2B focused entities." Consumer operations are run by a different company, Decifer Fintech Solutions Private Limited, while Ozi Technologies keeps the technology and B2B wholesale trade. The CIN places Ozi Technologies in Karnataka with a 2020 incorporation.

That split is the most interesting thing on the page and is worth reading twice. There are two businesses here: a licensed commerce platform, and a consumer quick-commerce operation running on it. The catalogue entry probably came from the first, but everything reachable on the public web is the second.

The assortment is diapers, wipes and baby skincare, kids fashion and footwear, toys and educational products, school supplies, mom care and maternity, baby food and feeding, and gear and furniture. OZi describes the catalogue as curated from trusted brands and the products as safe and verified, which is retailer language, not marketplace language.

API access

None for a partner, and nothing published. Checks on 2026-09-22:

• No api, docs, developer, seller or business subdomain of ozi.in resolves.
• partner.ozi.in resolves and serves a Vite single page application titled "OZI PARTNERS" with an empty root element, so the portal exists but everything behind it needs a login. Nothing about its scope, its audience or its features is public.
• No developer or integration page appears anywhere on the site. The business sitemap is six URLs: home, privacy, terms, about, shipping and contact.
• The only partner-facing contact published is the address partner@ozi.in.

The consumer service, and what it tells us

consumer-service.ozi.in answers unauthenticated GETs on its root with a service manifest. This is OZi's own output, not inference:

{
  "service": "OZi Order Management Microservice",
  "version": "1.0.0",
  "status": "running",
  "endpoints": {
    "health": "/health",
    "auth": "/api/v1/auth",
    "categories": "/api/v1/categories",
    "orders": "/api/v1/orders",
    "webhooks": "/api/v1/webhooks",
    "integrations": "/api/v1/integrations",
    "cart": "/api/v1/customer/cart"
  }
}

Two things follow, and only two are worth acting on.

First, it is a buyer API, not a seller API. The routes it advertises are login by phone, address book, cart, wishlist, coupons, categories, item details, order placement and order status, customer messaging and static policy pages. There is no catalogue write, no inventory endpoint, no settlement endpoint and no seller scope anywhere in it. Nothing here would let a brand read its own sales or update a listing.

Second, it names OZi's back office. The service exposes POST /api/v1/webhooks/pidge and POST /api/v1/webhooks/easyecom, and a status route that reports on both by name:

{
  "success": true,
  "data": {
    "pidge": { "healthy": false, "retryQueue": 0, "retryItems": [] },
    "easyecom": { "healthy": false, "retryQueue": 0, "retryItems": [] }
  }
}

So OZi runs EasyEcom as its order and inventory system and Pidge as its delivery orchestration layer, and it receives webhooks from both rather than sending them out. That is the single most useful fact on this page: if a brand needs OZi order data, the conversation is about EasyEcom, which has a documented API, rather than about an OZi endpoint that does not exist.

Authentication

Not published for partners. The consumer service authenticates buyers by phone number with a verification step, which is useless for a data integration.

Objects we can read

For a brand selling into OZi: nothing programmatic. OZi buys stock; a supplier sees purchase orders, invoices and remittances, not order-level data, unless OZi agrees to share sell-out reporting. Ask for that in the commercial conversation, and ask for it as a scheduled file or an EasyEcom share rather than as an API, because no partner API exists.

For competitive or catalogue work: the storefront is a normal website. Product, category and blog sitemaps are published at ozi.in/sitemap.xml, images are served from ImageKit and CloudFront, and product pages render server side. Crawl it politely.

Writing back: listings, price and stock

Not available. OZi controls its own catalogue, its own pricing and its own stock, because it owns the stock. A brand has no listing to write to. The closest equivalent is sending OZi an updated price list and catalogue through whatever commercial channel exists, and if OZi is on EasyEcom that is likely to be a file or a vendor portal rather than an API call.

Webhooks and notifications

None outbound. OZi is a webhook consumer, not a publisher: the only webhook routes it exposes are inbound receivers for Pidge and EasyEcom.

Nothing to poll either, since there is no partner-scoped read endpoint.

Rate limits and pagination

Not applicable. No partner interface exists to be limited.

Mapping to the unified model

Do not create an ozi sales channel for a brand that supplies OZi. Those transactions are wholesale: model OZi as a customer in whatever table holds distributor and retailer sales, and keep the purchase order number as the join key.

If OZi later agrees to share sell-out data, expect it to arrive in EasyEcom's shape rather than in a shape OZi defines, so map from /connectors/easyecom and record orders.channel as ozi with orders.channel_account_id set to the EasyEcom location or marketplace identifier that OZi allocates.

Recommendation for the catalogue

Reclassify. OZi is a quick-commerce retailer in baby and kids, and belongs next to the other Indian vertical retail apps in this catalogue rather than among store builders. If the entry exists because of the licensed B2B platform mentioned on the about page, that is a different product with no public presence at all, and the entry should say so.

Gaps and open questions

• What partner.ozi.in actually is: a brand portal, a delivery partner portal, or a store portal for the licensed B2B platform. It is login-gated and unlabelled.
• What the licensed B2B platform is, who licenses it, and whether it has its own interface. The about page is the only public mention of it.
• Whether OZi shares sell-out or inventory data with brands at all, in any format.
• Whether OZi's EasyEcom tenant can be shared with a brand as a vendor account, which would be the cleanest path to real data.
• Whether OZi operates any third party seller model. Everything public reads as first party, but the presence of a partner portal leaves room for doubt.

Sources

• ozi.in and ozi.in/about, read 2026-09-22, for the ownership and licensing statement, the CIN, the city list, the assortment and the sourcing description
• ozi.in/sitemap.xml and its business, product, category and blog children
• partner.ozi.in, a login-gated single page application titled "OZI PARTNERS", 2026-09-22
• consumer-service.ozi.in, its self-describing service root, its endpoint list and GET /api/v1/integrations/status, 2026-09-22
• DNS checks on api.ozi.in, docs.ozi.in, seller.ozi.in, business.ozi.in, admin.ozi.in and b2b.ozi.in, none resolving on 2026-09-22