How Long Does Business Registration Verification Take by State?

Executive Summary: A business registration verification is not one operation with one duration. It is fifty-one separate operations against fifty-one separate state systems, and the spread between the fastest and the slowest is roughly thirty to one. Most states answer a live lookup in 10 to 30 seconds. Oregon can take up to five minutes. That spread is small enough to ignore in a demo and large enough to break an underwriting SLA, a request timeout, and a borrower conversation in production. This post covers what timing to plan for by state class, how the slow tail should shape your service levels and queueing decisions, and when to say something to the borrower.

How Long Does a Live Registration Lookup Actually Take by State?

Start with the numbers you can plan against. On a live lookup, most states return in 10 to 30 seconds. Delaware typically takes 15 to 30 seconds. Oregon can take up to five minutes. A cached lookup returns in under a second in every state, at the cost of freshness, because the cached copy is on a monthly refresh cycle rather than pulled at request time.

Those four facts produce three planning classes rather than fifty-one individual numbers.

• Sub-second class. Any cached lookup, in any state. Response is immediate and the record is as current as the last monthly refresh.

• Standard live class. The large majority of states, returning in 10 to 30 seconds against the state's own site.

• Slow live class. States whose systems respond in minutes rather than seconds. Oregon is the reference case at up to five minutes.

Design for three classes and you can write one integration. Design for an average and you will build something that works for forty-nine states and pages your on-call engineer for the other two.

Why Is There No Single National Answer?

Because there is no single national registry. The National Association of Secretaries of State describes the arrangement plainly: "Most NASS member offices handle the registration of domestic and/or foreign corporations (profit and non-profit)," and "Fees vary from state to state."^[1] Each state runs its own filing office, its own search portal, its own uptime, and its own performance profile. An aggregating API normalizes the output of those systems. It cannot normalize how fast they respond.

Some states also meter the search itself. Texas charges "a $1.00 statutorily authorized fee associated with each search, which supports the ongoing operations and enhancements of SOSDirect."^[2] That is a cost line rather than a latency line, and it belongs in the same planning conversation because both are per-state properties that a single credit price hides.

Why Does One State Answer in Seconds and Another in Minutes?

The honest answer is that state response time reflects state infrastructure, and states buy infrastructure on their own budgets and their own schedules. You get no vote and no roadmap.

You do get evidence of how each state values speed internally. Delaware sells turnaround as a priced product on the filing side, with one-hour service at "$1,000.00 Completed within one hour of receipt. Filing must be received by 9:00pm EST or EDT," two-hour service at "$500.00," same-day service that "ranges from $100.00 to $200 for filings," and next-day service that "ranges from $50.00 to $100 for filings."^[3] A state that prices one hour of filing turnaround at a thousand dollars is telling you that speed is a scarce resource in its operation. Public search infrastructure is a separate system from the filing counter, and none of those tiers apply to a lookup, but the pricing is a useful signal about where a registry's capacity actually sits.

What Should You Assume About a State You Have Not Tested?

Assume standard class, verify before you rely on it, and never let an untested state reach a synchronous code path. The practical rule for a new state going live is to run a hundred lookups drawn from your own book against it and record the full distribution. Averages will tell you the state is fine. The 95th percentile tells you what your customers will experience on a bad afternoon, and the maximum tells you what your timeout has to survive.

What Timeout Should Your Application Set for a State Lookup?

This is where slow states stop being a data problem and start being an availability problem, because the default timeouts in common infrastructure are all shorter than a slow-state lookup.

• Heroku's router terminates a request "if it takes longer than 30 seconds to complete," returns an error page to the client, and emits an H12 to your logs.^[4]

• AWS Application Load Balancer sets `idle_timeout.timeout_seconds` with a documented default of "60 seconds."^[5]

• nginx as a reverse proxy defaults `proxy_read_timeout` to `60s`, and if "the proxied server does not transmit anything within this time, the connection is closed."^[6]

• Cloudflare returns error 524 when "Cloudflare successfully connected to the origin web server, but the origin did not provide an HTTP response before the default 125 seconds."^[7]

• A five-minute Oregon lookup exceeds all four of those defaults, which means a synchronous design does not fail occasionally in Oregon. It fails structurally.

Read that list as a stack rather than as options. A request that crosses Cloudflare, then an ALB, then nginx, then an application dyno inherits the shortest timeout in the chain, and the borrower-facing error is produced by whichever layer gives up first. Heroku's documentation adds the failure mode that makes this expensive to debug: after the router returns the error, "your application will not know that the request it is processing has reached a time-out, and your application will continue to work on the request."^[4] You have spent the credit, the state has done the work, and nobody wrote down the answer.

So the Slow States Have to Come Off the Request Path Entirely

