Full Verification API: One Call to Search All 50 Secretary of State Databases [2026]

Executive Summary: A full verification API solves one specific, recurring problem in business lending: an applicant submits a legal name, but the lender does not know where the entity is registered. Querying 50 Secretary of State systems one by one is expensive, slow, and operationally fragile. A full verification API collapses that search into a single request, returns consolidated results from every jurisdiction, and exposes multi-state registrations that single-state lookups miss. This resource explains what the API does, when to use it, how it compares to single-state queries, and the honest limitations lenders should plan around.

What Is a Full Verification API and When Do Lenders Need One?

A full verification API searches every U.S. Secretary of State database, plus the District of Columbia, in one call. It is a nationwide business entity verification tool built for workflows where the state of registration is unknown or where the applicant may be registered in several jurisdictions. The underwriting team does not have to pick a state upfront. The system searches all of them and returns matched entity records wherever they appear.

The use cases cluster into three categories. Trade credit teams see applications from buyers whose corporate registration state is not on the invoice.^[1] National alternative lenders and MCA providers receive merchant applications where the operating address differs from the registration address. Insurance underwriters and acquisition due diligence teams often need to confirm a target's full geographic footprint, including foreign-entity registrations that reveal where revenue is actually generated.^[2]

The common thread: the lender has the business name but not the state. Single-state lookups force a guess. A full verification API removes the guess.

Who Actually Buys This Capability?

Buyers fall into two roles. Risk and compliance leaders purchase for coverage: they need assurance that a KYB check examined every jurisdiction, not just the one the applicant wrote on the form. Engineering and operations leaders purchase for scale: maintaining scrapers or vendor integrations across 51 separate state systems is a staffing problem nobody wants to own.

Why Does the "Unknown State" Problem Break Standard Underwriting?

Single-state verification assumes the lender knows where the business is registered. In a clean application, that is true. Most applications are not clean.

Three patterns recur in underwriting review:

• The applicant writes an operating address, not a registration state. A Delaware LLC with a New York mailing address will not match when the underwriter queries only New York.

• The applicant lists the wrong state deliberately or by accident. Review of business credit fraud cases shows that inconsistent state data is a documented signal in MCA underwriting.^[3]

• The applicant is registered in multiple states. Franchise operations, interstate contractors, and trucking businesses are often formed in one state and registered as foreign entities in several others. A single-state query misses most of them.^[4]

When the verification step fails or returns a "not found" response, the underwriter has a choice: reject a potentially legitimate deal, send a manual research task back to the analyst queue, or approve without verification and accept the fraud risk. Each path costs money. A full verification API eliminates the branch point by confirming on the first call whether the business exists anywhere in the country.

"Inconsistencies between claimed and recorded state of registration are among the most reliable early signals of misrepresentation in small business credit applications." A recurring observation across MCA underwriting reviews and industry fraud reports.^[3]

How Does Full Verification Differ from Single-State SOS API Lookups?

Both products pull from the same primary source: live data from state Secretary of State websites. The difference is query shape and cost.

The cost comparison is not as one-sided as the credit difference suggests. If a lender queries 50 states individually, that is 50 credits per business. Full verification does the same work for 3. For teams that already know the state, single-state is cheaper. For teams that do not, full verification is 16 times more efficient per exhaustive nationwide search.

What Data Points Does the Full Verification API Return Across All 50 States?

Each jurisdiction that returns a match contributes the same data fields as a single-state SOS API call. Results are normalized so the downstream model does not need state-specific parsing logic.

Every matched state returns:

• Legal business name. Exact name as recorded in the state registry.

• Registration status. Raw state value (Active, Good Standing, Admin Dissolved, Forfeited, etc.).

• Normalized status. Cross-state label so a model can treat every state's "Active" equivalent as one value.

• Formation date and last filing date. Useful for flagging newly formed or dormant entities.

• Registered agent details. Agent name and address, often a commercial registered agent service.

• Principal and mailing addresses. The addresses on file with the state, which may differ from the application.

• Officer names. Where the state publishes them. Not every state does.

• Entity type. LLC, corporation, partnership, foreign entity, etc.

• State of formation. The "home" state versus foreign registrations.

• Confidence score per match. Used to disambiguate when multiple entities have similar names.

For multi-state registrations, the response includes one record per state. A business registered in Delaware and operating as a foreign entity in California and New York returns three records, each with its own address and status.

Why the Normalized Status Field Matters

Every state uses different vocabulary. Texas says "In Existence." Delaware says "Good Standing." California says "Active." A lender writing rules against raw status fields has to maintain a lookup table for all 50 states. The normalized status field collapses those 200-plus raw values into a consistent set an underwriting model can reason about without custom code per state.^[5]

How Do You Integrate Full Verification Into an Underwriting Workflow?

Full verification runs on a three-step asynchronous pattern. The request to initiate looks like this:

POST /fullVerification
x-api-key: YOUR_API_KEY
Content-Type: application/json

{
  "action": "initVerification",
  "businessName": "Acme Corporation",
  "callbackUrl": "https://yoursite.com/callback"
}

The response returns a `searchGuid`. The integrator then either waits for a POST to the callback URL when the search completes, or polls two status endpoints: `businessStatusCheck` for per-state results, and `fullStatusCheck` for overall progress.

The most common integration error is failing to URL-encode the `searchGuid`. It contains a `#` character that must be encoded as `%23` in all subsequent GET requests. Unencoded, the query parameter truncates at the hash and the API returns an empty result set.

