Daakit

DAAKit quick commerce fulfilment and shipping API: user name and password give a bearer JWT, with rates, pincodes, AWB, label, manifest, cancel and tracking.

DAAKit is an Indian quick commerce fulfilment and last mile company. It runs dark stores and smart warehouses for D2C brands and delivers in 30 minute, 60 minute, 2 to 4 hour and same or next day windows, with a shipping aggregation layer behind it that books AWBs on Delhivery, Blue Dart, DTDC, Ecom Express, Ekart, Amazon, Shadowfax and others. There is no public developer portal, but a working API collection published on Postman exposes the full shipping surface: token exchange, courier list, rate card, pincode serviceability, warehouse creation, shipment creation with AWB and label, manifest, cancel and tracking.

At a glance

What it is

DAAKit Technologies positions itself as a quick commerce enabler rather than a courier: brands store stock in DAAKit dark stores, DAAKit picks, packs and quality checks to defined procedures, then delivers hyperlocally. Its published scale is 2,900 or more pincodes, 10 or more states, 15 or more cities, 25 or more dark stores and 35 or more brands, with delivery windows of 60 minutes, 4 hours and same or next day.

The product is sold as four pieces: DAAKit Go (the hyperlocal fulfilment engine), Plan IQ (demand prediction and inventory planning), an ETA widget for the brand's website, and an AI assistant for tracking and support queries. Onboarding is described as connecting Shopify or WooCommerce "using secure APIs", so the normal path for a brand is a store integration, with the direct API as the alternative.

For the unified model DAAKit is a source of shipments and locations. Because it also holds stock in dark stores, an inventory surface presumably exists inside Plan IQ, but none is exposed in the published API collection.

API access

No documentation host, no developer page and no self-serve signup. The site funnels to a demo booking and to the seller panel at https://app.daakit.com/.
Base URL: https://api.daakit.com/. The host is live and answers an unauthenticated request with {"message": "Missing Authentication Token"}, the AWS API Gateway response, so the API sits behind API Gateway.
The only public reference is a Postman collection named "Daakit API", published by the handle pie-backend, carrying a prod_url collection variable of https://api.daakit.com/. It contains ten requests with real captured responses. It is not hosted by DAAKit, so treat it as strong evidence rather than as a contract: field names and response shapes here were captured from a live account, but DAAKit has not committed to them publicly.
No official SDK in any language, no OpenAPI specification and no DAAKit owned repositories were found on GitHub.
One artifact in the samples is worth noting: label and manifest URLs in older responses point at daakit.societykart.com while newer ones point at app.daakit.com. The platform appears to have been rehosted, so do not hard code the asset host.

Authentication

Bearer JWT, obtained by a login call. One credential pair per seller account.

POST user_name and password to the token endpoint.
Read the token from data, which is a bare string rather than an object.
Send it as Authorization: Bearer on every other call.
Re-login on expiry. There is no refresh token in the collection.

POST /api/token HTTP/1.1
Host: api.daakit.com
Content-Type: application/json

{
  "user_name": "seller@example.com",
  "password": "your_password"
}

{ "status": true, "data": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." }

curl -X POST "https://api.daakit.com/api/courier" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"filterType":"courier"}'

Token lifetime is not published and the sample token was redacted in the collection, so it could not be decoded. Read exp from the token in practice, or refresh on the first 401.

Every response uses the same envelope: a boolean status, then data on success or message on failure. Note that message is also used to carry a successful result in at least one place (the manifest endpoint returns the PDF URL in message), so do not treat message as an error signal.

Objects we can read

Couriers

POST /api/courier with {"filterType": "courier"}.

{
  "status": true,
  "data": [
    { "id": "1", "name": "Blue Dart" },
    { "id": "10", "name": "Delhivery Air 500 gms" },
    { "id": "13", "name": "Delhivery Surface 10 Kg" },
    { "id": "18", "name": "Shadowfax" }
  ]
}

Weight slabs are separate courier ids, not a parameter, exactly as on NimbusPost. Carriers visible in the sample include Amazon, Blue Dart, Blue Dart Express, Delhivery (air and four surface slabs), DTDC air and surface, Ecom Express, Ecom Express ROS, Ekart and Shadowfax. A tracking sample also shows Pickndel (SDD) with a separate courierDisplayName, so hyperlocal partners appear alongside national carriers.

