Sub-processors
Last updated September 4, 2026
Envoy uses the third-party services below to operate the EnvoyEngage platform and its apps. They may process personal data as described in our Data Processing Agreement.
Not every app uses every sub-processor. The last column says which apps send data to each one; where that differs, it is explained under Which apps use what.
| Sub-processor | Purpose | Location | Used by |
|---|---|---|---|
| Vercel | Application hosting, edge network, and delivery | United States / global | All apps |
| Supabase | Managed Postgres database, authentication, secrets storage, and file storage for ticket attachments | United States / configurable region | All apps |
| Inngest | Background jobs, webhook ingestion, and reconciliation | United States | All apps |
| Resend | Transactional and notification email delivery | United States | All apps |
| Anthropic | Claude models, for reading source documents and assisting with migration mapping | United States | Migratron, Librarian |
| Amazon Web Services | S3 staging for files you upload, and the compute that runs the Migratron migration engine | United States / configured region | Migratron, Librarian |
Which apps use what
Vercel, Supabase, Inngest, and Resend are platform infrastructure: every app runs on them, so anything you do in EnvoyEngage involves all four. The other two are app-specific.
Anthropic (Claude) — Migratron and Librarian only
Librarian sends the source documents you upload. Pages that carry no extractable text — scans, in practice — are read by Claude as images, and the proposed Guide structure is generated from each document’s title and a bounded excerpt.
Migratron sends three narrower things: a field-mapping spreadsheet, if you upload one, so its columns can be interpreted; the free-text migration instructions you write, so the names in them can be matched to records in your source system; and the field values of an individual record that failed to import, when you ask for a suggested correction. Where those inputs contain personal data — a case owner’s name, a malformed contact email — that data reaches Claude.
Migrated tickets are not sent to Claude in bulk: the migration itself is a deterministic transfer, and Claude is only involved in the assistive steps above.
VendorApp does not use Anthropic at all. No ticket, comment, or portal user is sent to Claude.
Separately, Envoy staff can operate a customer’s migration account through an opt-in connector from Claude. Where that is enabled, the records an operator queries are processed by Anthropic in the same way.
Amazon Web Services — Migratron and Librarian only
Both apps stage uploaded files in S3 rather than passing them through the application: Migratron holds CSV exports, Librarian holds source documents. Uploads and downloads use short-lived presigned URLs, and the buckets are not public.
Migratron additionally runs its migration engine on AWS compute. That service is the component that reads your source system and writes to your Zendesk, so it processes the records being migrated — including their comment history — for the duration of a migration.
VendorApp stores its ticket attachments in Supabase instead, and does not use AWS.
Your own systems
EnvoyEngage runs on top of accounts you already control. Your Zendesk is your own system of record under your agreement with Zendesk, and a Salesforce org connected as a migration source is likewise yours. Neither is a sub-processor engaged by Envoy. We access them only as needed to provide the Service you configure, using credentials you grant and can revoke.
The Zendesk RCS Bridge works the same way, and it is worth being precise about because messages are involved. The verified sender, the RCS agent, and the message traffic live in your own AWS account— Envoy reaches it by assuming a role you deploy, with an external ID your trust policy requires, and holds no standing credentials of its own. Sunshine Conversations is part of your Zendesk account rather than something Envoy engaged.
RCS messages in transit
Envoy’s application carries each RCS message between your AWS account and your Zendesk, so message content — including whatever a customer types — passes through it in the course of delivery. We do not keep a copy: an earlier diagnostic that retained message bodies has been removed, and what is stored is the mapping needed to route a reply back to the right handset.
RCS itself is a carrier channel. A message travels over Google’s RCS infrastructure and the recipient’s mobile network in the same way an SMS travels over a carrier, and the same way email crosses mail servers we do not operate. Those parties are inherent to the channel rather than sub-processors Envoy selected, but they do handle message content, and you should know that before choosing RCS as a support channel.
Sign-in with Google
Google sign-in is off by default and enabled per workspace on request. Where a workspace turns it on, Google processes the authentication of the people who use it. Workspaces on email and password, or on a magic link, involve Google not at all.
Changes
We will update this list and notify customers of intended additions or replacements so they can object as described in the DPA. Questions: jakub@goenvoy.co.