Subprocessors and service providers
SourcingOS separates core infrastructure from optional AI and data-provider integrations. The goal is to make the purpose and data boundary understandable, not publish a list of logos with no context.
Vercel
Purpose: Application hosting, edge delivery, deployment and request infrastructure.
Data boundary: Application requests and operational metadata needed to deliver the service.
Supabase
Purpose: Database, authentication and application data services.
Data boundary: Account and SourcingOS application data according to the product feature in use.
OpenAI / Anthropic
Purpose: Feature-dependent language-model processing when the corresponding model provider is configured.
Data boundary: Defined model inputs required for the requested AI feature; not every SourcingOS workflow uses an external model.
Talent / contact / research providers
Purpose: Provider-specific candidate research, evidence or contact-resolution features when connected and enabled.
Data boundary: The minimum identifiers/query context needed for the selected provider operation, subject to provider rights and SourcingOS approval/cost controls.
Provider-agnostic architecture
Optional people-data or contact providers do not define the canonical SourcingOS candidate schema. Their outputs pass through SourcingOS identity, provenance, evidence, permission and contact-resolution layers so providers can be evaluated or replaced without rewriting candidate truth.
What this page does not claim
This is an initial transparency surface, not a contractual DPA subprocessor schedule. Region, retention, training terms, DPA status and other procurement fields will be expanded as SourcingOS moves from beta into broader commercial use and vendor configurations stabilize.