Authentication

What the key determines

Your key is bound to a single group. That binding decides:

Which pharmacies you can act for. Naming an NPI outside your group is rejected.

Which environment you’re in. Keys don’t cross between sandbox and production.

To see exactly what a key can reach, call GET /api/v1/pharmacies/search. It takes no parameters and returns the group’s pharmacies.

Failure responses

401 — missing or invalid key

{
  "error": "Missing Authorization Header",
  "statusCode": 401,
  "message": "Missing authorization header"
}

The header was absent or the key wasn’t recognised.

403 — key not permitted here

Most often the pharmacy NPI you named isn’t in your group.It also covers a key that is well-formed but belongs to no group at all. That distinction started to matter in the 1 September release: GET /api/v1/ndc-transaction-statistic previously accepted any value shaped like a GUID, because the endpoint has no pharmacy to scope the key against and so never resolved it. It now resolves the key and returns 403 when nothing owns it. A real key is unaffected; a placeholder that appeared to work will stop.

400 — when it's really an auth problem

Request validation runs before authentication. A request that is both malformed and unauthenticated returns 400 with field-level validation errors, not 401:

{
  "errors": {
    "pharmacyNpi": ["Pharmacy NPI is required"],
    "searchingContext": ["The field SearchingContext is invalid."]
  },
  "title": "One or more validation errors occurred.",
  "status": 400
}

Fix the body first. If a well-formed request then returns 401, the problem is the key.

Get started

Guides

Reference

What the key determines

Failure responses

Rotating a key

​What the key determines

​Failure responses

​Rotating a key

What the key determines

Failure responses

Rotating a key