Docpharma

DocPharma is an Indian healthcare quick-commerce supply chain: dark stores, pharmacist validation, an in-house rider fleet and a technology layer called DocPharma One that takes orders from a brand's channels and fulfils prescription-compliant medicine and wellness orders, targeting delivery in under 30 minutes. It is not an ERP and it is not a point of sale. It is a fulfilment and last-mile provider that a healthcare or wellness brand plugs into, in the same category as a specialist third party logistics provider.

That matters for this catalogue, and the entry should be re-categorised: DocPharma is a source of orders, inventory and shipments, not of listings or accounting documents. It does not hold a brand's books.

It is also, unusually for this part of the catalogue, well documented. DocPharma publishes a Swagger UI for its Partner API at partner-api.docpharma.in/api-docs, serving a complete OpenAPI 3.0 specification with 61 operations, named schemas and field-level examples. Everything technical on this page comes from that specification, read on 2026-09-22 at version 1.0.36.

At a glance

What it is

DocPharma describes itself as "India's first healthcare quick commerce supply chain", positioned as infrastructure for other businesses: "Your business. Our infrastructure. Build, launch and scale your healthcare delivery network with DocPharma." The published operating flow is order received, guided and barcode-verified picking, a second manual validation where a pharmacist checks the invoice against the prescription and signs off, nearest rider assignment by distance, and OTP-confirmed handover.

Scale figures published on the site and read on 2026-09-22: over 30 dark stores live, over 12 cities covered, over 10 lakh orders delivered, over 6 lakh lives impacted, a fulfilment rate above 95 percent, delivery adherence above 93 percent and an in-house fleet of more than 500. The company raised 2 million dollars in September 2026 to expand to 50 cities, reported by The Economic Times Retail.

Named customers and brands on the site include Tata 1mg, MediBuddy, HealthKart, Wellversed, Visit Health, ekincare, PlatinumRx, ICICI Lombard, Niva Bupa, Kimirica, Circle Health and others, described as "30+ healthcare brands and marketplaces".

Named platform and carrier partners on the site: Unicommerce, Vinculum, Shopify, EasyEcom, Shadowfax, Delhivery, Blue Dart, ClickPost, Shipsy, Ekart, Xpressbees, Amazon Shipping, Pidge, Shiprocket and ElasticRun. The API specification confirms deep, first-class integrations with Shopify, EasyEcom, Unicommerce, ClickPost and MyOperator rather than generic connectors.

DocPharma One, the technology layer, covers inwarding and putaway with real-time inventory visibility, order orchestration across channels with allocation to a fulfilment location, guided picking with SKU scanning, last-mile orchestration choosing rider and delivery partner per service level, and end-to-end tracking. The certificate transparency record for the domain shows services matching that description: erp-api, logistics-api, picker-putter-api, rider-tracking, one.api, track and partner-api.

API access

There is no self-serve signup. The specification states that "Most endpoints require an API Key issued to the partner", and lists tech@docpharma.in as the contact.

Practical steps:

1. Commercial agreement with DocPharma as a brand or marketplace partner.
2. DocPharma issues a partner API key and a partner name. The partner name appears in paths such as GET /{partner_name}/inventory-availability/sku/{sku_id}/zipcode/{zipcode}, with Kimirca used as the documented example, so a partner is a first-class identity in the routing.
3. Integration is built against the development server https://partner-api.dev.docpharma.in, then pointed at the production host once confirmed.

The API version at the time of reading is 1.0.36, exposed both in the specification's info.version and by the root health endpoint. There is no versioned base path; individual operations carry /v1, /v2 and /v3 prefixes inconsistently, and in two cases both a v1 and a v2 of the same idea exist side by side, for example /inventory-availability and /inventory-availability/v2. Prefer the highest version documented for each operation.

If a brand does not want a direct integration, the shorter path may be through an order management system DocPharma already speaks: Shopify, EasyEcom or Unicommerce each have dedicated ingestion endpoints in the specification.

