How to Verify Business Registration Status via API

Executive Summary: Most guides to business registration verification stop at "call the endpoint and read the status field." That is the easy part. The hard part is what the status means in a state whose vocabulary nobody else uses, what your system does while a state takes four minutes to answer, and what you can show eighteen months later when the decision is questioned. This walks the full path, from first lookup to stored artifact.

What does verifying business registration status via API actually involve?

It involves four distinct operations that get collapsed into one sentence and should not be.

A registration status check is usually described as a single call. In practice it is a lookup, an interpretation, a wait, and a record, and each one can fail independently. A lender that builds only the first has automated the fastest part of the job and left the other three to a human.

The four operations, separated:

• Resolution. Turning whatever the applicant typed into an identified entity in a specific state's registry. This is a matching problem, not a retrieval problem, and it is where most volume is lost.

• Interpretation. Turning the state's status vocabulary into something your credit policy can act on. Fifty registries do not agree on what to call an entity that has stopped filing.

• Latency handling. Deciding what your system does while a slow state is still thinking. Some states answer in ten seconds and some take minutes.

• Evidence capture. Storing proof of what the record said at the moment you decided, in a form that survives the record changing afterward.

Skip any one and the workflow has a hole in it. Skip evidence capture and the workflow is fast, automated, and undefensible.

The Secretary of State API comparison covers vendor selection. This article assumes that choice is made and covers implementation.

Should you search by business name or by entity ID?

By entity ID whenever you have one, and the reason is not convenience. It is that name search and ID search fail in different directions, and only one of those failure modes is safe.

An entity ID search is a lookup against a primary key. It either resolves or it does not, and a wrong ID almost never returns a plausible wrong entity. A name search is a matching operation against a registry that may hold several confusingly similar names, and its failure mode is returning the wrong business with high apparent confidence. In underwriting, a clean miss is recoverable. A confident wrong match is not, because nothing downstream flags it.

The Cobalt Secretary of State API accepts either, plus two other paths:

• `searchQuery`. The business name. The most common entry point because it is what applications collect.

• `sosId`. The state-issued entity identifier. The most precise option when the applicant supplies it or a prior lookup captured it.

• `searchByPersonFirstName` and `searchByPersonLastName`. Finds entities associated with an individual, which is the path for owner-first workflows rather than entity-first ones.

• `street`, `city`, and `zip`. Address filters that narrow results in high-volume states rather than acting as a search key on their own.

• `state`. Required on every search unless you are retrieving a previous result by `retryId`.

A sequencing rule follows. Search by name once, capture the `sosId` from the result, store it against the borrower record, and use the ID for every subsequent check. The first lookup pays the matching cost once, and every recheck after that is a primary-key read, which removes match risk from the recurring part of the workflow.

What do you do when the name does not resolve cleanly?

You read the alternatives instead of retrying the same string.

When the exact match is uncertain, the response includes up to ten close matches in `possibleAlternatives`, covering abbreviations, punctuation variants, and common misspellings. Every result also carries a confidence score from 0.0 to 1.0, and that score should drive routing rather than a human eyeballing the list. Most customers auto-accept at 0.8 and above, queue 0.5 to 0.79 for review, and treat anything below 0.5 as a different business.

A no-result response is not proof the business does not exist. It commonly means the name is spelled differently in the registry, the entity is registered in a state other than the one searched, or the filing is too recent for the state database to reflect it. Oregon's own guidance puts online business registry filings at one to three business days to process,^[1] so an entity formed on Monday may legitimately be absent from a Tuesday lookup. Treating that absence as a decline is a real source of preventable false negatives on newly formed borrowers.

How should you interpret the status field across fifty states?

Carefully, and with the understanding that the word the state returns is a summary of a filing history rather than a verdict on the business.

Status vocabulary is not standardized across registries. "Active" in one state maps to "In Good Standing" in another and to the absence of a delinquency flag in a third. Normalizing those values is what makes automated decisioning possible, because credit policy cannot be written against fifty vocabularies. The Cobalt API returns the state's own status string and a normalized status alongside it, so policy runs on the normalized field while the raw value stays available for anyone auditing the decision.

The deeper issue is what the status is measuring. In most states, an adverse status is the downstream consequence of an administrative failure, not a finding about the business. Texas illustrates the chain plainly: the franchise tax report is due May 15, and an entity that does not file can receive a Notice of Intent to Forfeit Right to Transact Business followed by a Notice of Forfeiture of Registration, restored only after the delinquent reports and any taxes, penalties, and interest are settled.^[2] Delaware runs a parallel structure, with domestic corporation annual reports and franchise taxes due on or before March 1 and a $200.00 penalty plus 1.5% monthly interest for failure to file.^[3]

