Navigating National Drug Codes (NDC) in 2026: A Developer's Guide to US Drug Data

An NDC is a 10-digit number in three segments — labeler, product, package — and it identifies a specific packaged drug product in the US, not a drug ingredient. For 2026, build on the FDA NDC Directory as your register of record, normalize everything to NDC-11 on ingest, and map to RxNorm for anything clinical. A lookup API is only as good as the normalization layer you put in front of it.

Key takeaways

• NDC identifies a package, not a molecule. Three products from one labeler share an ingredient and nothing else.
• The FDA NDC Directory is the primary US source; openFDA exposes a JSON view of it, and RxNorm's getNDCProperties gives you the crosswalk to RxCUI.
• NDC-10 and NDC-11 are the same number with different padding. Pick one internal format — NDC-11 — and convert at the boundary.
• Most production incidents I have seen were not API failures. They were unnormalized NDCs arriving from a claims feed or a pharmacy system.
• You probably do not need a commercial NDC API until you need cross-border identifiers too. Start with openFDA.

What is an NDC and why is it critical for US drug data?

An NDC — National Drug Code — is a 10-digit identifier assigned to a drug product in the US, split into labeler code, product code and package code. The FDA maintains the National Drug Code Directory as the register of listed products. It is the join key between US claims, dispensing systems, and regulatory data.

The critical part is granularity. The labeler code identifies who markets the product. The product code identifies strength, dosage form and formulation. The package code identifies the box, bottle or blister. Change the pack size and you have a new NDC. Change nothing but the labeler and you have a new NDC.

That means an NDC is a poor clinical key and an excellent commercial one. For reimbursement, inventory and recalls, it is exactly right. For "is this the same drug as that one", you need a second identifier. That is what RxNorm is for, and I will come back to it.

Where does current NDC data actually come from?

The FDA NDC Directory is the primary US source for current NDC data, and everything else is downstream of it. The directory is published by the FDA as downloadable files and consumed by openFDA, by RxNorm's crosswalk, and by most commercial aggregators. If your provider cannot tell you which FDA release their data descends from, that is your answer about their data quality.

The practical consequence: the directory is a register of listed products, not a live inventory. A product can be listed and not on a shelf. A product can be discontinued and still appear in historical claims for years. Treat "present in the directory" and "dispensable today" as two different questions, because your users will conflate them.

FDA NDC Directory API

The FDA itself does not offer a single first-party REST endpoint under that name. The machine-readable view of the directory is openFDA, which exposes /drug/ndc.json. Each record carries the NDC, brand and generic names, labeler name, dosage form, route, active ingredients with strengths, and a packaging array with one entry per package NDC.

Two things to know before you build on it. First, openFDA applies rate limits that differ depending on whether you send an API key — check the current published limits rather than copying a number from a blog post, including this one. Second, the JSON is a flattened view. It is convenient for lookup and awkward for reconciliation, because packaging-level NDCs sit inside a product-level record.

NDC API options for developers in 2026

There are three realistic options: openFDA, the RxNorm API, and a commercial aggregator. Use openFDA for product attributes, RxNorm for clinical concepts, and a commercial provider only when you need identifiers outside the US or a contractual SLA. Most teams I have seen start with a commercial API and later wish they had started with openFDA.

The RxNorm side is documented at getNDCProperties in the RxNorm API, and the same API family gives you findRelatedNDCs to go the other way — from an RxCUI back to the NDCs that roll up to it. Those two calls are the whole crosswalk for most applications.

If you are also handling non-US registers, the identifier problem changes shape entirely; our notes on EMA IDMP 2026 submission readiness cover where the EU equivalents diverge.

NDC 10-digit vs 11-digit: what changes and when?

NDC-10 is the format as assigned, in three variable-length segments. NDC-11 is the same number with a leading zero padded into whichever segment is short, giving a fixed 5-4-2 layout. Billing and claims systems expect NDC-11. Product labels and FDA files often show NDC-10. Both are correct; they are not interchangeable as strings.

The trap is that padding is positional. A 4-4-2 NDC gets its zero in the labeler segment; a 5-3-2 gets it in the product segment; a 5-4-1 gets it in the package segment. If you strip hyphens and left-pad the whole string to 11 characters, you will silently corrupt every 5-4-1 NDC in your dataset. I have watched that bug survive a code review, a QA pass and a release, because the corrupted values still look like plausible NDCs.

