intelligent.pageDocs

Blitz

Blitz (formerly Grow Simplee) quick commerce carrier: no public API docs, session token from username and password, order create, cancel, tracking and NDR.

Blitz is an Indian quick commerce and same day delivery carrier for D2C brands, headquartered in Bengaluru and previously called Grow Simplee. It is not an aggregator reselling other couriers: it runs its own rider fleet and dark store network to hit 10 minute, 60 minute, same day and next day delivery windows, and sells that speed to brands as a conversion and RTO lever. There is no public developer portal. What can be established about its API comes from two aggregators that have integrated it, ClickPost and Unicommerce, both of which document the credential set and the supported operations.

At a glance

What it is

Blitz (Blitz Quick Commerce, Bengaluru, HSR Layout) positions itself as a last mile carrier for D2C brands who want quick commerce speed without building their own fleet. Its published service tiers are quick commerce (under 60 minutes, within roughly a 5 km radius), same day (1 PM pickup, 500 or more pincodes) and next day (evening pickup, 800 or more pincodes). It advertises dark store access, live rider tracking, same day reverse pickup, intercity delivery and configurable WhatsApp, SMS and email messaging, and it markets outcomes rather than rates: lower RTO, higher conversion, lower customer acquisition cost.

The company raised roughly Rs 51 crore in a Series A led by IvyCap Ventures, reported in November 2024. Customer quotes on its own site consistently refer to it as "Blitz (Previously Grow Simplee)", and Unicommerce's integration article is titled "Integration with Blitz (Formerly Growsimplee)", so the two names refer to the same carrier and older integrations are filed under Grow Simplee.

For the unified model Blitz is a source of shipments only. It is a carrier, so it holds no orders in the commerce sense, no catalogue and no stock.

API access

There is no self-serve path and no public reference.

  • No docs., developer., apidocs. or api-docs. subdomain on blitznow.in resolves. No developer link exists on the marketing site, which funnels prospects to a sales form at blitznow.in/boost-sales and to business@blitznow.in.
  • https://api.blitznow.in/ is live and answers {"message": "Missing Authentication Token"}, which is the AWS API Gateway response for an unauthenticated or unmatched route. The gateway is real, the routes are not published.
  • https://app.blitznow.in/ serves a seller web application and https://track.blitznow.in/ a buyer tracking page. Both are single page applications. Their internal endpoints are not a published contract and should not be relied on.
  • Unicommerce's integration guide states plainly that the credentials "will be provided by the Blitz team for every seller", which puts this in the same category as most Indian carriers: an onboarding conversation, not a signup.
  • No official SDK in any language, no Postman collection, no OpenAPI specification and no GitHub presence were found.
  • Blitz does not appear as a listed app on the Shopify app store under either name, so store integrations are presumably custom or routed through an aggregator.
Note

Because the carrier is already integrated into ClickPost (courier partner id 207 under the name Growsimplee) and into Unicommerce, the practical route for a brand is usually to reach Blitz through one of those rather than to build directly. If the brand is already on ClickPost, Blitz shipments arrive through the ClickPost API with no Blitz specific code at all. See ClickPost.

Authentication

Not documented first party. ClickPost's carrier setup page for Growsimplee lists the exact credential fields it collects from the seller and states what each is used for, which is the most precise public description of the auth model:

So the model is: POST credentials, receive a session token, present the token on subsequent calls, and hold a second credential pair for the NDR surface. Token lifetime, the token endpoint path, the header name and whether a refresh exists are all unpublished.

Unicommerce's connector form asks for a different but compatible set: User Name, Password, Service Type, Hand Over Mode (Drop or Pick), Pickup Address Id, Fetch Label Link (boolean) and API Url. The presence of a configurable API Url suggests either per tenant hosts or a staging and production split.

No example request, response, header name or token lifetime can be stated without inventing them, so none is given here. Confirm all of it with Blitz during onboarding.

Objects we can read

Shipments and tracking

Tracking is confirmed by both aggregators. ClickPost lists "Tracking" among the services integrated for courier partner 207 and Unicommerce states "AWB Tracking is provided in Uniware for Blitz shipped orders" and offers a Tracking Enabled switch on the shipping provider configuration.

What is exposed on the tracking read (scan history versus latest status only, location granularity, timestamps, rider location) is not published. Blitz markets live rider tracking on its buyer facing page, so rider geolocation likely exists in some form, but whether it is available over the seller API is unknown.

ClickPost's integration also notes OTP based delivery confirmation as an integrated service, which means a delivery OTP is part of the shipment record.

Proof of delivery

Not documented. ClickPost lists proof of delivery as a per carrier capability filter in its carrier directory, and proof of delivery is not among the four services ClickPost lists for this partner (order creation, order cancellation, tracking and OTP based delivery), so assume POD is not available over the API until proven otherwise.

