Alternative lenders processing high volumes of business loan applications need real-time access to verified entity data from Secretary of State offices. An SOS API eliminates the manual verification process that remains an “Achilles heel” for many lenders, delivering registration status, officer information, filing history, and formation details from all 50 states through a single integration. This guide explains exactly what data you can retrieve, how it’s normalized across states, and what to evaluate when choosing an API provider.
What Is Secretary of State API Data and Why Does It Matter for Lenders?
Secretary of State API data is business entity information pulled directly from state government databases. Every business registered in the United States files formation documents with its state’s Secretary of State office. That filing creates a public record containing the business name, entity type, formation date, registered agent, officers, and status. An SOS API retrieves that data programmatically instead of requiring manual lookups on each state’s website.
Why Manual Verification Fails at Scale
For alternative lenders, manual entity verification is an operational bottleneck. A typical verification requires navigating to a state’s business search portal, entering the business name or filing number, reviewing the results, and documenting what was found. Multiply that by hundreds of applications per month across 50 different state websites, each with its own interface and data format, and verification becomes what one underwriting director called their “Achilles heel.”1
The time cost is substantial. Bitty Advance documented spending 175+ hours per month on manual Secretary of State lookups before implementing API automation.2 That represents multiple full-time employees doing nothing but copying data from state websites into underwriting systems.
What Problems Does API Access Solve?
API access solves three core problems for lenders:
The alternative lending industry has seen significant fraud cases where verification failures enabled losses. In 2025, Tricolor Auto Group pledged 29,000 loans to multiple lenders simultaneously.4 While that case involved collateral fraud, the underlying lesson applies: verification must go beyond surface-level checks to examine the underlying data that reveals inconsistencies.
What Core Business Identity Data Can You Retrieve?
The foundation of any SOS API response is business identity data: the basic information that confirms who you’re lending to.
Legal Business Name
The exact name under which the business is registered with the state. This matters because businesses may operate under trade names or DBAs that differ from their legal name. A loan agreement needs the legal name. An API returns it exactly as the state has it on file.
Entity Type
The legal structure of the business: LLC, Corporation, Limited Partnership, or other formation type. Entity type affects everything from personal guarantee enforceability to how you pursue collection. An LLC borrower has different liability exposure than a sole proprietor operating as a general partnership.
State of Formation and Formation Date
Where and when the business was legally created. A Delaware corporation operating in California was formed in Delaware. The formation date establishes business tenure, a standard underwriting factor. A business claiming ten years of operations should have a formation date matching that claim.
Business Address
The principal office address on file with the state. This may differ from the mailing address or operational location the applicant provides. Address mismatches warrant investigation.
Filing Number
The state’s unique identifier for the entity. This number enables precise lookups and prevents confusion between similarly named businesses. “ABC Consulting LLC” may have hundreds of matches across states, but each has a unique filing number.
These five data points establish basic identity. They answer the fundamental question: is this a real, registered business that matches what the applicant claims?
How Does Registration Status Data Impact Lending Decisions?
Registration status is often the first check in any verification workflow. A business must be in good standing to enter contracts, maintain bank accounts, and operate legally. Status problems are immediate red flags.
What Status Values Do States Report?
Each state uses its own terminology. California uses “Active” and “Suspended.” Texas uses “In Existence” and “Forfeited.” Ohio uses “Active” and “Dead.” Florida distinguishes between “Active” and “Inactive” where inactive often just means a late annual report, not dissolution.
This variation creates a normalization challenge. An API that provides raw state responses without normalization forces lenders to maintain translation tables for 50+ different status systems. A well-designed SOS API normalizes these into consistent categories: Active, Inactive, Suspended, Dissolved, and similar standardized values.
What Do Different Statuses Mean for Lending?
Active/Good Standing: The business has filed required reports and paid required fees. It can legally operate and enter contracts.
Suspended/Not in Good Standing: The business has failed to meet ongoing requirements, typically annual report filings or tax payments. In California, “Suspended - FTB” indicates Franchise Tax Board issues. In Illinois, “Not Good Standing (NGS)” means compliance failures. These businesses may have limited ability to enter new contracts.
Dissolved/Cancelled/Dead: The business has been formally terminated, either voluntarily or administratively. Lending to a dissolved entity creates obvious problems.
Pending/Processing: Some states show a pending status for recent filings still being processed. A brand-new business may show as pending until the state completes registration.
Altscore.ai reported eliminating a 15% failure rate on manual verifications after implementing API-based status checks.5 That failure rate represented applications where manual verification missed status problems that the API caught automatically.
What Officer and Registered Agent Information Is Available?
Beyond business identity and status, SOS records often include information about the people behind the business.
Officer and Director Data
Many states require businesses to list officers or managing members in their formation documents and annual reports. The API returns this information where the state makes it publicly available. Typical fields include:
Officer data matters for several reasons. It helps verify that the person signing loan documents actually has authority to bind the company. It can reveal ownership structures relevant to personal guarantee analysis. And changes in officers over time, visible in filing history, can signal business instability or ownership disputes.
Why Officer Availability Varies by State
Not all states make officer information publicly accessible online. Delaware, for example, provides limited officer data through standard searches. California provides officer information through Statements of Information. Nevada keeps more information confidential. An SOS API returns what each state makes available, but lenders should understand that officer data completeness varies significantly by jurisdiction.
Registered Agent Information
Every business must designate a registered agent: a person or entity authorized to receive legal service on behalf of the business. Registered agent data is consistently available across states and includes:
Registered agent information has underwriting value. Frequent agent changes can indicate instability or attempts to evade legal process. A residential address for an agent on a business claiming commercial operations may warrant questions.
How Does Filing History Data Reveal Business Patterns?
Current status tells you where a business stands today. Filing history tells you how it got there. For lenders assessing risk, the journey often matters as much as the destination.
What Types of Filings Appear in History?
Filing history includes all documents submitted to the Secretary of State over the life of the entity:
How to Access Secretary of State Amendments Through API provides detailed guidance on using amendment data specifically for fraud detection and risk assessment.
What Patterns Signal Risk?
Filing history analysis reveals patterns that single-point verification misses:
The First Brands factoring fraud demonstrated how sophisticated lenders missed $2.3 billion in fabricated receivables.6 Multiple tier-one lenders failed to detect the fraud because they relied on relationship-based verification rather than systematic examination of underlying entity documentation and patterns.
What Supplemental Data Sources Complement SOS Records?
Secretary of State data provides the foundation, but comprehensive due diligence often requires additional data sources. Many API providers offer access to supplemental records alongside core SOS data.
UCC Filings
Uniform Commercial Code filings reveal existing liens and security interests against a business. A borrower with multiple existing UCC filings has already pledged assets to other creditors. The collateral you thought you’d secure may already be encumbered.
Court Records
Litigation history shows whether a business is involved in lawsuits, has outstanding judgments, or has filed bankruptcy. A business actively being sued by previous lenders presents obvious risk.
Contractor Licenses
For businesses in licensed trades, contractor license verification confirms the business holds valid licenses required to operate. Lending to an unlicensed contractor means lending to a business that cannot legally perform its stated work.
OFAC and Sanctions Screening
Office of Foreign Assets Control screening ensures the business and its principals are not on prohibited party lists. This is a compliance requirement, not a credit decision, but it must be part of any verification workflow.
Cobalt Intelligence provides SOS data as the core offering, with UCC, court records, and contractor license APIs available for lenders needing the complete picture.
How Do API Providers Normalize Data Across 50 States?
The 50-state normalization problem is significant. Each state designed its own database, terminology, and data formats independently. An API that simply passes through raw state responses leaves lenders to solve the normalization problem themselves.
What Gets Normalized?
Well-designed SOS APIs normalize key fields:
What Remains State-Specific?
Some data cannot be fully normalized because states capture fundamentally different information:
A good API preserves raw state responses alongside normalized fields, giving lenders both consistency and completeness.
Why Timestamps and Screenshots Matter
For audit and compliance purposes, knowing what data the state showed at a specific point in time matters more than having the “latest” data. SOS APIs should provide:
These elements create the “timestamped screenshots for audit defense” that compliance teams require when regulators or auditors examine verification practices.
What Should Lenders Evaluate When Choosing a Secretary of State API?
Not all SOS APIs are equivalent. The differences matter for both operational efficiency and data quality.
Real-Time vs. Cached Data
Some providers maintain cached databases updated periodically. Others pull data live from state sources on each request. The difference matters:
For underwriting decisions, primary source data eliminates questions about freshness. When you verify an entity through a real-time API, you get current state data with a timestamp proving when it was retrieved.
Coverage and Success Rates
All providers claim 50-state coverage. The meaningful metric is success rate: what percentage of lookups actually return data? States have technical issues. Business names have variations. Some providers handle these challenges better than others.
Documentation and Integration Support
API documentation quality affects integration time. Comprehensive docs with code samples in multiple languages enable faster implementation. See Cobalt Intelligence Documentation for an example of developer-focused API documentation.
Proof Points and References
Customer proof points demonstrate real-world performance:
Read How 1West Used Cobalt Intelligence to see how a high-volume lender implemented SOS verification.
Integration Timeline
Most teams integrate a well-documented SOS API in less than one day. The endpoint is straightforward: submit a business name and state, receive structured data back. The implementation complexity comes from deciding how to incorporate that data into existing underwriting workflows, not from the API integration itself.
Conclusion
Secretary of State API data provides the foundation for automated business verification. The core data, including business name, entity type, formation date, status, officers, and registered agent, answers the fundamental question of whether you’re lending to a legitimate, active business that matches applicant claims.
Key takeaways for alternative lenders evaluating SOS API options:
The lenders achieving the best unit economics on verification have moved beyond manual processes. They treat entity verification as automated infrastructure, not a staffing problem.
Schedule a demo to see how Cobalt Intelligence delivers real-time SOS data from all 50 states through a single API integration.
.jpg){kind=small}
.png)