Executive Summary: A multi-state verification status request can succeed while some state searches remain unfinished. Cobalt's businessStatusCheck documentation explicitly says it can return HTTP 200 before the request is fully complete.[1] Build the lending workflow around source completion and required coverage, then make the credit decision separately.
What does HTTP 200 mean in this workflow?
It means the status request succeeded according to the endpoint's contract. It does not mean every underlying state search finished, every entity matched, or the application satisfied underwriting policy.
HTTP semantics describe a successful response in relation to the request being handled.[2] Here, the request asks for the current state of a longer-running process. A successful answer can therefore describe work still in progress.
Why does this matter to a lending queue?
Imagine a hypothetical application that needs evidence from several jurisdictions. The integration receives a successful status response containing some completed state results, then marks the entire business check finished. A later reviewer sees a closed task without knowing which required searches were still outstanding.
The problem is the application mapping, not the mere existence of asynchronous delivery. Give the reviewer an evidence state that reflects the work completed and the work remaining.
Does another provider use the same pattern?
Middesk's quickstart similarly distinguishes a successful initial API call from a completed business verification and describes asynchronous result handling.[3] That is useful category context. It does not establish that all providers use the same status names or readiness rules.
Read each provider's endpoint contract and preserve its distinctions. Copying a generic “2xx means verified” rule across integrations would discard the information the response is intended to convey.
Which Cobalt fields should determine completion?
The documented Full Verification flow begins with initVerification, which returns a searchGuid for checking progress.[4] Store that identifier with the submitted application inputs and use it to correlate later evidence.
businessStatusCheck reports state results as they become available. The documentation for fullStatusCheck identifies sosStatus as the primary field for deciding whether the request is fully finished; other example statuses are marked for later use.[5]
Why not use overallStatus?
Because a familiar field name is not enough to establish its current meaning. The example comments, rather than the name alone, identify the completion field to use. Do not gate a funding workflow on a placeholder simply because “overall” sounds authoritative.
Confirm the response contract in your integration and keep the interpretation close to the code that uses it. If the provider changes the contract, that mapping should be reviewed deliberately.
How should the search identifier be sent?
Cobalt warns that the searchGuid must be URL encoded when passed as a query value because it contains #.[6] Use your client's query-parameter encoding rather than manually concatenating an identifier into a URL.
A malformed status request should remain a technical issue attached to the original search. It should not create an empty result that the reviewer might mistake for a completed search with no matching business.
How should the application track partial results?
Keep a per-request evidence record and a separate per-state view. The request-level record identifies the original input and current source-completion state. The per-state view shows which searches have returned, what each supplied, and whether it meets the lender's requirement.
The Cobalt businessStatusCheck example contains state-specific records and statuses, including possible alternative matches.[7] A completed state response can therefore require interpretation rather than automatically establishing the intended business match.
Use an evidence checklist such as:
• Source completion. Retain the documented sosStatus value before applying the lender's separate readiness rule.[8]
• Application reference. Identify the application and input revision that initiated the search.
• Source request. Preserve the returned search identifier and request details.
• Required jurisdictions. Record the states your selected review policy requires, separately from the provider's wider search scope.
• Returned evidence. Track each state response without treating a missing state as an empty completed search.
• Source completion. Evaluate the currently documented completion field for the correct request.
• Lender disposition. Record whether required evidence is sufficient, needs review or remains outstanding.
Should partial results be hidden until everything finishes?
Not necessarily. An analyst can begin reviewing available evidence if the interface clearly identifies it as partial. The useful boundary is between making progress and claiming completion.
Show which required jurisdictions are outstanding and what the team can do next. Avoid a single percentage that hides whether the missing state is material to the application. A nearly complete broad search can still lack the exact evidence the review requires.
What should the readiness rule look like?
Define readiness in terms the underwriting owner understands. Source processing must be distinguished from required coverage, match interpretation and the final lending decision. Your application can calculate these states separately and present them together.
The following example uses a customer-normalized view of source results. Its field names are illustrative application fields, not a Cobalt response schema.
def review_readiness(source_complete, required_states, evidence):
outstanding = [
state for state in required_states
if not evidence.get(state, {}).get("review_requirement_met", False)
]
if not source_complete:
return "source_processing", outstanding
if outstanding:
return "required_evidence_outstanding", outstanding
return "ready_for_lender_decision", []Can a lender proceed with a narrower required scope?
The responsible owner may define which evidence is required for a particular review. If a permitted decision uses a narrower scope than the provider's full search, document that explicitly. Do not describe the wider request as finished when only the lender's selected subset is sufficient.
This example waits for source completion to keep its meaning simple. A different policy may allow a specific interim action while the wider request continues, but that action needs its own label and authority. It should not silently reuse “completed verification.”
Does ready for decision mean approved?
No. It means the evidence prerequisites selected for that review are met. The actual lender disposition remains separate. Cobalt's API returns business-search information; the readiness code shown here is a proposed integration control, not a Cobalt credit decision.
Our pre-funding business verification framework provides broader context for keeping evidence checks tied to the decision they support.
How should an analyst handle an unfinished state?
Identify whether the state is still processing, returned insufficient evidence, or produced a result that needs identity review. Do not merge those situations into “not found.” They require different next steps and may belong to different owners.
Trulioo's partial-results documentation explicitly separates available results from sources still awaiting a result.[9] That is another example of why an available response should retain its coverage limitations. Its specific statuses are not interchangeable with Cobalt's.
What should happen while a search is processing?
Use the supported status-check or callback workflow and keep a bounded operational task. Define your own review interval, time budget and escalation path rather than inventing a vendor completion guarantee.
If your application stops waiting after its chosen time budget, label that as a local workflow timeout. Do not rewrite the provider's source status as failed or complete unless the returned evidence supports that label.
What if the source completes without sufficient evidence?
Move to the appropriate evidence-resolution task. A completed process and a satisfactory match are different states. Preserve alternative candidates and explain which identity fact remains unresolved rather than selecting the first result by convenience.
The no-match exception operations guide addresses that later stage. Keep it distinct from the current article's question of whether the underlying searches have finished.
Partial evidence can support progress without supporting a claim that the whole review is complete.
How should you handle callbacks and polling together?
Use one source-request identity and one application evidence record for both delivery routes. Otherwise the polling path and callback path can create competing versions of “current” evidence.
Cobalt's Full Verification documentation describes an optional callback and a returned search identifier for progress checks.[10] Build your correlation around the supported identifiers and actual response contract, then make updates safe when the same information is observed more than once.
Which arrival order should win?
Do not choose solely by arrival order. A later-arriving message can concern an earlier application revision or an earlier state of the source request. Compare the request identity and the evidence represented before updating the analyst view.
Preserve the raw observation and record why it did or did not change the current review. That gives support a way to explain the interface without erasing earlier events.
What should duplicate delivery do?
It should not create duplicate review tasks or erase a disposition already tied to the same evidence. Define duplicate handling in your application and test it with repeated fixtures. This is an implementation recommendation, not a claim that Cobalt guarantees one-time delivery.
If callbacks and polling disagree, retain the discrepancy and follow the supported reconciliation route. Do not pick whichever version produces the most convenient completion state.
What should the acceptance tests include?
Test a successful status read with only some states returned, all source searches complete with an unresolved match, a missing required jurisdiction, and an invalid or incorrectly encoded search identifier. Include a provider response for a different application revision.
The critical assertion is what the workflow tells the lender. A test should fail if a 200 response alone closes the overall review, if a missing result becomes “no business found,” or if source completion becomes automatic loan approval.
How should you test the documented completion field?
Build a fixture in which the documented sosStatus and a placeholder status would lead to different interpretations. Confirm the integration uses the current contract rather than the more attractive field name.[11]
Also test unknown status values. An unfamiliar value should create a visible review path until its meaning is confirmed. It should not inherit the behavior of a nearby known value simply because the string begins with the same letters.
How should operations validate the result?
Ask a reviewer to explain which states are available, which are still missing, and why the task is or is not ready for the next action. Use a realistic but synthetic application so the team can focus on the workflow without sharing borrower data.
Track your own unresolved processing age, evidence-resolution age and mismatch categories separately. The first can identify integration or source-progress questions; the others concern the evidence returned. A single turnaround measure would hide that distinction.
What should you verify in a Cobalt evaluation?
Bring the application stages and required-jurisdiction rules you intend to implement. Ask to walk through the start response, a partial status response, source completion and a completed search that still requires analyst review.
The current Full Verification documentation describes initiating searches across available states and retrieving state responses through its status actions.[12] Confirm the actual supported behavior for your use case, including how to identify the correct request in any listing of prior or ongoing searches.
Middesk's lifecycle documentation separates submission, verification and client approval.[13] Use that broader distinction when evaluating alternatives, while checking each vendor's real fields and process rather than importing assumptions across products.
Schedule a Cobalt demo with a partial-completion test case. The outcome to establish is clear: a successful status request should help your team understand the evidence available, without closing work that is still unfinished.
.jpg){kind=small}
.png)