If you’re evaluating 510(k) submission software, start with an uncomfortable truth: there is no API for your 510(k). The FDA publishes no programmatic submission endpoint for premarket submissions. eSTAR is a dynamic PDF you complete in Adobe Acrobat, and a human uploads it to the CDRH portal. Any vendor implying their system “integrates with the FDA” or “submits your 510(k) automatically” is selling you something that doesn’t exist. So the honest question isn’t “does your QMS integrate with FDA?” — it’s “how much of the binder does your QMS build for you before a human clicks upload?” That’s the question this guide answers.

There is no API for your 510(k)

Let’s be precise about the mechanics, because the marketing blurs them. eSTAR — the electronic Submission Template And Resource — is a guided, dynamic PDF form (built on Adobe’s XFA technology). You fill it out in Acrobat, attach your supporting documentation, and a person submits the finished package through FDA’s CDRH Customer Collaboration Portal. There is no public endpoint a QMS can POST to. Nothing “talks to the FDA” on your behalf.

That matters because it resets what “510(k) submission software” can honestly promise. No tool clicks submit for you. What a good quality system can do is far more valuable: assemble the current, controlled, consistent documentation that eSTAR asks for, so the human filling out the form is copying from a finished, provably up-to-date binder instead of chasing files across a shared drive. The form is the easy part. The binder is the work — and the binder is exactly what a QMS is for.

What changed in 2026 — and why it’s urgent now

Three things landed in quick succession, and together they make this the moment to get your document set in order:

• The QMSR took effect on February 2, 2026. FDA’s Quality Management System Regulation replaces the old Quality System Regulation and harmonizes 21 CFR Part 820 with ISO 13485:2016. Your quality system is now being read against 13485’s structure.
• eSTAR 6.1 (February 2026) was the QMSR alignment release. The template was updated so its questions and structure line up with the new regulation.
• eSTAR 7.0 became mandatory for new applications on August 3, 2026. If you’re preparing a submission now, you’re preparing it in the current template, against the current regulation.

Here’s the wedge most teams haven’t connected: the ISO 13485 re-mapping you’re doing for the QMSR uses the same document set that feeds your eSTAR sections. Design controls, risk management, human factors, labeling, the device master record — these aren’t two separate projects. Do the QMSR work inside a quality system that understands those document types, and your 510(k) readiness comes along for free.

What eSTAR actually asks for (and where the work really is)

eSTAR walks you through the sections of a 510(k), but completing the form is mostly a matter of attaching the right documentation and answering questions your quality records should already answer. The effort — and the risk — lives in the attachments:

• Design History File (DHF) outputs — design inputs, outputs, reviews, verification and validation.
• Risk Management File (RMF) — your ISO 14971 hazard analysis, risk controls, and residual-risk conclusions, kept current through post-market surveillance.
• Human Factors / usability engineering (HFE) documentation.
• Device Master Record (DMR) content — specifications, labeling, and manufacturing information.
• Supporting evidence — biocompatibility, software, performance testing, and the like.

Every one of those is a controlled document (or should be). If they live as current, released records in your quality system, assembling the submission is a collation exercise. If they live in a folder somewhere, half of them a revision behind, the submission becomes an archaeology project — which is where late submissions and Additional Information (AI) requests come from.

The real evaluation question: how much of the binder does your QMS build?

So when you evaluate a quality system for medical device work, replace “does it integrate with FDA?” with three questions that actually predict how a submission will go:

• Are the submission documents controlled and current? Can you prove, on demand, that the DHF, RMF, HFE, and DMR documents in the package are the released revisions — not a draft someone exported last quarter?
• Can the system compute readiness? Instead of a person maintaining a spreadsheet of “what do we still need,” can the system tell you which required document types are released, which are still in draft, and which are missing entirely?
• Can it assemble the package? Can it pull the current documents into an organized, bookmarked package a human can attach to eSTAR and upload — without hand-collating PDFs?

Notice what none of these require: a mythical FDA API. They require a quality system that treats your submission documents as first-class, flagged, controlled records — and knows how to report on them.

How TLM builds the 510(k) binder from your quality system

This is exactly where TLM is built to earn its keep — and it’s shipping today, not on a roadmap.

TLM carries native DHF, DMR, DHR, RMF, and HFE flags on controlled documents. Because those flags live on the documents themselves, your submission readiness is computed from the register — not rebuilt by hand in a spreadsheet every time. Tag a document as part of the Risk Management File once, and it counts toward your RMF everywhere it matters, at whatever its current released revision is.

On top of that register sits a submission readiness board, live in the reporting module. It shows each eSTAR-relevant document set moving through a simple state: gap → release → green. A missing or draft document shows as a gap; release it under control and the board turns green. You can see, at a glance, exactly how close the binder is — and what’s standing between you and upload.

When the set is green, TLM assembles a bookmarked package of the current, released documents — organized and navigable — for a human to attach to eSTAR and submit through the CDRH portal. No API. No “auto-submit.” Just the binder built for you, provably current, so the person clicking upload is working from finished evidence.

And because all of this runs on the same controlled medical device document control that a QMSR-aligned ISO 13485 quality system already needs, you’re not building submission readiness as a separate effort — it’s a byproduct of running your quality system well.

See the 510(k) readiness board on your own document set → Book a 20-minute walkthrough.

Frequently asked questions

Is there an API to submit a 510(k) to the FDA?
No. The FDA publishes no programmatic submission endpoint for premarket submissions. eSTAR is a dynamic PDF completed in Adobe Acrobat, and a person uploads the finished package through the CDRH Customer Collaboration Portal. Any vendor claiming their software submits your 510(k) automatically is describing something that doesn’t exist.

What is eSTAR?
eSTAR (electronic Submission Template And Resource) is FDA’s guided, dynamic PDF template for 510(k) and De Novo submissions. It walks you through each required section and takes your supporting documentation as attachments. You complete it in Acrobat; a human submits it.

Is eSTAR mandatory, and which version?
Yes, eSTAR is required for 510(k) submissions. Version 6.1 (February 2026) aligned the template with the QMSR, and version 7.0 became mandatory for new applications on August 3, 2026 — so current submissions are prepared in eSTAR 7.0.

Does QMS software submit my 510(k) for me?
No. Quality management software doesn’t submit anything to the FDA — there’s no API for that. What it does is far more useful: it keeps your DHF, RMF, HFE, and DMR documents controlled and current, computes how ready your submission is, and assembles an organized, bookmarked package that a human attaches to eSTAR and uploads.

How does the QMSR affect my 510(k) submission?
The QMSR (effective February 2, 2026) harmonizes 21 CFR Part 820 with ISO 13485:2016. The same document set you’re re-mapping for the QMSR — design controls, risk management, human factors, device master record — is exactly what feeds your eSTAR sections, so doing the QMSR work well directly improves 510(k) readiness.