Executive Summary: Contractor license verification by state is the practical problem every construction lender hits at intake: each state runs its own board, its own data, and its own lookup tool, so there is no single national source of truth. State contractor boards like California's CSLB license hundreds of thousands of contractors across dozens of classifications, and the verification path differs in every jurisdiction.[1] This guide maps which states Cobalt's Contractor License API confirms today, how fast a check returns, what the API needs as input, and how to route the states it does not cover.
Why does contractor license verification by state vary so much?
What makes contractor licensing fragmented?
There is no unified national contractor license database. Each state operates its own board with its own status definitions, classifications, and renewal rules. Multi-state exam accreditation through organizations like NASCLA helps standardize testing, but it does not create a single queryable record across all states.[2] A lender funding contractors in several states is effectively dealing with several separate verification systems.
Why does a lender care about license status?
A lapsed, suspended, or revoked contractor license is a repayment and collateral signal. A contractor who cannot legally operate may lose contracts, face fines, or trigger mechanic's lien disputes that complicate recovery on a funded project.[3] Verifying license status at intake gives underwriting an independent control instead of relying on the applicant's word.
Which states does Cobalt's Contractor License API confirm?
What is the confirmed state coverage matrix?
Cobalt's Contractor License API confirms four states today. Each maps to a specific state authority. The lender supplies the license number and the state code; the API returns status and detail pulled from that state's board.
| State | API state code | Authority behind the data | Returned signal | Action |
|---|---|---|---|---|
| California | `ca` | CSLB (Contractors State License Board) | Active / expired / suspended / revoked | Verify status before funding |
| Florida | `fl` | DBPR Construction Industry Licensing | Status, number, expiration, type | Verify status before funding |
| New York | `ny` | NYC Department of Buildings | Status, number, expiration, type | Verify status before funding |
| Texas | `tx` | TDLR (Licensing and Regulation) | Status, number, expiration, type | Verify status before funding |
What about Oregon and other states?
Be honest with operations here: only those four states are confirmed. Oregon is sometimes referenced in product materials, but its availability is not confirmed and should be routed to Cobalt sales rather than promised. Any state outside CA, FL, NY, and TX should go to the explicit fallback path described below, never silently cleared.
What does the Contractor License API actually return?
Which data points come back?
The documented return fields are license status (active, expired, suspended, or revoked), license number, expiration date, license type or classification, and disciplinary actions where the state makes them available. Disciplinary data varies by state, so treat its absence as "not reported here," not as "clean."
What does the API not return?
The API does not return bonding or insurance status as a documented field. It does not pull from NASCLA, NMLS, or the California DCA umbrella; those are external authorities you can consult directly but they are not Cobalt data sources.[4] It also does not cover non-construction professional licenses such as medical, legal, or financial-advisor credentials.
How fast is contractor license verification, and what does the call look like?
What is the verification speed?
The Contractor License API is asynchronous and delivers through a callback. Typical processing runs about 30 to 60 seconds. There is no synchronous response and no documented polling mechanism for this endpoint, so the integration is built around receiving the callback rather than blocking on a response.
What is the input constraint?
Search is by license number, not by business name. The lender must collect the license number at intake. This is the single most important integration constraint: if the application form does not capture the license number, the check cannot run. Build the intake form so the license number is a required field for construction borrowers.
curl --location 'https://apigateway.cobaltintelligence.com/contractorSearch?licenseNumber=123456&state=ca&callbackUrl=https://yourapp.example.com/cobalt/callback' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'The verification question is not whether the borrower says the license is current. It is whether the issuing state board confirms active status before money moves, and whether your workflow has a defined answer for every state the API does not cover.
How should a lender route states the API does not cover?
What is the fallback path?
For any state outside CA, FL, NY, and TX, route the file to a fallback: a direct lookup on that state's contractor board or a manual verification step. Florida's own portal and Texas TDLR both expose public "verify a license" tools, and most states publish similar lookups.[5][6] The rule is the same one good underwriting always applies: missing coverage is not a clean result.
Why does silent clearance create risk?
If an unsupported state quietly passes through as "verified," the lender has a hidden gap. A revoked license in an uncovered state looks identical to a confirmed-active license in a covered one. An explicit fallback flag forces a human to close the loop, which preserves the audit trail and the decision logic. This mirrors the unsupported-state handling in a pre-funding UCC lien search workflow, where coverage limits route to fallback rather than auto-clear.
How does license verification fit the broader risk stack?
What runs alongside the license check?
For construction lending, the common stack is Secretary of State entity verification, then contractor license verification, then court records for litigation and judgment context. Each layer answers a different question: the entity exists, the license is current, and no judgment is sitting against the business. Compliance screening such as OFAC sits alongside this, as covered in BSA/AML for alternative lenders.
Who owns the decision?
Cobalt is a data source, not a decisioning engine. The API confirms what the state board reports. The lender sets the rule for what an expired or suspended license means for approval, conditions, or decline. Cobalt provides the verified status; the lender owns the underwriting decision.
What implementation checklist should teams use?
What should the first version include?
1. Make license number a required intake field for construction borrowers.
2. Route covered states (CA, FL, NY, TX) to the Contractor License API by number.
3. Receive results via callback and store status, number, expiration, type, and any disciplinary detail.
4. Flag expired, suspended, or revoked status for underwriter review per your policy.
5. Route every other state, including Oregon, to a defined fallback lookup or manual check.
6. Store the raw response, the parsed status, and the decision reason for audit.
How can a lender start verifying licenses?
A practical first step is to map your construction borrower states against the four confirmed (CA, FL, NY, TX) and define the fallback path for every other state. To see the Contractor License API return live status against a real license number, you can book a Cobalt demo.
.jpg){kind=small}
.png)