intelligent.pageDocs

PharmEasy

PharmEasy has a seller API reachable only through approved OMS partners, username and password credentials issued per pin-code account, orders and catalogue readable, no public docs.

PharmEasy is India's largest online pharmacy and health commerce platform, operated by API Holdings, selling prescription and over-the-counter medicine, supplements, personal care, medical devices and diagnostics. For a brand or a pharmacy, PharmEasy is a hybrid: part of the catalogue is bought and held by PharmEasy's own distribution arm on a purchase-order basis, and part is fulfilled by third-party sellers who are onboarded onto a seller account and integrated over what PharmEasy's partners call the "PharmEasy API". There is no public developer portal, and credentials are issued by PharmEasy staff rather than self-service.

At a glance

What it is

PharmEasy runs a consumer app and website for medicine delivery, an OTC and wellness catalogue, lab tests through Thyrocare, and teleconsultations. Its own homepage claims over 50 lakh customers. The company also runs a franchise pharmacy network, advertised at pharmeasy.in/franchisestores as "250+ stores across 30+ cities", which is a retail programme and not a seller or vendor programme.

The commercially important structure for a connector is the pin code model. PharmEasy assigns serviceability by pin code, and a seller who covers several regions is given several PharmEasy accounts, one per set of pin codes. Each of those accounts has its own credentials. This is the single most consequential design fact on this page: a PharmEasy connector is inherently multi-account even for one legal entity, and the account, not the brand, is the unit of credentials and of order scope.

PharmEasy's consumer site carries no sellers, suppliers, distributors, B2B or API links in its footer. Everything on the supply side is arranged off-site with a PharmEasy account manager.

API access

An API exists. EasyEcom, an Indian order management system, exposes PharmEasy as a first-class channel named "Pharmeasy-API" in its Add Channels list, and its article opens with "Please follow the below-mentioned process to integrate PharmEasy API with EasyEcom." That is direct evidence of a working seller-facing API rather than a panel scrape.

How a seller gets in:

  1. Be onboarded as a PharmEasy seller through a category or account manager. There is no public sign-up funnel for this.
  2. Ask the PharmEasy team for the marketplace credentials for each account. The EasyEcom article is explicit: "Please ask PharmEasy Team for each account's marketplace credentials and integrate them in specific EasyEcom locations."
  3. Add the channel in the OMS, once per PharmEasy account, mapped to the matching warehouse or location.

No API version numbers, deprecation schedule, official SDK, Postman collection or public GitHub repository for PharmEasy were found. Notably, Unicommerce's integrations directory does not list PharmEasy, so the approved partner set appears narrower than for the large marketplaces.

Note

Because credentials are a plain username and password issued by a human, plan the credential store for rotation by ticket, not by refresh token. There is no documented expiry, which in practice means the credentials live until someone at PharmEasy changes them, and the failure mode is a silent authentication error on the next poll.

Authentication

Not published in any first-party form. What is documented is the shape of what the integrator supplies:

  1. In the OMS, open the channel list and select "Pharmeasy-API".
  2. Enter the username for that PharmEasy account.
  3. Enter the password for that PharmEasy account.
  4. Optionally enable "Create Products Automatically", which causes the OMS to create a master SKU for every SKU listed on that PharmEasy account.
  5. Save the channel. Repeat per PharmEasy account, binding each to the correct warehouse or location so that pin code serviceability lines up with real stock.

The transport (HTTP basic auth, a form login that returns a session token, or a login call that returns a bearer token) is not stated by any source we could read. Do not assume basic auth. Token lifetime, scopes and roles are likewise unpublished. No real token request or authenticated call can be shown here without inventing one.

Objects we can read

Orders

Orders are imported into the OMS from the PharmEasy account. Import is scoped to the account, and therefore to that account's pin codes. The endpoint, filters, date window behaviour and pagination model are not published. Sample response not published.

Order items

Order lines are matched against the seller's PharmEasy listings. If "Create Products Automatically" is off, the seller must upload a product master and map it to their PharmEasy listings by hand before order import will resolve the lines. Field names are not published.

Products and listings

This is the one object we can say something concrete about. The seller's PharmEasy listing set is readable in bulk: enabling "Create Products Automatically" causes the OMS to create a master SKU for all SKUs listed on PharmEasy, and EasyEcom describes this as "the easiest way to mirror the catalogue from PharmEasy to EasyEcom." So there is at least a list-my-listings read that returns enough identity to create a SKU record.

What that read returns beyond an identifier and a title is not published. Whether it carries price, MRP, stock or listing status is unknown. Sample response not published.

Inventory

Not documented. Whether PharmEasy exposes a per-listing stock read, and whether stock is per pin-code account or per seller, could not be established.

Shipments and tracking

Not documented. PharmEasy handles last-mile delivery to the patient itself in most of its network, so the seller-visible shipment object may be thin or absent.

Returns and cancellations

Not documented. Medicine returns are regulated and heavily restricted, so expect the volume to be low and the process to be manual.

Payments and settlements

Not documented. Assume seller-panel statements and a manual export until proven otherwise.

Customers

Not documented, and sensitive. Any order that carries a patient name, address, phone number or a prescription image is health-related PII under India's DPDP Act. Treat everything customer-shaped from PharmEasy as restricted, do not copy prescription images into the analytics store, and mask the address to pin code unless there is a specific operational need.

Locations

Locations are implicit. Each PharmEasy account maps to one of your warehouses, and that mapping is configured in the OMS rather than read from PharmEasy.

Writing back: listings, price and stock

No write path is documented. None of the sources describe creating a listing, updating a price or MRP, or pushing stock to PharmEasy over the API. The manual route is the PharmEasy seller panel, where listings and availability are maintained by hand or by bulk upload template.

Given that PharmEasy also buys directly through its distribution arm for part of the catalogue, a brand selling in that mode has no listing write path at all: PharmEasy raises a purchase order, owns the listing and sets the shopper price, exactly as Blinkit does. Establish which of the two models a given account is on before promising any write capability.

Webhooks and notifications

None documented. Plan for polling. Given that pharmacy orders are time-sensitive but not quick-commerce fast, a five to fifteen minute poll per account for new orders is a reasonable starting cadence, with a nightly full reconciliation over a 48 hour window to catch anything the incremental poll missed. Multiply that by the number of pin-code accounts, which is the real load driver here.

Rate limits and pagination

Not published. No quota numbers, headers or page sizes are available. Until the API reference is obtained under a partner agreement, be conservative: serialise per account rather than running all accounts in parallel, back off on any non-200, and keep the per-account poll under one request per minute.

Mapping to the unified model

Gaps and open questions

  • The actual authentication transport. Username and password is what the integrator enters; what goes over the wire is unknown.
  • Whether the listing read returns price, MRP, stock and status, or only identity. This determines whether PharmEasy can feed the listings table at all.
  • Whether any write path exists for price or stock. No source says yes and no source says no.
  • Whether orders carry a prescription reference or image URL, which would change the data-handling classification of the whole feed.
  • Which PharmEasy accounts are marketplace accounts and which are direct-purchase vendor accounts. The two have completely different object models and the sources do not distinguish them.
  • Unicommerce does not list PharmEasy among its integrations, while EasyEcom does. That gap is unexplained and suggests the partner list is short.

Sources