Getting Breach Data Into Your Product: Build, License, or White-Label

Your product needs breach exposure data. Customers keep asking whether their domains show up anywhere, or the roadmap grew an "exposure monitoring" line, or an RFP forced the question last Tuesday. However it started, there are three ways to get the data in: build the pipeline yourself, license an API and put your own experience on top, or white-label the whole capability inside your product.

The short version: build only if breach data is going to be your product. License when breach signal enriches a product that is about something else. White-label when the capability needs to ship this quarter under your brand. The rest of this guide is the honest math behind those three sentences, including the costs vendors do not put on pricing pages, ours included.

What a breach-data capability actually is

The visible part is a search box: an email or domain goes in, breach names come out. The invisible part is why this category is harder than it looks:

• Acquisition never ends. Across the 776 breaches in our catalog (as of August 2026), the median gap between a breach happening and its data surfacing publicly is 1,591 days, more than four years. 36 percent took over six years. Data trickles out on no schedule, forever, from forums, leak sites, and channels that appear and vanish. A pipeline is not a project; it is a standing operation.
• Verification is the product. Anyone can index rumors. Deciding what is genuine, what is a recycled combolist, and what is a fabrication padded into an old dump is analyst work, breach by breach. Get it wrong in one direction and your product alarms users over nothing; wrong in the other and you miss the exposure they paid you to catch.
• Normalization is unglamorous and endless. Every dump arrives in a different shape. Ours holds 776 breaches averaging 4.4 exposed data classes each, and every one of them had to be mapped to a consistent schema before an API could serve it.
• Scale is real. Our corpus stands at more than 11.5 billion records. Storage is the cheap part; making that queryable in well under a second, safely, is not.
• There are lines to hold. Serving raw passwords is a line responsible providers do not cross. Deciding what your product will refuse to do is part of the build.

Keep that iceberg in mind; all three paths are just different answers to "who runs it."

Path 1: Build it in-house

When it is right: breach data IS your product, you need sources nobody licenses, or custody requirements genuinely bar third-party data. Those are real cases. If one is yours, build.

The cost, in adjustable assumptions rather than a scary number. Run your own figures through this; ours are deliberately conservative:

• A data engineer to build and run acquisition and normalization, and a security researcher to source and verify. Two loaded salaries, most markets, lands between $250K and $400K a year combined.
• Infrastructure for double-digit billions of records with sub-second lookups: real but minor next to payroll.
• Nine to twelve months before the pipeline reaches useful coverage, during which your product ships nothing.
• Then the part that surprises teams: year two costs almost as much as year one, because acquisition and verification never stop. The four-year median surfacing lag means the breach that matters to your customers next year is one your team must catch next year.

That is how "add breach data" quietly becomes a half-million-dollar first year with a permanent six-figure tail. Not because anyone padded the estimate, but because the operation never ends. If the capability is not your core product, this money buys you an undifferentiated copy of something you could license.

Path 2: License an API, build your own experience

When it is right: breach exposure enriches your product but is not its identity. An MSP platform adding domain health to its dashboard, an IAM product flagging exposed accounts at onboarding, a security tool adding an exposure panel. You own the UX and the customer; the data problem is someone else's payroll.

The honest tiering, because this market's pricing spans three orders of magnitude:

• Self-serve API access starts near nothing. Our keyless free tier exists for exactly this kind of evaluation, and xonAPI+ starts at $5 a month. If what you need is an email-exposure signal at product scale, this tier of the market is genuinely sufficient, and not just from us.
• Mid-tier platform licensing adds domain-wide views, alerting workflows, and volume. This is where xonThreatIntel+ lives, with pricing on the site, not behind a sales call.
• You genuinely need a five-figure threat-intel contract when you require breadth far beyond email and domain exposure (malware infrastructure, actor tracking), contractual SLAs with legal teeth, analyst support on call, or indemnities your compliance team insists on. Those vendors are not overpriced for what they sell; they are overpriced for what most product integrations actually use, which is the exposure signal.

The test that cuts through it: write down the three API calls your feature actually makes. If they are all "is this email or domain exposed, and in what," you are shopping in the first two tiers no matter what the enterprise vendor's deck says.

Path 3: White-label the capability

When it is right: the capability has to exist inside your product, under your brand, on a quarter's timeline, and building a bespoke experience on a raw API is still more roadmap than you want to spend.

This is the OEM shape: your interface, your customer relationship, our catalog and pipeline underneath. Delivery is plain JSON into whatever you render. Your customers see your product answering a question it could not answer before; the standing operation from the iceberg section stays on our side of the wall.

What to negotiate in any white-label deal, ours included: whose brand appears where, what happens to your feature if the contract ends, where the data lives, and redistribution rights in writing. A vendor who answers those four in plain language is telling you something about the next five years of the relationship.

If you are an MSSP rather than a product team, the license path reads slightly differently: the "product" is your service, the integration is your reporting stack, and the unit that matters is the client domain. The shape that works is a per-client exposure baseline at onboarding, the same picture refreshed at every QBR, and alerting routed into your existing triage. Same tiers, same three-API-calls test; just swap "feature" for "deliverable." And when a client asks what any of it means, the client conversation is its own skill, one we have written up separately.

What the first sprint actually looks like on the license path, so the "weeks" claim is concrete: day one is the keyless free tier against your own domain, no contract, which tells you what the signal looks like on data you can judge. The integration itself is one exposure call in your backend plus rendering, and the honest majority of the sprint goes to the product decisions the data forces: what you show, what you alert on, and what you deliberately leave out.

The decision, side by side

Six questions to ask any breach-data vendor

Including us. The answers separate a data partner from a data liability:

1. Where does the data come from, and how is it verified before it enters the corpus?
2. Can we check the corpus claims ourselves, before signing anything?
3. What is the delivery format, exactly? Ask to see a real response, not a diagram.
4. What are the rate limits and volume terms in writing? Distrust "unlimited."
5. What happens to our feature and our data access when the contract ends?
6. Does the vendor serve raw passwords? If yes, walk away; the line matters, and your own legal team will agree.

Our answers are public by design: the catalog is queryable without a key at api.xposedornot.com/v1/breaches , every number in this post comes from it, the XposedOrNot platform it serves is open source, and pricing is on the site next to the products. Question 2 takes you ten seconds, which is the point of answering it that way.

Where to start, whichever path you pick

Run the free API against your own domain's reality before talking to anyone, us included. If the exposure signal is worth productizing, the build-versus-buy math above is waiting, and the numbers in it are yours to adjust. And if the answer is license or white-label, the integration conversation starts at plus.xposedornot.com: the breach-health picture inside your product, with the pipeline that feeds it staying our problem, permanently.

Appendix: Sources and receipts

• Catalog: 776 breaches, 11,583,247,069 records, live at api.xposedornot.com/v1/breaches (pulled 2026-08-19)
• Surfacing lag: median 1,591 days across 776 entries; 36% over six years (283/776 = 36.5%, rounded down per house rule) (breachedDate vs addedDate, same endpoint, computed 2026-08-19)
• Data classes: mean 4.4 per breach (4.456), same pull
• Salary assumptions: stated as adjustable ranges, not receipts; run your own market's numbers