Pharmaceutical Data API: How to Evaluate One

A pharmaceutical data API is a machine-readable interface that delivers structured medicinal product data, prices, package identifiers, product information texts and supply status, on demand and per query, directly into another system. Unlike a flat-file or database dump, it returns only the records you ask for, at the moment you ask, so the answer reflects the current state of the source rather than the state at the last import.

The distinction matters more in pharmacy and pharmaceutical trade than in almost any other data domain, because the underlying facts change on different clocks. A price can change twice a month. A shortage notification can appear this morning. A summary of product characteristics may be revised once in three years. A single nightly dump treats all of these as one refresh cycle, and every consumer of that dump inherits the slowest clock in it.

Note the ambiguity in the term itself: in pharmaceutical contexts, API also means active pharmaceutical ingredient. This article is about application programming interfaces for drug data.

What an API delivers that a flat file does not

An API changes three things: latency, granularity and the ownership of the data pipeline. A flat file, whether CSV, fixed-width or a full relational dump, requires you to receive it, validate it, stage it, transform it and load it before anyone can query it, and to repeat that on every delivery. Everything in that chain is your operational risk.

Neither model is superior in the abstract. Bulk analytics over the whole German market is a poor fit for record-by-record calls, and a live availability check at the point of dispensing is a poor fit for last night's export. Most serious integrations end up using both: a periodic bulk load for the stable master data, and API calls for the fields that move.

Where a pharmaceutical data API actually gets integrated

The integration targets are narrower and more predictable than the general "healthcare API" literature suggests. In the DACH market, the recurring ones are:

• Pharmacy management software, for article lookup, price calculation, substitution candidates and stock decisions.
• Hospital information systems and hospital pharmacy systems, for house list maintenance, therapeutic alternatives and unit-dose preparation.
• Wholesale ERP, for purchasing, margin calculation, order validation and returns handling.
• Warehouse management systems, where package identifiers and pack size drive slotting and picking logic.
• E-commerce and shop systems, where product texts, images, pack data and legal classification feed the catalogue.
• E-prescribing and E-Rezept infrastructure, where the prescribed item must be resolved to a dispensable package.
• Telemedicine and health apps, which typically need a narrow lookup and reverse-lookup rather than a full master data set.

Each of these has a different tolerance for latency and a different definition of "complete". A warehouse system that misses a discontinued pack causes a picking error. A shop system that misses one causes a customer complaint. A hospital pharmacy system that misses one causes a therapy substitution problem. The evaluation criteria should follow from which of these you are building.

"We do not want large volumes of data sitting in our portal. We would rather call an API against a service that is current." Managing director at an IT service provider for the pharmaceutical sector (translated from German)

That sentiment recurs across integration conversations, and it is worth reading carefully. The objection is not to the data volume as such. It is to owning a copy that silently ages.

How to evaluate coverage

Coverage is the first filter, and it has three axes that are usually conflated. Territorial coverage is which markets are represented. Layer coverage is how many data layers exist per product: article master, pricing, reimbursement status, product information texts, patient leaflets, ingredients, ATC classification, shortage status, interactions. Depth coverage is how far back and how far down each layer goes.

A provider can be excellent on one axis and thin on another. Several widely used open sources are strong on one national market and one layer: openFDA and RxNorm from the US National Library of Medicine and FDA ecosystem are authoritative for US products and identifiers, and offer nothing for German PZN-based dispensing. Conversely, a national article master covers dispensing perfectly and stops at the border, which is exactly the wrong shape for parallel import, cross-border sourcing or an EU-wide shortage response.

For pharmazie.com, the scope is 25+ databases in one interface, covering 50,000+ German products and 120,000+ international products across 50+ countries, which is the most complete single answer available for cross-border and cross-layer questions in DACH. For a purely domestic, single-layer use case, that breadth may be more than you need, and you should say so during evaluation rather than pay for reach you will not call.

Update cadence: ask per data type, never in aggregate

"Daily updates" is close to meaningless as a single claim, because different layers have different natural frequencies and different providers refresh them independently. The correct question is a matrix, not a number.

Two practical tests. First, ask the provider for the timestamp semantics: does the record carry the time it was fetched from the authority, or the time it was loaded into the provider's store, or the effective date of the change? These are three different fields and integrators regularly conflate them. Second, pick a change you can independently verify, a recent shortage notification in the BfArM shortage register is ideal, and check how long it took to appear in the API. That single measurement tells you more than any SLA document.

Identifiers: the part that decides whether the integration works

Most failed pharmaceutical data integrations fail at the join, not at the transport. Your system already has a master data record for a product. The API returns a record for a product. Whether those are the same product is an identifier question.

