← Trust
Subprocessor list

Every third party that touches customer data

This list is the complete set of processors + infrastructure vendors any RailCall customer's data can conceivably reach. New vendors land here before production traffic hits them — that's a hard rule, not a nice-to-have. Last updated 2026-07-25.

United States (regions: US-East · Virginia)

Application + database hosting for the marketplace, license service, and railcall.ai website.

Data categories
  • • Account email
  • • Password hash (argon2id)
  • • Marketplace listing metadata
  • • Purchase records
  • • Refresh tokens (sha256 hash only)
  • • Audit log rows
SOC 2 Type II. Data encrypted at rest by Render's managed Postgres. TLS 1.2+ for every ingress.
WorkOS ↗
processor
United States

SSO (SAML/OIDC) and SCIM Directory Sync for Enterprise-tier customers only.

Data categories
  • • User email
  • • Full name (if the IdP shares it)
  • • Group memberships (SCIM only)
  • • IdP connection metadata
Only Enterprise customers who opt in. Their IdP secrets (SAML metadata, OIDC client secrets) live in WorkOS — RailCall never sees them.
Stripe ↗
processor
United States + regional processing per Stripe's own subprocessor list

Payment processing for module purchases and subscriptions.

Data categories
  • • Buyer email
  • • Card details (in Stripe; never in RailCall systems)
  • • Charge history
PCI DSS Level 1. RailCall uses Stripe Checkout and Billing Portal — card data never enters our systems.
Resend ↗
processor
United States

Transactional email delivery (verification, password reset, invitations, receipts).

Data categories
  • • Recipient email address
  • • Email subject + body (which may include invitation tokens and account URLs)
Email content never contains raw secrets — tokens are one-shot magic links, not passwords.
United States (Microsoft-owned)

Source code hosting + release artifact hosting (station tarball + air-gap bundle).

Data categories
  • • Public repo contents
  • • Release tarballs (bit-identical to what customers download)
No customer data. Present here for completeness — customers install RailCall by fetching from GitHub raw + release assets.
United States

DNS for railcall.ai. No CDN or WAF layer yet (direct-to-origin).

Data categories
  • • Request source IP (via DNS lookup logs, per Cloudflare's standard practice)

What lives on the customer's own machine

RailCall is local-first by design. The Studio, the workflow engine, and every signed receipt live on the customer's own hardware — not in any vendor's cloud, ours or otherwise. Third parties above only see what a customer explicitly sends through them (marketplace metadata, email delivery, SSO claims). Payload data your workflows process — CRM records, lead lists, form submissions, whatever — never leaves the customer's machine unless the workflow itself sends it somewhere.

Enterprise customers who need audit centralisation configure their own receipt vault destination (S3 bucket, NFS mount, custom Python driver) — RailCall never sees those receipts.

How we add new vendors

  1. 1. New vendor evaluated against our vendor-management policy (SOC 2 CC9.2 / HIPAA §164.308(b) / GDPR Art. 28).
  2. 2. DPA / BAA signed if the vendor will touch personal data.
  3. 3. This page updated before the vendor's endpoint is called from any RailCall system.
  4. 4. Enterprise customers notified via email 30 days before a new subprocessor comes online, per DPA §5.
Questions? sales@railcall.ai·Legal / DPO enquiries also welcome from your GRC team directly.