Legal
Subprocessors
Everyone who can receive your data, and the build check that stops this list going stale.
The list
The table covers two things at once, so the first column says which: the rows without a marker are this website’s and are complete for it; the rows marked “hosted service” belong to a service that is not open yet. The TokenTriage software you run yourself is a third case and has no subprocessors at all, because it sends us nothing — see the privacy policy, §2.
The hosted plane is a second population, it is not open yet, and it is already in the table below. Running a gateway on your behalf means standing it on infrastructure we do not own, and those providers would receive customer data in a way no visitor’s browser ever touches. Their rows are listed now, ahead of the service opening and while they still receive nothing from it, and each is marked “hosted service” so you can tell the two populations apart at a glance.
Listing them early costs this page some of its guarantee, which is the trade and it is deliberate. The build check described below is the entire reason to believe this page, and it cannot see a single one of those rows. So the honest order is to name them first and weaken the claim to match, rather than hold a shorter list that the check covers completely and add the rest on the morning the service opens — which is the day nobody would be reading this page carefully. What the check does and does not reach is set out under “What the check cannot see”, with a rendered count, rather than left for a reader to work out.
| Provider | What it does | What it can receive | Where | Optional |
|---|---|---|---|---|
| Cloudflare, Inc. | Serves this website and runs the single edge function that proxies analytics events, so it terminates every request to tokentriage.com.Not corroborated by the policy check: It serves the origin itself. A CSP describes where a page may send the visitor onward, never who handed the page over in the first place — so the host is structurally invisible to it and has to be declared here by hand. |
| Global edge network; nearest point of presence to the visitor | No — it serves the site |
| PostHog, Inc. | Product analytics — which pages get read and which links get clicked, so the site can be improved against evidence rather than taste. |
| United States (PostHog US Cloud) | Yes |
| Cal.com, Inc. | Runs the "Book a demo" scheduler. It loads only on the pages that offer a booking, and only sees anything if you open it. |
| United States | Yes |
| Buttondown, LLC | Delivers the launch-updates mailing list. It receives an address only when you submit the subscribe form yourself. |
| United States | Yes |
| Amazon Web Services, Inc.hosted service | Runs the hosted service — compute, databases, object storage and networking. It is the infrastructure the service is built on, so it can hold anything the service holds.Not corroborated by the policy check: Server-side infrastructure. A CSP describes where a page may send a visitor’s browser; it is structurally blind to a service that receives data from our servers instead. |
| United States (us-west-2) | No — it runs the hosted service |
| Amazon Web Services, Inc. — Amazon SEShosted service | Transactional email delivery for the hosted service: sending account-verification, password-reset, billing and notification messages.Not corroborated by the policy check: A mail provider carries a message after it has left the page — in fact it is never in the page at all, because the service sends it server-side. It can never appear in a CSP. |
| United States (us-west-2) | No — it runs the hosted service |
| Stripe, Inc.hosted service | Takes payment for paid plans and issues invoices and receipts.Not corroborated by the policy check: Server-side, and for a hosted checkout the browser’s destination is the processor’s own domain rather than ours — so this site’s CSP never grants an origin for it either way. |
| Per its own terms | No — it runs the hosted service |
A disclosure about our transactional email, made deliberately
Some of the messages our mail provider carries contain sign-in and verification codes.For the short window in which one of those codes is valid, the message that contains it is a live credential for the account it was sent to. Anyone who can read the message in that window can complete the step it was sent for.
This is inherent in sending a verification code by email and it is true of every service that does it. We state it rather than leaving you to work it out, because it is the honest reason a mail provider is a real subprocessor and not a utility: it sees your address, it sees the body, and for a few minutes the body matters.
How this list is kept honest
Every page on this site is served with a Content-Security-Policy that names, host by host, the only external places your browser is permitted to contact. Your browser enforces it: a destination the policy does not grant does not load. That makes the policy a statement about what can happen, not about what we intended.
A build check reads that policy and this list and refuses to ship if they disagree:
- An external origin the policy grants that no entry here claims — an unnamed recipient.
- An entry here claiming an origin the policy no longer grants — a stale name.
So adding a third-party script to this site and naming it on this page are the same change. The build refuses whichever half arrives alone.
That guarantee covers this website, and it does not stretch to cover the hosted service. It is a statement about what a browser may contact. A provider our servers talk to is never contacted by your browser at all, so no policy can grant it an origin and no check can catch its omission. Those rows are declared by hand, each with a written reason, and the count below says how many — which is the honest measure of how much of this page rests on the build check and how much rests on us having written it down.
What the check cannot see
A Content-Security-Policy describes where a page may send you onward. It is structurally blind to two things, and pretending otherwise would make the guarantee above sound broader than it is:
- The host that served the page. It hands over the page rather than being contacted by it, so it never appears in the policy.
- What happens after a message leaves the browser. Where a form posts to a provider, the policy proves the destination but says nothing about what that provider does next; that is governed by their own terms, which is why each row links to them.
- Anything that is not a browser at all. A policy governs what a page may contact from a visitor’s device. A provider reached server-side — infrastructure running a hosted workspace, or a service carrying a message we send — is never contacted by a browser and so can never appear in it. Those rows are declared by hand with a written reason, and the count below is the honest measure of how much of this page rests on that rather than on the check.
3 of the 7 entries in the table above are corroborated by a granted origin. The remaining 4 — Cloudflare, Inc., Amazon Web Services, Inc., Amazon Web Services, Inc. — Amazon SES, Stripe, Inc. — are declared by hand for the reason above, and the register requires that reason to be written down before the build will accept the entry.
Changes
We will update this page before or at the time a new provider starts receiving data — which the build check makes close to unavoidable. If you would like to be told when it changes, or you have a question about a row, write to [email protected].