Executive Summary: No official bulk download of Secretary of State data covers all fifty states and the District of Columbia, because each state decides for itself whether to publish a file, what it contains, how often it refreshes, and what it costs. A few states post open-data files, some offer extracts by subscription or sale, and commercial providers license compiled multistate datasets, but those are secondary copies on the licensor's schedule. For a lender or platform that needs current records, the working unit is a keyed lookup per record, run singly or as a batch, with the durable dataset in your own store. This guide inventories what the states offer, explains how batch processing works on a lookup API, and names what a lookup API, Cobalt's included, will not deliver.
Is There a Bulk Download of Secretary of State Data From One Source?
Which states publish bulk files today?
The honest answer starts with a state-by-state inventory, because the registries are fifty-one separate systems with no shared publication rule. Cobalt states that it never purchases or resells aggregator data and retrieves records directly from state websites, or through official state APIs when available, which is a reminder that even a vendor with national coverage is assembling fifty-one sources rather than reading one.[1] A sample of official programs, each probed live on September 24, 2026, shows how different the offers are.
• Colorado. The Department of State publishes its business entity register as an open dataset covering entities registered since 1864, with an automated update scheduled every day after midnight.[2]
• Connecticut. The Secretary of the State publishes the master business table from the Connecticut Business Registry on the state open-data portal with a daily update frequency.[3]
• New York. The Department of State posts an active-corporations dataset monthly, accurate as of the last business day of the month named in the dataset.[4]
• North Carolina. Business registration data is offered through a data subscription service delivered by FTP in CSV format, updated weekly, with a data dictionary on the server.[5]
• Utah. The state offers a full download of the Division of Corporations database through its subscriber program, assessed per record.[6]
• Washington. The state's open-data listing for corporations search states that the Corporations Data Extract feature is no longer available and directs users to export lists from the search tool instead.[7]
• Texas. As of September 24, 2026, SOSDirect charged a statutorily authorized fee per search, metering even single lookups at the source, and its page announced the new SOSPortal going live on September 29, 2026.[8]
Seven states, six delivery models: daily open data, monthly open data, weekly subscription FTP, a full database sold per record, a withdrawn extract, and metered search. Nothing in that list adds up to a national file, and the other forty-four jurisdictions each need the same inquiry.
Why do the state files not add up to one dataset?
Beyond the cadence differences above, identifiers and field sets break any attempt to stitch the files together. Colorado's file keys on an entity ID and carries agent name parts and a principal address.[2] New York's keys on a DOS ID and carries a CEO name and a process address.[4] Connecticut's keys on an account number and carries an annual-report due date and a registration date.[3] None of those identifiers means anything outside its own state.
A normalized response is the alternative to stitching files. In Cobalt's own unpublished measurement on September 11, 2026, three large national companies were searched by name in all fifty states and the District of Columbia, 153 probes in total, each with a 180-second ceiling. All fifty-one jurisdictions returned the same eight fields, including status, normalizedStatus, filingDate, sosId, and confidenceLevel, while officer records came back from 32 of them. One day and three well-formed names show what a state can return, not what it never returns, and set no service expectation. Still, that is what a per-record lookup gives you that a pile of state files does not: one schema, with the gaps marked per state.
What does "no bulk data" mean when a vendor says it?
When a lending-software prospect asked on a 2026 demo call whether the API was the only way to get the data and whether any bulk data existed, Cobalt described a batch tool in which the user uploads a CSV and Cobalt processes it through the same API, and said there is no separate bulk-data product or data dump. Cobalt's public help center confirms that the batch upload tool requires no integration and returns a downloadable CSV of structured results, including entity data and screenshots.[9] The statements that the tool runs the same lookups as the API and that no dump exists came from the call rather than a public document, so confirm the current behavior with Cobalt before relying on them.
The distinction matters for an architecture decision. "Bulk" in Cobalt's usage means many lookups, each keyed to a name or a registration number, each returning a record observed at that moment. It does not mean a file of every entity in a state.
Why Does a File Fail the Use Case Even Where One Exists?
How fast does the underlying data move?
The Census Bureau counted 578,926 business applications in July 2026, seasonally adjusted, and it counts an application as a filing for an employer identification number on IRS Form SS-4.[10] Not every applicant registers an entity with a state, but the pace explains why a monthly or quarterly file ages quickly: anything formed, dissolved, renamed, or re-agented since the cut is missing or wrong in it. A lender funding a business formed three weeks ago may not find it in a monthly snapshot.
Cobalt's cached layer has the same property by design. Its help center states that refresh cadence varies by state, that a few sources refresh only on request or trigger, and that any successful live call also updates the cache.[11] A cache miss only means the entity is not in the cache; it does not prove the entity does not exist at the state.[12]
What audit artifacts does a file lack?
A state file carries no evidence of what the registry showed at the moment your underwriter decided. A live lookup can return a screenshot of the state page, which Cobalt's API reference describes as a short-lived URL,[13] and a Cobalt document link is valid for three days by default, extendable to thirty on request, which is why the artifact has to be copied into your own system at batch time.[14] The record you keep for an examiner is the response you received, with your request key, the time you received it, and the source URL, not a row from a file cut two weeks earlier.
The Cobalt guide on real-time SOS data versus cached registry data works through what goes stale and when. This article stays on the narrower question: given that no official national file exists, how do you process a list.
When is a file still the right tool?
Files suit jobs that tolerate age and need breadth: building a name-matching index, sizing a market by county, seeding a type-ahead list, or reconciling a portfolio against a state's active list once a quarter. For those, the open-data portals above are a sensible source in their states. The moment the job becomes "decide on this applicant today," the file stops being the source of record and becomes, at best, a pre-screen.
What Are the Alternatives Before Choosing a Lookup API?
Can you build against the state programs directly?
Yes, for the states that publish, but each difference above becomes code you maintain: a parser and a schema mapper per state, a scheduler per cadence, a fee account where the state charges, and a monitor that notices when a program disappears, as Washington's open-data listing recorded in 2024.[7] Cobalt's own account of how it decides which state datasets to add, weighing engineering and ongoing maintenance against lookup volume, describes the same cost from the vendor's side.[15]
What do licensed datasets and scrapers offer?
Two other approaches exist. Licensed entity datasets and periodic feeds from commercial providers trade freshness for breadth and convenience, and the buyer inherits the licensor's refresh cycle and schema. In-house scrapers against state search pages give control at the cost of maintenance every time a state changes its site. Cobalt's help center describes state sites that refresh frequently, load slowly, and use CAPTCHAs, and recommends the callbackUrl pattern for resilient integrations; a team running its own scrapers absorbs those behaviors directly.[16]
What does a per-record lookup change?
A per-record lookup inverts the model. Instead of receiving everything and searching locally, you send a key and receive one observation at a known time, with a confidence score and, when requested, a screenshot. Cobalt's public API reference documents that request and response surface.[13] The cost shows up as latency and per-record metering rather than as a file to parse, which is why the design of the batch, not the existence of one, decides whether the approach works.
The rest of this guide uses the Cobalt SOS API as the worked example, because its public help center documents the batch behaviors an engineer has to plan around. The same design questions apply to any per-record registry API. Cobalt is a data source; the match rules, thresholds, and dispositions described below belong to you.
How Does Batch Processing Actually Work on a Lookup API?
What does one lookup return?
A single-state lookup takes a business name or a state registration ID plus a state code[17] and returns the entity record: status, normalized status, filing date, registered agent, addresses, officers where the state publishes them, a confidence level, possible alternatives, and an optional screenshot URL.[13] Cobalt's own sources disagree on where that ID path works. The API reference documents sosId as a general search input,[13] and the help center says a state plus registration ID scopes the lookup to that exact record, with no search for similar entities.[18] Cobalt's public fields-by-state spreadsheet, however, marks its searchBySosId row for only Florida and Mississippi.[19]
How does a CSV batch differ from a data dump?
A batch is a list of inputs, not a list of outputs. The required-fields guidance says batch uploads should add street, city, and ZIP when available, and warns that those values must be exact because typos may cause false negatives.[17] The API reference describes street, city, and zip as AND filters over the top ten name-search results, each checking the physical, then mailing, then agent address for the value passed, so they only narrow a name search.[13] The fields-by-state spreadsheet marks its searchByAddress row for 49 of 52 jurisdictions, all but Delaware, DC, and Puerto Rico.[19] Larger batch runs still return live data unless you choose cache mode.[20]
CSV itself is a thin format. RFC 4180 defines the delimiter, quoting, and line rules, not what any column means.[21] Your batch file therefore needs a documented column contract: which column is the raw client input, which is the validated legal name you actually searched, and which is the registration ID. Cobalt recommends keeping the validated name actually used as its own column so runs are reproducible and normalization lift can be measured.[22]
How do asynchronous lookups fit a batch?
Live state lookups do not finish on a uniform clock. Cobalt's help center says that when a state takes longer than about twenty seconds, the API returns an Incomplete response with status code 202 and a retryId while the search keeps running; you either poll with that retryId or supply a callbackUrl, in which case Cobalt replies immediately with a requestId and later POSTs the finished result to your endpoint with the same requestId.[23] The public API reference describes the same retryId path for requests that take longer than thirty seconds,[13] so build the worker to handle a 202 whenever it arrives rather than around a fixed threshold. For large runs, Cobalt's guidance is to prefer the callback so slow states do not tie up HTTP threads, to use retryId polling if you have no webhook yet, and to expect variance by state.[24]
Expect variance by state (e.g., IL is slower); design queues with backoff and idempotency.
That sentence from Cobalt's batch guidance is the job description for the batch worker.[24] The September 11 measurement described above shows the spread. Of its 153 probes, 110 returned a live record in 1.51 to 170.27 seconds, with a median of 15.01; three returned Nevada records from the cache while that state's site was down for maintenance; 19 completed with no exact match; and 21 did not finish inside the 180-second ceiling. A ten-thousand-row batch is not a loop; it is a queue with a long tail.
How Should an Engineering Lead Design the Batch Run?
What is the unit of work and its key?
Make the unit of work one row keyed by state plus normalized name, and store the registration ID the state returns once the row resolves. That ID is the state's official registration number, unique within its jurisdiction,[25] so state plus ID identifies the entity in later runs. Search by the ID only in states where you have confirmed an ID lookup works; elsewhere the row stays a name search, which can return alternatives and should carry your disambiguation rule. Cobalt's guidance for messy inputs is to run a second cleaned pass with normalized names and locality, measure the lift against the raw pass, keep a small gold set of known answers, and drive decisions with your own thresholds.[26]
How do you handle rate limits, retries, and partial completion?
Three rules cover most failures. First, respect the endpoint throttle. Cobalt returns HTTP 429 on extreme spikes, such as hundreds or thousands of requests in a second, while normal bursts of five to fifty or more are queued and processed steadily.[27] RFC 6585 defines 429 as the signal that a user has sent too many requests in a given amount of time, and allows the response to carry a Retry-After header saying how long to wait.[28] Second, retry with backoff and make the operation idempotent. AWS's retry-with-backoff guidance says operations should be idempotent when you use the pattern, because otherwise partial updates might corrupt the system state.[29] A keyed row makes idempotency simple: a repeat of the same key either returns the stored result or adds a newer observation beside it.
Third, treat partial completion as the normal end state of a run, not an error. Some rows will be complete with a record, some complete with no exact match and an alternativeResults list, some incomplete with a retryId, some waiting on a callback, and some failed. Persist all five states per row. The API reference documents the no-exact-match response as Complete, with a list that may be empty,[13] and 19 of the 153 probes in the September 11 measurement ended that way. Route those rows to review under your disambiguation rule, and let a second pass sweep the incomplete, waiting, and failed rows rather than restarting the file.
What does the customer-owned record look like?
The record you store is yours, not the vendor's schema. The example below is an illustrative, customer-owned batch row with synthetic identifiers. It borrows field names the Cobalt response uses, such as requestId and retryId for asynchronous completion and normalizedStatus and confidenceLevel from the result, and wraps them in your own keys and policy fields.[13] The two asynchronous fields stay null here because this row came back from a cache pass.
{
"batchId": "sos-refresh-2026-09-24-a",
"rowKey": "tx|example-entity-0001-llc",
"input": {
"searchQuery": "EXAMPLE ENTITY 0001 LLC",
"state": "tx",
"liveData": false
},
"attempt": 1,
"requestId": null,
"retryId": null,
"status": "complete",
"receivedAt": "2026-09-24T14:02:11Z",
"provider": {
"title": "EXAMPLE ENTITY 0001 LLC",
"normalizedStatus": "Active",
"filingDate": "04-02-2019",
"normalizedFilingDate": "2019-04-02T00:00:00.000Z",
"sosId": "EXAMPLE-0000001",
"stateOfSosRegistration": "TX",
"confidenceLevel": 0.97,
"updatedAt": 1788059400000,
"screenshotUrl": null
},
"policy": {
"matchRule": "batch-v3",
"disposition": "accept",
"needsLive": false
}
}The policy block is where your rules live. Cobalt returns a confidence level; you decide what auto-accepts and what goes to review. Cobalt's help center says every cached response includes createdAt and updatedAt so you can judge record age,[30] and the API reference ties them to liveData=false,[13] but the fields-by-state spreadsheet marks them for only 26 of its 52 jurisdictions.[19] You decide the maximum tolerated age for each decision type; send a cached row without updatedAt to the live pass, since its age is unknown.
How Do Cached Mode and Full Verification Fit a Batch?
When does cached mode replace a live pull?
Send liveData=false to force cache-only behavior for a row.[31] Cobalt's batch guidance is explicit about sequencing: when speed matters more than recency, start with cache for breadth, then re-run the rows with no hits live.[24] A cached hit is only as current as its updatedAt value, and a cached miss is not a negative finding,[12] so the cache pass narrows the work rather than closing it. The verification waterfall guide covers the routing logic between the two modes for individual decisions; in a batch, the same logic becomes two passes over one keyed file.
What does Full Verification do when the state is unknown?
Full Verification answers a different question: not "what does Texas say about this name" but "where is this name registered at all." One request fans out across all fifty states and the District of Columbia and returns every registration found, consolidated in one response,[32] and only the business name is required.[17] It runs as an asynchronous job with three documented actions. The initVerification request starts the search in every available state, accepts an optional callback URL that receives the results once all states have run, and returns a searchGuid.[33] The businessStatusCheck request then shows each state's result as it completes, and the API reference warns that the searchGuid must be encoded because its # character will otherwise break the query parameter.[34] The fullStatusCheck request lists all previous and potentially ongoing requests from your API key, and its sosStatus field is the primary status for telling whether a request has fully finished.[35] Cobalt's Full Verification API guide walks through those three actions as its three-step asynchronous pattern and puts a complete result at five to thirty minutes, depending on which state is slowest to respond, so Full Verification belongs at the head of a batch as a state-resolution step for rows with no state, not inside the per-row loop.
What does the full batch look like as a waterfall?
The sequence has five passes. Resolve the state for rows that lack one, with Full Verification or your own data. Run a cache pass over every row. Run a live pass over the misses and over rows whose decision requires freshness or a screenshot. Sweep the incomplete rows through retryId polling or callbacks. Reconcile everything into your store with per-row provenance. Every pass writes the same keyed record, and no pass overwrites an earlier observation without keeping it. For teams still moving off manual lookups, the step-by-step automation guide covers the integration mechanics this design assumes are in place, and the guide to automating lookups at scale covers the engineering architecture around them.
What Does Not Exist, and What Should You Confirm Before Building?
Which promises should you not expect?
• An official national file. Registries publish state by state, so no primary source publishes one file of every registered entity in the country, and a licensed multistate dataset is a secondary compilation on its licensor's schedule. Cobalt retrieves records from state sources directly rather than reselling an aggregator's data.[1]
• A file feed from Cobalt. The help center documents an upload tool that returns a results CSV, not a scheduled export of a database.[9] Do not design around a delivery cadence, record count, or file format that no document promises.
• A guaranteed refresh cadence for cached rows. Cadence varies by state, and a few sources refresh only on request or trigger.[11]
• A uniform response time. Cobalt's help center says slower states such as Oregon and Delaware may require up to five minutes on a live lookup.[36] In Cobalt's September 11 measurement, all three Delaware probes returned a record in 13 to 20 seconds. One Oregon probe returned a record in about 30 seconds, and the other two completed with no exact match. Set a row's stall threshold no lower than the help center's figure, and treat the measurement as one day's observation, not a service level.
• Officer data everywhere. Officers came back from 32 of 51 jurisdictions in Cobalt's September 11 measurement, and Cobalt describes officer records as public registry information rather than validated identity proof.[37]
• A decision. Cobalt returns the record and a confidence level; the accept, review, and reject thresholds stay with you.[26]
Which state-level limitations carry into every batch?
Delaware's online entity status is a paid request at the state.[38] Cobalt states that it works in states that require paid access, such as Texas,[39] so ask how state-level fees are handled, including after the Texas SOSPortal launch, before you size a Delaware-heavy or Texas-heavy batch. Fields vary by state; Cobalt offers a downloadable spreadsheet of which fields each state returns, and a batch schema should be built from that list rather than from one state's sample response.[40] Cobalt's sources disagree on screenshots: the API reference says they are not yet available in all states,[13] the help center says they are available from every state,[41] and the spreadsheet marks screenshotUrl for all 52 of its jurisdictions,[19] so confirm capture with Cobalt for your batch's states before a design relies on a screenshot.
What should you bring to an integration review?
Bring five things: a sample file of real inputs with their messiness intact, your key strategy, your tolerated record age per decision type, your callback endpoint or polling plan, and the retention rule for the responses and screenshots you will store. Sandbox mode accepts test parameters and returns dummy responses so developers can validate requests and integration flow before live use,[42] and the API reference lists test values for complete, incomplete, failed, retryIdInvalid, and badRequest outcomes.[13] For request-log retention and security controls, request Cobalt's current security documentation. The Top 34 questions about the Secretary of State API page answers questions about the API beyond batch design. To check your batch design against current API behavior, schedule a workflow and integration review.
Re-probe the state programs you depend on each quarter. The inventory above was accurate on September 24, 2026, and Washington shows how quickly one entry can change.
.jpg){kind=small}
.png)