The State Registry Has the Business but the API Does Not: A Lender Escalation Checklist

Executive Summary: State registry data is the record a lender ultimately relies on when a state entity search returns something different than what the operator can see on the Secretary of State site. This gap is not a defect narrative; it is an operational reality that alternative business lenders need a repeatable escalation path for, one that treats a missing or divergent API result as a discrepancy to document and route rather than a verdict on whether the business exists.

What Happens When The State Site And The API Disagree?

Why does a visible state record sometimes not appear in a lookup?

An operator working a file for Borrower A pulls up Entity B on a Secretary of State portal, sees an active filing, and then runs the same name through an API and gets no result or a different status. Several ordinary causes explain this before anyone should assume the API is broken. The name on the state's results page may differ from the legal name inside the record; Cobalt's API documents a searchResultTitle field that appears only when the name on the search results differs from the name in the details, for example when the results list a DBA and the details page lists the legal name^[1]. The entity may be formed in one state and registered in another; the documented response carries separate stateOfFormation and stateOfSosRegistration fields for that reason^[1]. The state portal itself may be unavailable; the API documents a message value for a state that is down for maintenance when recent results exist^[1]. And the state's own database may be incomplete: New York's Department of State says that because it relies on information provided to it, the completeness or accuracy of its search database cannot be guaranteed^[2]. None of these causes supports a conclusion that the business is absent; they only tell the operator where to look next.

What is the documented scope of a coverage report?

Cobalt's help documentation addresses this exact scenario: when an operator finds a record on a Secretary of State site that the tool does not return, the guidance is to notify Cobalt right away with the example, and it describes coverage accuracy as a top priority and shared missed examples as the input that helps the team update and improve^[3]. This is a reporting channel, not a guarantee of resolution timing or of universal statewide coverage. It also is not a claim that every missed example results in an update within any particular window. The practical takeaway is that a discrepancy report is a documented input into a vendor's own quality process, and the value of that report to the lender's own risk file depends entirely on how completely the original query, the timestamp, and the state identifier were preserved before the report was filed. A workable policy is to treat every no-match against a known state record as an item requiring a structured packet, not a retry-until-it-changes shortcut.

Why Should Operators Preserve The Exact Query Before Escalating?

What fields make a lookup reproducible later?

The single biggest failure mode in escalation is losing the ability to reproduce exactly what was searched. Cobalt's API accepts a business name search through searchQuery, or a direct identifier lookup through sosId, alongside a state parameter that is required unless a retryId is being used and can be expressed as lowerCamelCase or as an abbreviation^[1]. If an operator later cannot say whether the original call used searchQuery with a typed name or sosId with a specific identifier, nobody can tell whether a no-match reflects a name-matching problem or something else. Cobalt's own guidance for batch work recommends keeping a separate column for the validated legal name actually used in the search, copied from the state site rather than taken from raw client input, because it improves reproducibility and lets a team re-run the same query consistently later^[4].

How does the state identifier reduce ambiguity in a packet?

New York's own entity database illustrates why a state-assigned identifier carries more weight than a name string. The Department of State's online search accepts either a name or an ID in its Search By field, and a name search can be run with begins-with or contains matching rather than an exact match, which is one reason an operator browsing the state site can see a record that a stricter query does not surface^[2]. The department also cautions that its database search should not be read as an indication that a name is or is not available, and that its own name-availability determination applies only to the date and time the search was completed^[5]. That caveat matters for a lender escalation packet in two ways. First, it confirms that even the authoritative source treats a search as time-bound, which supports recording a timestamp on every lookup, not just the API-side ones. Second, it means an escalation packet that only records a business name, without the state identifier used in the direct state search, gives the reviewing team less to work with. We recommend capturing the state-assigned identifier whenever the operator can read it off the state page, alongside the exact name string and the matching mode the state site was using, so a later side-by-side comparison does not depend on guessing which of several similarly named entities the operator originally viewed.

What Belongs In A Reproducible Escalation Packet?

Which fields turn a complaint into a reproducible ticket?

An escalation packet is only useful if it lets a second person, days later, reconstruct exactly what happened without asking the original operator to remember details. At minimum, a workable packet includes the following elements, treated as a proposed control an operations team adopts on its own recordkeeping side.

• Exact query string. The literal value passed as searchQuery or sosId, copied rather than retyped from memory, consistent with Cobalt's guidance to track the actual name searched separately from raw input^[4].

• State parameter used. The literal state value submitted, in whichever format was sent, so a reviewer is not left guessing whether an abbreviation or the lowerCamelCase form was passed to the endpoint^[1].

• Timestamp of the lookup. The date and time the API call was made, paired with the date and time the state site was viewed, because the state's own search result is understood to apply only to the moment it was run^[5].

• State-assigned identifier, when visible. The DOS-style ID or equivalent entity identifier from the state page, captured even when the original search was name-based.

• Screenshot or saved source reference. A captured view of the state page showing the record. The API describes its own screenshot link as short-lived and not yet available in all states^[1], and Cobalt's help documentation says document URLs are time-limited by default and can be extended on request^[6], so neither is a permanent archive on its own.

