Executive Summary: Contractor license status confirms who is legally permitted to perform certain work in a jurisdiction, but it does not tell a construction underwriter what that contractor is currently building, how much work is in backlog, or when jobs will complete. This article separates the credential question from the project workload question, offers a credential-to-project evidence matrix, and gives reviewers a worksheet for recording what a license check actually established versus what still requires borrower-provided documentation.
What Does A Contractor License Actually Confirm?
Which fields does a license lookup return?
A contractor license record, whether pulled directly from a state board site or through an API, returns identity and credential fields: business name, license number, license type, status, issue and expiration dates, location, and bond company, amount and expiration fields[1]. California's Contractors State License Board (CSLB) database, for example, returns a status disclaimer noting that the board's records may not yet include all relevant information due to workload, and that complaint disclosure is restricted by statute[2]. None of these fields describe an open project, a signed contract, or a completion schedule. The record answers a narrower question than many underwriters assume it answers: is this credential currently valid, and what class of work does it authorize.
Why does classification matter more than a single status flag?
CSLB organizes contractors into classifications, such as General Building Contractor, Electrical Contractor, or Plumbing Contractor, each covering a defined scope of work[3]. A license active for one classification does not establish that the holder is licensed, active, or currently engaged for a different scope on a specific project. A reviewer who only records "active" without recording the classification and its match to the contracted work has recorded an incomplete answer. We recommend that reviewers store classification alongside status as a matched pair, not as two independent facts checked off separately, because the classification is what ties the credential to the actual construction scope in a loan file. CSLB's own consumer guidance places the license check among hiring precautions, alongside questions about contractor type, contracts, and permits; nothing on that page describes the check as a way to monitor work in progress[4]. A construction lender evaluating draw requests or extending a line against progress needs project-level facts that a status check was never built to supply, and treating classification as decorative metadata rather than a scope boundary is a common and avoidable gap in underwriting files.
How Should Underwriters Separate Credential Status From Workload Evidence?
What is the practical boundary between the two questions?
The credential question asks: is this contractor authorized to perform this class of work in this jurisdiction, as of the record's timestamp. The workload question asks: what projects is this contractor or borrower currently engaged in, what is the backlog value, and when do draws or completions occur. A license record cannot answer the second question because job-level data such as permits, notices of commencement, and associated-contractor lists is fragmented across state, county, and city sources, with only some states maintaining it centrally[5]. Treating a clean license status as proof of active workload conflates two separate evidentiary categories.
Why does this separation change how files get labeled?
A workable policy is to label the recorded conclusion narrowly: "credential status reviewed" rather than "contractor cleared for project." This distinction matters because the next reviewer who opens the file needs to know exactly what was checked. A workable operating principle for any construction underwriting desk:
Record what the source confirmed before recording what the file assumes; a credential timestamp is not a workload snapshot, and collapsing the two into one label removes the ability to audit either one later.
This principle applies whether the reviewer pulled a license record directly from a state site or through an integrated API. Since job-level data is fragmented and not centrally documented across most jurisdictions[5], a reviewer who wants project evidence has to look elsewhere: borrower-submitted contracts, draw schedules, permit copies, or notices of commencement where the state happens to publish them. Some states, including Florida, Georgia, Iowa, Michigan, Ohio, and Utah, maintain notice-of-commencement filings at the state level, but many others push this recordkeeping down to county or city offices, creating thousands of potential lookup points[5]. A construction lender operating nationally cannot assume uniform coverage and should document, file by file, which jurisdiction's evidence was actually obtained.
What Alternative Approaches Exist Before Any Vendor Bridge?
How does a direct state authority lookup work?
The most direct approach is querying the state licensing board's own public search tool. CSLB's Check A License tool lets a reviewer look up a contractor license by license number, business name or personnel name in order to verify information, including complaint disclosure[6]. This is a public lookup taken directly from the licensing authority, but it is manual, one license at a time, and does not export structured data for a loan origination system without additional reviewer effort. The disclaimer attached to CSLB records also notes that complaint disclosure is restricted by statute and that some information may not yet be entered into the board's database due to workload[2], so even a direct lookup carries documented completeness caveats and should be recorded with the date and time it was performed.
How do borrower documents and internal review fill the workload gap?
Because no license record establishes current projects, a second approach is requesting borrower-submitted project documentation directly: signed contracts, draw schedules, permit copies, and completion certificates. A third approach is internal review, where underwriting staff cross-reference the borrower's stated project list against any public permit or notice-of-commencement filings available in that jurisdiction, understanding that such filings exist at the state level in only a handful of states and are otherwise scattered across county or city offices[5]. None of these three approaches, direct lookup, borrower documents, or internal review, individually confirms both credential validity and project workload; each addresses one side of the boundary this article describes. A construction lender's policy should specify which combination of these applies to a given loan type before the file is submitted for a credit decision, since none of them functions as an automated determination on their own.
Where Does A Contractor License API Fit In This Workflow?
What does the documented API actually return and require?
Cobalt Intelligence's contractor license search endpoint requires three parameters: licenseNumber, state, and callbackUrl, and returns results asynchronously to the supplied callback rather than in the initial response[1]. The documented state codes for this endpoint are ca, fl, ny, or, and tx in the parameter description, while the endpoint summary on the same page names ca, fl, ny and tx[1]. Either way, this is a short documented list, not a representation of nationwide or all-trades coverage, and it does not include job-level or permit data. The initial 200 response carries only a status message, a requestId, and the callback URL; a file should therefore sit in a "pending callback" state until the completed result actually arrives, rather than being treated as checked at submission time[1]. When the request is complete, the callback body includes fields such as businessName, licenseNumber, licenseType, status, normalizedStatus, issue and expiration dates, location fields, and bond company, bond amount and bond expiration date[1]. If a required parameter is missing, the API returns a 400 status with a message stating that license number, state, and callback URL are required[1].
How should contractor license numbers be stored before calling the API?
Cobalt's help documentation recommends storing contractor license numbers in a dedicated database field rather than a generic custom attribute field, because a dedicated field produces consistent formatting and reduces integration errors when the data is sent to the API[7]. This is a data hygiene recommendation, not a claim about coverage or accuracy of the underlying state record. Reviewers should also expect that job-level data, including permits and associated-contractor lists, remains fragmented and is not a documented universal output of this or any single API, since state, county, and city jurisdictions maintain such records unevenly[5]. A construction lender evaluating this tool should treat the returned callback fields as a documented credential snapshot for the listed states, with project workload evidence sourced separately through borrower documents or jurisdiction-specific permit lookups.
What Does A Credential-To-Project Evidence Matrix Look Like?
Which fields belong in each column?
A matrix separates what a license record confirms from what remains open for project-level evidence. The columns below reflect fields documented in the CSLB source and the Cobalt API callback structure, alongside a plain description of the workload gap that credential data alone does not close.
| Credential Field (Documented) | Source | What It Confirms | Project Workload Gap Remaining |
|---|---|---|---|
status / normalizedStatus | API callback[1] | Credential validity at record timestamp | No current project, contract, or draw evidence |
licenseType | API callback[1] | Authorized scope classification | No confirmation contractor is engaged on the borrower's specific scope |
expirationDate | API callback[1] | Credential lapse risk window | No link to project timeline or draw schedule |
businessName / dbaName / alternateNames | API callback[1] | Names the state associates with the license | No proof the license holder is the counterparty on the borrower's contract |
| Classification detail | CSLB classifications[3] | Scope boundary for licensed work | No confirmation of active backlog within that scope |
| Complaint disclosure (restricted) | CSLB disclaimer[2] | Limited public complaint history, where disclosable | Not a completion or performance record for any specific project |
| Permits / notices of commencement | State/county/city, fragmented[5] | Some states show filed notices centrally | Most jurisdictions require manual county/city lookup |
How should a reviewer read gaps in this table?
Each row shows a documented field paired with the workload question it cannot answer. A reviewer should not check a single "clear" box that spans both columns; the credential column and the workload column require independent evidence trails. Where the jurisdiction is not one of the states with documented API coverage, or where job-level filings are not centralized, the matrix should show "not obtained" rather than leaving the cell blank, since a blank cell is easy to misread later as "not applicable."
How does the license holder's identity fit into the matrix?
The name row deserves its own review step, because a license can be valid and still belong to a different party than the one the borrower's contract names. The documented callback carries businessName, dbaName, and an alternateNames list, and the CSLB search tool separately allows lookup by business name or by the personnel name associated with a license[1][6]. We recommend comparing those returned names against the exact counterparty named in the construction contract and against the borrower's own legal name, and recording the result as a separate line: "license holder matches contract counterparty," "matches through a listed alternate name," or "does not match." The same discipline used to resolve a submitted DBA against a registered legal entity before business verification applies here; a plausible trade name should not be allowed to select the license holder silently[8]. A name mismatch is a distinct finding from a credential lapse or a workload gap, and it needs its own resolution before the credential can be credited to the project at all.
What Should A Borrower Document Request Include?
Which project-specific documents close the workload gap?
Since license and credential records do not establish current projects, backlog, or completion status, a construction lender's document request to the borrower should ask for materials the license record cannot supply: signed construction contracts naming the contractor and scope, current draw schedules, permit copies from the relevant jurisdiction, and any notices of commencement filed where the state or county publishes them. Where the project falls in a state with centralized notice-of-commencement filings, such as Florida, Georgia, Iowa, Michigan, Ohio, or Utah, the borrower or reviewer may be able to supplement with a public filing lookup[5]; elsewhere, the borrower's own documentation may be the only available evidence.
How does a document request avoid overlapping with the credential check?
A workable policy keeps the two requests distinct. The credential check, whether pulled directly from CSLB or through an API lookup, answers whether the license is active and what classification it covers[6]. The document request answers what the contractor is actually doing right now. A reviewer combining both into a single generic "verification complete" note removes the ability to tell later which question was actually answered. We recommend a written request template listing: (1) executed contract or subcontract copies, (2) draw schedule with milestone dates, (3) permit numbers and issuing jurisdiction, (4) any notice of commencement filed for the project, and (5) a borrower attestation of current backlog value across all active jobs. None of these documents are validated by the license lookup itself; they are separate evidence categories that the lender's underwriting policy, not any single data source, determines are required for the credit decision.
How Does One Illustrative Worked Case Show The Boundary?
What does the scenario involve?
Consider an illustrative example, not an observed transaction: Borrower A applies for a construction line secured by a project where Entity B is listed as the general contractor. The underwriter runs a license lookup for Entity B's license number in a documented state, and the callback returns a status of "Active", a licenseType of "General Building Contractor", and an expirationDate roughly a year out[1]. The underwriter records this as a positive credential finding. Separately, the loan file lists a project address, an estimated draw schedule running about eighteen months, and a stated backlog of three concurrent projects for Entity B.
What must the reviewer confirm before treating the file as complete?
The license callback confirms only that Entity B holds an active credential of the stated classification as of the query date[1]. It says nothing about whether Entity B is actually engaged on Borrower A's project, whether the stated three-project backlog is accurate, or whether draws align with any real construction milestone. Two further observations belong in the file. First, the returned businessName should be compared with the contractor named in the contract; if the contract names "Entity B Construction" while the license record shows "Entity B Builders Inc" with no matching alternate name, that is an open identity item, not a formatting footnote. Second, the expirationDate sits inside the eighteen-month draw window, so the worksheet should carry a renewal re-check date rather than treating a one-time active result as valid for the life of the loan. The reviewer should then request the signed contract naming Entity B for this specific project, a current draw schedule, and, if the project sits in a jurisdiction with centralized notice-of-commencement filings, a copy or confirmation of that filing[5]. Below is an illustrative customer-owned review record showing how a reviewer might document this separation internally. This is a proposed recordkeeping format only, not a Cobalt output.
{
"record_type": "illustrative customer-owned review record",
"file_id": "application-example-1",
"borrower": "Borrower A",
"contractor_entity": "Entity B",
"credential_check": {
"source": "state-license-lookup",
"status": "Active",
"licenseType": "General Building Contractor",
"expirationDate": "not disclosed in this example",
"license_holder_matches_contract_counterparty": "pending name comparison",
"renewal_recheck_date": "not disclosed in this example",
"reviewed_by": "underwriter-initials",
"reviewed_date": "not disclosed in this example"
},
"project_workload_evidence": {
"signed_contract_obtained": false,
"draw_schedule_obtained": false,
"permit_or_notice_of_commencement_obtained": false,
"borrower_backlog_attestation_obtained": true,
"outstanding_items": [
"signed contract copy",
"draw schedule",
"permit or notice of commencement where jurisdiction publishes it"
]
},
"reviewer_note": "Credential status confirmed active for documented classification. Project workload evidence remains incomplete pending borrower document submission."
}What Does A Decision Table And Reviewer Checklist Look Like In Practice?
How should reviewers route a file based on what evidence exists?
| Scenario | Credential Check Result | Project Evidence on File | Recommended Routing |
|---|---|---|---|
| A | Active, classification matches scope, holder matches contract counterparty | Full contract, draw schedule, permit copy | Proceed per lender's standard construction underwriting policy |
| B | Active, classification matches scope | No contract or draw schedule submitted | Hold for borrower document request; do not treat as project-cleared |
| C | Active, classification does not match contracted scope | Contract submitted | Escalate for classification review; scope mismatch is a separate finding[3] |
| D | Expired or status not active | Any level of project documentation | Escalate; credential lapse is independent of workload evidence and requires resolution |
| E | Not in a documented API-covered state | Any level of project documentation | Use direct state authority lookup or manual verification; do not assume unsupported states are clear[1] |
| F | Active, but license holder name differs from the contract counterparty | Any level of project documentation | Resolve the legal-entity versus trade-name question before crediting the license to the project[8] |
What belongs on the reviewer worksheet?
We recommend a short checklist attached to every construction file before it moves past initial underwriting review:
• Credential classification recorded. Confirm the license classification matches the contracted scope of work, not just an active status flag[3].
• Source and timestamp logged. Record whether the check came from a direct state lookup or an API callback, and the date of that record[6].
• Jurisdiction coverage confirmed. Note whether the state is within documented API coverage or required a manual state-site lookup[1].
• License holder identity compared. Record whether the returned business, DBA, or alternate name matches the contract counterparty, and how any difference was resolved[1].
• Project evidence itemized separately. List contract, draw schedule, and permit or notice-of-commencement status as distinct line items, not folded into the credential note[5].
• Outstanding items dated. Any missing document should carry a follow-up date rather than remain an open-ended gap, and an expiration inside the project window should carry a renewal re-check date.
This worksheet is a proposed internal control, not a vendor feature, and each lender should adapt it to its own construction lending policy.
What is the strongest objection and why is it only partly right?
The most common objection is that an active license already answers the question that matters: is this contractor legally allowed to do the work. If the credential is active and the classification fits, some underwriters argue additional project documentation is redundant paperwork. This objection has a narrow truth to it. For the credential question alone, an active status from CSLB or a documented API callback is sufficient evidence that the license exists and is current as of that record[1][6].
The objection stops applying the moment the underwriting question shifts from credential validity to project cash flow. A construction loan is not secured by the existence of a license; it is secured by the completion of a specific, financed project. Backlog, draw timing, and completion risk are workload questions that no license record, whether pulled from CSLB directly or through Cobalt's documented callback fields, is built to answer[1][5]. CSLB's own disclaimer notes that its database may not yet reflect all relevant information due to workload constraints on the board itself[2], which further limits how much weight even a clean credential check can carry. The honest answer is that an active license is sufficient for the credential question only; underwriting project cash flow requires project-specific evidence gathered under the lender's own policy, separate from any license lookup. Related coverage on why an active license is not enough for construction lending, and on specialty trade coverage gaps across HVAC, electrical, and plumbing boards, expands on this same boundary from different angles[9][10].
For lenders who want to see how the documented contractor license lookup fits into a broader borrower-identity workflow, the practical next step is to bring a concrete file, including the states and license numbers involved, to a walkthrough at Cobalt's demo page and evaluate the callback fields against your own construction underwriting policy directly.
.jpg){kind=small}
.png)