Where Does Full Verification Fit in the Underwriting Timeline?

Because the API takes 5 to 30 minutes to return complete results, it belongs early in the workflow, not at a blocking decision point. The pattern that works best across Cobalt customers:

• Step 1. Application received. Initiate full verification immediately, fire-and-forget.

• Step 2. Run parallel workstreams. Bank statement analysis, credit pulls, and ID verification proceed without waiting.

• Step 3. Verification callback arrives. Results merge into the underwriting file.

• Step 4. Risk model runs with complete entity data, including any multi-state registrations the applicant did not disclose.

• Step 5. Approval, decline, or manual review queue.

Lenders attempting to wait synchronously on full verification results will see processing stall on edge-case states. Alabama, Hawaii, and Washington are consistently slower than Delaware, Texas, and California. The callback pattern is not a nice-to-have; it is the design assumption.

When Should You Use Full Verification vs Building a Multi-State Query Layer In-House?

Several lending teams have attempted an in-house build. The pattern is familiar: a small engineering team scopes a six-month project, ships a prototype covering five states, then discovers the tail states are where the work lives.^[6]

The build-in-house cost surface has five components most estimates miss:

• Initial scraper development. Fifty state websites, each with its own form structure, CAPTCHA behavior, and rate limits.

• Ongoing maintenance. States push UI changes several times per year. Each break halts verification for that state until a developer reworks the scraper.

• Paid data sources. Delaware and a handful of other states charge $15 to $25 per status lookup. These are not optional; those states do not publish free data.

• Infrastructure. Headless browser fleets, IP rotation, proxy management, and retry logic for state systems that time out intermittently.

• Compliance documentation. Auditors expect evidence that each query hit the primary source at a specific timestamp. Building that audit trail is its own subsystem.

A full verification API moves all five line items off the internal roadmap. The calculation that matters is not "API cost versus engineer cost this month." It is "API cost versus the multi-quarter roadmap slot an in-house build consumes, plus the ongoing headcount it requires after launch." Cobalt customers who previously ran in-house state scrapers have documented maintenance cycles consuming 20 to 40 engineering hours per month before switching.^[7]

What Are the Honest Limitations of Cobalt's Full Verification API?

Five constraints every buyer should factor into their evaluation.

• Processing time is 5 to 30 minutes. Not suitable for workflows that need a verification answer inside the first minute of an application.

• Cost per call is higher. 3 credits per full verification versus 1 for a single-state SOS API call. For high-volume workflows where the state is known, single-state lookups remain more cost-efficient.

• URL encoding is non-obvious. The `searchGuid` contains a hash character that breaks query parameters if not encoded. This is the most common integration support ticket.

• Officer data coverage is state-dependent. Some states publish officers; others do not. Full verification returns what exists; it does not invent what the state withholds.

• Verification confirms existence, not financial health. A business can be active, in good standing, and still be a poor credit risk. Verification is one input in a broader underwriting decision, not a standalone approval signal.

Cobalt positions the full verification API as a data source in a verification stack, not as a decisioning engine. The stack typically pairs it with TIN/EIN verification for identity, UCC filings for collateral visibility, and OFAC screening for sanctions.^[8]

How Does Full Verification Compare to Middesk, CSC, and Wolters Kluwer?

Three vendor categories show up in lender evaluation cycles. Each solves an adjacent problem differently.

Cobalt sits in a separate row because the product is not a KYB platform. It is the verification data layer that KYB platforms, lending systems, and compliance teams plug into their own decisioning logic. The platforms above all do something Cobalt does not, which is own the end-to-end workflow. Cobalt does something they do not, which is serve primary-source SOS data with timestamps suitable for audit trails, at API speeds, with direct state coverage.

The honest answer for most alternative lenders: pick a KYB platform for case management if that is missing, and plug Cobalt in for the underlying verification data the platform needs as input. Teams already running their own underwriting stack usually skip the KYB platform entirely and integrate Cobalt directly.^[9]

What Should the Evaluation RFP Actually Ask?

Generic RFP questions like "do you support all 50 states" or "can I run a test applicant" are table stakes and do not differentiate vendors. Five questions that surface real differences:

• Data freshness guarantee. When my underwriter queries at 10:32 a.m., did the answer come from the state system at 10:32 a.m. or from a cached snapshot taken last Thursday?

• State-by-state coverage fidelity. For the ten states I care about most, show me exactly which raw status values you return and how you normalize them.

• Audit trail format. What evidence do you return that proves the query hit the primary source, and will my compliance auditor accept it?

• Multi-state match reconciliation. When a business shows up in five states, how do you help me decide which registration is authoritative?

• Reference at my volume tier. Not "we work with large lenders." Which specific lender at 10K to 50K monthly verifications will take my call?

The RFP that fails to ask these questions ends up comparing vendors on logos and sales decks rather than on the properties that matter when an underwriter is sitting in front of the screen at 2 a.m. on a Sunday.

For a broader comparison framework covering single-state and full verification scenarios together, see the Business Verification APIs guide for alternative lenders. For lenders evaluating where verification sits inside a larger KYB stack, the TIN/EIN verification API resource covers the identity-matching layer that pairs with full verification. For teams weighing the full build-versus-buy decision, the SOS API vs building in-house cost comparison walks through the maintenance math in detail.