Every SaaS company publishes its vendor list. Almost nobody reads it.
Somewhere on almost every B2B SaaS company's website — usually under /legal, /trust, or a link buried in the DPA — there is a page that lists, by name, the third-party vendors that company uses to process customer data. 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.
These pages are called subprocessor disclosures, and they exist because the law requires them to.
Why these pages exist
Under GDPR, a SaaS company processing personal data on behalf of its customers is a processor, and any vendor it passes that data to is a subprocessor. Article 28 requires the processor to get authorization from its customers before engaging subprocessors — and in practice, the standard mechanism for "general written authorization" is a published list plus a notification promise: here are our subprocessors; we'll tell you before we add one. The same pattern is baked into most Data Processing Agreements, and equivalents exist under UK GDPR and a growing set of US state privacy laws.
The result is a remarkable piece of infrastructure that nobody designed on purpose: a distributed, self-published, legally maintained registry of who uses what. Companies keep these pages current because the downside of a stale one is contractual, not cosmetic. Enterprise customers audit them. Lawyers review them. When a vendor is added, the page 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 subprocessor disclosure is different in kind, not degree:
- It's first-party. The company itself wrote "Twilio Inc. — SMS and voice message delivery" on its own legal page. There is no stronger public evidence that a vendor relationship exists.
- It covers the product, not the website. Subprocessors process customer data, so the list reflects the production stack — the systems that actually touch users.
- It's maintained under legal pressure. Most public data rots. This data has a compliance team 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 them?
Because they were written for lawyers, one company at a time. The pages have no standard format — some are HTML tables, some are PDFs, some are paragraphs of prose inside a 40-page DPA. They live at unpredictable URLs. 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 an API should solve. Finding the page, parsing the table, normalizing the vendor names, categorizing each row, and keeping the quoted evidence 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 on the page.
That's the thesis behind VendorStacks: treat the world's subprocessor disclosures as the dataset they already are. One API call answers whether an entity publishes a disclosure, where it lives, and which vendors are on it — structured across 13 categories, evidence included. The reverse index answers the question in the other direction: which entities disclose a given vendor.
The companies wrote it all down. Someone just had to read it.