Executive Summary: Every Secretary of State API vendor says it covers all 50 states. That claim is nearly meaningless on its own, because a state can be "covered" by a vendor that returns nothing more than a name and an active flag, while your underwriting model needs a formation date, a registered agent, and an officer list. Secretary of State API coverage is not a yes or no property of a vendor. It is a matrix of state, field, latency, and freshness, and the only way to buy correctly is to score that matrix before you sign. This checklist gives risk and engineering teams the questions to ask, the tests to run, and the failure modes that show up in month three rather than during the sales demo.
What Does "Secretary of State API Coverage" Actually Mean?
Coverage is four separate promises bundled under one word, and vendors rarely separate them for you.
The first promise is jurisdictional reach: can the API return a result from this state at all. The second is field depth: which of the fields your decision engine consumes are actually populated for that state. The third is latency behavior: how long the lookup takes and whether it completes synchronously. The fourth is freshness: how far behind the state's own record the returned data can be. A vendor can score perfectly on the first and fail badly on the other three, and the aggregate word "coverage" hides that.
The reason those four come apart is structural. The National Association of Secretaries of State notes that "Most NASS member offices handle the registration of domestic and/or foreign corporations (profit and non-profit)" and that "Fees vary from state to state."[1] There is no federal business registry that an API can query. Each state runs its own filing office, its own database schema, its own status vocabulary, and its own public disclosure policy. An aggregating API is a normalization layer over 51 independent systems, and normalization can only surface what a state chooses to publish.
Why Does the Word "Covered" Break Down at the Field Level?
Take officer data. Delaware's Division of Corporations tells the public that "Current officers and directors for Delaware corporations can be found on the most recent annual report," while shareholder detail "is not on file with the Division of Corporations. That information is maintained by the corporation itself."[2] New York is stricter still: its Department of State records "may include the name and address of the chief executive officer and the principal business location of a business corporation, provided that the business corporation has filed its Biennial Statement as required by Section 408 of the Business Corporation Law."[3] In New York the officer field is conditional on a filing the entity may simply not have made.
California publishes its own boundary. The Secretary of State's records request guidance describes what Business Search returns, including entity name, number, status, addresses, and officer names, and separately lists what is not available through it, including ownership information, bylaws, and bankruptcy detail for non-public companies.[4] None of that is a vendor limitation. It is the source of record's limitation, and every vendor inherits it.
So the honest formulation of the buying question is not "do you cover Michigan." It is "for Michigan, which of my eleven required fields are populated, at what rate, and how stale can each one be."
How Do You Verify That a Vendor Really Covers All 50 States?
Ask for evidence, not a map graphic. A coverage map with 50 states shaded blue is a marketing asset. The verification artifacts that matter are three.
• A per-state field matrix. Rows are states plus the District of Columbia. Columns are the fields you consume. Cells are populated, sometimes populated, or never populated. If a vendor cannot produce this, they have not measured their own coverage.
• A live test key with no result filtering. You should be able to run your own entity list against the API before you sign, including the states you know are difficult.
• A source-record link per result. Every returned entity should carry the state's own URL for that record so you can spot-check the normalization by eye.[5]
• A documented status normalization table. States use different words for the same condition. You need to see how the vendor maps them before you build rules on top.
• A written statement of known gaps. Any vendor operating at 50-state scale has them. A vendor claiming none has not looked.
The fifth item is the one that separates serious providers from the rest. New York's Department of State publishes this caveat on its own search database: "As the Department relies upon information provided to it, the information's completeness or accuracy cannot be guaranteed."[5] If the state that owns the data will not guarantee completeness, a reseller who does is either not reading the source or not telling you the truth.
What Should the Test List Look Like?
Scale is part of why this test matters. Delaware alone reported 2,287,728 registered business entities as of 2025, including 334,461 new entities formed that year, a fifteen percent increase over the prior year.[12] A registry that large produces genuine name collisions, and a vendor's behavior under collision is invisible until you feed it real names. If you want to see what the underlying manual process looks like before you automate it, our California Secretary of State business search guide walks a single state's portal end to end.
Build a 200-entity test file drawn from your own book, weighted toward the states where you fund most, and salted deliberately with hard cases: recently formed LLCs, entities with punctuation and abbreviation variants in the legal name, entities you know are administratively dissolved, and at least five entities from slow states. Run it against every finalist vendor with identical inputs on the same day. Differences in match rate on identical inputs are the only vendor comparison that survives contact with production. Our sibling guide on benchmarking business verification match rates covers test-set construction and false-negative cost in detail, and the pre-purchase testing checklist covers sandbox behavior, error shapes, and support expectations.
Which Data Fields Should You Expect, and Why Does Depth Vary by State?
Field depth varies because annual report requirements vary, and the annual report is where most of the interesting fields come from. Cogency Global's August 2025 review of state filing requirements documents how far apart the states sit: Alaska requires "percentage of ownership to be listed for all members in member-managed LLCs," Arizona corporations must submit a Certificate of Disclosure covering officer and director details plus five years of legal history questions, Massachusetts requires disclosure of "term expiration dates of officers," and Washington entities must list "all governing persons."[6] States that ask for more publish more. States that ask for less cannot publish what they never collected.
A practical field expectation for a 50-state SOS lookup looks like this.
States that give you officers are giving you last year's officers. States that publish nothing are at least honest. The dangerous middle is a state publishing a field it stopped updating.
Cobalt's SOS Search returns the following where the state makes them available: legal business name, registration status, a normalized status value standardized across all states, filing date, registered agent name and address, principal and mailing address, officers and directors with names, titles, and addresses, entity type and subtype, state of formation, a direct URL to the state record, and an optional timestamped screenshot. Each result also carries a confidence score between 0.0 and 1.0 and up to ten close matches in a `possibleAlternatives` array when the exact match is uncertain.
The load-bearing phrase is "where the state makes them available." Officer data availability varies by state. Some states publish officer and director information and others do not, and the API returns whatever the state exposes. Treat any vendor field list as a superset, never as a per-state guarantee, and design your decision rules so that a missing officer array in a non-disclosing state routes to a documented alternative rather than to a decline. The field-by-field reference for SOS API responses walks the response schema in full.
How Should Normalized Status Change Your Rule Design?
States do not agree on status vocabulary, and the disagreement is not cosmetic. An entity that is inactive in one state's vocabulary may be delinquent, revoked, administratively dissolved, or voluntarily withdrawn, and those four carry very different credit meanings. A normalized status field collapses that variance into a consistent set your rules engine can switch on, but you should still log the raw state value alongside the normalized one. When an exception review escalates, the reviewer needs the state's own word, not the mapped word.
How Should You Evaluate Slow States and Async Response Behavior?
This is the coverage dimension that buyers underweight and operations teams pay for. A state is not usefully covered if the lookup does not finish inside your application's timeout.
Response time on live lookups varies widely by state. Most states return in 10 to 30 seconds. Delaware typically takes 15 to 30 seconds. Oregon can take up to five minutes for a live lookup. Cached lookups return in under a second but carry different freshness properties, which the next section addresses.
Any honest 50-state API therefore has to offer an async path, and you have to decide during evaluation which of the two async mechanisms your stack will use.
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=oregon&liveData=true&callbackUrl=https://yoursite.com/webhook' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'The callback pattern posts results to your endpoint when the lookup completes. The alternative is polling with a `retryId` returned on the initial response, re-requesting until `status` reads `complete`. Callback is the better default for high volume because it removes the polling cost, but it requires a publicly reachable endpoint with its own retry and idempotency handling. Our sibling post on business registration verification time by state covers per-state timing expectations, and the published async webhook architecture guide for long-running SOS lookups covers the endpoint design itself.
What Should You Test Before You Commit to a Timeout Policy?
Run every finalist against the same slow-state entity list and record the full distribution, not the average. Averages hide the tail, and the tail is what pages your on-call engineer. Then confirm the vendor exposes deterministic test modes so your engineers can build error handling without burning credits or waiting on real state systems. Cobalt's `test` parameter accepts `complete`, `incomplete`, `failed`, `retryIdInvalid`, and `badRequest`, which lets you exercise each branch of your handler in CI.
What Update Freshness Should You Require, and How Do You Test It?
Freshness has two layers, and buyers usually only think about one. The first layer is vendor-to-state: how current is the vendor's copy relative to the state's database. The second layer is state-to-reality: how current is the state's database relative to what the business actually did.
The second layer is the one that surprises lenders. Oregon's Secretary of State publishes its own processing status, and as of August 6, 2026 the office listed online filings at "1-3 Business Days" and had processed mail and fax filings only through July 29, 2026.[7] An entity that filed by mail in early August is not in the searchable registry yet, no matter how real-time your API is. New York states that "The information available through this site is updated daily," which is a good number, and also notes that a name availability determination "applies only to the date and time that the name search was completed."[3]
The buying consequence is that "real-time" should be defined as real-time against the state of record, and your policy has to absorb state-side lag separately. Cobalt's SOS Search returns primary data pulled live from official state websites on every request when `liveData=true`, and a monthly-refresh cached copy when `liveData=false`. The recommended pattern is a waterfall: check cache first for a sub-second response, then follow with a live lookup when there is no match or the cached record is stale.
• Set a maximum cache age per decision type. Pre-screening tolerates a monthly-refresh record. Pre-funding verification should not.
• Require a source URL on every response. The state's own record link is your audit anchor and your fastest manual recheck path.[5]
• Require timestamped screenshots for funded files. A watermarked capture of the state page proves the record read at the moment of decision rather than at the moment of audit.
• Confirm screenshot retention terms. Cobalt's screenshot URLs remain downloadable for a limited window of 3 to 30 days, so your system has to pull and store the image rather than storing the link.
• Re-verify at defined checkpoints, not continuously. A point-in-time recheck before funding is a different product from continuous change detection, and conflating them inflates your credit spend.
That last distinction matters enough to separate. Our sibling posts on automating filing status updates via API and real-time SOS data versus cached registry data cover the recheck and staleness patterns respectively.
Which States Charge Pass-Through Fees That Change Your Unit Economics?
Some states charge for the exact data point a lender most wants, and that cost flows to you regardless of vendor.
Delaware is the clearest case. The Division of Corporations sells online status in two tiers: a $10 option that returns "a screen displaying the current status of the entity you requested which can be printed," and a $20 option that returns "the status, the last 5 filings, franchise tax assessment, total authorized shares (if applicable), and tax due." Neither tier generates an official certificate of good standing, which is a separate and considerably more expensive product.[8] Cobalt passes the Delaware status cost through at cost rather than marking it up, and this is a state-imposed fee, not a vendor surcharge. New Jersey status data is similarly restricted, with the Division of Revenue's Status Report product listing "registered agent, business addresses, filing date, date last annual report filed, officer/directors/managers and legal status" behind its records service.[9]
Texas charges at the search level rather than the status level: "There is a $1.00 statutorily authorized fee associated with each search, which supports the ongoing operations and enhancements of SOSDirect."[10] The authorizing statute, Section 405.018, directs that "The secretary of state shall set and charge a fee for access to information under Subsection (a) in an amount reasonable and necessary to cover the costs of establishing and administering the system."[11]
None of this shows up in a per-credit price comparison. Model it directly: take your actual state mix, apply the per-state pass-through, and compare blended cost per verification rather than headline credit price. A vendor with a lower credit price and no Delaware pass-through disclosure is not cheaper. It is less specific.
Does Volume Change the Calculation?
It changes which lookups you can afford to run live. High-volume pre-screening belongs in cached mode, where the response is sub-second and the record is monthly-refresh. Live lookups belong at the decision point, where the cost of a stale answer exceeds the cost of the call. The build-versus-buy math shifts too once pass-through fees and state-by-state scraping maintenance enter the model, which our published SOS API versus building in-house cost comparison works through.
How Do You Score Coverage Across Vendors Without Guessing?
Turn the four dimensions into a scored rubric weighted by your own state mix, then run every finalist through the same test file on the same day.
Weight each state by the share of your funded volume it represents, not equally. A 3 percent match-rate gap in a state that carries 22 percent of your originations is a material problem. The same gap in a state carrying 0.4 percent is noise. Score each vendor per state on four axes: match rate against known-good entities, field completeness against your required field list, p95 latency, and record currency measured against a hand-checked sample of the state's own site. Multiply by the state weight and sum.
Three vendor answers should change your score materially.
• Whether the vendor names its slow states in writing. Vagueness here predicts production surprises.
• Whether the field matrix distinguishes "never available" from "sometimes empty." These require different fallback logic and conflating them breaks your rules.
• Whether the vendor passes state fees through at cost or marks them up. Ask for the Delaware line specifically.[8]
• Whether test mode covers failure branches, not just the happy path. You cannot ship error handling you could not exercise.
• Whether the vendor states limitations unprompted. Delaware's own FAQ draws a clear public-record boundary and so should your vendor.[2]
For context on how the broader market sorts on these axes, our pillar comparison of top Secretary of State API solutions for verifying businesses reviews the current vendor field, and the explainer on how a US corporate registry API works covers why the aggregation problem exists at all.
What Does a Coverage-Verified Integration Look Like in Practice?
Before you build against any vendor, run one lookup per priority state and read the raw response rather than a dashboard rendering. The shape below is what a completed SOS Search returns.
{
"status": "complete",
"statusCode": 200,
"requestId": "abc123-def456",
"results": [
{
"title": "ACME CORPORATION",
"filingDate": "2015-03-15",
"stateOfFormation": "Delaware",
"status": "Active",
"entityType": "Corporation",
"registeredAgent": {
"name": "CT Corporation System",
"address": "1209 Orange St, Wilmington, DE 19801"
},
"physicalAddress": "456 Corporate Blvd, Suite 100, New York, NY 10001",
"sosUrl": "https://icis.corp.delaware.gov/ecorp/...",
"screenshotUrl": "https://screenshots.cobaltintelligence.com/..."
}
],
"possibleAlternatives": []
}Read four things in that payload. The `sosUrl` proves the record traces to the state. The `screenshotUrl` gives you the audit artifact, subject to the 3-to-30-day download window. The presence or absence of an `officers` array tells you the real field depth for that state. And `possibleAlternatives` tells you whether the match was clean or whether a human needs to look.
Then wire your confidence thresholds. Cobalt returns a confidence score from 0.0 to 1.0, and the conventional split is auto-accept above 0.8, human review between 0.5 and 0.79, and treat below 0.5 as a probable different entity. Set those thresholds per state rather than globally if your test file shows the score distribution shifting in states with high name collision.
Where Does the SOS Check Sit in the Wider Stack?
An SOS API is a data source, not a decisioning engine, and it verifies registration rather than identity, tax standing, or lien position. It answers whether the entity exists, in what status, since when, and under whose agent and officers. It does not answer whether the EIN matches, whether there are prior liens, or whether the principals appear on a sanctions list. Sequence it accordingly: SOS registration, then EIN or TIN verification, then UCC, then sanctions screening, with each step's failure routing to a documented exception path. Cobalt also offers a beta `findRelatedBusinesses=true` parameter that surfaces other entities linked to the agents and officers in a result, adding one to two seconds to response time and matching only against Cobalt's own database. It is useful as a fraud signal, and being a beta feature its behavior may change.
.jpg){kind=small}
.png)