Skip to content

Subprocessors

Every company in the path, and the ones that have never seen anything.

A subprocessor list is only worth reading if it distinguishes what is in use from what is merely wired up. This one does, and it names where each fact came from.

Facts checked 14 August 2026

11 companies · 10 in use · 1 never contacted

Checked 14 August 2026 · this list re-read 26 September 2026

This list was read again, row by row, against the running product on 26 September 2026; each row names what was looked at and when. The rest of the documents carry the date at the top.

Established by going through Slate itself — every outside connection it makes, every piece of software it is built from, and where the database physically sits — rather than by copying another company’s trust page. Nobody here can add a company to this list from a settings screen: adding one takes a change to the software, which is why the page can be kept honest by a person rather than by a compliance department.

The list

11 outside companies can touch data in Slate. 10 are in use today; each row below says when it is in the path, and two of them — the database and the host — are in it for every request. 1 has never been handed anything at all — it is set up and switched off.

  • Supabase

    In use

    Database, authentication, the API that every screen reads through, and public file storage and delivery.

    What it can see · Operator and guest data
    • Database records, including operator accounts, organizations, bookings, customer names, email addresses, phone numbers, and website content such as photo paths and alt text.
    • Operator login records — the IP address and browser of each sign-in, held by the authentication service.
    • Files an operator uploads — logos, service photos and website photos — in a public storage bucket inside the same project.
    Where
    Database and Storage origin: United States — AWS us-east-1 (Northern Virginia), read from the live project on 14 August 2026, not assumed. Uploaded files are delivered through Supabase's globally distributed content delivery network and may be cached outside the United States.
    Status today
    Always in the path. There is no part of Slate that works without it.
    Checked against
    Live project metadata (region us-east-1, Postgres 17.6) and src/lib/supabase/.

  • Vercel

    In use

    Hosting, the serverless runtime that executes every request, the scheduled jobs, the page-view counter on the marketing site, and page-load performance on the marketing site and inside the operator console.

    What it can see · Operator and guest data
    • Every HTTP request: the IP address it came from, the URL, timing and status.
    • Runtime logs, which are our own first-party record when something breaks.
    • Page views on the marketing pages: the path, the referring site, the country and the kind of device, with a daily-rotating hash of connection and browser standing in for the visitor. Never a booking page, a manage link or the console, and never a query string.
    • Core Web Vitals — how fast a page loaded and became usable — on the marketing pages and, separately, inside the operator console once an operator has a workspace. Never a booking page, a manage link, an embedded widget, or the console before a workspace exists. No cookie, no query string.
    Where
    Serverless execution in Washington, D.C. (Vercel's iad1) — measured on 14 August 2026 from the x-vercel-id response header of the live deployment, not assumed. Vercel's edge network, which terminates the connection and serves cached static files, is global and is not US-only.
    Status today
    Always in the path. Six scheduled jobs: four run every five minutes — expiring unpaid holds, running automations, reconciling subscription quantity, delivering webhooks — one runs hourly, sending the account emails that follow a sign-up, and one runs every minute, telling the Slate team about a new account and sending that account its welcome email. The execution region is Vercel's project default — no regions key is pinned in vercel.json — so it is measured rather than configured, and a change made in Vercel's dashboard would move it without touching this repository.
    Checked against
    vercel.json, src/instrumentation.ts, and the x-vercel-id header returned by /book/[slug] and /support — measured on 14 August 2026 against https://slate-phi-eight.vercel.app (the deployment URL in use that day, before the slate-booking.com domain existed) and re-measured on 15 August 2026 against https://slate-booking.com, which returned iad1 both times.

  • Stripe

    In use

    Card payments taken on the operator's own Stripe account, and — separately — Slate's own subscription billing.

    What it can see · Operator and guest data
    • On a guest checkout: the amounts, the line-item labels and the guest's email address. Names and phone numbers are not passed.
    • Card details are entered on Stripe's own hosted page. Slate never receives or stores a card number.
    • Whatever Stripe sends back about a payment, stored as-is, which can include the name and address a guest gave Stripe.
    Where
    United States and Stripe's global infrastructure.
    Status today
    Live. Card payments run on each business's own Stripe account once it connects one from the console. No guest checkout has yet been created and no card payment has yet reached Stripe through Slate; Slate's own billing has created no Stripe customer, because the only plan is free. The six events in Slate's Stripe log all came from Slate's own test-mode checks.
    Checked against
    src/lib/stripe/, and Slate's own records read on 4 September 2026: the organizations table (0 connected Stripe accounts so far), stripe_checkout_sessions (0 rows), payments (0 rows), subscriptions (0 with a Stripe identifier), stripe_events (6 rows, none from live mode).

  • Resend

    In use

    Outbound email — booking confirmations and cancellation notices to guests; operator alerts; account emails to operators (a welcome, setup nudges, a note when the booking page goes live); sign-in and password-reset links, which our authentication service sends through it; notifications of demo requests and new sign-ups to Slate's own team; and messages from the support form.

    What it can see · Operator and guest data
    • The recipient's address, the subject and the body of any message that reaches it.
    • For a sign-in or reset email: the operator's address and the one-time link inside it.
    Where
    United States.
    Status today
    In use since 20 August 2026. Slate's own record of outgoing messages holds mail Resend accepted (the first on 31 August 2026, the latest on the day this was checked), alongside older rows from the weeks it refused. Operator sign-in and reset links also travel through it, because the authentication service is configured to send that way.
    Checked against
    src/lib/email/, the authentication service's SMTP setting, and the message log read on 4 September 2026 — which holds rows Resend accepted since 31 August 2026 as well as the failed rows from before the sending domain existed.

  • Auth0 (Okta)

    In use

    Operator sign-in and sign-up, when Auth0 sign-in is switched on: the hosted login page, password storage and checking, email verification and password reset for accounts created there, and "Continue with Google".

    What it can see · Operator data
    • The operator's email address and name, and for Google sign-in the profile picture Google supplies.
    • A hashed password, for operators who choose one there. Slate never sees it.
    • The IP address and browser of each sign-in attempt, kept in Auth0's own security log.
    Where
    United States (the tenant is in Auth0's US region).
    Status today
    In the sign-in path since 7 September 2026: the AUTH0_ENABLED switch is on in production, so operators who choose it sign in and sign up through Auth0's hosted page, and Auth0 receives the email address, name and, for Google sign-in, the profile picture of each of them. Accounts that predate it can still sign in with their Slate password and never touch it.
    Checked against
    src/lib/sso/config.ts (the AUTH0_ENABLED switch), the Vercel production environment set to true on 7 September 2026, and the Auth0 tenant configuration made the same day.

  • Twilio

    In use

    Text messages: an operator's SMS automations to their guests, Slate's own texts to operators and prospects who ticked the box on the demo form, and Slate's alerts to its own founders when somebody creates an account.

    What it can see · Operator and guest data
    • A phone number and the text of the message.
    • For Slate's own texts: the number, the message, and whether the person replied STOP.
    • For a new-account alert to Slate's own founders: the account holder's name, email address, sign-up time, how they signed in, and, if they have already set up a business, its name and public booking link, in the body of a text to a founder's phone.
    Where
    United States and Twilio's global infrastructure.
    Status today
    In use for Slate's own text messages to operators and prospects who ticked the box on the demo form: a message is attempted only for a number with recorded consent and no STOP on record. Also in use for Slate's alerts to its own founders when somebody creates an account; those go to the founders' own numbers, held in the deployment configuration, and to nobody else. An operator's own SMS automations use the operator's own account, not Slate's, and are switched off until the operator turns them on.
    Checked against
    src/lib/sms/company.ts (consent-gated send), src/app/api/sms/inbound/handler.ts (STOP/START), the Vercel environment (credentials present from 4 September 2026), and the org messaging settings table (zero operator automations enabled), read the same day. Founder alerts: src/lib/sms/team.ts and src/lib/signupAlerts/run.ts, read 7 September 2026.

  • Google

    In use

    Google Workspace hosts Slate's own mailboxes at slate-booking.com, so mail sent to Slate is received and held there. Separately: reading an operator's Google Calendar so their existing commitments block out booking slots, and Google sign-in for operator accounts.

    What it can see · Operator and guest data
    • Any email sent to a slate-booking.com address — support@, demo@, the founders' own addresses — including a guest's reply to a booking confirmation, since replies are addressed to support@slate-booking.com.
    • If a calendar is connected: the calendar being read, and the sign-in handshake. Busy-block titles come back into Slate.
    • Nothing is written back to a calendar. The permission Slate requests is read-only, so there is no code path that could create or change a Google event even if one were written.
    Where
    Google's global infrastructure.
    Status today
    In the path for inbound mail: the MX record for slate-booking.com points at Google (smtp.google.com), checked by DNS lookup on 4 September 2026. The calendar connection has never been used — zero connections exist — and Google sign-in is unused: every one of the 30 operator logins is an email login.
    Checked against
    A DNS lookup of the domain's MX record on 4 September 2026; src/lib/calendar/ (the requested scope is calendar.readonly); the integration connections table (zero rows) and the authentication identities table (email only), read the same day.

  • Google Analytics

    In use

    Google LLC's page-view counter for the marketing site, loaded only if a visitor accepts the cookie banner.

    What it can see · Marketing site visitors
    • The page visited, the site the visitor came from, and device and browser details Google's own script collects — the same data any Google Analytics property receives.
    • A visitor's IP address, which Google's script sends as part of the request; Slate does not separately collect or store it.
    Where
    United States and Google's global infrastructure.
    Status today
    Requested only after a visitor clicks Accept on the marketing site's cookie banner. Declining, or leaving the banner unanswered, means Google's script is never requested at all — no request, no cookie, nothing. Never loaded on a booking page, an embed, a manage link or in the operator console.
    Checked against
    marketing/src/scripts/consent-analytics.ts (the loader, and the `/get-started`-only gate that does NOT apply to this one), marketing/src/components/marketing/ConsentBanner.astro (where the choice is asked), and marketing/astro.config.ts's CSP, which only a marketing page's CSP still carries — middleware.ts strips it from the two guest booking surfaces.

  • Meta Pixel

    In use

    Meta Platforms, Inc.'s advertising pixel, on the get-started page only, loaded only if a visitor accepts the cookie banner — so Slate can measure and target its own advertising.

    What it can see · Marketing site visitors
    • That a browser visited the get-started page, the visitor's IP address, and the device and browser details Meta's own script collects, which Meta can connect to a Facebook or Instagram account signed in on the same browser. Never a name, an email address or anything a visitor typed.
    • Nothing from any other marketing page, and nothing from a booking page, an embed, a manage link or the console — the pixel is requested on no other route.
    Where
    United States and Meta's global infrastructure.
    Status today
    Requested only on /get-started, and only after a visitor clicks Accept on that page's cookie banner. Declining, or leaving the banner unanswered, means Meta's script is never requested. No `<noscript>` fallback pixel: Meta's own snippet includes one that fires without consent, and it is deliberately left out for exactly that reason.
    Checked against
    marketing/src/scripts/consent-analytics.ts (META_PIXEL_PATH gates it to /get-started; no noscript fallback in the source), and marketing/astro.config.ts's CSP, which only a marketing page's CSP still carries — middleware.ts strips it from the two guest booking surfaces.

  • Anthropic

    In use

    The console assistant and the setup interview: an operator's own words, and their organization's setup, sent to Anthropic's model so it can answer and make the changes they ask for.

    What it can see · Operator data
    • What an operator types into the console assistant or the setup interview, and the setup record built from it: services and prices, boats, rooms and gear, opening hours, team names.
    • The organization's current setup when the assistant looks it up. Never a guest, a booking or a customer record: the assistant has no tool that reads them, and it cannot cancel, refund or change a booking.
    • Under Anthropic's commercial API terms, what Slate sends is not used to train its models.
    Where
    United States (Anthropic's API).
    Status today
    In use since 20 August 2026, and only while an operator is using the assistant or the setup interview. Nothing is sent at any other time, and nothing is ever sent about a guest.
    Checked against
    src/lib/assistant/client.ts and src/lib/assistant/tools.ts (every tool either reads the organization's setup or adds to it), src/app/api/onboarding/interview/route.ts, and the platform status page's live probe of the key, read on 4 September 2026.

  • GitHub

    Not in use

    Files a founder's own edit request about a screen in Slate's admin map as an issue on Slate's private repository, once GITHUB_ISSUES_TOKEN is set.

    What it can see · Infrastructure
    • The screen id and title the request is about, and the founder's own words describing what should change.
    • Never a booking, a guest, a customer record or an operator's own data — the request form has no field for any of those and nothing else is sent.
    Where
    United States and GitHub's global infrastructure.
    Status today
    Not yet in use. GITHUB_ISSUES_TOKEN is unset, so "Request an edit" on the founders' screens page is disabled with a sentence saying so, and no request has reached GitHub. The map and its sign-offs work without it.
    Checked against
    `.env.example` (the two GitHub vars and the disabled-button sentence), the isGitHubConfigured() guard in src/lib/github/client.ts, and the Vercel production environment, which had neither GITHUB_ISSUES_TOKEN nor GITHUB_WEBHOOK_SECRET set when listed with `vercel env ls production` on 8 September 2026.

And where a company would normally be, and is not

Not counted above, because there is nobody to count. It is on this page because the absence is the useful fact.

  • None — error monitoring is self-hosted

    Not in use

    Recording server errors so they can be fixed.

    What it can see · Infrastructure
    • A scrubbed error line: the route template with any identifier removed, and a message with email addresses, references, tokens, keys, card-length digit runs and phone numbers replaced before it is written.
    Where
    Nowhere external.
    Status today
    There is no error-monitoring vendor. No Sentry, no Datadog, no session replay. The destination for error reports is unset in production, so nothing is transmitted anywhere; one scrubbed line goes to our own server logs.
    Checked against
    src/instrumentation.ts and the runtime dependency list.

What is not on the list, and never has been

The absence of a vendor is a stronger statement than the presence of one, and it costs us nothing to make: there is nothing in Slate that could do any of this, so there is nothing here to switch off and nothing to take our word for.

Analytics

No PostHog, Segment, Mixpanel, Amplitude, Plausible or Fathom, anywhere, ever — and no analytics tool of any kind loads on the marketing site without a visitor clicking Accept first. Two counters run without asking, because neither is third-party: Vercel Web Analytics, on the marketing pages only, and Vercel Speed Insights, on the marketing pages and inside the operator console — both cookieless, neither on a booking page — see Vercel's row above for exactly what each receives. A third, Google Analytics (Google LLC), runs on the marketing site too, but only for a visitor who accepts the cookie banner there; declining, or never answering, means it is never requested. None of the three ever runs on a booking page, an embed, a manage link or in the console. Slate does separately work out which channel a completed booking arrived from, so a business can see which of its own links are earning their keep — that is worked out inside Slate, from the booking, and goes to no outside company.

Advertising and tracking pixels

No ad network, no conversion pixel and no remarketing tag anywhere a guest or an operator works with their own business — a booking page, an embed, a manage link, the console. Nothing Slate holds about a guest or an operator is ever shared with an advertiser or sold to anyone, and nobody browsing a booking page is followed off it. The one exception lives on the marketing site alone, and only with consent: a Meta Pixel on the get-started page, which sends Meta that visit with the browser's device details so Slate can measure and target its own advertising — never a guest, a booking or an operator's own data, and never without that visitor accepting the cookie banner first.

Session replay and heatmaps

No Hotjar, no LogRocket, no Clarity, no recording of what a visitor does on a page.

Customer messaging widgets

No Intercom, no chat bubble, no CRM script. The support page is a plain form and an email address.

CDNs and font hosts

The three brand typefaces are served from Slate's own domain. A guest opening a booking page makes no request to any third party — that was a deliberate decision about the page that takes the money.

None of which means Slate records nothing. It is a booking system: it holds your guests’ names and contact details, their bookings, what they paid, and — on a booking somebody actually completed — which of your links or listings brought them. That belongs to you and it stays between you, Slate and the companies listed further up this page. It is never handed to an advertiser, sold, or used to build a picture of anybody.

Which is also why there is no cookie banner on a Slate booking page: there is no non-essential cookie to ask you about. The Privacy Policy covers that in full.

How that was checked

So you do not have to take our word for the section above. 5 independent checks, each of which someone else could repeat:

  1. A search of every file Slate is built from, upper and lower case alike, for every common analytics, advertising and monitoring library. Four real matches now: @vercel/analytics and @vercel/speed-insights, the host's own page-view and performance counters — each imported in exactly one wrapper file per surface and mounted only through the marketing footer and, for Speed Insights, the console layout as well, with tests that fail if either is ever mounted anywhere else, loaded on a booking page, or handed a query string; and, gated behind a visitor's own consent choice in marketing/src/scripts/consent-analytics.ts, Google's gtag.js (Google Analytics) on the marketing site and Meta's fbevents.js (the Meta Pixel) on the get-started page only — neither is requested until Accept is clicked, and a test fails if either is ever requested with no consent stored, on a booking page, or on an embed. Every other match was a written-out explanation of why a tool was turned down.
  2. Every piece of software Slate loads to run, read in full: eight of them — the database client and its server-side helper, a date library, React with Next.js, and the two counters described above. Nothing else in that list measures anything but page loads and their speed.
  3. Slate's own records and the public DNS, read on 4 September 2026: which providers have accepted something (the message log), which have been handed nothing (zero connected Stripe accounts, zero calendar connections, zero texts), and the mail-exchange record that says where mail to slate-booking.com is delivered.
  4. The booking page exactly as a browser receives it: everything it runs and everything it loads ahead of time comes from Slate's own address, including the parts the web framework adds for itself. The only script we wrote by hand reads your light-or-dark preference before the page draws. No outside stylesheet, no remote font, no remote image, and nothing quietly reporting back.
  5. Every outside address our own servers contact, listed out: Stripe, Resend, Twilio and Google. All four are contacted by our own servers, none of them without a key, and nothing in a guest's browser — a booking page, an embed, a manage link — ever talks to any of them. The only outside addresses any browser talks to directly are on the marketing site, and only after that browser accepts the cookie banner there: googletagmanager.com on every marketing page, and connect.facebook.net on the get-started page as well.

When this list changes

A new subprocessor means a code change, so this page is updated in the same work as the integration, and the check date at the top moves with it.

There is no notification list. Slate’s email provider rejects every request, so we cannot honestly point you at an announcement channel — the date on this page is the record. If your business needs advance warning before a new processor is added, write to us and we will agree something in writing that we can actually keep.

legal@slate-booking.com