No official SDK is published in any language and no Postman collection could be found.

Authentication

A static API key, issued per partner. There is no OAuth flow, no token exchange and no expiry documented.

Two documented placements, from the specification's security schemes:

• ApiKeyAuth: header x-api-key.
• ApiKeyQueryAuth: query parameter api_key.

Prefer the header. A key in a query string ends up in access logs, browser history and referrer headers.

An authenticated call:

POST /v2/place-order HTTP/1.1
Host: partner-api.dev.docpharma.in
x-api-key: YOUR_PARTNER_API_KEY
Content-Type: application/json

{
  "partner_order_id": "988772772722",
  "partner_order_no": "ORD-2026-001",
  "customer_name": "Ramesh Kumar",
  "patient_name": "Sita Ramesh",
  "mobile_no": "9876543210",
  "email_id": "ramesh.kumar@example.in",
  "state": "Haryana",
  "city": "Gurgaon",
  "zipcode": "122001",
  "lat": 28.4635,
  "long": 77.0292,
  "address_1": "Flat 402, Sector 45",
  "payment_mode_order": "Prepaid",
  "order_type": "HL"
}

There is no token to refresh. Multi-account handling is by key: one key per partner identity. If a group runs several brands, ask DocPharma whether that is one key with a partner name per order or several keys, because the partner name also appears as a path parameter on at least one endpoint.

The specification documents a 401 response shape (UnauthorizedErrorResponse), so an invalid key is signalled explicitly rather than by a generic error.

Objects we can read

Orders

POST /fetch-details returns the full order by partner order number. The request is a single field, partner_order_no.

Response fields, with the specification's own example values:

{
  "partner_order_no": "ORD-2026-001",
  "partner_order_id": "988772772722",
  "patient_name": "Ramesh Kumar",
  "status": "shipped",
  "mobile_no": "9876543210",
  "email_id": "ramesh.kumar@example.in",
  "state": "Haryana",
  "city": "Gurgaon",
  "zipcode": "122001",
  "address_1": "Flat 402, Sector 45",
  "address_2": "Near HUDA City Center",
  "prepaid_amount": 299,
  "collectible": 0,
  "total_amount": 299,
  "shipping_charges": 40,
  "discount": 30.1,
  "payment_mode_order": "PREPAID",
  "prescription_link": ["https://s3.ap-south-1.amazonaws.com/docpharma-prescriptions/rx_1001.jpg"],
  "webhook_url": "https://api.partner.com/docpharma-webhook",
  "created_at": "2026-09-04T06:30:00.000Z",
  "is_delayed": false,
  "items": [],
  "suborders": [],
  "erp_order_id": "ERP99182",
  "vendorId": 631112
}

Everything in that response except the identifiers and the money is PII, and prescription_link is health data. Prescriptions are personal medical records and must be treated accordingly: do not copy them into a general analytics store, and if any prescription URL is retained, retain the reference, not the image.

Two structural details matter. suborders means an order can be split across fulfilment nodes. erp_order_id is documented as "Primary ERP order ID if order split is disabled for the partner", so whether a partner's orders split is a per-partner configuration that changes the shape of what comes back. Establish that setting before modelling.

is_delayed is a first-class flag, which is a good signal to carry into the unified model even though there is no unified field for it.

Order items

Line items are described by the OrderItemDetail schema on the write side: partner_sku_code, sku_name, fh_sku_type (documented examples Medicine, Healthcare, FMCG), sku_qty, mrp, discount_amount, variant_id, line_item_ids and fulfillment_line_item_ids for Shopify, partner_wms_batch_no, combo_child_batches for bundles, and easy_ecom_ref_id. The read side returns items as an array; its element schema is not expanded in the specification.

Products and listings

None. DocPharma does not hold a brand's listings. It holds the partner's SKU codes only so it can map them to stock in its own stores. Product images can be fetched by catalogue id with GET /images/{id}.jpg, and arbitrary assets through GET /s3-image/{path}, which returns a presigned URL.