• Independent state evidence, when the discrepancy is material. For a New York entity, copies of filed documents can be ordered online for entities formed or authorized on or after July 30, 1990, or by written request, as plain or certified copies^[7]. An ordered copy gives the packet a state-issued document rather than a screenshot.

How should the packet be stored so it survives a later audit?

Once assembled, the packet should be stored somewhere the operations team controls directly, not left inside a support ticket thread that may not be retrievable later. This is a customer-owned recordkeeping decision, not a vendor feature. Store the raw API response body alongside the packet rather than a summarized status alone. The documented response includes an optional message that appears only when live data was requested and the live lookup failed or the state was down for maintenance while recent results existed, and createdAt and updatedAt values that appear when cached data was requested^[1]. Those fields tell a later reviewer whether the API answered from the state site at that moment or from a recent stored result, and that distinction is lost if only a status word is kept. A simple structured record, kept per discrepancy, also lets a team see how many escalations relate to the same state, the same name-matching pattern, or the same time window, which is useful context whether or not any individual ticket gets resolved quickly.

How Do State Search Limits Shape What Counts As A True No-Match?

What does the alternatives list actually tell a reviewer?

Before treating any result as a hard no-match, an operator should check whether the API returned close alternatives rather than nothing at all. Cobalt's help documentation says the API returns up to roughly the top ten alternatives so a team can filter and select the best match by its own logic, for example by city, ZIP, or entity type when several results look similar^[8]. This means a true no-match packet should show that the alternatives list was reviewed and none of the candidates matched, not just that the top result was empty. If the escalation packet omits this step, a reviewer cannot tell whether the discrepancy is a genuine coverage gap or a name-matching threshold issue that the alternatives list would have resolved.

Why do expansion limits change what appears in a response?

The same help documentation describes state-by-state limits on how many candidate records get fully expanded, a balance between completeness and performance, and notes these limits may change if state systems slow down or alter their structure^[8]. When no address is supplied, the API returns only what is visible on the immediate search results page, meaning names and URLs without deeper detail, while supplying an address allows fuller expansion including entity status, filing number, and date^[8]. The API documentation adds that street, city, and zip act as AND filters against the top ten results of the name search, checking the physical address, then the mailing address, then the agent address^[1]. An escalation packet should therefore record whether address parameters were included in the original call, since an incomplete field set is a documented product behavior, not evidence that a record is missing from the underlying state source, and an address filter that excludes every candidate can itself produce an empty result for an entity the state site plainly lists. Treating an absent field as proof of an unrecorded real-world event is a misreading operations teams should guard against when building these packets.

What Does A Worked Escalation Example Look Like?

How would Borrower A's file move through the packet steps?

Consider an illustrative, hypothetical scenario built for demonstration only: an operator reviewing a loan application for Borrower A locates Entity B as an active entity on a state's own Secretary of State portal. The operator then runs the same name through a lookup and receives a no-match result with an empty alternatives list. Rather than retrying the same query repeatedly, the operator follows a bounded escalation sequence: confirm the exact legal name against the state page character by character, note the state-assigned identifier shown on the state site, capture the query parameters actually submitted including which state value and whether searchQuery or sosId was used, record the timestamp of both the state-site view and the API call, and save a screenshot or export of the state page promptly, since the vendor-returned screenshot link is described as short-lived^[1]. One additional retry is reasonable at this point, since the documentation itself describes a state being down for maintenance as a condition the API reports^[1], but the original query and evidence are preserved regardless of whether the retry changes the outcome.

What does the completed record look like once the packet is assembled?

The packet becomes a structured, customer-owned review record rather than a narrative email. Below is an illustrative example of how an operations team might store this internally; it is not a Cobalt request or response format.

{
  "record_type": "illustrative customer-owned review record",
  "escalation_id": "application-example-1",
  "borrower_reference": "Borrower A",
  "entity_reference": "Entity B",
  "state_queried": "exampleState",
  "query_type": "searchQuery",
  "query_value": "Entity B LLC",
  "address_parameters_included": false,
  "state_site_identifier": "example-state-id-000000",
  "state_site_match_mode": "contains",
  "state_site_viewed_at": "2026-09-11T14:02:00Z",
  "api_call_made_at": "2026-09-11T14:05:00Z",
  "api_result_summary": "no_match_empty_alternatives",
  "api_message_field_present": false,
  "retry_attempted": true,
  "retry_result_summary": "no_match_unchanged",
  "screenshot_reference": "internal-storage-path-example",
  "status": "escalated_to_vendor_pending_review"
}

This record gives a second reviewer everything needed to reconstruct the discrepancy without contacting the original operator.

What contrasting case does not warrant escalation?

Consider a brief contrasting scenario, again illustrative. An operator searches for "Entity B Inc" and receives no exact match, but the alternatives list returns "Entity B Incorporated" at a matching address with a similar entity type^[8]. Here, the discrepancy is fully explained by the search step itself: the state's registered legal name differs slightly from the operator's typed input, and the alternatives mechanism surfaced the correct candidate. No escalation packet is needed, because the tool behaved as documented and gave the operator exactly the information needed to resolve the mismatch through ordinary name correction. Copying the corrected name back into the batch tracking column, as Cobalt's guidance recommends for reproducibility, closes the loop without any vendor contact^[4].

