Legal

Subprocessor list

This page lists the third parties that may process tenant data when ELAYGENT is operated as documented. The list follows the platform's deployment configuration — if a vendor is not on this list, the standard product does not call them.

"Vendor offers BAA" reflects the vendor's standard offering. Whether ELAYGENT has a signed BAA with that vendor for your specific tenant is a separate question — confirm with us before relying on PHI-bearing features for healthcare deployments.

Supabase

Required · Supabase-managed Postgres in the project's configured region (typically US-East).

Vendor offers BAA

Authentication, primary application database (Postgres), and KB document storage.

Data processed

  • User identities (email, role, tenant association).
  • Tenant configuration, locations, audit log rows.
  • Uploaded knowledge-base documents and reviewed knowledge chunks.
  • Vector embeddings for approved knowledge chunks when RAG indexing is enabled.

What it does NOT do

  • We do not run our own Postgres alongside Supabase — Supabase is the database.
  • Supabase Storage holds raw KB files; reviewed chunks and embeddings live in Postgres, not in a separate vector database.

Vapi

Required · Vapi-managed infrastructure; check Vapi's current data-residency posture.

BAA posture unclear — verify

Voice AI receptionist — handles inbound calls, conversation, and call transcript generation.

Data processed

  • Call audio for the duration of the call.
  • Transcripts of calls handled by the AI receptionist.
  • Caller phone number and any caller-supplied details (name, intent, scheduling info).

What it does NOT do

  • We do not retain call audio in ELAYGENT databases by default — transcripts and metadata are stored, not raw audio.
  • Vapi BAA posture must be verified directly with Vapi for healthcare deployments; do not assume.

Twilio

Optional · Twilio-managed infrastructure (US default unless regional Twilio account is used).

Vendor offers BAA

SMS sending/receiving, WhatsApp messaging, telephony number provisioning.

Data processed

  • Outbound and inbound SMS message bodies and metadata.
  • Phone numbers (caller and clinic).
  • WhatsApp message content when WhatsApp Business is enabled.

What it does NOT do

  • Removing Twilio breaks SMS/WhatsApp channels but does not break voice (Vapi) or the rest of the platform.
  • We do not store SMS bodies beyond what is needed for audit and recovery context.

Stripe

Optional · Stripe-managed infrastructure.

BAA not applicable (no PHI)

Billing — subscription management, invoicing, payment processing for tenant billing.

Data processed

  • Tenant billing contact info.
  • Subscription state, invoice history, payment method tokens (Stripe never sends raw card numbers to ELAYGENT).

What it does NOT do

  • Stripe processes billing only — no patient data, no clinical data, no PHI.
  • BAA is not applicable because the data Stripe sees (tenant billing contact, payment method) is not PHI.
  • Removing Stripe disables in-app billing but does not break operational features.

OpenAI

Tenant-controlled · OpenAI-managed infrastructure (US).

Vendor offers BAA

Optional AI provider for receptionist conversation, summarization, and recovery copilot drafts.

Data processed

  • Call transcript snippets and lead-context fragments sent for summarization or reply drafting.
  • Knowledge-base text chunks sent for embedding generation and retrieval when RAG is enabled.

What it does NOT do

  • Tenants may BYOK their own OpenAI key, in which case the data goes to that tenant's OpenAI account, not ELAYGENT's.
  • We do not fine-tune models on tenant data and do not opt into OpenAI's training pipeline.
  • OpenAI BAA must be signed at the OpenAI account level — confirm this with OpenAI for healthcare deployments.

Anthropic (Claude)

Tenant-controlled · Anthropic-managed infrastructure (US).

Vendor offers BAA

Optional AI provider — alternative to OpenAI for the same tasks (summarization, copilot drafts).

Data processed

  • Same categories as OpenAI when Anthropic is the configured provider.

What it does NOT do

  • Tenants may BYOK their own Anthropic key.
  • We do not fine-tune Claude models on tenant data.
  • Anthropic BAA posture is confirmed for enterprise tier; verify your account.

Perplexity

Optional · Perplexity-managed infrastructure (US).

No BAA offered

Optional AI provider for web-grounded research used by the reputation/intelligence audits.