Inventory

Three shapes, all read-only to the partner, because the stock is DocPharma's.

• POST /inventory-availability/v2 checks several items at once against a destination. The request takes zipcode (required), items (required), service_type (one of HL, SDD_NDD, COURIER, BATCH), plus latitude, longitude and address. It is documented as supporting "automatic bundle/combo product explosion, allocated stock deduction, dynamic ETA calculations, and geocoding fallback". The v1 endpoint at /inventory-availability still exists; use v2.
• GET /{partner_name}/inventory-availability/sku/{sku_id}/zipcode/{zipcode} checks one SKU, intended for Shopify and marketplace product pages.
• GET /store-level-inventory/v2 returns a paginated snapshot for one store: store_code is required, with page defaulting to 1 and page_size defaulting to 50. This is the endpoint for a periodic full sync. The v1 form exists without combo resolution.

The response schemas for all three are declared as { status, data } with data typed only as an object, so the inner field names are not in the specification. This is the one significant gap in an otherwise well specified surface. Get a real response from DocPharma before writing the parser.

Note that availability is a function of destination, not just of stock. The same SKU can be available for a hyperlocal order in one pincode and unavailable in another, which means inventory cannot be cached globally.

Shipments and tracking

• POST /logistics/v1/create creates a shipment for an invoiced partner order, taking partner_order_number and an optional x_clickpost_ref_order_id. ClickPost is the carrier aggregator behind it.
• GET /logistics/v1/order-status takes logistic_order_id, described as the fh_order_id, and returns "latest status, delivery date/ETA, tracking link, and full status history timeline".
• GET /logistics/v1/serviceability checks whether a destination pincode can be served.
• GET /awb/{id}.pdf downloads the shipping label.
• POST /v2/update-logistic-status and POST /v1/manual-update-logistic-status write status back.

Returns and cancellations

A rich set, which reflects how much of pharma fulfilment is exception handling:

• POST /v2/place-order-rvp creates a reverse pickup order.
• POST /v2/cancel-order cancels before shipment and "releases allocated stock".
• POST /v2/cancel-till-ofd and POST /v3/cancel-till-ofd cancel up to out-for-delivery, v3 with "automatic inventory handling". POST /v1/cancel-till-ofd is the admin form keyed on fh_order_id.
• POST /v2/reject-order rejects an order.
• POST /v1/mark-lost-damaged and POST /v1/mark-rto-nsa handle loss in transit and return to origin from a non-serviceable area.
• POST /v2/easy-ecom-mark-return carries quality check results, and POST /v2/unicommerce-mark-return marks a return or RTO complete.

Payments and settlements

No settlement object. Payment is carried on the order: payment_mode_order is one of Prepaid, COD or Partial Paid, with collectible as the cash to collect at the door, prepaid_amount on the read side, and a PaymentDetail structure with payment_status (documented as 1 for COD, 10 for prepaid or partial paid), transaction_id and amount. Invoices are available as PDF at GET /invoices/{id}.pdf.

Customers

No customer object. Customer identity travels on the order: customer_name, patient_name, mobile_no, email_id and the address fields. Note that customer and patient are separate people in this model, which is correct for pharmacy and is worth preserving rather than collapsing.

Locations

No list endpoint. Locations appear as store_code on the store-level inventory read, partner_store and vendor_code on order creation for pre-allocated routing, and implicitly through pharmacy reassignment.

Delivery estimation

• POST /eta takes zipcode and service_type (here the enum also includes NON_HL) and returns eta_hours and eta_time alongside current_time, in a DD-MMM-YYYY HH:MM:SS format.
• GET /eta/{partner_name}/zipcode/{zipcode} returns the partner-specific mapping.

Writing back: listings, price and stock

For DocPharma, read this as pushing orders and adjustments in. There are no listings to write, and stock belongs to DocPharma, so the writable surface is the order lifecycle.