Rates

POST /api/courierrate with filterType, origin, destination, paymentType (cod or prepaid), orderAmount, length, breadth, height and weight.

{
  "status": true,
  "data": [
    {
      "id": "10",
      "name": "Delhivery Air 500 gms",
      "freightCharges": 68.08,
      "codCharges": 40,
      "totalCharges": 108.08,
      "minWeight": 500,
      "chargeableWeight": 1000
    }
  ]
}

Weights are grams. A slab the account is not rate carded for comes back with zeros rather than being omitted (the sample shows Delhivery Surface 2 Kg at freightCharges: 0), so filter zero rated rows before presenting options.

Pincode serviceability

POST /api/courierpincodeserviceability with {"filterType": "pincode"} returns the entire table with a COD and a prepaid flag per courier and pincode, and a count (21,263 rows in the sample).

{
  "status": true,
  "count": 21263,
  "data": [
    { "courierId": "10", "pincode": "110001", "cod": "Y", "prepaid": "Y" }
  ]
}

This is a full dump with no filter parameter, so cache it on a schedule and never call it in a request path.

Shipments and tracking

GET /api/trackshipment/{awb}

{
  "status": true,
  "data": {
    "id": "8",
    "orderId": null,
    "orderNumber": "2024101302360887880",
    "created": "2024-10-13",
    "edd": "",
    "pickupDate": "",
    "rtoInitiateDate": "",
    "deliveredDate": "",
    "shippedDate": "",
    "awbNumber": "FSPP0004247124",
    "rtoAwb": "",
    "courierId": "1",
    "warehouseId": "14",
    "rtoWarehouseId": "14",
    "status": "booked",
    "rtoStatus": "",
    "shipmentInfo": "",
    "history": []
  }
}

One AWB per call, and the lifecycle dates are dedicated fields (pickupDate, shippedDate, deliveredDate, rtoInitiateDate, edd) rather than having to be derived from scans. history is present but empty in the sample, so its element shape is unverified. The RTO leg carries its own rtoAwb and rtoStatus.

Shipment detail

The label endpoint doubles as a detail read: it returns a full record per AWB including orderNo, orderDate (epoch seconds as a string), paymentMode, orderAmount, awbStatus, shipmentWeight, dimensions, courierName and courierDisplayName, sellerName, a consigneeDetails object (name, two address lines, city, state, pincode, phone, all PII) and a productDetails[] array with productName, productQty, productSku and productPrice.

Locations

Warehouses are created over the API (see below) and referenced by numeric pickupWarehouseId and rtoWarehouseId on every shipment. No warehouse list read appears in the collection.

Not available

No order list, no products or listings, no inventory (despite DAAKit holding stock in dark stores), no customers endpoint, no settlements, no COD remittance, no proof of delivery and no NDR endpoint.

Writing back: listings, price and stock

Not applicable, this is a fulfilment and carrier aggregator. DAAKit holds physical stock but exposes no catalogue, price or stock API. The write path is the shipment lifecycle.

Create a warehouse

POST /api/createwarehouse takes a pickup object (pickupWarehouseName, pickupName, pickupAddress, pickupAddress2, pickupPincode, pickupPhone, pickGstNumber), an isRtoDifferent flag, and an rto object with the same fields prefixed rto.

{ "status": true, "pickupWarehouseId": 9, "rtoWarehouseId": 10 }

Both ids come back even when the RTO address is the same, and both are required on shipment creation. Note the GST field on the pickup block is spelled pickGstNumber, not pickupGstNumber.

Create a shipment

POST /api/createordershipment

Core fields: orderNumber, paymentType, orderAmount, shippingCharges, codCharges, discount, packageWeight (grams), packageLength, packageBreadth, packageHeight (cm), courierId, pickupWarehouseId, rtoWarehouseId, a consignee object and an orderItems[] array (orderItemName, orderItemQty, orderItemPrice, orderItemSku).

Flags: isRequestAutoPickup (yes raises the courier pickup in the same call, which is why there is no separate pickup endpoint), isShipmentCreated, isDangerous, tagIfAny.