• PZN (Pharmazentralnummer) identifies a specific package in Germany. It is the practical join key for German dispensing, pricing and ordering. It does not travel across borders.
• EAN and GTIN identify a trade item and are what your warehouse and shop systems most likely already carry. Multiple PZN can map to trade item structures in awkward ways.
• PhPID (Pharmaceutical Product Identifier) under ISO IDMP as implemented by the EMA identifies the pharmaceutical product at substance, strength and dose form level, independent of packaging and independent of country. It is the identifier that makes cross-border equivalence tractable.
• ATC codes from the WHO classification system group by therapeutic use, not by product identity. Useful for alternatives, wrong as a join key.

Before signing anything, run a matching test: take 500 real records from your own master data, call the API, and count exact matches, ambiguous matches and misses. A provider that will not support this test during evaluation is telling you something.

Rate limits, export ceilings and where the licence line sits

Every commercial pharmaceutical data API draws a line between interface access, which is the right to query the service for operational use, and a raw data licence, which is the right to hold and redistribute a substantive copy of the data set. The line is usually drawn as a volume threshold, and where exactly it sits is a commercial fact you should establish early rather than discover in month four.

At pharmazie.com the threshold is explicit: exports up to 5,000 PZN per call fall under normal interface access, and beyond that a raw data licence applies. The value of an explicit number is not that it is generous or strict, it is that you can design against it. An undefined "reasonable use" clause cannot be designed against.

Related questions worth resolving in writing:

1. Is billing per call, per seat, per connected end customer, or flat? Per-call billing on a user-facing search feature is difficult to forecast, because your cost scales with user behaviour you do not control.
2. If you are a software vendor serving many end customers, does the licence price per your installation or per connected customer? This is the single most common cost surprise for platform vendors.
3. What caching is permitted, and for how long? A permitted cache changes your architecture and your rate limit maths substantially.
4. What are the uptime commitment and the maintenance windows, and are the windows aligned with the update cycle or with your peak hours?
5. How are breaking changes versioned and announced, and how long do old versions run in parallel?

The direction of travel: FHIR and structured product information

Pharmaceutical data is moving from document-shaped to structure-shaped, and integration decisions taken now should assume that direction. Three currents matter.

FHIR as the transport and model. HL7 FHIR defines MedicinalProductDefinition and related resources specifically for regulated medicinal product data, and German telematics infrastructure builds on FHIR profiles for both the electronic patient record and E-Rezept, as specified by gematik. An API that can answer in FHIR-shaped resources reduces the mapping layer you would otherwise maintain.

ISO IDMP. The EMA implementation programme is progressively making PhPID and the associated substance, product and organisation identifiers the regulatory backbone across the EU. Systems that carry only national package identifiers will need a bridge to that layer.

Electronic product information. The move from PDF summaries of product characteristics toward structured, machine-readable product information is what turns product texts from an attachment into a queryable field. Any evaluation should ask what a provider returns today for product information: a link, a blob of text, or structured sections.

Realistic integration pitfalls

Six recur often enough to plan for:

• Treating the pack as the product. Substitution, alternatives and shortage responses all operate above package level. If your model has only PZN, you cannot answer them.
• Caching prices with the wrong lifetime. Price validity has effective dates. A cache keyed only on product, without a validity window, will serve a correct-looking wrong price.
• Ignoring the discontinued and withdrawn states. Absence from a current file and explicit discontinuation are different facts, and only the second lets you tell a user why.
• Underestimating the ERP side. The API is rarely the hard part. Legacy wholesale and hospital systems often have no clean extension point, and that work sits with you, not the data provider.
• Testing with clean data. Evaluation with a curated sample hides exactly the ambiguous matches that will dominate your support load.
• No monitoring on staleness. If an update job fails quietly, the system keeps answering, just wrongly. Alert on data age, not only on HTTP errors.

A short evaluation checklist

1. Which markets, which layers, which depth, stated separately.
2. Update cadence per data type, with timestamp semantics defined.
3. A join test on 500 of your own records before contract.
4. The exact volume threshold where interface access becomes a raw data licence.
5. Billing basis, and how it scales with your growth, not with today's usage.
6. Versioning policy, deprecation window, uptime and maintenance schedule.
7. What is returned for product information: link, text, or structured sections.
8. Whether FHIR-shaped output and IDMP-level identifiers are available or on a stated roadmap.

Answer those eight and the technical integration becomes an engineering task with a known shape. Skip them and the integration becomes a discovery process at production scale, which is considerably more expensive.

This content is intended for healthcare professionals and does not constitute medical advice. Last reviewed: July 2026.