Order creation, POST /v2/place-order, is the main write. Required fields are partner_order_id, partner_order_no, customer_name, patient_name, mobile_no, email_id, state, city, zipcode, lat, long, address_1, payment_mode_order and payment_mode_item. Latitude and longitude are required, not optional, because pharmacy assignment for hyperlocal delivery depends on them. A partner that cannot geocode reliably will not be able to place hyperlocal orders.

order_type selects the service level and is documented with its physical meaning:

• HL, hyperlocal, within a 6 km radius, typically about two hours.
• SDD_NDD, same or next day, within 100 km.
• COURIER, pan-India standard shipping.
• BATCH, scheduled batch fulfilment.

The response is { status, status_code, order_number, data }, with order_number being DocPharma's identifier. A 400 is documented as "Validation failed or duplicate order", which implies duplicate detection on partner_order_id or partner_order_no. That is the nearest thing to idempotency on offer, and it should be confirmed: which field is the duplicate key, and does a duplicate return the original order number or only an error.

Other writes:

• POST /update-order-detail updates bill amount, items and prescriptions on an existing order.
• POST /v1/update-address-details changes the destination address.
• POST /update-new-pharmacy reassigns fulfilment to a different pharmacy, with POST /reassign-picker-order and POST /cancel-picker-order handling the picking task.
• POST /v1/manual-update-product-mrp overrides a product MRP. This is the only price write, it is under the "Manual Orders & Utility" tag, and it should be treated as an operational override rather than a catalogue sync.

Channel ingestion endpoints exist so that a brand's existing platform can feed DocPharma without a custom build: POST /v2/shopify-place-order and POST /v2/shopify-cancel-order for Shopify webhooks, POST /v2/easy-ecom-place-order and POST /v2/easy-ecom-cancel-order for EasyEcom, and GET /unicommerce/orders/fetch-new-orders for Unicommerce, where DocPharma pulls rather than being pushed.

The Unicommerce set is a complete lifecycle, which is worth knowing if a brand already runs Unicommerce: check status, invoice, reject or switch facility, assign logistics and AWB, dispatch, push tracking milestones, confirm delivery, initiate RTO, mark RTO delivered, switch location back, plus purchase inward (POST /unicommerce/purchase/inward, described as purchase order to goods receipt note to putaway), a retry for failed inward records, and a purchase return gatepass adjustment.

Shopify has its own OAuth handshake: GET /shopify-auth/install and GET /shopify-auth/auth/callback. DocPharma is therefore a Shopify app, not just a webhook consumer.

Webhooks and notifications

Webhooks exist in both directions, which is rare in this part of the catalogue.

Outbound, DocPharma to you. CreateOrder carries a webhook_url field, documented as the "Callback webhook URL where DocPharma will post status and invoice updates". It is set per order, not per account, which is unusual and means a partner can route different orders to different endpoints. The event set and the request body for these callbacks are not in the specification. Ask for them.

Inbound, you or the ERP to DocPharma. POST /transactional-webhook and POST /v2/transactional-webhook accept order events, the v2 form documented as forwarding to the ERP, named eVital, and processing "Order Saved, Edited, Accepted, Rejected, Shipped, and Delivered". The documented request body:

{
  "order_status": "shipped",
  "order_number": "OMLKTMIP8H",
  "id": "4AS+0qPrLz32Zy68CCBgHA==",
  "transaction_type": "sales",
  "transaction_nature": "shipped",
  "total": 16,
  "amount": 16,
  "payment_mode": "Credit",
  "bill_no": 220,
  "bill_date": "2026-08-31 16:14:14",
  "delivery_type": "pickup",
  "chemist_id": "YT3/3PEAnmEolCPrStruew==",
  "patient_name": "Mohit Chauhan",
  "mobile": "9999911111",
  "reject_reason": "",
  "bill_pdf_url": "https://example.com/invoice/print/OMLKTMIP8H.pdf",
  "items": []
}

