Pharmacies API

A pharmacy connection is a link between your tenant and a compounding pharmacy that can fill orders. Orders route to a connection; the connection's capabilities and status decide whether it's eligible. This resource is read-mostly from an integrator's seat — you list connections, read one, and read the routing policy that binds them together.

What a pharmacy connection is#

Filling a compounded prescription happens at a licensed pharmacy, not at neolife. A connection is your tenant's onboarded relationship with one such pharmacy: it carries a stable id, a display name, a status, and a set of capabilities (which product categories and protocols that pharmacy can fill).

When you submit an approved order, neolife picks a connection for it using your routing policy. That's the whole point of the resource: connections are the destinations, and the policy is the rule that maps an order to one of them. See Routing for how the match is made.

Connections are provisioned as part of onboarding a pharmacy to your tenant. Once a connection exists and is active, it becomes a candidate for routing.

List connections#

Returns every pharmacy connection on your tenant.

curl https://api.neolife.health/v1/pharmacies \
  -H "Authorization: Bearer $NEOLIFE_API_KEY"

[
  {
    "id": "phc_8c2a…",
    "pharmacyName": "Example Compounding Pharmacy",
    "status": "active",
    "capabilities": {
      "categories": ["peptide", "hrt"]
    }
  }
]

Each entry is a routing destination. status and capabilities are the two fields routing reads — a connection that isn't active, or that can't fill an order's category, is skipped.

Get the routing policy#

Reads the policy that decides which connection an approved order ships to.

curl https://api.neolife.health/v1/pharmacies/routing-policy \
  -H "Authorization: Bearer $NEOLIFE_API_KEY"

The policy is what turns "I have three connected pharmacies" into "this specific order ships to this specific pharmacy." You don't route orders by hand — you submit an approved order and the policy resolves the destination. Routing explains the resolution order and how capabilities filter the candidate set.

Provisioning and policy changes are tenant-admin actions, done from the dashboard. Machine API keys are built for the runtime path — list connections and read the policy — while onboarding a pharmacy, toggling its capabilities, and editing routing rules stay in the console under an operator's control.

How this fits the order lifecycle#

1. A patient completes intake and a licensed provider approves the order.
2. On submit, the routing policy selects an eligible pharmacy connection.
3. Fulfillment status flows back over PHI-free webhooks and events.

You rarely touch this resource per order — you configure connections and a policy once, then submit approved orders and let routing do the mapping.

Sync an Empower catalog#

If a connection is backed by Empower, you can pull its authoritative product catalog into your tenant at any time. The sync upserts products keyed by Empower's item designator id — names, strengths, forms, package sizes, refrigerated and controlled flags — and never invents SKUs.

curl -X POST https://api.neolife.health/v1/pharmacies/phc_8c2a…/sync-catalog \
  -H "Authorization: Bearer $NEOLIFE_API_KEY"

{ "synced": 48, "skipped": 0 }

Orders can only reference SKUs this sync produced; there is no free-text path into a pharmacy-bound line.

Related#

• Empower Pharmacy — the full connect flow, enrollment gates, and programmatic access
• Orders — where routed orders reference these connections
• Routing — how a connection is chosen