Zippee is quick commerce as a service. A D2C brand keeps its own storefront and its own customers, stock sits in Zippee dark stores, and Zippee picks, packs and runs the last mile in 60 minutes, 120 minutes or same day. It is not a courier and not a marketplace: it is a fulfilment and delivery network, which means it holds inventory, so inventory and locations genuinely apply alongside shipments. There is a real, modern API behind it, a federated GraphQL gateway, and none of it is documented in public. The capability set can nonetheless be pinned down precisely, because ClickPost has integrated Zippee as a carrier and publishes what it wired up. This page combines both.
At a glance
What it is
A Gurugram company at 345, Udyog Vihar II, Sector 20, Gurugram, Haryana 122008, contact hello@zippee.delivery. It is one of the larger operators in this part of the catalogue, not a two-person startup.
Published scale as of 2026-09-22, from Zippee's own structured data and marketing:
Everything except the last is a vendor claim. The last is a secondary source and still originates with the company.
The positioning is explicitly anti-marketplace, the same argument LoQally makes at smaller scale: brands get quick commerce speed on their own website without listing on a quick commerce app, so they keep margin, customer data and brand control. Two named pieces of product go beyond plain fulfilment: an AI Control Tower that "predicts high-risk orders before they fail" and confirms COD over WhatsApp, and an NDR Bot that auto-retries missed deliveries.
Integrations are claimed at 100 plus, with Shopify, WooCommerce, Amazon, Flipkart, Swiggy, Zomato, Shiprocket, Unicommerce and EasyEcom named. That set is telling: Zippee ingests orders from storefronts, marketplaces, food aggregators and order management systems alike.
The operating domain is zippee.delivery. zippee.ai 301 redirects to it. zippee.in is not Zippee: it is a domain broker page offering the name for 5,500 dollars, and zippee.co is parked on GoDaddy addresses. Anything citing zippee.in as the company is wrong.
API access
Zippee publishes no developer documentation. What is verifiable from outside on 2026-09-22:
The gateway answers GET /health without credentials and enumerates its own service topology:
{
"status": "healthy",
"timestamp": "2026-09-21T20:23:44Z",
"services": [
{ "name": "core", "status": "healthy", "url": "http://zippee_core:8081/graphql" },
{ "name": "fulfillment", "status": "healthy", "url": "http://zippee_fulfillment:8082/graphql" },
{ "name": "tracking", "status": "healthy", "url": "http://zippee_tracking:8083/graphql" },
{ "name": "integration", "status": "healthy", "url": "http://zippee_integration:8084/graphql" },
{ "name": "notification", "status": "healthy", "url": "http://zippee_notification:8085/graphql" },
{ "name": "finance", "status": "healthy", "url": "http://zippee_finance:8086/graphql" },
{ "name": "reporting", "status": "healthy", "url": "http://zippee_reporting:8087/graphql" },
{ "name": "sse", "status": "healthy", "url": "http://zippee_sse:8088" },
{ "name": "audit", "status": "healthy", "url": "http://zippee_audit:8090" }
]
}
That is a federated GraphQL architecture with nine subgraphs behind one gateway, plus a server-sent events service for streaming and a separate audit service. It tells you what the domain model is divided into, which is the most useful thing available in the absence of a schema: core, fulfilment, tracking, integration, notification, finance, reporting.
POST /graphql with a trivial unnamed query returns {"errors":[{"message":"Unable to parse GraphQL query - could not identify operations"}]}, so the gateway requires named operations and gives nothing away anonymously. Every other path returns a bare Not found. Responses carry strict-transport-security with preload, content-security-policy: default-src 'none', x-content-type-options: nosniff, a restrictive permissions-policy and cache-control: no-store. This is a well-configured production gateway, not a hobby deployment.
The route in is commercial: join the waitlist at zippee.delivery/contact, then onboarding. Zippee's own homepage names "Onboarding and API integration for your online store" as step one of its service, so API access is part of the standard engagement rather than a special request.
Reaching it through ClickPost instead
ClickPost has integrated Zippee as a carrier and publishes the capability matrix, which is the only precise public statement of what the interface supports:
ClickPost also describes Zippee as "a quick commerce logistics platform that helps D2C brands deliver faster and more efficiently" with "an extensive network of 50+ dark stores and a dedicated last-mile delivery fleet" across 12 plus cities. Note the discrepancy: ClickPost says 50 plus dark stores and 12 plus cities, Zippee's own site says 140 plus and 21 plus. The ClickPost page is stale. Prefer Zippee's numbers and treat the ClickPost page as evidence of capability, not of scale.
If ClickPost is already in the stack, integrating Zippee through it is the pragmatic route: you code against ClickPost's documented REST interface and Zippee becomes a carrier code. See /connectors/clickpost.
Authentication
Not published. The gateway requires a named GraphQL operation and, on the evidence of the sealed schema, a credential before anything is returned. No token endpoint, header name, lifetime, refresh mechanism, scope model or multi-brand pattern is documented anywhere.
For a GraphQL gateway of this shape the overwhelmingly likely model is a bearer token in the Authorization header, scoped to a brand account, but that is an inference and not a finding. Settle it in onboarding before designing a credential store, and ask specifically whether tokens are per brand, per dark store or per integration.
No authenticated example can be shown, because none has been made and guessing credentials against a production host is not acceptable practice.
Objects we can read
No schema is published, so no field names can be quoted. The service split above is the best available map of what exists.
Orders
Ingested rather than owned. Orders arrive from Shopify, WooCommerce, Amazon, Flipkart, Swiggy, Zomato, Shiprocket, Unicommerce, EasyEcom or a custom store through the integration service, and Zippee fulfils them. Read the order from the sales channel connector; use Zippee for what happens after.
Order items
Implied by pick and pack. Not documented.
Products and listings
Not applicable as listings. Zippee needs product identity, dimensions and stock depth to run a dark store, but it does not publish a catalogue or own a listing.
Inventory
Real, and the reason Zippee is different from a carrier. Stock sits in 140 plus dark stores and Zippee's own service description names "dark store inventory management" as a step in its process. A stock-by-SKU-by-dark-store table therefore exists in the fulfilment service. Nothing about its interface is published: no query, no update mechanism, no reservation model, no replenishment model. How stock is allocated across 140 stores, and who decides, is the most commercially important unanswered question on this page.
Shipments and tracking
The tracking service is its own subgraph, and the server-sent events service alongside it suggests live status streaming to the dashboard. ClickPost confirms both polling and webhook tracking, plus proof of delivery, so scan history and POD both exist at the interface.
Field names, the status vocabulary and the event shape are unpublished. Sample response not published. A public buyer tracking page runs at zippee.delivery/track-order.
Returns, NDR and RTO
Well covered by capability, badly covered by documentation. ClickPost lists NDR, NDR action update and return webhooks. Zippee's own material describes an NDR Bot that auto-retries missed deliveries and a Control Tower that predicts high-risk orders and confirms COD over WhatsApp before dispatch. RTO reduction is the headline metric. None of it has a published interface.
Whether a returned unit restocks into the dark store it shipped from, and how that appears in inventory, is unknown and matters for a brand holding stock there.
Proof of delivery
Supported, per ClickPost. Format and retrieval mechanism unpublished.
Payments and settlements
A dedicated finance subgraph exists, so billing, COD collection and remittance are modelled. COD is clearly central: a 92 percent COD fulfilment rate is a headline claim and COD confirmation over WhatsApp is a named feature. No remittance cycle, statement format or interface is published. Ask.
Customers
Buyer name, address and phone reach the rider on every order, and Zippee messages buyers on WhatsApp for COD confirmation. All PII. The product proposition is that the brand keeps the customer relationship, so get the processor and controller roles written into the contract.
Locations
140 plus dark stores across 21 plus cities. No location list or serviceability query is published. Serviceability is the whole product here: which pincodes get 60 minutes, which get same day, and which fall back to a normal courier. That lookup must exist and is undocumented.
Writing back: listings, price and stock
Not applicable, this is a fulfilment and delivery network rather than a sales channel. Zippee holds no listings and sets no prices.
The write path, as confirmed by ClickPost's capability matrix, is: create the order, generate the AWB, fetch the label, raise a pickup request, cancel if needed, and post an NDR action update to resolve a failed delivery. Manifestation and label generation are explicitly named.
The other write-shaped operation, and the one unique to a dark store model, is stock allocation: deciding which SKUs sit in which of 140 locations at what depth, and keeping that in step with the brand's own inventory. Nothing describes whether that is self-serve in the Blaze dashboard, programmatic, or a joint planning exercise with Zippee. It should be the first question in onboarding.
Webhooks and notifications
Push exists. ClickPost lists tracking by webhook and return webhooks against Zippee, which means Zippee emits status and return events to an integrator endpoint. Zippee itself documents no event catalogue, no request body, no signature scheme and no retry policy, so all four must be settled in onboarding. Do not expose an endpoint until you know how authenticity is proved.
The notification subgraph and the server-sent events service are separate concerns: notification is buyer messaging, WhatsApp and similar, and SSE is most likely the dashboard's live feed rather than an integrator-facing stream. Confirm whether SSE is offered to brands, because for a 60 minute delivery a stream beats polling by a wide margin.
If push is unavailable, poll through ClickPost rather than building a poller against an undocumented GraphQL gateway.
Rate limits and pagination
Not published. No quota header appeared on any unauthenticated response. GraphQL makes page sizes a schema question, and the schema is sealed. Agree a query budget and a page size in onboarding, and expect a federated gateway to care more about query depth and complexity than about request count.
Mapping to the unified model
Field names are unknown. The right column names the concept or the source.
Gaps and open questions
- The entire GraphQL schema. No types, no queries, no mutations, no enums are public, so nothing can be implemented against Zippee directly today.
- Authentication model: token shape, scope, lifetime and whether it is per brand.
- Inventory allocation across 140 dark stores: who decides, how it is changed, and whether it is programmatic.
- Serviceability lookup by pincode and service level. This must exist and is undocumented.
- Return restock behaviour into a dark store.
- COD remittance cycle and statement format, despite COD being a headline capability.
- Whether the server-sent events service is offered to brands or is dashboard-only.
- Webhook event catalogue, body and signature.
- The ClickPost carrier page contradicts Zippee's own site on scale, 50 versus 140 dark stores and 12 versus 21 cities. The ClickPost page is stale; that also means its capability list may lag the current interface in either direction.
Sources
- Zippee homepage, read 2026-09-22, for the service description, dark store and city counts, brand count, delivery tiers, integration list, Control Tower and NDR Bot, and the Gurugram address from its structured data
- Zippee partners page, for the partner programme
GET https://api.zippee.delivery/health, which returns the nine-service topology quoted above, andPOST https://api.zippee.delivery/graphql, which rejects unnamed operations, both checked unauthenticated on 2026-09-22- Live DNS and HTTP checks on
zippee.delivery,api,blaze,docs,developer,appanddashboard, pluszippee.ai,zippee.inandzippee.co, run 2026-09-22 - ClickPost, Zippee carrier integration, for the capability matrix and the named APIs, with the caveat that its scale figures are stale
- ClickPost developer documentation, the aggregator route described above
- An Angel One unlisted-companies report linked from Zippee's own site, reporting 9 lakh orders in February 2026 across 21 cities