Required fields are order_status, order_number and id. The id and chemist_id values are base64-looking opaque tokens, so they are encrypted or encoded identifiers, not integers.

No signature header, HMAC secret or verification scheme is documented for either direction. That is a gap worth raising: an unauthenticated inbound webhook that mutates order state is a problem, and an outbound callback with no signature cannot be trusted by the receiver. Ask DocPharma how both are authenticated before going live.

A telephony webhook also exists, POST /myoperator/webhook, carrying inbound call outcomes from MyOperator, alongside POST /myoperator/call/initiate for masked rider-to-customer calls.

Rate limits and pagination

No rate limit is published: no number, no quota header, no burst policy appears anywhere in the specification.

Pagination exists only on the store-level inventory endpoints, as page and page_size query parameters, defaulting to page 1 and 50 rows. There is no cursor and no total count documented. Every other read is keyed on a single identifier.

Practical cadence, to be confirmed with DocPharma:

• Availability checks are request-time, called when a customer enters a pincode, not on a schedule.
• Store-level inventory as a periodic reconciliation, hourly at most, paging through each store.
• Order state from the outbound webhook, with POST /fetch-details used only to reconcile orders whose callbacks were missed, not as a polling loop.

Mapping to the unified model

Gaps and open questions

• The inner shape of every data object is missing. Inventory availability, store-level inventory and logistics status all declare data as an untyped object, so the field names for stock quantity, carrier, AWB and tracking events are unknown. This is the single blocking gap for implementation.
• The full status enumeration for orders is not published, only the example shipped.
• The outbound webhook is described only by a field name on the order. Its events, request body, retry policy and any signature are undocumented.
• Neither webhook direction documents a verification mechanism. An unauthenticated inbound webhook that changes order state deserves a direct question to the vendor.
• No rate limit, no quota header and no concurrency guidance.
• The production base URL is not in the specification, which lists only a development server and localhost. Confirm it.
• Duplicate handling on order creation is implied by a 400 description but the duplicate key and the response for a repeat are not specified.
• Commercial terms, onboarding time, minimum volumes and geographic coverage per service level are not published. Coverage matters a lot here, since HL is a 6 km radius from a dark store and there are about 30 stores in about 12 cities.
• Whether /inventory-availability v1 and /store-level-inventory v1 are deprecated is not stated.
• The payment_status codes 1 and 10 are documented but the full code list is not.
• The ERP behind DocPharma is named as eVital in the webhook description. Whether that ever becomes directly accessible to a partner is unknown, and probably not.
• Catalogue correction: this entry sits under ERP, accounting and POS systems. It is neither. It should move to fulfilment and logistics providers, alongside the third party logistics entries.
• Name collisions to avoid: docpharma.com is DOC Generici, an Italian generic medicines manufacturer, and DocPharma NV was a Belgian generics company acquired by Matrix Laboratories. Neither is this company.

Sources

• DocPharma Partner API Swagger UI, read 2026-09-22. OpenAPI 3.0, "DocPharma Wrapper API" version 1.0.36, 61 operations, ten tags, two API key security schemes. Source of every endpoint, schema and field on this page
• DocPharma website, read 2026-09-22. Positioning, operating flow, scale figures, customer and partner lists, DocPharma One description
• The Economic Times Retail: DocPharma raises 2 million dollars to expand healthcare quick-commerce network to 50 cities, dated 1 September 2026, cited on the DocPharma site
• Certificate transparency record for docpharma.in, queried 2026-09-22, showing the service split: partner-api, erp-api, logistics-api, picker-putter-api, rider-tracking, one.api, track, admin-panel-backend, communication-service, across dev, staging and production
• Postman public search for docpharma, run 2026-09-22: no collection
• GitHub repository and code search for docpharma, run 2026-09-22: no vendor owned repository or SDK. Four unrelated repositories share the name