Executive Summary: The new cachedData field changes what a 202 Incomplete Secretary of State API response can contain, but it does not change what incomplete means. A Cobalt response can now carry an available cached business record beside retryId while the live search continues. An integration should parse request state first, preserve the live job, treat the cached array as optional interim material, and wait for the later live response before setting final verification.
What Does a 202 Incomplete SOS Response Mean?
Why is 202 a processing state rather than a result state?
Cobalt's public SOS API reference says some state searches take longer to complete and return a retryId that the client uses to check status and obtain the completed business data.[1] The Help Center describes Incomplete the same way: the lookup is still processing, and the client can poll with retryId or receive the completed result through a webhook.[2]
The status guide separates 202 + Incomplete from complete, cache-miss, fallback, and failed outcomes.[3] That distinction matters because a status handler should decide whether work is terminal before a field mapper decides what business data is present.
How does HTTP define 202 Accepted?
RFC 9110 says 202 Accepted means a request has been accepted for processing but the work has not completed.[4] The standard calls the response intentionally noncommittal. It can describe current progress and point to a status monitor, but it cannot make the later operation complete.
That standard meaning supports a simple integration rule: top-level request status outranks the presence of a business object. If the response is incomplete, the job stays open even when useful data is available.
What Fields Can the New Response Contain?
What does the approved response example show?
Cobalt's September 2026 feature release defines this representative shape:
{
"status": "Incomplete",
"statusCode": 202,
"retryId": "72f06828-f593-40f1-9b4d-65a248e78869",
"cachedData": [
{
"title": "FF PIZZA LLC",
"status": "Active",
"normalizedStatus": "Active",
"stateOfSosRegistration": "CA",
"updatedAt": 1788994658510
}
]
}The top-level fields describe the open request. The nested fields describe one available cached observation. updatedAt helps the consumer assess how recently that cached record was updated.
Which fields are guaranteed?
The approved example does not establish that cachedData appears on every incomplete response or that every shown nested field appears for every state and record. The public Postman schema documents many SOS response fields, but field availability can vary with state data and request options.[1]
Build for field presence and type validation:
• Require top-level state. Validate status and statusCode before mapping any record.
• Require open-job identity. Preserve retryId when the response supplies it.
• Treat cachedData as optional. An absent array is a supported branch, not a parser error.
• Treat nested fields as conditional. Avoid converting a missing cached field into an empty final field.
• Preserve the raw response. A normalized internal model should not erase the source payload or request state.
The parser's first question is not "Did I receive a business record?" It is "Has this live search reached a terminal state?"
How Should a Parser Branch on the Response?
What is the minimum state table?
A small state table prevents field presence from becoming an accidental completion rule.
| Top-level state | cachedData | Integration meaning | Allowed next step |
|---|---|---|---|
| Incomplete | Present | Live pending with interim cached observation | Store, label, apply limited policy, continue live path |
| Incomplete | Absent | Live pending without interim observation | Continue live path, show pending |
| Complete | Not applicable | Terminal live result or terminal no-match | Store final observation, close or review |
| Failed | Not applicable | Terminal error | Route by error policy |
| Retry invalid | Not applicable | Prior request cannot be retrieved by that identifier | Investigate or restart under policy |
Cobalt's public status page explains that an invalid retry identifier may not exist, may have expired, or may no longer be available.[3] That is a different operational condition from an incomplete request with no cached match.
Why should cached and live data use separate observation slots?
If the final response overwrites the cached object, the system loses what it displayed or used while the search was pending. A lender-owned model can store one request record plus an immutable interim observation and a final observation. The final one closes the live state. The interim one preserves history.
Microsoft's asynchronous request-reply pattern similarly keeps request acceptance, pending status, and final resource separate.[5] The pattern is not a Cobalt schema, but it explains why process state and result data should not be collapsed.
How Should updatedAt Affect the Response Handler?
What does the timestamp prove?
updatedAt proves when the cached record was updated according to the response. It does not prove that the record is acceptable for every business action. Cobalt's cache-validity page says cached records do not auto-expire and instructs consumers to use createdAt and updatedAt to judge freshness for their use case.[6]
A response handler should store the raw timestamp and a calculated age at evaluation time. It should also store the lender rule that accepted or rejected interim use. This makes the rule inspectable later rather than burying it inside interface behavior.
What if the timestamp is missing or too old?
The safe branch is live pending. Do not infer recency from the fact that cachedData appeared. Cobalt's Help Center says response messages and timestamps help distinguish live from cached information.[7] State cache updates also vary, so a general cadence should not replace the actual record timestamp.[8]
An action-specific policy can use three outcomes:
• Eligible for temporary display. Show source, age, and pending state.
• Eligible for reversible preparation. Permit only the named lender-owned step.
• Not eligible for interim use. Keep the request pending and wait for live.
None of these outcomes marks final verification complete.
What Should Happen When cachedData Is Absent?
Why is an absent array not a no-match?
The feature returns cachedData when a cached match is available. Its absence means no interim cached match was supplied. Cobalt's cache-miss guidance says a miss does not prove that the entity does not exist at the state and recommends a live lookup when certainty matters.[9]
For this response path, the live lookup is already running. Keep the same retryId, preserve the pending state, and wait for the terminal result. A screen may say No interim cached match, live search pending. It should not say Business not found.
Which branches must remain distinct?
At least five conditions deserve separate codes:
• No interim cached match. Live search remains open.
• Terminal live no-match. The completed state search returned no matching record.
• Live fallback to recent data. A live attempt had an issue and the response supplies cached data with an explanatory message.[3]
• Request failure. The search ended with an error.
• Invalid retry. The completion identifier cannot retrieve the prior job.
That separation aligns with Cobalt's no-match exception guidance, which treats missing evidence as a routed state rather than an automatic clean result.
How Should Retry and Callback Delivery Update the Same Request?
What should be idempotent?
A poll response, callback, or delivery retry can all refer to the same logical verification. The consumer should make state updates idempotent so the same event does not create a second completion or decision effect. AWS says operations combined with retry and backoff should be idempotent to avoid duplicated or partial state changes.[10]
Cobalt's batch guidance recommends callback delivery for long-running work, polling when webhooks are unavailable, and queues designed with backoff and idempotency.[11] The feature adds an interim-data branch to that existing transport choice.
What transition rules prevent duplicate completion?
Use one lender request key and permit only valid transitions:
• Accepted to live pending. Initial request is recorded.
• Live pending to interim available. Cached observation is stored without closing the request.
• Live pending to live complete. Final result closes the open state.
• Interim available to live complete. Final result is stored beside, not on top of, the interim observation.
• Live complete to live complete. Duplicate delivery is acknowledged without repeating the business effect.
For webhook receivers, the Standard Webhooks specification recommends unique event identifiers, timestamp checks, and idempotency handling as general safeguards against duplicate delivery and replay.[12] These are consumer design practices, not claims about Cobalt's callback signature or delivery contract.
What Should Engineering Log and Test?
Which fields make the response traceable?
OWASP says application event records should capture when, where, who, and what, plus result status, reason, HTTP status, and the action taken.[13] For this response, log the lender request key, search inputs, state, top-level status, retryId, raw cached payload, updatedAt, receipt time, later live payload, and transition outcome.
This is an operational checklist, not a legal retention schedule. NIST describes log management as an enterprise process for creating, moving, storing, accessing, and disposing of event data for operational and investigative use.[14] The lender still owns access, redaction, retention, and compliance interpretation.
Which tests should block release?
Test at least the following cases before allowing the field into a production decision path:
• Incomplete with a valid cached array.
• Incomplete without a cached array.
• Missing or invalid updatedAt.
• Cached record outside the lender's interim-use rule.
• Final live result equal to the cached match.
• Final live result different from the cached match.
• Duplicate poll or callback delivery.
• Invalid or unavailable retry identifier.
The public Postman reference documents general test values including complete, incomplete, failed, retryIdInvalid, and badRequest, but it does not promise a fixture for every new cached-data branch.[1] Use controlled mocks for consumer state logic and contract tests for provider behavior.
How Does This Fit the Existing SOS Integration?
What does not need to change?
The integration still starts a live search, handles incomplete state, preserves retryId or callback identity, and waits for the terminal result. The new work is additive: recognize the optional array, preserve its provenance, and decide whether lender policy permits an interim action.
That makes this article narrower than a general retry and graceful-failure guide or an async webhook architecture. Those resources cover transport and resilience. This feature changes the data available while that transport is still active.
What is Cobalt's role in the conclusion?
Cobalt supplies the incomplete status, process identifier, optional cached observation, cache timestamp, and later live result. The lender owns parsing, persistence, freshness rules, interface labels, testing, and every underwriting decision.
If your engineering team wants to review how the SOS response states map into your lender-owned workflow, schedule a demo with Cobalt.
The safe implementation is not complicated. Parse state before data, keep one live job open, and make finality a deliberate transition rather than an inference from the presence of business fields.
.jpg){kind=small}
.png)