Subprocessors

Status: DOCUMENT ONLY, maintained by hand. Nothing checks that this list matches what the code actually calls, but for one company: since the launch audit (2 October), tests/docs.ts fails when a file that hands something to OpenRouter is not named here. Recorded as an unevidenced control (CC9.2, vendors and business partners; it was filed under CC9.1, business disruption, until the launch review moved it).

Last reviewed: 2026-10-23: Google Document AI reads a scanned PDF's words (src/worker/ocr.ts, 00674), only for a business that switches on Read scanned PDFs; it is handed the business's own uploaded file, before anybody signs it. Earlier the same day: Google Web Risk is also asked about each business's own website, reply-to domain and proven domains (00672), which are the business's, not a person's; and Google's PageSpeed Insights and Chrome UX Report read our own public pages, which is not a subprocessor's work and is not listed. Earlier, 2026-10-22: an open incident on our status page is given an update every thirty minutes nobody else has written one, drafted by OpenRouter from what our checks counted (00671); it is handed the incident's name and those counts, nothing of a customer's. Earlier the same day: OpenRouter is asked, from Ops, what to change on our own site for a search or a page (00667); it is handed our pages and Google's figures, nothing of a customer's. Before that, 2026-10-17: Railway runs our servers in its US West region (California, us-west2) since 17 October, beside the database in Oregon; they were in its US East region (Virginia, us-east4). Still the United States, and nothing else about what Railway is handed changed. Before that, 2026-10-02: a business's outgoing signing mail and texts are screened for spam and phishing before they are sent (00500): OpenRouter's row now says it is handed what is screened, and Google Web Risk is listed as an optional lookup of the links in it, off until its key is set. The same day, the launch audit found the support agent in the portal sending each question to OpenRouter with nothing here saying so, so OpenRouter's row now does; and a reading of an answer aloud is now kept for a week (00493). Before that, 2026-10-01: messages to our inbox, through the contact form or by email to support@, go to OpenRouter to be judged for sales pitches (00465), so OpenRouter's row says so; and ElevenLabs keeps the assistant's conversations and recordings for one year (365 days, set on every agent, including conversations already stored). Earlier the same day: the assistant can read a business's own account for its owner or admin, after a code read back in the conversation (00463), so ElevenLabs's row now says it receives those answers. Before that, 2026-09-30: the phone number is answered by the same assistant (docs/support-agent/PHONE.md), so ElevenLabs and Telnyx carry calls: the ElevenLabs and Telnyx rows say so. Earlier the same day: the assistant on the website is switched on in production, so ElevenLabs now receives what visitors say to it; Cloudflare Turnstile's keys are set, and it checks more than the contact form; and Resend's row had said it never sees a document's text, when the completion email has carried the signed PDF since 9 September. Before that, 2026-09-29, adding ElevenLabs for the assistant on the website (switched off until its keys are set). Before that, 2026-09-26. The launch review found this list had left out three companies that handle customer data -- Railway, which runs every server process; Vercel, which passes the signing pages and the app through to them; and Sentry, which receives error reports -- and said things the code contradicted ("no payment processor", "no analytics", "no CDN in front of the API"). All three are added below and the rest corrected against the live configuration. Before that: 2026-09-23, Cloudflare Turnstile (00403) and Stripe for the membership and prepaid credit (00402).

Who processes customer data

That is the whole list today.

What each one is given, precisely

Supabase holds the database. They are the processor for everything the product stores. Credentials are stored hashed or encrypted before they reach disk, and the encryption key is not in the database — so a Supabase employee with database access has ciphertext for webhook secrets and partner tokens, and plaintext for agreement content.

Resend is handed one message at a time: to, subject, text. The text of a signing-link email contains the signer's name, the sender's name, the document's *title*, and the link. It does not contain the document's body. A completion copy contains the title and the verification code, and has the signed copy attached (src/worker/messages.ts): the sealed PDF kept at completion (00453), which carries the document's text, the names, the signatures and the photographs. Every signer with an email address is sent one (00440).

The link is a bearer credential, which means it is in Resend's logs for their retention period. That is inherent to emailing a link and is the reason the token expires and is rotated on every reminder.

OpenRouter is handed one request per click of "Write a draft": a system prompt that is the same for everybody and a user message built from the six fields named in the table. src/portal/draft.ts is the whole of what builds it, and tests/draft.ts asserts the prompt holds no tenant id, user id, address or token. The draft that comes back is shown in the new-template form and is not stored by us until the customer saves it as a template; what is stored on every run is the model, the token counts and the cost (public.record_draft, 00190). OpenRouter's and Anthropic's own retention of prompts is governed by their terms; we send them nothing we would mind them keeping, which is the design rather than a hope. Switched off entirely when OPENROUTER_API_KEY is absent.

