Is there an NMLS API?

What are you actually asking?

"Is there an NMLS API" is three questions wearing one coat, and they have three different answers.

Can I read license statuses automatically? Partly. Your own company account produces reports covering your licenses, your people and your open items, on demand, as CSV. There is no endpoint to call and no way to schedule it.

Can I file automatically? Not through an interface NMLS publishes, because there is no such interface. Through the screens that do exist, yes, and that is a real distinction rather than a technicality. More on it below.

Can I keep my HR system in sync with NMLS? Not natively. NMLS will not push you anything, and nothing you change in your own systems propagates back to it. Anything that looks like sync is something pulling on a schedule and reconciling.

If somebody told you to "just integrate with NMLS," the second and third answers are the ones to forward. The first is where the practical work actually lives, and most of this post is about it. It is also, for the record, the work Payna does, which is why we know the shape of it well enough to write this down.

Why is there no NMLS API?

The reason is structural rather than a matter of anyone dragging their feet.

NMLS is the system of record for more than fifty independent state agencies. Each one writes its own statutes, defines its own license types, sets its own forms and runs its own review workflow. An API is a promise about a stable contract: these fields, these meanings, this behavior, and notice before any of it changes. No single party is positioned to make that promise on behalf of fifty-plus regulators who did not agree to it and can amend their own requirements independently.

CSBS is rebuilding the system, and the schedule is public. NMLS Modernization ran phase one in July 2024, covering accounts and account management, and phase two in September 2025, covering associations and improvements to individual license applications. Phase three landed in August 2026 with state agency task management and branch license processes. Phases four through six run from 2027 to 2029.

Six phases across five years, and the published roadmap does not describe an API. Plan on the system you have.

That is the assumption everything else here rests on, and it is the assumption we built Payna around: not that the system will get easier to talk to, but that it will not.

What about the paid data feed?

There is a subscription product, NMLS B2B Access, operated by State Regulatory Registry LLC. If you have heard it described as "the NMLS API," it is worth knowing what it actually sells.

Its own subscription agreement calls the content Public Use Information: what is public about every company and every licensed individual. That definition is the important part, because it settles the question without anyone needing to read a schema. A deficiency is not public. It exists between one licensee and one regulator, inside that licensee's own account. Neither are pending applications, tasks, correspondence or documents.

So the feed is a directory of what the public can see about everyone, including you. It has nothing to say about the state of your own file. It is built for looking outward at counterparties, not inward at your own book.

What can you pull today, for free?

Something. Not what you want, but it is free and it is more than most teams are using.

Inside your own NMLS account there are fifteen standard reports. They cost nothing and need no agreement. Three of them carry the operational weight, and it is worth being clear about what each one is and is not.

Individual Active License Items

The outstanding deficiencies and requirements sitting on your active individual licenses. This is the closest thing to a list of what is currently wrong across your originators. It tells you the item exists and what the regulator called it. It does not tell you what will actually clear it, who is holding it up, or how long it has been sitting there.

Co-Br Active License Items

The same for company and branch licenses. Company-level items get missed more often than individual ones, mostly because onboarding checklists are written around people and nobody owns the entity.

Individual Roster

Licensed individuals plus pending applicants. Useful for answering "who do we actually have" rather than "who did we hire," and that gap is usually wider than anyone expects.

Beyond those three: criminal background check compliance, pre-licensing education and testing compliance and non-compliance, MLO temporary authority eligibility, renewal activity for companies, branches and sponsored individuals, the authorized agent roster, and surety bond reports.

They download as CSV, and that is the ceiling. There is no API on these, no scheduling, no notification when something changes, and no way to ask a question the report was not designed to answer. What you get is a flat file, correct as of some point in the recent past, that you then have to do something with.

Pull Individual Active License Items anyway. Most teams find open items they did not know about, and finding them late is the expensive version. If the results need translating, we wrote separately about what an NMLS deficiency actually is and who is allowed to clear one. Payna pulls these on a schedule rather than on somebody's memory, which is the difference between a report and a control.

Why is free and correct still not enough?

Three reasons, in increasing order of how much they cost you.

