You build pharmacy, clinic or ERP software and your customers expect reliable drug data inside it. pharmazie.com supplies that data from 25+ databases across 50+ countries, by web service or as a configurable download into your own system.






But what we need now is access to this medical data. That means we would need a PZN lookup and reverse lookup as an API.
Developer, software startup
Your roadmap is blocked on something you do not produce yourself. Every week without a data source is a feature your customers cannot use, and a portal your users have to open next to your product does not count as a solution.
Traditionally, our ERP system was not built to communicate with other systems.
Project manager, IT service provider for pharma
Your customers live in SAP, Sage, Navision or their own merchandise management system. If the drug data does not arrive there, nobody uses it, and the integration effort lands on your engineering team rather than on the data supplier.
If the doctor's practice is supposed to pay almost 200 euros a month on top, honestly they are probably a bit put off.
Co-founder, software provider for medical practices
You are not the end user of this data, your customers are. A price that ignores that has to be carried by your own margin or passed on to a customer who then walks away. Per call billing has the same effect: you cannot quote a price for your own product.
Our web service enables machine to machine communication over the internet, so you can use our data and functions on your own IT systems. Price comparison or a drug safety check can be called up directly in your system instead of in a second portal.
In the service download you determine which data you want to download and how often you want to update it. You also define the data file format that best suits your system, so your import does not have to be rebuilt around ours.
Behind the connection sits a network of 25+ databases from 50+ countries, including the ABDA article master data, Gelbe Liste, ROTE LISTE, Austria and Switzerland. One relationship covers what would otherwise be several separate sources for your product.
MSV3 is the German standard interface between pharmacy systems and suppliers. Availability query and ordering over the MSV3-Client are live and productive today. The MSV3 server, which lets you offer yourself as a supplier, is in a 2026 pilot phase.
pharmazie.com gives software vendors a way to put drug data inside their own product rather than beside it. A web service enables machine-to-machine communication over the internet, so your pharmacy, clinic or ERP software can call the data and functions it needs, for example a PZN lookup or a price comparison, from your own interface. Behind that connection sits a network of 25+ databases from 50+ countries.
The reason vendors come to a single provider is coverage they would otherwise assemble piece by piece. The network includes the ABDA article master data, alongside further German and international sources and separate country dictionaries. Your product presents one consistent data layer to its users instead of stitching several feeds together and maintaining each one.
Not every product needs the whole market. In the service download you determine which data you take and how often you refresh it, and you define the file format that best suits your system. That keeps the payload matched to your use case rather than forcing your software to ingest and discard data it will never show.
Vendors ask for this in three different shapes, and the words are used loosely across the industry. The distinction that actually matters is not technical. It is who the end user sees, who holds the onward licence, and who answers the support call.
| Model | Whose brand the end user sees | Who holds the onward licence | Who supports the end user | Fits when |
|---|---|---|---|---|
| OEM | yours only; the data source is not visible | you, towards your customers | you | the data is a feature of your product and you want no third party in the relationship |
| White-label | yours, on a working module you did not build | you, within an agreed scope | you, with second level from us | you want the capability without building the interface for it |
| Connect | both; your product calls the platform | usually the end customer, directly | shared, along a defined line | your customer wants their own data relationship, or you are publishing into a marketplace |
The choice is decided by the licence scope, not by the technology. All three can be delivered over the same web service or download. What differs is what you may do with the data afterwards, and that is a question to settle before the architecture, not after it.
MSV3 is the German standard interface between pharmacy systems and suppliers. Availability query and ordering over the MSV3-Client, the buyer side, are live and productive today and offered as a standard add-on, so your software can check in real time what a wholesaler can deliver and place orders directly. The MSV3 server, the seller side that lets you offer yourself as a supplier, is in a 2026 pilot phase, so we name it as a pilot rather than as a finished feature.
The question this segment asks most is how it is licensed when you pass the data on to your own end customers. That is not something to settle on a web page. What we can state is the basis: downloads are supplied under licence from our data partners, and that licence governs what you may store in your own database and process further. It is a conversation to have before you build, not after.
The clearest test is a 30-minute demo on the use case you are building for, with the fields and the software you actually run.
More clarity, faster research, and faster decision-making.






Two routes. Our web service enables machine to machine communication over the internet, so you can call our data and functions, for example price comparison or a drug safety check, directly from your own system. Alternatively you take a configurable download and load it into your own environment. What we do not publish is a self service developer portal with public endpoint documentation and a sandbox. The technical detail comes from our team in a call, not from a signup form.
In the service download you define the data file format that best suits your system. We deliberately do not list JSON, XML and CSV here as a blanket promise, because the answer depends on which databases you licence and which route you take. Bring the format your import expects to the demo and we will tell you straight away whether it works.
This is the question this segment asks most, and it is the one we will not answer with a price list. What we can state is the basis: downloads are supplied under licence from our partners and data suppliers, and every offer is put together individually. Whether your model is per user, per institution, per end customer or a raw data licence, that has to be agreed for your case, including with the data owners behind the respective databases. Bring your customer count and your commercial model to the first call and you will get a concrete answer there.
Not something we can wave through on a web page. Downloads come under licence from our partners and data suppliers, and that licence governs what you may do with the data, including caching, enrichment and passing it on inside your product. It is exactly the question that decides your architecture, so it belongs at the start of the conversation. Ask it in the first call and we will get you a binding answer rather than a comfortable one.
Yes. The ABDA article master data and IFA-Taxe is part of the network, alongside ABDA-Database CAVE, ABDA-Database Active Ingredients Dossiers, the German drug interactions ABDA-Database, recent news and the archive.
The network covers 25+ databases from 50+ countries, and the country dictionaries are separate databases, for example the Austrian drug dictionary with WHO ATC and the Swiss Pharmaindex HCI. What we are working on is one consolidated EU database that unifies active ingredients and links EU authorisation numbers to PZNs. That is a real gap and a frequent request, and one we will be able to close within 2026.