A quality check block is also accepted: qcCheck, brandName, productSize, productColor, orderCategoryId, productDamage, productUsage, productColourType, productSizeType, returnReason and four uploadedImage slots. Those fields are reverse pickup with quality check semantics, so the same endpoint appears to serve returns, but the collection has no separate return example and returnReason is not documented as switching the direction of the shipment. Confirm before relying on it.

{
  "status": true,
  "data": {
    "orderId": 12,
    "shipmentId": 13,
    "awbNumber": "77706864421",
    "courierId": "1",
    "courierName": "Delhivery",
    "status": "booked",
    "extraInfo": "",
    "paymentType": "cod",
    "label": "https://app.daakit.com/assets/labels/20241027180523-18612.pdf",
    "manifest": "https://app.daakit.com/assets/manifest/20241027180525-13.pdf"
  }
}

The AWB, the label PDF and the manifest PDF all come back in one call.

Label, manifest, cancel

POST /api/createLabel with {"awbNumbers": ["PTT142566"]} returns the shipment detail records described above.
POST /api/createmanifest with {"awbNumbers": [...]} returns the manifest PDF URL in message.
POST /api/cancelshipment with {"awbNumber": "FSPP0004246117"} returns {"status": true, "message": "Shipment Cancelled"}. Note this endpoint takes a single awbNumber, while label and manifest take an awbNumbers array. The path is also inconsistent in the collection, appearing as /api/cancelshipment with a leading slash against a base URL that already ends in one.

Webhooks and notifications

Not published. The collection contains no callback registration, no event catalogue and no signature scheme. DAAKit markets an AI assistant that automates shipment tracking and delivery updates for the brand's customers, but that is a buyer facing channel, not a server side push.

Poll instead. Because trackshipment takes one AWB per call, request count scales linearly with open shipments, and the delivery windows are short (30 to 60 minutes for hyperlocal). A 5 to 10 minute cadence on hyperlocal shipments and 30 minutes on same or next day shipments is proportionate, but with no published rate limit this needs agreeing with DAAKit before going live. Refresh the pincode serviceability dump weekly, not per order.

Rate limits and pagination

Not published. No rate limit figure, quota header, burst allowance or 429 semantics appears in the collection or on the site.

Pagination is effectively absent. There is no order or shipment list endpoint at all, tracking is one AWB per call, and the serviceability read returns all 21,000 or so rows in a single response with a count and no page parameter. The label endpoint accepts an array of AWBs, which is the only batching mechanism available, and its maximum batch size is not stated.

The practical consequence: the connector must be the system of record for every AWB it creates, because there is no way to enumerate shipments from DAAKit.

Mapping to the unified model

Gaps and open questions

No first party documentation exists. The entire surface is known only from a Postman collection published by a third party handle, so nothing here is a committed contract.
Token lifetime is unknown (the sample token was redacted) and there is no refresh token.
No webhooks, and tracking is one AWB per call, which is the binding constraint for a hyperlocal carrier with 30 minute windows.
history[] is empty in the published tracking sample, so the scan event shape is unverified. That is the single most important unknown for building shipments.events[].
Weight units appear to differ between write (packageWeight: 300, grams) and read (shipmentWeight: "0.5", likely kilograms). This must be confirmed before any conversion.
The quality check and return fields on createordershipment suggest reverse pickup with QC is supported through the same endpoint, but there is no return example and no documented flag that reverses the shipment direction.
No order or shipment list endpoint, so there is no way to reconcile against DAAKit or to backfill history.
No inventory API despite DAAKit holding stock in dark stores. Whether Plan IQ exposes one is unknown and matters, since stock position is the whole point of dark store fulfilment.
No NDR, no proof of delivery, no COD remittance and no settlement surface.
Asset hosts have changed (daakit.societykart.com to app.daakit.com), so label and manifest URLs should be treated as opaque and fetched promptly rather than stored and re-resolved later.
No rate limits, no changelog, no versioning. The paths are unversioned (/api/...), so a breaking change has nowhere to land except the existing path.

Sources

DAAKit product site
DAAKit Go, hyperlocal fulfilment product
DAAKit frequently asked questions
Daakit API, published Postman collection
https://api.daakit.com/ (live API host behind AWS API Gateway, returns "Missing Authentication Token" unauthenticated)
DAAKit seller panel