Someone has to remember. A report that requires a human to log in, navigate, request and download is a report that gets pulled when somebody thinks of it. That tends to mean during renewal season, after an examination notice, or the week a problem surfaces. The rest of the year the file on somebody's desktop is a photograph of a moment that has passed.

The data is already behind. The "as of" reports carry the previous day's data. A report requested on a Friday, a Saturday or a Sunday returns the prior Thursday's data. Over a weekend, a deficiency report can be three days behind the system it describes.

A row is a fact, not an action. This is the real one. A CSV row tells you a deficiency exists. It does not assign an owner. It does not know that clearing this particular item needs a document only the client holds, or that you asked for that document eleven days ago, or that the person who asked has since left. It does not chase anyone, and it cannot file the response.

The report tells you the deficiency exists. Everything after that is a person.

That is the part Payna is actually for. Not talking to NMLS, which nothing can do, but turning each row into work that has an owner, a date and a next step, and keeping it that way between the moments somebody remembers to look.

Can anything file into NMLS for you?

Not through an API, because there isn't one to file through. But the question people actually mean is "does a human have to sit there and do this," and that answer is no.

Here is the distinction that matters. NMLS publishes no programmatic write path: no endpoint accepts an MU1, an MU2, an MU3, an MU4, an amendment, a sponsorship request, a renewal, a Mortgage Call Report, a disclosure update, a document upload or a deficiency response. That is not going to change on the roadmap above.

What exists is a web interface. And a web interface can be driven.

That is what Payna does. It works the same screens your team works: new applications, amendments, renewals, Mortgage Call Reports, document uploads and deficiency responses, along with pulling license items, education and individual records back out on a schedule rather than when somebody remembers. No integration was required, because none was available.

How far it goes is your call. Some teams want the filings prepared and nothing else. Others hand the whole calendar over. You attest either way, and your signature goes on every submission.

Consumer Access, worth a sentence since it comes up: it is a public lookup for checking a license, not a data source for running an operation.

What were you actually looking for?

Probably not an API.

Nobody wants an integration for its own sake. What sits underneath the question is something more like this: licenses that stay current without anyone watching them, deficiencies cleared before they age into a problem, renewals filed inside the window rather than in its last week, one named owner per open item, and a register on your side that is actually the system of record rather than a spreadsheet somebody updated in March.

None of that requires NMLS to publish an API, which is fortunate, because it is not going to. It requires the reports pulled on a schedule instead of on a memory, the rows turned into owned work, the filings prepared without a person retyping them, and somebody accountable for each item until a regulator agrees it is closed.

That is all achievable today. It just does not arrive as an integration, and the companies still waiting for one are the ones absorbing the cost in headcount.

And if you did want the API, in the sense of wanting license state inside your own systems, that part exists too. Payna's API is a documented REST interface over your own licensure data: status by state, sponsorship state, CE completion, open regulator conditions. It is the thing people are picturing when they search for an NMLS API, pointed at your book rather than at the registry.

Frequently asked

Does NMLS have a REST API?

No. There is no public REST or JSON API, no developer portal, no documentation and no sandbox. The subscription data product that exists delivers files rather than endpoints, and it carries public directory information rather than your account's internal state.

Can I see my deficiencies through the NMLS data feed?

No. The feed's own agreement defines its contents as Public Use Information, and a deficiency is not public. It sits between you and one regulator inside your own account. Deficiencies appear in the free reports in your NMLS account instead.

How do I export NMLS license items?

Run Individual Active License Items for individual licenses, or Co-Br Active License Items for company and branch licenses, from the reports section of your own NMLS account. Both download as CSV. There is no charge and no agreement required.

Can I file an MU4 programmatically?

Not through an NMLS interface, because none accepts a filing programmatically. The forms can still be prepared and filed for you through the web interface that does exist, which is how filing gets automated in practice. You attest.

Is an NMLS API coming?

Nothing in the published NMLS Modernization roadmap describes one. The program runs six phases from 2024 through 2029, covering accounts, associations, application improvements, state agency task management and branch license processes.

Sources

• Overseeing Company Activity Using NMLS Reports
• NMLS Company Reports field definitions, release 2025.9
• NMLS B2B Access subscription agreement, the source of the Public Use Information definition
• CSBS, NMLS Modernization
• NMLS Consumer Access