Two consequences for how you read the field:

• An adverse status is often a paperwork event, not a solvency event. A profitable business with an inattentive bookkeeper produces the same status string as one that is winding down. The status tells you to look; it does not tell you what you will find.

• Reinstatement can erase the gap retroactively. Florida provides that reinstatement "relates back to and takes effect as of the effective date of the administrative dissolution," and the corporation "may operate as if the administrative dissolution had never occurred."^[4] A borrower that lapsed and reinstated may show a clean current record with no trace of the interval.

• The record is silent on things that never get filed. Texas states there is "no filing requirement with the secretary of state when there is an ownership change" for corporations or LLCs.^[5] An entity can change hands entirely and the registration record will not move.

• Officer data availability varies by state. Some registries publish officer and director detail; others publish none. The API returns whatever the state makes available, so an empty officers array is frequently a state characteristic rather than a data gap.

• A current status says nothing about tomorrow. It is accurate on the day pulled and carries no forward guarantee, which is why point-in-time verification and ongoing monitoring are different products solving different problems.

For state-by-state status vocabulary and what individual terms mean in individual registries, the entity status definition pages hold that detail. The interpretation workflow across states is covered in the sibling post on reading registration statuses across states.

How do you handle states that take minutes rather than seconds to respond?

By deciding in advance that your integration is asynchronous, even though most calls will complete synchronously.

Response times are a property of the state's system, not of the API in front of it. Most states return in 10 to 30 seconds, Delaware runs 15 to 30, and Oregon can take up to five minutes on a live lookup. Past roughly 30 seconds the response comes back with a `retryId` rather than results, and you either poll that ID or supply a `callbackUrl` and receive the results when they land.

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 design mistake is building the synchronous path first and bolting async on when Oregon breaks something. Write every lookup against the async contract from the first line of code and treat the fast synchronous case as the happy path rather than the only path. Retrofitting is expensive because the timeout behavior tends to be buried in whatever HTTP client wrapper was convenient at the time.

A second lever removes most of the latency question. The API supports a cached mode alongside the live one:

The recommended pattern is a waterfall: check cache first for a sub-second answer, then run a live lookup when there is no match or the cached record is stale enough to matter. Reserving live calls for applications that survive triage cuts both latency and credit consumption on the volume that never reaches a funding decision.

Webhook mechanics for the async path are covered in detail in the async webhook architecture guide, and expected timing by state is worked through in the sibling post on verification time by state.

The states that are slow are slow every time. Treat response time as a known attribute of each state rather than as an intermittent failure, and the async design stops feeling like defensive engineering and starts looking like a fixed cost you budgeted for.

What makes a verification defensible after the record changes?

Storing the answer is not the same as storing the evidence, and the difference only becomes visible when someone challenges the decision.

A stored status string is your assertion about what the record said. It is not proof. When the same lookup runs twelve months later and returns something different, the stored string does nothing to establish which of the two was true at decision time. Only an artifact captured from the source at the moment of the decision does that.

The API supports this directly. Setting `screenshot=true` returns a URL to a timestamped screenshot of the actual state page, watermarked with the date and time of verification, with no Cobalt branding on the image. The response also carries `sosUrl`, the direct link to the state's own record, and `requestId`, which ties the response to a specific call in your logs.

{
  "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": []
}

One limitation matters more than any other here, and it is the most common way an audit trail turns out to be missing when it is needed. Screenshot URLs are temporary. They remain valid for download for a limited period, between 3 and 30 days, after which the link stops resolving. A workflow that stores the URL and not the image has stored a pointer that will expire quietly. The screenshot has to be pulled down and written into your own system of record as part of the same transaction that writes the decision.

The practical minimum to persist per verification:

• The full raw response body, not a parsed subset, because the field you did not think to keep is the one the question will be about.

• The `requestId`, which links the stored record back to the API call for reconciliation.

• The downloaded screenshot image, stored in your system rather than referenced by expiring URL.

• The `sosUrl`, which points at the state's own record for independent verification.

• Your own decision timestamp and the policy version applied, so the outcome can be reproduced against the rules that were live at the time.

This is also where the regulatory case sits. The CDD rule requires covered financial institutions to "establish and maintain written procedures that are reasonably designed to identify and verify beneficial owners of legal entity customers," where a legal entity customer includes "a corporation, limited liability company, or other entity that is created by the filing of a public document with a Secretary of State or similar office."^[6] Procedures that are reasonably designed are demonstrated by retained evidence, not by asserting the procedure existed. Lenders inside the scope of the CFPB small business lending rule under Regulation B carry separate recordkeeping obligations on covered applications, with compliance dates extended by interim final rules in June 2024 and June 2025.^[7]

