Vendor onboarding for regulated hardware is a database query, not a document review

The lookup is the easy half. In the field guide's own sample function, the OpenFDA registrationlisting endpoint is queried by registration number ^[4], the product codes are pulled from the first returned listing, and a match is declared only when the expected product code appears in that set and the expected address appears as a lowercased substring of `address_1` [c6b]. Set membership on a product code is a real test. Substring matching on a street address is not. Factories write their own address differently on a certificate than the registration filing does, and two units in one industrial park can share enough of a string to pass. Since the stated goal is resolving a registration number to the exact legal name, owner/operator and site you are auditing ^[13], address normalisation is where the engineering hours actually go.

The same example has a second seam. The guide describes the minimal flow as three assertions, one of them being that the registration is active ^[6], while the sample code reports `status` as an output field rather than testing it [c6b]. A factory whose registration exists but has lapsed clears that function.

Throughput is not the binding constraint. Without an API key the device API permits 40 requests a minute ^[5], which is 2,400 an hour ^[1], and a key lifts the ceiling six-fold ^[2]. At that rate, how often you re-verify a supplier base is a scheduling choice rather than a capacity one, which is the real difference from document review: a PDF cannot tell you that a registration lapsed last quarter, and a repeat query can.

EUDAMED is the part that a query cannot yet close. Article 33 of EU MDR 2017/745 requires economic operators to register once the database is fully activated, and actor, device and certificate records all sit there, but the modules come online progressively, so the guide's advice is to confirm an actor registration now and re-check when the certificate module is active ^[11]. A supplier file therefore cannot store a verdict on its own. It stores a verdict plus the date a new module changes what the verdict is worth.

What makes any of this enforceable rather than merely tidy is that both regimes require the underlying records: 21 CFR Part 807 Subpart C for US establishment registration and device listing, Part 820 for quality systems ^[2], Articles 52 and 31 of EU MDR 2017/745 for conformity assessment and operator registration ^[3], and Part 830 for the UDI data that populates GUDID ^[7]. The one artefact with no public registry behind it is the ISO 13485:2016 certificate, where the guide's test is that the certificate number resolves on the issuing certification body's own search tool ^[12]. That pushes the question upstream: which certification bodies you are willing to accept becomes a procurement decision, because for that document there is no government database to fall back on.