Returns

Unicommerce's integration supports reverse shipment with a ReversePickup-Prepaid shipping method and AWB generation set to API, and Blitz markets same day reverse pickup. So reverse shipments can be created over the API. There is no evidence of a returns list or returns read endpoint.

Serviceability, rates and settlements

Not documented. Unicommerce's article notes "Limited pickup serviceability" as a feature highlight and requires the operator to define serviceability manually in Uniware (any facility to any place, this facility to selected pincodes, or any facility to selected pincodes), which implies that a serviceability lookup either does not exist over the API or was not used in that integration.

No rate card, no COD remittance and no settlement endpoint is documented anywhere.

Writing back: listings, price and stock

Not applicable, this is a carrier. Blitz holds no catalogue, price or stock. The write path is the shipment lifecycle, and both aggregators confirm the same three operations.

  • Create a shipment. ClickPost lists "Order Creation" as integrated. Unicommerce requires forward shipping methods for both COD and prepaid with "AWB Generation selected as API", which means the AWB is minted by Blitz at creation rather than drawn from a pre allocated series.
  • Cancel a shipment. ClickPost lists "Order Cancellation" as integrated, authenticated with the primary session token.
  • Create a reverse shipment. Unicommerce configures a ReversePickup-Prepaid method with API AWB generation.
  • NDR actions. ClickPost's credential table names reattempt and RTO initiation explicitly, authenticated with the separate NDR credential pair.

Labels and manifests are generated by Blitz, not by the integrator. ClickPost exposes a Label setting with values "Courier Partner Generated" and "Clickpost Generated", and Unicommerce states "Label pdf is provided by Blitz" and "Manifest is also provided by Blitz". Unicommerce's Fetch Label Link boolean implies the label comes back as a URL rather than as inline binary.

One integration detail worth carrying forward: ClickPost exposes an Order Number Format setting with values "Reference Number", "Order ID" and "Order ID + Reference Number", and warns that it must match the format the seller's team uses to look up shipments on the Blitz portal. Blitz identifies shipments by whichever string is sent at creation, so the connector must fix one convention and keep it stable, otherwise panel lookups and API records will diverge.

Webhooks and notifications

Not published. Neither aggregator's setup documentation mentions a callback URL, a webhook secret or an event catalogue for this carrier. ClickPost's own model is that it fetches carrier status "via webhooks (status push from carrier to Clickpost systems) and via periodic polling if webhooks are not available", so a push option may exist under contract, but it is not established for Blitz.

Blitz does send buyer facing notifications (configurable WhatsApp, SMS and email messaging is a marketed feature), but those go to the customer, not to the seller's server.

Until a push contract is confirmed, assume pull. For a same day and quick commerce carrier the useful polling cadence is much tighter than for a standard parcel carrier: promised windows are 10 to 60 minutes, so a 5 minute poll on the open shipment set is proportionate, dropping to 30 minutes for next day shipments. Whether the API tolerates that cadence is unknown, which is the first question to ask.

Rate limits and pagination

Not published. No rate limit, quota header, burst allowance, page size, cursor or date window is documented anywhere, first party or third party.

Two practical implications. First, size the tracking poll conservatively and ask for a limit in writing before going live, especially given the tight delivery windows that push toward frequent polling. Second, there is no evidence of any bulk or list read at all, so every read is likely per AWB, which makes request count scale linearly with open shipments.

Mapping to the unified model

Field names are not published, so this table maps concepts rather than exact fields. Every row needs confirming against a real response before it is implemented.

Gaps and open questions

  • No first party documentation of any kind could be read: no endpoint paths, no request or response bodies, no field names, no status code vocabulary. Everything above is the intersection of two aggregators' setup guides.
  • The token endpoint, token lifetime, header name and refresh behaviour are unknown.
  • Why NDR needs a separate credential pair is unexplained. It may indicate a separate service or a separate permission model, which affects how credentials are stored and rotated.
  • Whether a serviceability or pincode lookup exists is unclear. Unicommerce's integration requires serviceability to be defined manually, which suggests it does not, or was not used.
  • No proof of delivery, no rate quote, no COD remittance and no settlement surface is evidenced.
  • No webhook contract is evidenced, which matters more than usual given 10 to 60 minute promised windows.
  • The API Url field in Unicommerce's connector implies configurable hosts. Whether that is per tenant, per environment or legacy is unknown.
  • Older integrations are filed under "Growsimplee" while the brand is now Blitz. Carrier name normalisation must treat both as one carrier, and ClickPost's courier partner id 207 still carries the old name.
  • Rider live location is marketed to buyers. Whether it is readable by the seller over an API is unknown.

Sources