OpenRouter, for the review (src/portal/review.ts, 00202, 00483), is handed one request per click of "Check with AI" on a template's page or "Review with AI first" on the send screen, and only for a business that has switched ai.review on under Settings — the engine refuses to record a review while it is off, so a screen cannot run one by mistake. The request is the template's text *as written*, placeholders still in braces ({{guest_name}}, not a name), with the business's name, the kind of document and the state or country to keep in mind. For a template that is an uploaded PDF it is the words on the file's pages instead, read here from its text layer (src/pdf/text.ts) — the file the business chose to have signed, never a copy anybody filled in. The blanks the person has just filled in on the send screen are not sent; neither is any signer. What comes back is read strictly: a finding whose quote is not in the text is dropped, a finding that is a verdict is dropped, and the rest are kept on document_reviews so that when the document is then sent the evidence package can say what was flagged and that it went out anyway. The model, tokens and cost are metered; the prompt and the raw answer are not kept. tests/review.ts asserts the prompt carries no id and no address.

OpenRouter, for tidying (src/portal/polish.ts), is handed one request per press of "Tidy up the wording" on a template screen. It carries the same things the review does and nothing more: the template's text as written, placeholders still in braces, with the business's name, the kind of document and where it operates. What comes back is checked before it is shown — every placeholder that went in must come back and none may be invented, and text that has collapsed to a summary is refused — and then it is shown in the form the person was already in, beside a button that restores their own words. It is never written to a template; a template changes only when somebody presses Save. The model, tokens and cost are metered through the same public.record_draft the drafter uses, so the two share one daily cap; the prompt and the raw answer are not kept. tests/templates.ts asserts the prompt's rules and the checks. Switched off entirely when OPENROUTER_API_KEY is absent.

OpenRouter, for the support agent (src/portal/agent.ts, 00325), is handed one request per press of Ask on the portal's support screen, and only when our own documentation has something on the question: an empty question, one longer than five hundred characters, and one the catalogue has nothing on are answered "I could not find an answer" without a request. The request is the question as the person typed it and up to six passages of our published documentation (app.knowledge_search), under a system prompt that is the same for everybody and tells the model to answer from the passages or say it does not know. The question is the one thing in it that is the customer's, and it says whatever they chose to type. The business's name, who asked, and any document are not sent. The question and the answer are kept on the cost ledger (public.record_agent_answer), because a question the documentation could not answer is how we learn what to write next. Each business may ask a hundred a day and each person twenty an hour (00493). Switched off entirely when OPENROUTER_API_KEY is absent.

OpenRouter, for reading an answer aloud (src/portal/voice.ts, 00357) is handed one request per press of play on a support answer. What it carries is the answer's own words and nothing else — not the question, not the business's name, not the person's. The answer is a sentence we wrote out of our own published documentation, so this is the one model call in the product that carries nothing of a customer's at all, and tests/portal.ts asserts both absences against the request body.

It cannot be handed anything else, and that is a property of the schema rather than a habit of the caller: public.speakable_answer takes the id of a recorded answer and returns that row's own text, so there is no parameter anywhere in the path for a sentence. A voice on this product can say exactly one class of thing — an answer that was already recorded, under the business hearing it, whose citations were already proved to point at real pages. The audio is returned to the browser and kept for a week beside the answer (support_answer_audio, 00493), so playing it again, or the page reloading its player, is served from what was kept rather than asked for again; the request id, the model and the byte count go on the cost ledger, and a business may have a hundred readings a day. Switched off entirely, with no player on the page, when OPENROUTER_API_KEY is absent.

OpenRouter, for the spam check (src/api/spam.ts, 00465), is handed one request per message that reaches the inbox by the contact form or by email to support@: the message as the sender wrote it, its subject (or the topic picked on the form), and the sender's name and address, with a few facts about the address worked out here (its domain, and whether that is a free mailbox). It is the sender's own message to us, not a customer's document or a signer. What comes back is read strictly: a verdict the model is not sure of, an answer that is not the JSON asked for, an error or a timeout is "not spam", and the message reaches the inbox as it did before. A message judged a pitch is filed in the inbox's Spam pile without an alert; only the reason, in a few words, is kept on the thread. The engine never files somebody with an account, or somebody we already have a thread with, as spam. Switched off entirely when OPENROUTER_API_KEY is absent.

