Every SaaS company publishes its vendor list. Almost nobody reads it.

Somewhere across almost every B2B SaaS company's public web presence — trust centers, security pages, legal and compliance docs, changelogs, help articles — the company names, in writing, the third-party vendors it runs. Twilio for SMS. SendGrid for email. Stripe for payments. AWS for infrastructure. Zendesk for support. Not guessed from JavaScript tags, not scraped from job postings: stated, in writing, by the company itself, scattered across its own site.

Some of these statements exist because the law requires them; most exist simply because customers and auditors ask. Either way, the company wrote them down.

Why companies write it down

Some of it is driven by regulation. Under GDPR, a SaaS company processing personal data on behalf of its customers has to name the vendors it passes that data to and keep the list current — a pattern echoed in most Data Processing Agreements and in a growing set of US state privacy laws. But plenty of it is just good hygiene: trust centers, security overviews, and integration docs that name vendors because enterprise buyers ask who touches their data before they sign.

The result is a remarkable piece of infrastructure that nobody designed on purpose: a distributed, self-published registry of who uses what, spread across each company's own web presence. Companies keep it current because the downside of a stale answer is contractual, not cosmetic. Enterprise customers audit it. Lawyers review it. When a vendor is added, the public record changes — often before the integration ships.

Why this data beats every alternative

The standard ways to figure out a company's stack are all inference. Technographic scrapers fingerprint JavaScript on the marketing site — which tells you about the marketing site, not the product. Job postings tell you what a company is hiring for, which lags or leads reality by quarters. Review-site presence tells you someone evaluated a tool once.

A first-party statement like this is different in kind, not degree:

• It's first-party. The company itself wrote "Twilio Inc. — SMS and voice message delivery" on its own site. There is no stronger public evidence that a vendor relationship exists.
• It covers the product, not the website. These statements are about the systems that actually process customer data, so they reflect the production stack — not whatever tag happened to fire on the marketing page.
• It's maintained under real pressure. Most public data rots. This data has customers and auditors keeping it fresh.
• It's quotable. Every claim comes with a sentence you can cite, verbatim, from a URL the company controls.

So why does nobody read it?

Because it was written one company at a time, for readers of one company at a time. There's no standard format — some statements are HTML tables, some are PDFs, some are paragraphs of prose inside a 40-page document. They live at unpredictable URLs across each site. Vendor names are inconsistent ("Twilio", "Twilio Inc.", "Twilio Ireland Limited"). Reading one takes a few minutes; reading a thousand is a research project. The data is public, high-signal, and — for any question that spans more than a handful of companies — practically inaccessible.

That access gap is exactly the kind of problem a pipeline should solve. Crawling a company's public web presence — rendering JS-heavy pages and PDFs, and working through known URL patterns, subdomains, sitemaps, and web search to find where vendors are named — then normalizing the names, categorizing each mention, and keeping the quoted source attached is mechanical work. It doesn't need a human, and — done carefully — it doesn't need an LLM either. String matching against a curated vendor taxonomy is deterministic, auditable, and never invents a vendor that isn't in the source.

That's the thesis behind VendorStacks: treat these public statements as the dataset they already are. One API call returns which vendors an entity runs — structured across 13 categories, each match with the quoted source attached. A reverse index answers the question in the other direction: which entities name a given vendor.

The companies wrote it all down. Someone just had to read it.