Setting this contrast next to the worked Borrower A example clarifies where the line sits. In the worked example, the exact legal name and identifier from the state page were confirmed and still produced no match with an empty alternatives list, which is the pattern that warrants a full packet and a coverage report. In the contrasting case, the alternatives list did its job on the first pass. A reviewer who escalates every non-exact first result, without checking alternatives first, will generate packets for discrepancies that a normal part of the search flow already resolved, diluting attention from the cases that genuinely need a documented review.

How Should Longer-Running Or Delayed Lookups Be Handled?

What does an incomplete or pending status actually mean?

Some state lookups take longer than others to complete. The API documentation says some requests can take longer than 30 seconds, and for those the caller receives a documented 202 response with a status of Incomplete, a retryId, and a message that the state is taking longer to acquire the data; the retryId is then used to check back on the request and retrieve the business data when it completes^[1]. This is documented behavior, not a failure. A packet built around a lookup that returned a retryId should record that identifier explicitly, since it is the mechanism for retrieving the eventual result rather than resubmitting the original query from scratch. The documentation adds that a caller who wants a screenshot must include screenshot=true on the retry request as well^[1], so an operator who omits it on the retry will receive the completed record without the page capture the packet needs. Treating a pending response as a final no-match, without following the retry mechanism through to completion, produces an escalation packet built on an incomplete picture.

Why does a callback URL change what "no result yet" means?

The API also accepts a callbackUrl, described as a URL used to send the business data after the request completes, and the documented response notes that a requestId appears only on callback data^[1]. When a callback pattern is in use, an escalation packet needs to record whether the callback was received and, if so, its requestId, separate from whether the initial synchronous response looked like a no-match. An operator who escalates before a callback has had a reasonable chance to arrive is escalating on an incomplete data set. We recommend a fixed internal waiting window, set by the operations team itself as a proposed control, before treating a callback-pending lookup as a candidate for escalation. This keeps the distinction clear between a result that has not arrived yet and a result that has arrived and genuinely conflicts with the visible state record.

Which Discrepancy Scenarios Warrant Which Escalation Path?

How does a decision table help route different mismatch types?

Not every discrepancy needs the same treatment. The table below offers a proposed routing structure an operations team can adapt.

What should never be treated as an automatic escalation trigger?

A single retry producing the same result is not, by itself, proof the record does not exist anywhere in the state's system; it only confirms the query behaved consistently across two attempts. Similarly, an entity showing as inactive, dissolved, or under a different status than expected is a status difference to note in the packet, not evidence of fraud or an automated basis for declining an application. New York's own database page says the system should not be used to determine the acceptability of an entity name, and the same restraint applies in the other direction: a lookup result is not a determination about the applicant^[2]. These distinctions matter because a decision table only helps if operators resist the urge to shortcut past the routing logic when a result looks unusual.

What Should A Reviewer Worksheet Look Like In Daily Use?

Which checklist items keep escalation from becoming another queue?

A worksheet works best as a short, repeatable sequence rather than a long form nobody finishes. We recommend the following sequence as a proposed reviewer checklist, adaptable to internal tooling.

• Confirm the exact legal name. Copy it directly from the state page rather than retyping from client-supplied paperwork, consistent with tracking the actual name searched separately from raw input^[4].

• Record the state parameter format used. Note whether the lowerCamelCase or abbreviation format was submitted, since the state value is a required input and a malformed value can itself produce an unexpected result^[1].

• Check the alternatives list before declaring no-match. Review any returned candidates for city, ZIP, or entity type overlap before concluding the record is absent^[8].

• Note whether address parameters were included. An unaddressed query returns only limited fields on alternatives, and an address filter narrows the candidate set, neither of which should be read as a coverage gap^[8].

• Capture the retry or callback status. Distinguish a completed no-match from a request still pending completion, and record the retryId or callback requestId^[1].

• Save a time-stamped screenshot or export. Do this promptly given the short-lived screenshot link and the time-limited document URLs described in the documentation^[6].

A workable operating principle: no discrepancy leaves the reviewer's desk without the original query, the state identifier, and a timestamp attached, because a packet missing any of these three cannot be independently reproduced later.

How does this worksheet fit into a broader review process?

This worksheet is not a substitute for a lender's underwriting policy; it is a narrow procedural layer that ensures whatever escalation reaches a vendor or a compliance reviewer is reproducible. Pairing it with a documented internal sign-off step, where a second person confirms the packet is complete before submission, keeps the process auditable without adding an open-ended manual review queue. For further background on how operations teams structure broader no-match handling beyond this specific escalation packet, related reading is available on finite-state approaches to no-match workflows^[9], on structuring a sandbox evaluation before relying on any SOS API in production^[10], and on the tradeoffs between live and cached state data^[11].

If your team is working through a specific state registry discrepancy right now, bring the exact query, state identifier, and timestamps to a walkthrough at the Cobalt Intelligence demo and we can look at your concrete scenario together.