Executive Summary: A lending CRM or origination platform with a built-in Secretary of State check made integration decisions on your behalf: which request parameters were sent, which response fields reached the screen, how a slow state was handled, and where the evidence went. A direct SOS API account hands those decisions back to you, along with the request history, the test mode, and the add-on checks the platform may never have wired in. This guide for operations and technology leads at funders covers what changes, what stays the same, and how to cut over without breaking underwriting.
What Actually Changes When a Funder Moves From a Platform's Built-In SOS Check to a Direct SOS API Account?
Who holds the API key, the request history, and the usage record?
On a direct account, the API key is generated at signup and is available on your own Cobalt dashboard, and the same key serves both testing and production.[1] [2] Usage is tied to your organization rather than to a single key, so developer or service accounts under the same company domain draw from one pool,[3] and an account endpoint reports the key's usage and due date.[4] The history of what you asked and what came back is the log you keep.
On a platform-embedded check, the answers depend on the integration, so ask the platform whose API key it calls with, who keeps the request log, which parameters you can set, and who takes a wrong-looking result to the data vendor. If it cannot answer, that is the finding.
The interagency guidance on third-party relationships issued by the Federal Reserve, FDIC, and OCC in June 2023 states that "Third parties may enlist the help of suppliers, service providers, or other organizations, which this guidance collectively refers to as subcontractors."[5] The platform is your third party, and where it holds the vendor relationship, the data vendor is its subcontractor; on a direct account, the data vendor is your third party. The guidance is directed to banking organizations the agencies supervise and says supervisory guidance "does not have the force and effect of law."[5] It can reach a nonbank funder through a partner bank: the funder is that bank's third party, and the guidance says it is important for the bank to "obtain and evaluate information regarding the third party's legally binding arrangements with subcontractors or other parties,"[5] which include a direct data-vendor agreement.
What did the platform decide on your behalf?
An SOS search can verify a business's legal name, state registration, standing or status, filing dates, addresses, registered agent, officer information when the state provides it, and assumed names where states publish them, and the help center says results include a timestamped screenshot and the source URL.[6] A platform screen that shows a status badge and a formation date has chosen two of those outputs and set the rest aside.
Cobalt's published threshold guidance treats a confidence score of 0.80 or higher as an auto-accept, 0.60 to 0.79 as a review case, and below 0.60 as a likely reject unless other signals such as address are strong.[7] If the embedded integration never surfaced the score, ask the platform whether it applied a cutoff to accept a match, and at what value.
Which checks can a built-in integration leave out?
Cobalt's API reference documents TIN verification,[8] UCC search,[9] court records,[10] and Business Monitoring[11] as endpoints separate from the Secretary of State search. An embedded integration exposes only the endpoints and parameters it wired, so ask your platform which of these it calls.
Which Request Parameters and Response Fields Does a Direct Integration Expose?
Which request parameters shape each lookup?
The state parameter accepts a camel-cased name such as northCarolina or an abbreviation such as nc, and a search needs at least one of searchQuery, sosId, or a person-name query.[12] Sending liveData=false serves a result from Cobalt's cache for a much faster response, while the live path fetches from the state registry itself.[13] The screenshot, uccData, callbackUrl, and test parameters are likewise request-level decisions in the API reference.[14]
The endpoint mechanics and the normalization model are covered in the developer integration guide to connecting to a Secretary of State API. Each switch changes what your evidence means.
Which response fields never reached your screen?
The messages array states when live data was unavailable and cached data was returned, and the createdAt and updatedAt values show how old that cached record is.[15] A platform that displayed Active without that message has shown you a cached read and a live read as the same thing. When you request them, screenshotSucceeded and uccSucceeded report whether the screenshot was captured and the lien data retrieved.[14]
The field set itself is state-dependent. Cobalt's own measurement on September 11, 2026 searched three large national companies by name in each of the 50 states and D.C.: 153 probes, each with a 180-second ceiling. Eight fields came back from every jurisdiction that returned a record: title, status, normalizedStatus, filingDate, normalizedFilingDate, sosId, stateOfSosRegistration, and confidenceLevel. Officers came back from 32 of 51 jurisdictions on at least one probe, and distinct populated fields per state ranged from 12 to 25, median 20. The measurement covers one day and three well-formed names, and it shows what a state can return rather than what it never returns. Cobalt's downloadable field-by-state spreadsheet covers the same planning question.[16] On a direct account you see that variation, and your rules must say what happens when a response carries no officers.
Which states behave differently once you see the raw response?
Three state behaviors surprise teams that only saw a platform screen. First, Delaware's online entity status is a paid request, and the Division of Corporations states that requesting it will not generate an official certificate of good standing.[17] Cobalt's help center says Cobalt "does not automatically include these paid status pulls," names New Jersey as another state that restricts status data by statute,[18] and says elsewhere that Delaware "omits status fields";[19] the field spreadsheet marks Delaware's normalizedStatus as not returned.[16] In the September 11 measurement, Delaware's status read "Franchise tax is in good standing" on two probes, normalized to "Active," and "Not available" on the third, normalized to "No status found." Give both states their own status-mapping branch.
Second, latency belongs to the state, and the published and measured figures disagree. Cobalt's help center puts cached lookups at one to three seconds, often under one, live lookups in fast states at about 7 to 15 seconds, and slower states such as Delaware, Nevada, and Texas at up to two minutes.[20] Another answer says slower states such as Oregon and Delaware "may require up to 5 minutes."[21] In the September 11 measurement, the 110 live probes that returned a record took 1.51 to 170.27 seconds, with a median of about 14.8 seconds and a ninetieth percentile of 65.39. Texas was the fastest live state at 1.51 to 2.13 seconds, and Delaware returned in 13.26 to 20.13 seconds. Another 19 probes completed with no exact match, and 21 did not finish inside the ceiling. Neither source is a service expectation, so set per-state timeouts from your own shadow run, and allow a slow state the full five minutes before treating its lookup as lost.
Third, when a live search fails or the state site is down for maintenance, the API reference documents three responses: recent results with an optional top-level message saying which of the two happened, a Failed status (statusCode 500) that still returns matching businesses from Cobalt's database, and a Failed status with a message and no results.[14] The help center lists the second response's error message as a 200 partial success,[12] and all three Nevada probes carried its maintenance message, with records attached. Have your handler read the top-level message and check for records instead of branching on status alone, and confirm the sosId and confidenceLevel before treating a record as the business you searched. Your workflow now decides whether a cached fallback counts as evidence; a reasonable default is no for final verification and yes for pre-screening.
How Does the Asynchronous Path Work When No Platform Sits Between You and the State?
What happens after roughly twenty seconds?
When a state takes longer than about 20 seconds, Cobalt's help center says the API returns an Incomplete status with status code 202 and a retryId instead of holding the connection open. You then poll with that retryId or supply a callbackUrl, the route Cobalt recommends for batch and high-volume use; Cobalt replies immediately with a requestId and later POSTs the finished result with the same requestId.[22] [23] The API reference says some requests "can take longer than 30 seconds to complete" and return a retryId,[14] so code for a 202 at any point past about 20 seconds instead of hard-coding either number.
On a direct account that loop is yours: a reachable listener, a store that records the requestId before the callback arrives, and a timeout per state rather than one global number.
How do you make callbacks and retries safe?
The callback is an HTTP POST into your system. RFC 9110 defines the idempotent property as follows, then lists PUT, DELETE, and the safe methods as idempotent, which leaves POST out:
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.[24]
Your receiver has to supply the idempotency the method does not: key the verification record on the requestId, accept a duplicate delivery without creating a second record, and never let a late callback overwrite a decision already recorded. Cobalt's API reference sets the same discipline for Business Monitoring webhooks: "publicly reachable HTTPS; return a 2xx within ~5s; failed deliveries are retried with backoff; dedupe on masterRequestId + checkNumber."[11] Acknowledge first and process afterward.
Treat the listener as an API you expose. OWASP's 2023 API Security Top 10 names Broken Authentication as API2 and Improper Inventory Management as API9.[25] A requestId you recorded shows that a delivery answers your request, not that Cobalt sent it. Because you supply the callbackUrl on each request,[14] put an unguessable token in its path, reject any delivery that lacks it, accept only HTTPS, and inventory the endpoint with your other APIs.
Cobalt's endpoint throttles with HTTP 429 on extreme spikes of hundreds or thousands of requests in a second, while normal bursts of five to fifty or more are queued and processed.[26] A morning batch that the platform may have metered now needs your own concurrency ceiling. The same code also marks account limits: "Trial limit exceeded" on the search endpoint,[14] which the help center says a trial key receives past its usage limit,[27] and "Usage cap exceeded" on the UCC endpoint,[9] each asking you to contact support to upgrade. The help center lists "Usage cap exceeded" from the search endpoint as a 200 Bad request,[12] so branch on the message, not the code: back off and retry a throttle, and send a limit to a person.
Which Add-On Checks Become Available on a Direct Account, and Where Do Their Limits Sit?
Before treating a direct account as a superset of the embedded check, name the alternatives: stay embedded, keep the platform's check for intake and add a direct account for what it never exposed, buy those categories from separate vendors, or build state connectors in-house. For a Salesforce-based CRM, Cobalt's help center adds a fifth: "A basic Salesforce connector is available, though most clients prefer custom integration to fit their CRM setup."[28] Here is what each Cobalt add-on covers and where it stops.
What does TIN/EIN verification confirm, and what can it not do?
In Cobalt's TIN check, you submit a business name and a TIN, and the response says whether the IRS confirms that they match; no additional business details are returned, and you cannot search by TIN.[29]
The response carries a status that the API reference says represents the request's state (Pending, TIN Matched, Did Not Match, or In Review), an irsCode from 0 to 8, an irsReason, an irsServiceStatus reporting whether the IRS service was running, slow, or in an outage, and a lastIRSCheckDate for a cached result.[8] Code 0 means the TIN and name combination matches IRS records; 1, the TIN was missing or not nine digits; 2, the TIN is not currently issued; 3, the combination does not match; 4, the matching request was invalid; and 5, the request was a duplicate. Codes 6, 7, and 8 report a match on IRS SSN, EIN, or both SSN and EIN records, and each can instead mean an ITIN match.
Treat every path as data handling: recheck later on Pending or In Review, which are request states, not match results; retry when irsServiceStatus reports an IRS slowdown or outage; fix the entry on a 1 or 4; check for the earlier request on a 5, which flags a duplicate; confirm the number with the applicant and recheck later on a 2; and on a 6 from a business, which matched an individual's records, confirm the applicant sent its EIN rather than an owner's SSN. Store lastIRSCheckDate with every answer, as you store live or cached for SOS results.
A code 3 on the name the broker typed calls for a rerun under the state-registered name, which is why the sequencing guide to where the SOS registration check fits in a lender's KYB stack runs the TIN match after the registration lookup; if a 3 persists, request a W-9. Ask your compliance team which uses of TIN results it permits, and keep them out of credit rules until it answers: 26 CFR 31.3406(j)-1 extends the tax code's confidentiality rules to details a payor receives through the IRS TIN Matching program and says "A payor may not take into account any such matching details in determining whether to open or close an account with a payee."[30]
What does uccData=true add, and which states does it cover?
Adding uccData=true attaches any lien filings found to the business record, and a separate UCC search endpoint searches by debtor name without a business search, returning up to 30 filings with uccDataCount carrying the total.[9] Coverage is the limit, and the public figures differ: the help center says 11 states,[31] the UCC endpoint lists 13,[9] and the field-by-state spreadsheet marks the flag for ten.[16] Check every state you fund, and keep a separate lien source for states outside the list.
The name you search under matters because the filing office indexes an initial financing statement by the debtor's name.[32] A search under a trade name or a mistyped suffix can miss filings that exist, so run the standalone search under the registered name the SOS lookup confirmed.
What do court records and Business Monitoring cover after the decision?
Court records run asynchronously: the court endpoint requires a callbackUrl and accepts newYork or miamiDade as the jurisdiction,[10] so a business sued anywhere else will not appear.
Business Monitoring is the add-on built for after the decision. You enroll a business by name or sosId plus its state, set a checkFrequency of 1 to 30 whole days, and every check is POSTed to your HTTPS callbackUrl; the first is a baseline, and later checks carry changes with a severity of critical, major, or minor. The reference caps monitoring at 500 businesses per state.[11] The Business Monitoring announcement states the limits: results carry no screenshot, freshness is bounded by your cadence, the scope is the Secretary of State record only, and severity ranks the change rather than the company.
What Does the Audit Trail Look Like When You Hold the requestId Yourself?
What should each verification record contain?
Cobalt's help center describes a common integration pattern: call the API when a profile is created or updated, show the result to analysts, and store the structured payload plus the screenshot URL for audit, with callbacks for slow states.[33] On a direct account, you design that record.
The following is an illustrative, customer-owned verification record, not a Cobalt API schema:
{
"verificationId": "ver-2026-000481",
"providerRequestId": "abc123-def456",
"completedAt": "2026-09-24T14:02:38Z",
"request": {
"searchQuery": "Example Borrower LLC",
"state": "fl",
"liveData": true,
"screenshot": true,
"uccData": true,
"delivery": "callback"
},
"result": {
"sosId": "FL-EXAMPLE-0000001",
"status": "ACTIVE",
"normalizedStatus": "active",
"filingDate": "2021-03-09",
"confidenceLevel": 0.97,
"source": "live",
"screenshotSucceeded": true
},
"evidence": {
"screenshotStoredAt": "evidence-store/2026/09/ver-2026-000481.png"
},
"policy": {
"rulesVersion": "kyb-rules-v7",
"disposition": "auto-accept",
"reviewer": null
}
}Three design choices carry the audit value: providerRequestId, the requestId Cobalt returns on a callback request, joins the original request, the callback, and any later support ticket; source records whether the result was live or cached at the moment of decision; and the policy block records which rules version produced the disposition, so a reviewer can tell a data change from a rule change. Because requestId appears "Only on callback data,"[14] store the retryId for a polled lookup; a synchronous lookup returns neither, so your verificationId is its only join key.
How do screenshot expiry and retention rules change storage design?
Screenshots of the state page can be included with a lookup and show the timestamp and source URL with no Cobalt watermark,[34] but the API reference calls the screenshot link "a short lived URL" and says screenshots are "Not yet available in all states."[14] For documents, the help center says "Links are valid for 3 days by default and can be extended up to 30 days on request."[35] Download the bytes at completion, store them under your own identifier, read screenshotSucceeded before treating the evidence as captured, and confirm screenshot support per state in the field spreadsheet.
How Do You Run the Cutover Without Breaking Underwriting?
How do you use test mode before the first live call?
Cobalt's sandbox mode returns dummy responses to test parameters so developers can validate the integration flow before live lookups,[36] and the test parameter accepts complete, incomplete, failed, retryIdInvalid, and badRequest,[14] which drives each branch without touching a state registry. The sandbox evaluation checklist for testing an SOS API before buying turns those values into an acceptance test, including a repeated callback delivery and a deliberately expired screenshot link.
Test mode covers response shapes only; budget live calls in the states you fund to learn which return officers and how long each takes.
How do you shadow the platform's results before you switch?
Run the direct account alongside the embedded check for at least a month on the same applications, and compare fields rather than badges: sosId, normalizedStatus, filingDate, confidenceLevel, and the live-or-cached source. Cobalt retrieves data directly from state websites or official state APIs rather than from aggregators,[37] so when the two runs disagree, rule out a parameter difference, such as cached on one side and live on the other, before calling it a data difference. Log each with both request identifiers and resolve it before go-live.
Measure the async path in the same period: completion times per state, callbacks that arrived after your timeout, and duplicate deliveries. Those numbers set your timeouts and reconciliation job.
Which rules does your team now own?
Cobalt returns data for your team to review and decide on; the Top 34 questions about the Secretary of State API makes the same point in its answer on alerts. The rules the platform held implicitly now need an owner and a version number:
• Status mapping. Which normalizedStatus values are eligible, which trigger review, and which decline, with the raw state status stored beside the normalized one.
• Confidence threshold. Your auto-accept, review, and reject bands, starting from the published 0.80 and 0.60 guidance.
• Review routing. What happens to a moderate match, an empty result on a newly formed entity, and an alternatives list with two plausible candidates.
• Evidence retention. How long structured responses and screenshot bytes are kept, under which identifier, and who can access them.
• Re-verification cadence. Which accounts are enrolled in monitoring, at what interval, and which change severities reach a person.
• State exceptions. The documented handling for Delaware and New Jersey status, for states whose responses carry no officers, and for states that regularly exceed your timeout.
What Should the Vendor-Management File Say About the Change?
Why does the oversight picture change when the relationship becomes direct?
Once the data vendor is your direct third party, its due diligence, contract review, and ongoing monitoring are yours to document. For vendor security, request Cobalt's current security documentation and review it yourself. The interagency guidance lists contract provisions that "Provide termination and notification requirements with reasonable time frames to allow for the orderly transition of the activity," and its planning section calls for contingency plans in case an activity must move to another third party or in-house.[5] Ask for the first on the direct agreement, and write the second for the direct vendor before go-live.
What do you ask the platform for before you disconnect?
Before the embedded check is switched off, obtain the platform's verification history for your accounts: request dates, results as displayed, screenshots as files rather than links, and the platform's record identifiers mapped to your new verification IDs. The guidance's contract principles include the third party's obligation to retain and provide timely and accurate information,[5] a fair request of a platform even where no regulator requires it. If the platform cannot export screenshot bytes, record that gap.
When Is the Built-In Integration Still the Right Answer?
Which teams should stay embedded?
An embedded check is sufficient when the platform exposes the fields your policy uses, when your file already stores the screenshot bytes and the request identifier, and when your lien, TIN, and court checks come from sources you chose deliberately. It also suits a team with no engineering capacity for a callback listener. A hybrid also works: keep the platform's check at intake for speed, and open a direct account for the add-on checks and for monitoring after funding.
What does a direct account add, in Cobalt's own terms?
Cobalt integrates with lenders and CRMs for due diligence and merchant verification,[38] and endpoint improvements reach an existing integration without rework.[39] Cobalt lists SOS search in all 50 states and D.C. alongside TIN/EIN, court, and UCC checks,[40] and a direct account can add Business Monitoring,[11] test mode,[36] and a requestId on every callback,[22] which the platform may never have wired in. Each state still returns only what it publishes.
The limits travel with the account: officer data depends on the state, Delaware status is a paid state request, UCC coverage is partial, court records cover two jurisdictions, screenshot links expire unless you download them, and no response makes a credit decision. To map your platform's current field set against a direct integration and review the callback and evidence design before cutover, schedule a workflow review. Bring the platform's parameter list.
.jpg){kind=small}
.png)