They do, and the SOS Search API supports that with a `callbackUrl` parameter for delivery on completion and a `retryId` for retrieval of a result that was still running when you last asked. The endpoint design, retry semantics, and signature handling for that pattern are covered in the published async webhook architecture guide for long-running SOS lookups, and this post does not repeat that material. What belongs here is the timing decision that comes before the architecture: which states you route asynchronously, and what latency budget justifies the extra machinery.

The threshold most teams land on is your shortest infrastructure timeout minus a safety factor. If the shortest hop in your stack gives up at 30 seconds, anything you expect to exceed roughly 20 seconds belongs on the async path, which puts the slow class there permanently and part of the standard class there during state-side slowdowns.

How Should Slow States Change the Way You Queue Verification Work?

Once slow states are off the request path, the next decision is queue shape, and this is where most teams lose throughput without noticing.

The failure is head-of-line blocking. A single work queue processing verification jobs in arrival order will spend five minutes on an Oregon entity while ninety Texas and California entities wait behind it. Throughput collapses to the speed of the slowest member of each batch even though the fast states are idle.

Partition by state class instead of by arrival time.

• Run a separate queue per timing class, with the slow class getting its own workers and its own concurrency limit so it cannot starve the fast lane.

• Size concurrency by class, not globally. The fast queue is bounded by your own rate limits. The slow queue is bounded by how many outstanding state sessions you are willing to hold.

• Give each class its own retry budget. A retry in the standard class costs seconds. A retry in the slow class costs minutes and a credit, so retry once and escalate rather than retry three times on a timer.

• Key every job to the state's own identifier where you have one, so a duplicate submission collapses instead of buying the same answer twice.

• Batch by state, then by portfolio, because grouping work by the system you are calling makes the tail visible in your metrics rather than smeared across every batch.

The sequencing rule that follows from all of this: pre-screen the whole batch in cached mode first, in under a second per entity, and reserve live lookups for the entities where the cached answer is missing, stale, or decision-relevant. That is the waterfall pattern, and it is the single largest lever on both wall-clock time and credit spend for portfolio work. Our sibling post on automating filing status updates via API covers the recheck cadence side of the same problem.

Does Any of This Change for a One-Off Underwriting Decision?

Yes, in the direction of accepting the latency. A single pre-funding verification on a deal that has been in process for four days does not need a queue. It needs a live lookup, a screenshot for the file, and a human who has been told that this particular state takes a few minutes. Queue engineering is a portfolio problem. Deal-level verification is a patience problem, and the patience is cheap when it is paid once.

What Does State Latency Do to Your Underwriting SLA?

An SLA written as "verification completes in under a minute" is a promise about the fastest forty-nine states and a guaranteed breach in the slowest two. Write the service level the way the data actually behaves.

State the target per timing class, and publish the mix. If Oregon is 0.4 percent of your funded volume, a five-minute worst case there is a rounding error in your blended number and a hard breach in a flat SLA. If a slow state carries 8 percent of your originations, it belongs in the headline number with its own line. The arithmetic is unglamorous: weight each state's p95 by that state's share of your volume, sum the products, and publish that instead of an average of state averages.

Speed matters here for a reason that shows up in the demand data. The Federal Reserve's Small Business Credit Survey reporting notes that "the share that applied at online lenders increased for the fifth consecutive survey year," while also finding that among firms that borrowed from online lenders, "60% reported higher-than-expected borrowing costs."^[8] Applicants are choosing the faster channel in growing numbers and then reporting that the experience did not match what they expected. A verification step that silently stalls is a small contribution to that gap, and it is one of the few contributions that is purely an engineering choice.

Two cost facts belong in the same model, because they change which lookups you can afford to run live rather than cached. Delaware's 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 returning "the status, the last 5 filings, franchise tax assessment, total authorized shares (if applicable), and tax due."^[9] Cobalt passes that state fee through at cost rather than marking it up, and it is a state-imposed charge rather than a vendor surcharge. New Jersey status data sits behind a records service whose Status Report "Lists registered agent, business addresses, filing date, date last annual report filed, officer/directors/managers and legal status (active, dissolved, merged, etc.)."^[10] Slow and paid are different constraints, and a state can be both.

The teams that miss their verification SLA are rarely the ones with the slowest states. They are the ones who wrote a single number for fifty-one different systems and then discovered which two of those systems they had described incorrectly.

For the field-level and coverage-level version of this same per-state analysis, our SOS API data coverage by state checklist scores states on field depth and freshness alongside latency, and the pillar comparison of top Secretary of State API solutions for verifying businesses covers how the vendor field sorts on those axes.

When Should You Tell the Borrower Anything About a Verification Delay?