This was Hume's Octave, and the change is worth recording because it took Hume off the path of anything a customer does. Hume is still used -- by the Ops Studio, to voice SignSealer's own how-to videos from scripts we write -- and that carries no customer data at all (see below). Octave is $150 a million characters on the rung we would have been on — about six cents every time somebody pressed play on a four-sentence answer — against $7 a million for the same job here. What Hume is good at is knowing how a line should *feel*, which is worth paying for when a voice performs and worth nothing when it reads back "one reminder is sent, and only if they have not signed". The model and voice are two constants in src/portal/voice.ts, so changing either is a reviewed change rather than a new relationship for this document to describe.

OpenRouter, for outbound screening (src/worker/screen.ts, 00500), is handed one request per distinct piece of content a business sends to somebody outside it -- a document sent to fifty people is one request -- for every business at trust level 0 or 1 (not yet paying with clean mail) and for anything our own rules flagged at any level. It carries the business's name and the name it sends as, its reply-to domain and footer, the message as the recipient would read it with our signing link, the recipient's name and address and any one-time code taken out, the document's title, the first 1,200 characters of the document's text and of an uploaded file's words, the links found, and what our own rules found. The name of the person who booked a party is taken out too, unless that name is itself what the rules flagged (another company's name typed as a person's). The business's words are fenced as data under a random fence made for the call, and the answer is read strictly: allow, hold or block with reasons, and anything else counts as no answer -- which holds a new business's mail that our rules flagged for a person rather than sending it. Since 00680 it is not told the business's trust level or age, and its answer about mail our rules found nothing in is advice kept for Ops to read, not a stop. The verdict, the reasons, the model, the tokens and the cost are kept (outbound_screenings, ai_runs), with what was screened; never billed to the business. Without OPENROUTER_API_KEY on the worker nothing is sent to OpenRouter, and a new business's mail that our rules flagged waits for a person.

OpenRouter, for search suggestions (the Suggest button in Ops, src/ops/server.ts, and the weekly run, src/worker/search-suggest.ts; the prompt and the checking are src/lib/search-suggest.ts, 00667), is handed one request per press of Suggest on the Search screen and at most five a week from the worker. It carries one search or one of our own pages: the weekly figures Google's Search Console reports for that search (its impressions, clicks and average position), the pages of ours Google showed for it, Google's own answer on whether the page is indexed, what Ops said had changed, and the words on our own public page as it reads now, fenced as data. A search is something a stranger typed into Google, reported by Google without saying who; nothing in the request is a customer's, a signer's, or anything from a business's account. The answer is checked here before it is kept, and a person decides on each suggestion. The model, tokens and cost are kept (search_suggestion_runs, ai_runs). Without OPENROUTER_API_KEY nothing is sent.

OpenRouter, for status updates (src/worker/status-updates.ts, 00671), is handed one request for each open incident on our status page that has gone thirty minutes with nothing said and no update a person scheduled for the next thirty, at most one per incident per half hour. It carries the incident's title and status, the name of the part of SignSealer affected, how long it has been open, how many of our checks ran in the last thirty minutes and how many failed, whether the latest passed, and the last update posted on it. Never what a check reported in its own words, which names hosts and queues, and nothing of a customer's, a signer's or a business's. The answer is posted only if it is short and carries no link or address, labelled on the page as automatic; otherwise a sentence made from the counts alone is posted instead. Without OPENROUTER_API_KEY on the worker nothing is sent, and that sentence is the update.

Google Web Risk (src/worker/screen.ts, 00500) is asked, when WEB_RISK_API_KEY is set on the worker, whether each web address found in a business's outgoing mail is on Google's phishing, malware or unwanted software lists. It is handed the address and nothing else. A hit stops the mail at any trust level. Unset, the links are judged by our rules and the model alone, which the worker says once when it starts.

The same lookup is made about each business's own site (src/worker/business-risk.ts, 00672): the website on its profile, the domain of its reply-to address and the domains it has proven for signing and for mail, when any of them is new or has changed and every 30 days after, at most 2,000 lookups a day. Each is handed as an address and nothing else; a reply-to is handed as its domain, never the mailbox. A hit holds the business at trust level 0 and tells Ops, which decides; what was asked and answered is kept (business_web_risk_checks).