How do you map NDC to RxNorm and GTIN?

Map NDC to RxCUI through RxNorm, and map NDC to GTIN through the packager's GS1 data. RxNorm gives you the clinical concept — ingredient, strength, dose form — that NDC cannot express. GTIN gives you the barcode identity used in scanning and logistics. Neither replaces NDC; they answer different questions about the same box.

One caveat worth stating plainly: NDC-to-RxCUI is not one-to-one in either direction. Several NDCs collapse to one RxCUI, and one NDC can relate to more than one concept depending on how precisely you specify strength and form. Store the mapping as a table with a source and a date, not as a column on your product row. When the mapping changes, you want to know what it was last week.

If you are wiring this into a clinical system, our FHIR R4 medication data implementation guide covers how MedicationRequest and MedicationKnowledge expect these identifiers to be carried.

Integrating NDC data into an EHR or pharmacy system

Integrate by normalizing on the way in, not on the way out. Every inbound NDC — from a feed, a scan, a fax, a CSV — should pass through one function that strips separators, detects the segment layout, pads to NDC-11 and validates the result against your local reference table before it touches a database column.

A checklist I would actually run before go-live:

1. Normalize at the boundary. One function, one place, called by every importer.
2. Store NDC-11 as the key, and keep the original string alongside it for audit.
3. Reject rather than guess. An NDC that does not validate against the directory should fail loudly, not silently become a new product.
4. Version your reference data. Record the FDA release date with every row you ingest.
5. Handle the packaging array explicitly. Product-level and package-level NDCs are different rows in your schema.
6. Log the mapping. When an NDC maps to an RxCUI, store when and from where.

For pharmacy management specifically, the failure mode is inventory drift: the same physical product entered three times under three string variants. Normalization fixes that before it becomes a stock discrepancy.

NDC data harmonization: what breaks and how to fix it

NDC data harmonization means making identifiers from different systems refer to the same thing — and it fails in predictable ways. Hyphens present or absent. Leading zeros added or dropped. Case differences in labeler names. Discontinued products still flowing through claims. Package-level and product-level NDCs mixed in one column. None of these are exotic; all of them are common.

The fix is boring and it works. Normalize to a single canonical form, keep the source value, and reconcile against a dated reference rather than against your own table. Reconciling against your own table is how a typo becomes a standard.

One more thing, and I mean this as a caution rather than a pitch: if you are pulling interaction data alongside NDC data, the identifier hygiene problem doubles, because interaction sources key on different concepts. We wrote about that in drug interaction APIs in 2026.

Next steps

Start with openFDA. Pull a few thousand records, run them through your normalization function, and count how many fail. That number tells you more about your integration risk than any vendor comparison will. Then add the RxNorm crosswalk for the clinical layer, and only then decide whether you need a commercial NDC code lookup API in 2026 at all.

If you would rather not rebuild the reference layer, you can search the Drug Database catalogue and check what identifiers are exposed per product before you write any code.

FAQ

What is the difference between an NDC-10 and an NDC-11?

NDC-10 is the number as assigned, in three variable-length segments. NDC-11 is the same number padded with a leading zero into the short segment to give a fixed 5-4-2 layout. Claims systems expect NDC-11; labels often show NDC-10.

Is there a free NDC lookup API?

Yes. openFDA exposes the FDA NDC Directory as JSON at /drug/ndc.json, and the RxNorm API provides NDC properties and NDC-to-RxCUI mapping at no cost. Both apply rate limits, so check the current published figures before sizing a batch job.

How do I convert an NDC to RxNorm?

Call getNDCProperties in the RxNorm API with the NDC and read the returned RxCUI. To go the other way, use findRelatedNDCs with an RxCUI. Treat the result as a many-to-many mapping and store it with a source and date.

How often should I refresh NDC reference data?

Refresh on a schedule you can defend, and always record the FDA release date you ingested. NDCs are added and discontinued continuously, so a refresh cadence matters less than knowing exactly which release your data came from.

Can I use an NDC as a primary key in my database?

Not the raw string. Use a normalized NDC-11 as a key, keep the original value in a separate column for audit, and version your reference data. Raw NDCs from external feeds are inconsistent enough to create duplicate products silently.