Borrower communication is a timing decision, and treating it as a support decision is how a four-minute lookup becomes a lost deal.

Set thresholds in the workflow rather than in someone's head.

• Under 30 seconds: say nothing. A spinner is sufficient. Narrating a normal wait teaches the applicant that something is fragile.

• 30 seconds to two minutes: acknowledge without diagnosing. Tell the applicant the state registry is being checked directly and that some states respond more slowly. Do not name a completion time you cannot hold.

• Beyond two minutes: move the applicant off the wait. Let the rest of the application continue and deliver the verification result out of band. Nothing about a slow state should block a document upload.

• On failure: never route the wording through blame. The applicant did not cause a state timeout, and a message implying their information was wrong generates a support ticket and a trust problem at the same time.

• On completion: record the timestamp, not the impression. A timestamped screenshot of the state page is the artifact that proves when the record was read, and Cobalt's screenshot URLs remain downloadable only for a limited window of 3 to 30 days, so the file has to pull and store the image rather than store the link.

What Should an Internal Handoff Say That an External Message Should Not?

Internally, name the state and the class. "Pending, slow state, expected within five minutes" tells an underwriter to move on and come back. "Verification pending" tells them nothing and produces a status-check message to engineering. The internal note should also carry the request identifier so that a stalled job can be traced without re-running the lookup and spending a second credit on an answer you already bought.

How Do Registry Processing Backlogs Change What "Verified" Means?

There is a second clock, and it is slower than the first by orders of magnitude. Your lookup measures how long the state takes to answer. It does not measure how long the state took to record what the business actually did.

The states publish this themselves. As of August 6, 2026, Oregon listed online business registry filings at "1-3 Business Days" and had processed mail and fax business registry filings only through "7/29/2026."^[11] California's processing dates page on the same date showed corporate and LLC filings processed to "Online 08/05/2026," "In Person 08/03/2026," and "Mail 07/31/2026."^[12] New York states that "The information available through this site is updated daily."^[13]

So a thirty-second live lookup in Oregon can return a perfectly current read of a registry that is itself a week behind on paper filings. The two layers of freshness that this creates, vendor-to-state and state-to-reality, are covered in the coverage by state checklist, and the real-time versus cached registry data comparison covers what goes stale and when. The timing consequence for this post is narrow and worth stating on its own: a fast answer is not a current answer, and a very recently formed or recently amended entity is the case where your lookup speed matters least. Our guide to verifying business registration status via API walks the status interpretation step that follows.

How Do You Measure Verification Timing in Production?

Measure per state, measure the tail, and exercise the slow branch deliberately rather than waiting for a real slow state to teach you.

Deterministic test modes are how you build the timing handlers before you own the traffic. The `test` parameter accepts `complete`, `incomplete`, `failed`, `retryIdInvalid`, and `badRequest`, which lets a continuous integration suite exercise each branch without burning credits or waiting on a live state system.

curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=oregon&liveData=true&test=incomplete' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'

Then instrument the real path. Every completed response carries the fields you need to attribute time correctly.

{
  "status": "complete",
  "statusCode": 200,
  "requestId": "abc123-def456",
  "results": [
    {
      "title": "ACME CORPORATION",
      "filingDate": "2015-03-15",
      "stateOfFormation": "Delaware",
      "status": "Active",
      "entityType": "Corporation",
      "sosUrl": "https://icis.corp.delaware.gov/ecorp/...",
      "screenshotUrl": "https://screenshots.cobaltintelligence.com/..."
    }
  ],
  "possibleAlternatives": []
}

Log `requestId` against your own job identifier and the state you queried, and your latency data becomes per-state automatically. Track p50, p95, and p99 by state, alert on the completion rate rather than on latency alone, and keep the maximum in view, because the maximum is what sets your timeout.

Which Timing Metrics Actually Change a Decision?

Four of them. The per-state p95 sets the SLA line for that state. The per-state maximum sets the timeout and the async threshold. The share of lookups that finish in the standard class tells you whether a state has degraded before your customers report it. And the ratio of cached pre-screens to live lookups tells you whether your waterfall is doing its job or whether the pipeline has quietly gone all-live and taken your credit spend with it.

An SOS API is a data source rather than a decisioning engine, and timing discipline does not change what the data can answer. It answers whether the entity exists, in what status, since when, and under whose agent and officers, with officer availability varying by state because some states publish that information and others do not. It does not answer whether the EIN matches, whether liens exist, or whether the principals appear on a sanctions list. What per-state timing discipline buys is the ability to put that answer inside a decision window you can promise and keep. The state that takes five minutes is not a vendor defect and it is not going to get faster because you asked. It is a fixed property of the system you are querying, and the teams that plan for it explicitly stop being surprised by it.