Google Document AI (src/worker/ocr.ts, 00674) reads a scanned PDF, when a business has switched on Read scanned PDFs under Settings and DOCUMENT_AI_KEY and DOCUMENT_AI_PROCESSOR are set on the worker. It is handed the uploaded file, only a file whose pages are pictures, with its first fifteen pages to be read: the business's own document, before anybody signs it. It answers with the words and where each sits on the page, which are kept here (pdf_words, pdf_ocr) so the boxes can be placed and the checks can read them; Google keeps nothing of an online request once it has answered. At most 100 pages a day for a business and 2,000 for everybody. A signed copy, a signer's answers and the evidence store never go to it.

A business's own Google Drive is not a subprocessor of ours (00675). A business that connects it under Settings has each document it completes put in a SignSealer folder in its own Drive (src/worker/drive.ts): that is the business sending its own copy to its own account, as forwarding the completion email would, with the one permission drive.file (only the files SignSealer makes there). The tokens are sealed with the credential key like every partner credential. Choosing a file from Google Drive to upload (src/portal/drive.ts) reads that one file with the person's own token for the visit, which is used once and kept nowhere.

Dictating a question is not a subprocessor of ours. The microphone button on the support screen uses the browser's own speech recognition (src/portal/dictate.ts), so no audio reaches us. It is worth being exact about where it does go, because the engines differ: Chrome sends the audio to Google to transcribe it and Safari can do it on the device. Neither sends it to us, and neither is acting for us — it is the person's own browser doing what they asked it to. The page says so beside the button.

Uploaded files are not a subprocessor at all. A .docx or a text file dropped on the templates screen is read in this process — src/portal/import.ts reads the zip and the paragraphs itself, with no library and no network — and what survives is the words, in the form, unsaved. The file is never written to disk, never stored, and never sent anywhere.

The wording of the four messages a signer reads is the business's own (00236) — the signing request by email and by text, the reminder, and the signed copy. That changes what is *said*, never who it goes to or what leaves the building: the same address, the same provider, the same signing link. Two sentences are not theirs to remove — "Reply STOP to opt out." and "Reply HELP for help." on a text are appended by the sender rather than carried in the template — and a signing request without its link is refused rather than sent.

Stripe is handed, per Checkout, the amount of credit being bought, a success and cancel URL, the business's name in the line's description, the tenant id and the amount as metadata on the session and its payment, and either the Stripe customer id already on file or the contact email. The card is kept for automatic reloads, each an off-session charge carrying the tenant id and the reload's id (src/worker/reloads.ts, 00402); a reload whose charge was not answered is looked up among the customer's recent payments by that id before it is tried again (00493). Checkout for a plan's subscription, which carried a price id and the plan code, is no longer offered since plans gave way to the membership (00402). What comes back through /hooks/stripe is verified over the raw bytes with the endpoint's secret and reduced to ids, a status and a price before anything of ours reads it (src/billing/stripe.ts, app.apply_stripe_event). Switched off entirely when STRIPE_SECRET_KEY is absent.

On signsealer.com, and only after a visitor says yes

The marketing site can load Google Analytics, the Meta pixel and the LinkedIn Insight tag (apps/site/components/Consent.tsx), each only after the visitor accepts it in the cookie banner, and never on a signing page, a certificate check or the app. They receive that visitor's browser details and the site pages they read, under their own terms. They are not processors of customer data: no signer, no business's records and no document ever reaches them. What each sets is on /legal/cookies.

Connections a business chooses

A business can connect its own booking system or automation tool -- Guesty, Hostaway, Lodgify, Hostfully, HubSpot, Zapier, Make, or its WordPress site. Data moves between SignSealer and that service because the business asked for it, under the business's own agreement with that service: the booking details that decide what to send, and the documents' status and links going back. They are the business's vendors rather than ours, and nothing moves to one until the business connects it.

What is not a subprocessor

• Timestamp authorities (Sectigo, DigiCert). A sealed PDF's timestamp is asked for with the SHA-256 of the file -- a fingerprint that reveals nothing of what the file says (src/pdf/tsa.ts).
• UptimeRobot fetches our public health pages to tell us when something is down. It sees no customer data.
• Hume and Google Cloud voice and render SignSealer's own videos in the Ops Studio (src/ops/studio). They are handed scripts we wrote and screen recordings of demo accounts, never a customer's.
• Apple App Store Connect and Expo build the tablet app, and are how it will be published; it is not in the App Store yet. They see our code, not customer data.

Changes

This page and the privacy policy carry the date they were last changed, and a new subprocessor that would see customer data is added here before it starts to. A notice period agreed with customers comes with a signed DPA, which is drafted and waiting on legal review; until then what we do as a processor says what applies. It is a prerequisite for any enterprise customer.