Executive Summary: A professional license check for marketplace lending answers a specific intake question: does the borrowing business actually hold the credential it needs to legally do the work it does. For construction-adjacent marketplaces funding contractors, that credential is a state contractor license, issued and tracked by boards like California's CSLB.[1] This use case walks through how a marketplace lender verifies a contractor license at onboarding, where Cobalt's coverage is confirmed, and how to route the borrowers and states that fall outside it.
Why does a marketplace lender need a license check at intake?
What risk does an unlicensed or lapsed borrower create?
A marketplace lender funding a construction business is exposed if that business cannot legally operate. A lapsed, suspended, or revoked license can stop the borrower from winning contracts, collecting on completed work, or defending against disputes, including mechanic's lien fights that complicate recovery.[2] For VP Risk and Marketplace Ops, the license is a leading indicator of whether the revenue backing the advance can keep flowing.
Why verify rather than trust the application?
Self-reported status is not a control. A borrower may report a license that expired, was suspended after application, or belongs to a different entity. An independent check at onboarding gives the marketplace an objective input it can apply consistently across every contractor in the book, instead of relying on each applicant's disclosure.
What does "professional license" mean in this use case?
Which licenses does this cover?
Scope this honestly. For Cobalt, "professional license" here means contractor licensing in four confirmed states: California, Florida, New York, and Texas. Contractor licensing itself is fragmented; even with multi-state exam accreditation through groups like NASCLA, there is no single queryable national record.[3] It does not extend to medical, legal, real-estate, or financial-advisor licenses, which sit under separate boards such as California's DCA umbrella.[4] If a marketplace funds those professions, this specific check does not apply and those credentials need a different verification path.
Which states are confirmed?
| State | API state code | Authority behind the data | Intake action |
|---|---|---|---|
| California | `ca` | CSLB | Verify before activation |
| Florida | `fl` | DBPR Construction Industry Licensing | Verify before activation |
| New York | `ny` | NYC Department of Buildings | Verify before activation |
| Texas | `tx` | TDLR | Verify before activation |
Oregon and every other state are not confirmed. Route Oregon to Cobalt sales and route all other states to a fallback lookup. Do not let an uncovered state pass as verified.
How does the onboarding check run end to end?
What does Marketplace Ops collect at intake?
The single hard requirement is the license number. The Contractor License API searches by license number, not by business name, so the onboarding form must capture the number as a required field for contractor borrowers. If the number is missing, the check cannot run, so the form design is the first place this use case succeeds or fails.
What does the API call look like?
curl --location 'https://apigateway.cobaltintelligence.com/contractorSearch?licenseNumber=987654&state=fl&callbackUrl=https://marketplace.example.com/cobalt/callback' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'
The endpoint is asynchronous and delivers through a callback, typically in 30 to 60 seconds. That fits onboarding well: the marketplace can hold activation in a pending state while the callback resolves, rather than blocking the applicant on a synchronous response.
How should Ops turn a license result into an onboarding action?
What signals map to what actions?
| Signal | Onboarding action | Why it matters |
|---|---|---|
| Active license, covered state | Continue activation | Issuing board confirms legal operation |
| Expired or suspended | Route to risk review | Borrower may not be able to operate or collect |
| Revoked | Hold or decline per policy | Strong signal the business cannot legally perform |
| Disciplinary action present | Route to risk review | Context that may change terms |
| Uncovered state or Oregon | Fallback lookup, no auto-clear | Coverage gap must be closed by a human |
Who sets the threshold?
Cobalt is a data source, not a decisioning engine. The API reports what the state board says. VP Risk sets the rule for what expired, suspended, or revoked status means for activation, pricing, or decline. Cobalt confirms the status; the marketplace owns the decision and the audit trail.
The onboarding question is not whether the contractor says the license is current. It is whether the issuing state board confirms it before the marketplace activates the borrower, and whether Ops has a defined answer for every state the check does not cover.
How does the marketplace handle states the check does not cover?
What is the fallback path?
For any state outside CA, FL, NY, and TX, route the borrower to a fallback: the state board's public verify tool or a manual review step. Florida's portal and Texas TDLR both publish public license lookups, and most states offer an equivalent.[5][6] The principle matches the unsupported-state handling in a pre-funding UCC lien search workflow: missing coverage routes to fallback, never to silent clearance.
Why does this matter for a high-volume book?
Marketplace lending runs on throughput, so the temptation is to auto-pass anything the API does not flag. That is exactly how a revoked license in an uncovered state slips through. An explicit fallback flag keeps the gap visible and forces a human to resolve it before activation.
How does the license check fit the rest of onboarding?
What runs alongside it?
For a construction-adjacent marketplace, the practical stack is Secretary of State entity verification, then contractor license verification, then court records for litigation and judgment context. Compliance screening such as OFAC runs alongside, as covered in BSA/AML for alternative lenders. Each layer answers a separate onboarding question, and the license check is the one that confirms the borrower can legally do the work.
What should engineering store?
Store the raw callback response, the parsed status, the license number and expiration, any disciplinary detail, and the activation decision reason. The raw record proves what was checked. The parsed fields drive routing. The decision reason explains, months later, why the borrower was activated, conditioned, or declined.
What onboarding checklist should the team use?
What should the first version include?
1. Require the license number on the contractor intake form.
2. Send covered-state borrowers (CA, FL, NY, TX) to the Contractor License API by number.
3. Hold activation pending while the callback resolves.
4. Apply risk rules to expired, suspended, revoked, or disciplinary results.
5. Route Oregon to sales and all other states to a fallback lookup.
6. Store raw response, parsed status, and activation reason for audit.
How can a marketplace start checking licenses at onboarding?
Begin by making the license number a required intake field for contractor borrowers in the four covered states, then wire the rest to a fallback. To see the Contractor License API return live status during an onboarding flow, you can book a Cobalt demo.












.png)