Data processed

  • Search queries derived from tenant clinic name and location.
  • Public web result snippets returned to the audit.

What it does NOT do

  • We do not send PHI to Perplexity. Queries are clinic-name and location level only.
  • Removing Perplexity disables the research-augmented portion of intelligence audits but does not break the core audit.

Resend

Optional · Resend-managed infrastructure.

BAA posture unclear — verify

Transactional email delivery (review requests, intake confirmations, alerts).

Data processed

  • Recipient email addresses.
  • Email subject and body content (which may include patient name and appointment context).

What it does NOT do

  • Removing Resend disables outbound email but does not break SMS, voice, or the dashboards.
  • Resend BAA posture must be verified directly with Resend before relying on it for PHI in healthcare deployments.

Google (Places API)

Optional · Google-managed infrastructure.

BAA not applicable (no PHI)

Read-only ingestion of public Google review snapshots and aggregate ratings per Google Place.

Data processed

  • Outbound: Google Place IDs and API key.
  • Inbound: public review excerpts and aggregate rating that Google Places API exposes (no PHI).

What it does NOT do

  • Read-only — we do not push patient data to Google Places.
  • BAA is not applicable because the data is public review content, not PHI.

Yelp Fusion

Optional · Yelp-managed infrastructure.

BAA not applicable (no PHI)

Read-only ingestion of public Yelp review snapshots per Yelp business ID.

Data processed

  • Outbound: Yelp business IDs and API key.
  • Inbound: bounded review excerpts (3 per business, ~160 char text) and aggregate rating that Yelp Fusion exposes.

What it does NOT do

  • Read-only — we do not push patient data to Yelp.
  • BAA is not applicable because the data is public review content.

Sentry

Optional · Sentry-managed infrastructure.

Vendor offers BAA

Error monitoring and source-map upload for portal and backend.

Data processed

  • Stack traces, request paths, and error metadata.
  • User ID and tenant ID context attached to errors (not PHI by default; PII scrubbing rules apply).

What it does NOT do

  • Sentry is optional — without it, errors still log server-side but no remote aggregation happens.
  • PHI must not be sent to Sentry. Confirm scrubbing configuration before enabling for healthcare tenants.

Apple App Store (iOS IAP)

Optional · Apple-managed infrastructure (global).

BAA not applicable (no PHI)

In-app subscription purchases and restore flows for the iOS patient/operator wrapper app.

Data processed

  • Purchase receipts (transactionId, productId, original transaction id).
  • Subscription state (purchase date, expiration, cancellation).
  • App Store account identifiers tied to the Apple ID making the purchase (ELAYGENT does not receive the underlying Apple ID).

What it does NOT do

  • BAA is not applicable — the data Apple sees is purchase and subscription state, not PHI.
  • Removing Apple IAP only disables iOS in-app subscription purchases — web Stripe checkout still works.
  • Apple Server-to-Server Notifications V2 (StoreKit2) is partially wired today; until it is finished, lifecycle changes initiated outside the app may take longer to reflect in tenant entitlements.

Expo Push (Notification Service)

Optional · Expo-managed infrastructure (US default; relays to APNs / FCM downstream).

No BAA offered

Server-to-device push delivery for the customer-facing mobile patient app.

Data processed

  • Expo push tokens registered by the mobile app for the device.
  • Push notification titles and bodies (which may include appointment context such as time, clinic name, or short reminder text).

What it does NOT do

  • Push is best-effort and supplementary to SMS — removing Expo does not break the platform.
  • We do not put PHI into notification bodies. Notifications are 'Reminder: appointment at <clinic name>' style copy; sensitive details stay inside the app.
  • Expo relays to Apple APNs and Google FCM, which have their own data-handling policies.

Google Calendar (per tenant)

Tenant-controlled · Google-managed infrastructure (US default).

Vendor offers BAA

Two-way appointment sync to a tenant's connected Google Calendar.

Data processed

  • Appointment time, duration, clinic name.
  • Patient name and short visit context where the tenant has enabled patient-name sync.

What it does NOT do

  • Active only when a tenant location has Google Calendar writeback enabled.
  • Tenants must sign a BAA with Google Workspace separately for PHI-bearing calendars; ELAYGENT does not bypass that requirement.
  • Distinct from the read-only Google Places review ingestion — different surface, different data.