Why does the legal name field matter more than the status field for secured lenders?

Because perfection turns on the exact name, and the registration record is the controlling source for it.

Under UCC Article 9, a financing statement adequately names a registered organization only if it provides "the name that is stated to be the registered organization's name on the public organic record most recently filed with or issued or enacted by the registered organization's jurisdiction of organization."^[8] That is the registration record, which makes the `title` field returned by an SOS lookup the field your filing has to agree with.

An error is not automatically fatal. A financing statement with minor errors stays effective "unless the errors or omissions make the financing statement seriously misleading," and a debtor name error is not seriously misleading if a search under the correct name using the filing office's standard search logic would still disclose the filing.^[9] That safe harbor is narrower than it sounds, because standard search logic in most offices is unforgiving about anything beyond trivial variation.

The timing rule is the one to design around. When a name change renders a filed statement seriously misleading, the filing remains effective for collateral acquired within four months after that point, and an amendment must be filed inside that window to preserve effectiveness for collateral acquired later.^[10] The clock starts at the change, not at the moment anyone notices it, so a verification cadence longer than four months cannot reliably protect the filing. Capturing `title` verbatim on every lookup and diffing it against the name on the financing statement catches this before the window closes.

The registered agent field carries a similar time-boxed signal. In Texas, an agent's resignation terminates the appointment "on the 31st day after the date the secretary of state receives notice."^[11] An entity between agents may not receive service, which is a collectability problem before it is anything else.

Where does the registration check belong in the verification sequence?

First, because it is the step that determines whether the rest of the sequence is being run against the right entity.

The Secretary of State record establishes that a legal entity exists, what it is legally called, when it was formed, and what state it answers to. Running a tax identification check, a lien search, or a sanctions screen against a misidentified entity produces clean results about the wrong business, and nothing later in the sequence detects that.

What the SOS response deliberately does not include is worth stating plainly, because assuming otherwise creates coverage gaps that look like passes:

• No sanctions or watchlist screening. OFAC and related screening is a separate check on a separate schedule.

• No tax identification verification. Matching the EIN to the legal name is its own step, and the IRS does not require a new EIN when a business changes its name, address, or responsible party,^[12] so an EIN can outlive the identity it was issued under.

• No lien or UCC data by default. UCC filing information is available by adding `uccData=true` to the search, not in the base response.

• No court records, judgments, or professional licenses.

• No bank or cash flow data of any kind.

Cobalt's Find Related Businesses capability, added via `findRelatedBusinesses=true`, surfaces other entities linked to the agents and officers on a result and flags whether the related entity's address matches. It is in beta, adds one to two seconds at the top end, and its behavior may change, so it belongs in enrichment and review workflows rather than in an automated decline path today.

Where this check sits relative to EIN, sanctions, and lien steps is worked through in the sibling post on the SOS check inside a KYB stack, and the broader tool landscape is mapped in the KYB API guide for lending risk assessment.

What should you test before committing to an integration?

The states and conditions that will actually break it, rather than the ones that demonstrate it working.

A sandbox run against a well-known active entity in California proves little, because every provider handles that case. The evaluation questions worth answering are about the edges:

• Run a slow state end to end. Use Oregon on a live lookup and confirm your code handles the `retryId` path, not just the synchronous one. The API also exposes a `test` parameter with `complete`, `incomplete`, `failed`, `retryIdInvalid`, and `badRequest` values so these paths can be exercised without live calls.

• Run a name that resolves ambiguously. Confirm `possibleAlternatives` and confidence scoring route the case the way your policy intends rather than silently taking the first result.

• Run an entity in an adverse status and confirm the normalized status maps into your credit policy correctly, including the reinstated case where the current record reads clean.

• Run a state that publishes no officer data and confirm an empty officers array does not fail a downstream requirement that assumed the field was always populated.

• Download a screenshot and re-request it after the expiry window to prove your capture step actually persisted the image.

• Confirm the pass-through cost cases. Delaware status checks carry a state-imposed fee of $10 or $20 depending on the tier, passed through at cost, and New Jersey status data is restricted by statute with a small fee attached.^[13] Both are state fees, not surcharges, and both belong in your unit economics before volume ramps.

Cobalt bills 1 credit per lookup from a shared pool across the API suite, which keeps the arithmetic simple once the pass-through states are accounted for. The build-versus-buy version of that arithmetic is worked through in the in-house cost comparison, and the sandbox evaluation is expanded in the sibling post on testing an SOS API before buying.

A working single-state lookup is typically a few days of engineering. The interpretation layer, the async handling, and the evidence capture take the remaining time, and they are what separate a verification that holds up from one that merely returns quickly.