Executive Summary: How construction lenders should approach specialty license verification for HVAC, electrical, and plumbing trades, where coverage honesty matters more than for any other license type. The goal is not to promise that one API confirms every specialty trade in every state. The goal is to make one funding decision easier to defend when specialty trade licenses map to different state boards, sit at different levels of government, and are covered unevenly by any single data source. The core problem is that teams assume a specialty license verification workflow behaves like a national database, then route a file as clean when the relevant HVAC, electrical, or plumbing credential was never actually confirmed. Cobalt's Contractor License Verification API covers select states only, and returns license status, license number, expiration date, and disciplinary actions where available at one credit per lookup.[1] The trades themselves are licensed by different authorities, from state boards like California's CSLB to Texas TDLR trade licensing.[2][4] Cobalt should be positioned as a data source, not a decisioning engine.
Why does specialty trade licensing complicate verification?
What operational risk does this remove?
The lender is not collecting a specialty license record for decoration. The lender is trying to remove a specific uncertainty before a construction file advances. For HVAC, electrical, and plumbing work, the uncertainty is compounded, because the credential a reviewer needs may be issued by a state trade board in one state, a state contractor board in another, and a local authority in a third. A useful workflow turns that uncertainty into a small set of routes: clear, correct, retry, unsupported, or manual review.
Specialty trades are where coverage honesty matters most. A general status flag hides the fact that an HVAC license in one state and a plumbing license in another are confirmed by different sources with different fields. A workflow that pretends otherwise will label files clean that were never verified. The safer posture treats specialty verification as a set of source-specific answers, each with an explicit coverage label.
How do specialty trades map to different boards?
There is no single national body that licenses HVAC, electrical, and plumbing contractors. Some states license these trades through a dedicated department, some through a contractor board, and some leave parts of the work to local jurisdictions. That fragmentation is the central fact of specialty verification.
| Trade example | Typical licensing authority | Verification implication |
|---|---|---|
| Electrical in California | State contractor board classification | Confirm classification and status on the state record |
| Electrical in Texas | State trade department | Confirm the trade license on the state record |
| HVAC in Florida | State construction licensing | Confirm the license on the state record |
| Plumbing in a non-covered state | State or local authority varies | Route to manual verification against the correct board |
| Any trade in a local-permit jurisdiction | City or county authority | Confirm at the jurisdiction level, not a state source |
Which buyer should care most?
• VP Risk in construction lending. This buyer needs faster separation between specialty files that a covered source can confirm and files that require manual verification.
• Compliance. This buyer needs source evidence and documented exception handling that survives an audit.
• CTO or head of engineering. This buyer needs a pattern that can be logged and changed without rewriting credit policy.
• Operations. This buyer needs fewer late-stage surprises when a specialty trade turns out to be outside covered coverage.
The article should not imply that a specialty lookup approves a loan. It should show how one evidence layer reduces ambiguity while the lender's policy takes over. Cobalt's state coverage guide is the honest map of where specialty license evidence is directly available and where it is not.[8]
What should the lender verify first for a specialty trade?
What is the minimum viable workflow?
The minimum viable workflow is to identify the specific trade and the state, check whether that combination is inside covered coverage, run the API lookup where it is, and route to documented manual verification where it is not. The contractor name and license number should be captured, and the raw response stored with a timestamp and an explicit coverage label before any internal mapping.
The specialty record is only useful if the lender keeps the source result separate from its own policy interpretation, and keeps the coverage label visible. An active HVAC license in a covered state is a source fact. Whether the file was actually verifiable at the source is a coverage fact. Mixing coverage into a flat status is the fastest way to make an unverified specialty file look clean.
Why is coverage honesty the core discipline?
For specialty trades, the most dangerous failure is a false positive of coverage, not a false positive of status. A workflow that returns clean when it simply could not check the trade in that state has told the reviewer nothing while looking like it told them something. The discipline is to make unsupported coverage a first-class outcome that routes to manual review, never a silent pass. Cobalt covers select states only, so honest specialty verification means naming the boundary in every file.
This is different from the discipline a general license workflow needs. In a single-trade, single-state file, the main risk is misreading a status, and a careful reviewer catches it. In specialty work, the main risk is that the file was routed as verified when the trade and state combination was never inside coverage at all. No amount of careful status reading fixes a coverage gap that the workflow never surfaced. That is why specialty verification puts the coverage label ahead of the status field: a status of active means nothing until the file has confirmed that the source could actually answer for that trade in that state. Naming the boundary is not a caveat added at the end. It is the first decision the workflow makes.
What limitation should stay visible?
Cobalt's Contractor License Verification API covers select states only: California, Texas, New York, Florida, and Oregon. Within those states it returns license status, license number, expiration date, and disciplinary actions where available, but coverage of a specific specialty trade still depends on what the state source records. The product does not offer nationwide specialty coverage, native monitoring webhooks, or built-in scoring. The right posture is to state that limitation plainly, then design the route around it.
What does a specialty API workflow actually return?
How does Cobalt fit without overstating the product?
Cobalt's Contractor License Verification API screens a submitted contractor identity against a covered state source and returns license status, license number, expiration date, and disciplinary actions where available.[1] A representative request or downstream workflow event for a specialty lookup looks like this:
{
"trade": "hvac",
"state": "FL",
"source": "state_license_record",
"coverageCheck": "covered_or_manual",
"creditCost": 1,
"owner": "construction_underwriting"
}The request is only the start. The lender should persist the raw response, map the result into internal statuses, and show the reviewer why a file cleared, corrected, retried, or moved to manual review. A specialty lookup for a trade and state that the source does not cover should return an unsupported-coverage outcome that routes to manual verification, not a clean status.
Which fields should stay separate?
The most common implementation mistake is turning source fields, coverage, and policy fields into one flat status. A source can return an active license, an expired license, a suspended license, unsupported coverage for the trade or state, a timeout, or a valid record. The lender's policy can then route that outcome to correction, retry, hold, manual review, or continue.
| Field group | Stored example | Why it matters |
|---|---|---|
| Applicant input | Contractor name, license number, trade, state | Shows what the applicant or system supplied |
| Source result | Status, license number, expiration date, disciplinary flag | Shows what the source returned |
| Coverage label | Covered, unsupported state, unsupported trade, source outage | Prevents an unverified trade from looking clean |
| Policy route | Clear, correct, retry, manual review, hold | Shows how the lender interpreted the source |
| Reviewer evidence | Notes, manual verification result, reviewer name, timestamp | Shows who accepted or changed the route |
For specialty trades, the coverage label is not optional metadata. It is the field that keeps an honest workflow honest.
For specialty trades, the most expensive mistake is not a wrong status. It is a clean-looking file that was never actually checked. Make unsupported coverage a visible route, never a silent pass.
How should specialty license exceptions route to review?
Which exceptions are operational, not risk?
Every exception deserves a label. Some are operational, such as a mistyped license number, a source outage, or a trade description that does not map cleanly to a board. Some are risk signals, such as an expired specialty license on active work, a suspended status, or a disciplinary action. And one category is unique to specialty work: unsupported coverage, where the source simply cannot confirm the trade in that state. Treating unsupported coverage as clean is the failure this workflow exists to prevent.
| Result | Likely cause | Recommended route |
|---|---|---|
| Format invalid | Wrong license number or missing field | Ask applicant to correct input |
| Source unavailable | State source outage or timeout | Retry later with bounded backoff |
| Unsupported coverage | Trade or state outside covered coverage | Manual verification against the correct board |
| Expired or suspended license | Real status change on the record | Manual review before funding |
| Active and in scope | Covered evidence aligns with policy | Continue to the next underwriting step |
How do retries stay safe?
Retries should be bounded and tied to technical failures, not to coverage gaps. If a trade and state are outside covered coverage, retrying the same call will never produce an answer, so that path routes to manual verification. If a covered source timed out, a bounded retry is appropriate. A live lookup that returns no matching record for a covered trade is a meaningful signal and should route to review.
Who owns each route?
Ownership should be assigned before the workflow goes live. Engineering owns technical reliability, request shape, logging, and error handling. Operations owns applicant correction loops and the manual verification queue that specialty trades rely on heavily. Risk owns the interpretation of an expired or suspended specialty license. Compliance owns audit and documentation rules. Product or revenue teams can request lower friction, but they should not silently convert unsupported coverage into a clean specialty status.
What should engineering build into the first version?
What should be logged?
The first production version should be small, observable, and recoverable. Store the external source data, the coverage label, and the internal policy routes separately.
• Input snapshot. Store the raw submitted contractor name, license number, trade, state, and normalized values.
• Source response. Preserve the status, license number, expiration date, disciplinary flag, source timestamp, and raw fields before internal mapping.
• Coverage label. Show whether the result was covered, unsupported state, unsupported trade, source-unavailable, or review-required.
• Policy route. Keep the lender's clear, correction, retry, and manual-review route separate from the source data.
• Reviewer action. Log who changed the route, why it changed, and which manual verification result supported the change.
What should dashboards show?
Dashboards should make exception volume visible without pretending that every exception is the same kind of risk. For specialty trades, the coverage rate is the metric that keeps the workflow honest.
| Dashboard metric | What it tells the team | Better follow-up |
|---|---|---|
| Unsupported coverage rate | How often specialty files fall outside covered coverage | Size the manual verification queue realistically |
| Input correction rate | How often license numbers arrive unusable | Improve intake form validation |
| Manual-review rate | How often status requires judgment | Refine thresholds and staffing |
| Retry rate | How often technical failures interrupt the workflow | Improve timeout and backoff handling |
| Expired or suspended rate | How often the record shows a status change | Monitor exposure across the pipeline |
What should not be automated first?
Do not start with automatic decisions for every exception. Start with classification. A mistyped license number needs correction. A source outage needs retry. A suspended specialty license needs policy review. An unsupported trade or state needs a manual verification route, never a silent clean status. Classification before automation protects the team from turning a coverage gap into a false clean file.
What should a buyer ask before approving this workflow?
What questions expose weak implementations?
The buying conversation should focus on source, coverage, and honesty about the boundary. A polished demo matters less than whether the specialty route refuses to fake coverage it does not have.
1. Which trades and states does the source actually cover, and how is coverage labeled?
2. What happens when a specialty trade falls outside covered coverage?
3. What does the response include for active, expired, suspended, and unsupported cases?
4. How is unsupported coverage kept from looking like a clean pass?
5. Which exceptions are automated, and which ones route to manual verification?
6. What evidence is available to defend the funding decision six months later?
What does a practical first rollout look like?
A practical rollout starts with a narrow use case and a small group of reviewers. The lender does not need to cover every trade in every state before getting value from an honest specialty route. It needs one trade, a few covered states, a documented manual fallback, one exception taxonomy, and one readback report. The first week should focus on historical comparison, paying close attention to how many specialty files sit outside covered coverage. The second week should run the API route in shadow mode. The third week should define queue ownership for corrections and manual verification. The fourth week should lock the field map and document the coverage boundary in plain language.
How should the final decision be framed?
The final decision should be framed as coverage-honest workflow fit. Where a trade and state are covered, the API route belongs in the stack and provides clean license evidence. Where they are not, the honest route is manual verification against the correct board, because HVAC, electrical, and plumbing trades map to different authorities and no single source covers them all. Cobalt can provide the covered license data layer, but the lender decides how that layer, and the honest gaps around it, translate into approval, hold, correction, or decline. The reason lenders keep funding under-verified specialty contractors is rarely a missing tool. It is a workflow that hid a coverage gap instead of routing it.[9] Placing specialty verification inside a broader diligence stack keeps the boundary visible.[10]
.jpg){kind=small}
.png)