Every verification vendor we have encountered follows the same playbook. They pick a category — payroll, banking, insurance — and start signing API partnerships one provider at a time. Each new source means months of business development, legal negotiation, technical integration, and ongoing maintenance. Coverage grows linearly with deal velocity. It is a fundamentally slow model.
We built Burnt on a different premise. The internet already has the trust infrastructure needed to verify data from virtually any source. We just had to build on top of it.
Why does traditional verification require partnerships?
The standard model works like this: a verification company approaches a data source — say, a payroll provider — and negotiates access to their API. Once the deal is signed, engineers build and test the integration. The verification company can now verify data from that specific provider. Then they move on to the next one.
This model has obvious constraints. Each integration is a standalone project. The business development cycle alone can take three to six months. Legal teams review data-sharing agreements. Engineering teams build and maintain connectors. When the source changes their API (and they do), the integration breaks and needs updating.
The result is that even the largest verification platforms, after years of operation and significant investment, cover only a few hundred sources. That sounds like a lot until you consider how many organizations issue data that someone might need to verify. Every employer. Every bank. Every insurer. Every airline. Every government agency. Every utility. The long tail is effectively infinite, and the API partnership model will never reach it.
The coverage ceiling
There is a harder problem beneath the operational one. Many data sources will never agree to an API partnership. A small regional employer has no incentive to integrate with a verification platform. A government portal was not designed to serve third-party API requests. A foreign institution may have no legal basis to share data with a US-based vendor. The partnership model does not just scale slowly — it has a structural coverage ceiling that no amount of sales effort can break through.
How does permissionless verification work?
Permissionless verification sidesteps the partnership model entirely. Instead of asking a data source for API access, we use protocols the source already participates in — without their active involvement or even their knowledge.
Three protocols make this possible:
- DKIM for email. When any organization sends an email, their mail server attaches a DKIM signature — a cryptographic proof that the email came from that domain and has not been tampered with. Burnt verifies this signature using the sender's public DNS key and extracts the specific fact needed from the authenticated email. The sender does not need to do anything. The signature is already there.
- HTTPS/TLS for websites. Every HTTPS website presents a TLS certificate that proves the server's identity. When a user logs into their account on any website, the session is cryptographically authenticated. Burnt verifies the server's identity through the certificate chain and extracts verified data from the authenticated session. The website does not need to provide an API.
- OAuth for portal access. Many platforms already support OAuth for user authentication. When a user authenticates with their account, Burnt can access the specific data the user consents to share. The platform's existing authentication infrastructure is the integration.
Each of these protocols operates at internet scale. They are not niche standards that require adoption. They are foundational infrastructure that virtually every organization already uses. A company that sends email is already producing DKIM-signed statements. A company that runs a website is already presenting TLS certificates. Neither needs to opt in to anything new.
We do not need United Airlines' permission to verify a booking confirmation they sent. The DKIM signature they already attach to every email is all the permission we need.
What does this mean for coverage?
The coverage difference between partnership-based and permissionless verification is not incremental. It is categorical.
A traditional verification platform might support 200 or 300 data sources after years of integration work. Those sources tend to cluster in well-served verticals like payroll and banking, where the business case for API partnerships is strongest. Outside those verticals, coverage drops off sharply.
Permissionless verification covers any organization that sends email or operates a website. That is not a subset of the internet. That is the internet. Airlines, hospitals, government agencies, utilities, membership programs, small businesses, foreign institutions, university registrars — every one of them becomes a potential verification source without a single partnership conversation.
Coverage that scales automatically
There is a compounding effect. When a new company launches and starts sending emails, it becomes a verification source automatically — the moment it configures DKIM on its mail server (which virtually every email provider does by default). When a government agency launches a new online portal, it becomes a verification source automatically — the moment it obtains a TLS certificate (which is required for HTTPS). Coverage does not grow because we signed a deal. It grows because the internet grew.
What are the technical tradeoffs?
Permissionless verification is not a strict superset of API-based verification. Each approach has distinct strengths, and understanding the tradeoffs matters.
API integrations provide structured data. When you have direct API access to a payroll system, you get clean, typed fields: annual salary, start date, employment status. The data arrives in a predictable format that is easy to process programmatically.
Permissionless verification works with unstructured data. An email contains natural language and HTML formatting. A web portal displays information in a layout designed for human consumption, not machine parsing. Extracting the relevant fact requires parsing that unstructured content — which is now reliable thanks to advances in language models, but it is a different kind of processing than reading a JSON API response.
API integrations are bounded by access. You can only query what the API exposes. If the payroll API does not include a field you need, you cannot get it. And you can only query sources you have integrated with.
Permissionless verification is bounded by what the user can see. If the data is visible on a web page or present in an email, it can be verified. The coverage is broader, but the data is less structured.
Why the combination is powerful
The strongest verification infrastructure uses both approaches. API integrations where they exist and where structured data matters. Permissionless verification everywhere else — which, given the long tail of data sources, means most of the world. The practical result is a system that can verify data from a Fortune 500 payroll provider and a regional credit union with equal confidence, even though one has a public API and the other has only a website and an email server.
The verification industry has operated under the assumption that access requires permission. That each new data source requires a new relationship, a new contract, a new integration. That assumption made sense before DKIM, before HTTPS was universal, before OAuth became the standard authentication pattern.
It does not make sense anymore. The trust infrastructure is already there. We just built on top of it.
Frequently asked questions
Permissionless verification means verifying data from a source without needing that source's cooperation, API access, or partnership. Burnt uses protocols the source already participates in — DKIM signatures on emails, TLS certificates on websites, OAuth for portal access — to verify data without any integration or agreement.
Burnt can verify data from any company that sends DKIM-signed emails or operates an HTTPS website with user accounts. Since virtually every organization does both, coverage is effectively universal. No API partnership or integration is required with the data source.
Traditional verification requires building and maintaining a separate API integration for each data source, which takes months of business development, legal review, and engineering. Burnt uses existing internet protocols that every organization already participates in, so adding a new source requires no partnership work.
For email verification via DKIM, no — Burnt verifies the cryptographic signature independently using the sender's public DNS key. For portal-based verification via HTTPS, the user logs into their own account normally. In both cases, no special notification is sent to the data source.