Microsoft Graph (Outlook Calendar, per tenant)

Tenant-controlled · Microsoft-managed infrastructure (US default; subject to tenant's Microsoft 365 region).

Vendor offers BAA

Two-way appointment sync to a tenant's connected Outlook / Microsoft 365 calendar.

Data processed

  • Appointment time, duration, clinic name.
  • Patient name and short visit context where the tenant has enabled patient-name sync.

What it does NOT do

  • Active only when a tenant location has Outlook/Microsoft 365 writeback enabled.
  • Tenants must sign a Microsoft BAA separately for PHI-bearing calendars under Microsoft's standard healthcare terms.

PostHog

Optional · PostHog-managed infrastructure (US Cloud by default; EU Cloud if configured).

BAA posture unclear — verify

Optional product analytics — feature usage and funnel telemetry for the portal.

Data processed

  • User identifier (Supabase user id), tenant id, role.
  • Page views and event metadata (button clicks, page transitions).
  • Browser and viewport metadata via the standard PostHog JS client.

What it does NOT do

  • PostHog only loads when NEXT_PUBLIC_POSTHOG_KEY is set; removing the key disables analytics with no other impact.
  • We do not send PHI to PostHog. Events are tied to portal users (clinic staff and operators), not to patients.
  • Session replay / autocapture of form inputs is NOT enabled; if turned on later, this entry must be updated.

Eligibility Bridge (per tenant)

Tenant-controlled · Per the bridge vendor a tenant configures — verify the bridge's region directly with that vendor.

BAA posture unclear — verify

Real-time insurance eligibility checks via a tenant-configured third-party bridge.

Data processed

  • Patient name, date of birth, insurance member id, payer.
  • Eligibility response payloads from the bridge (coverage status, copay, deductible).

What it does NOT do

  • The bridge URL is configured per-location by the tenant; ELAYGENT is the relay, not the data destination.
  • Tenants must independently sign a BAA with their chosen bridge vendor for PHI; ELAYGENT cannot grant one on the bridge's behalf.
  • Removing the shared secret disables eligibility checks for all tenants and surfaces a clear configuration error.

Dentrix Ascend (per tenant)

Tenant-controlled · Henry Schein One-managed (US).

Vendor offers BAA

Direct PMS integration when a tenant chooses Dentrix Ascend as their PMS (Henry Schein One API Exchange partner adapter).

Data processed

  • Appointment data (patient name, phone, scheduled time, service type).
  • Patient identifiers as configured.

What it does NOT do

  • Active only when a tenant location has Dentrix Ascend enabled AND Henry Schein One API Exchange partner access has been granted to ELAYGENT.
  • Until partner approval is finalized, dentrix_ascend_direct locations fail with a clear partner-access-required error rather than silently downgrading.

Open Dental (per tenant)

Tenant-controlled · Open Dental-managed (US).

Vendor offers BAA

Direct PMS integration when a tenant chooses Open Dental as their PMS.

Data processed

  • Appointment data (patient name, phone, scheduled time, service type).
  • Patient identifiers as configured.

What it does NOT do

  • Active only when a tenant location has Open Dental enabled.
  • Customer keys are per-tenant and configured by the tenant; ELAYGENT staff configure the developer key.

NexHealth (per tenant)

Tenant-controlled · NexHealth-managed (US).

Vendor offers BAA

Direct PMS integration when a tenant chooses NexHealth as their PMS broker.

Data processed

  • Appointment and patient data normalized through NexHealth's API.

What it does NOT do

  • Active only when a tenant location has NexHealth enabled.
  • We do not resell NexHealth — the tenant brings their NexHealth account.

Vercel

Required · Vercel edge + the configured serverless function region (typically US-East).

Vendor offers BAA

Hosting platform for the portal and backend Next.js applications, including cron scheduling.

Data processed

  • Request and response data in transit.
  • Build artifacts and edge cache (no application data persisted to Vercel beyond standard request logs).

What it does NOT do

  • Vercel hosts the application; primary data persistence is in Supabase Postgres, not on Vercel.
  • BAA must be signed at the Vercel Enterprise tier — Hobby/Pro tiers do not include one.