Subprocessors & Service Providers

LeadForge relies on third-party providers to host, secure, operate, and support parts of the Service. This document identifies material providers used in the current production architecture and the functions for which they are used.

A provider's legal role may vary by service and context. Depending on the processing, a provider may act as LeadForge's processor or subprocessor, an independent service provider, or a provider acting directly for the customer.

Inclusion in this document does not mean every provider receives every category of LeadForge data or participates in every customer workflow.

Vercel is used to host and deliver the LeadForge web application and server-side application functions.

Information processed through the application may transit Vercel infrastructure as part of normal request handling, deployment, delivery, logging, and service operation.

Relevant data may include application requests, network and technical metadata, server-side processing inputs and outputs, and other information necessary to deliver the hosted application.

Neon provides managed PostgreSQL database infrastructure used by LeadForge.

LeadForge stores persisted application records in this environment, including account and Workspace references, leads and business records, imports, workflow state, communications, usage and entitlement records, generated artifacts, and other product data.

Database access is performed through the LeadForge application and authorized operational tooling rather than being exposed directly to ordinary end users.

Clerk provides authentication and identity services used to sign users in, maintain authenticated sessions, and support account identity functions.

Authentication-related identifiers, profile information, session state, and technical authentication information may be processed through Clerk when those functions are used.

LeadForge relies on Clerk for portions of the authentication lifecycle while LeadForge remains responsible for application-level authorization to protected product data.

Stripe provides payment, checkout, subscription, and transaction processing.

Stripe processes payment credentials and related payment information. LeadForge does not use its application database as a repository for full payment-card numbers.

LeadForge receives billing, customer, subscription, checkout, transaction, and status information needed to administer paid plans, capacity, and entitlements.

OpenAI provides model and transcription processing used by LeadForge AI-assisted features.

Depending on the feature invoked, information sent for processing may include user prompts, relevant lead or territory information, Lead Intelligence, Workspace or Personal context selected for the request, generated-work context, support context, meeting audio, transcript content, or other feature-specific inputs required to perform the requested operation.

LeadForge uses OpenAI across features that may include LeadForge Copilot, Business Partner Tasks, Lead Intelligence synthesis, Pitch Deck generation, Copilot Discovery, Meeting Intelligence transcription and artifact generation, and AI-assisted Support.

LeadForge constructs feature-specific context and does not intentionally transmit an entire customer Workspace to an AI provider for every request.

Stream provides live video infrastructure used by Team Video Chat.

Meeting participation information, call identifiers, live media, and technical call data may be processed through Stream when users join or operate a live meeting.

Meeting Intelligence capture is controlled by LeadForge's application workflow. Temporary captured audio used for Meeting Intelligence may be processed separately from the live Stream call and may be sent to OpenAI for transcription or downstream AI processing.

Google services are used for business discovery through Google Places and for optional customer-connected Google mailboxes.

Business discovery requests may send search parameters to Google and return public business information used by LeadForge discovery workflows.

When a user connects a Google mailbox for Email Campaigns, LeadForge requests identity-related permissions and Gmail send access needed for the supported connection. The current integration is designed for sending through the connected account and is not designed to read mailbox contents.

Google may process account identifiers, authorization information, message-delivery requests, and business-search requests as necessary to provide those services.

Microsoft services are used for optional customer-connected Microsoft mailboxes.

The current integration requests identity information, authorization needed to maintain the connection, and Microsoft Graph Mail.Send permission for Email Campaign sending.

The integration is designed for sending through the connected mailbox and is not designed to read mailbox contents.

Microsoft may process account identifiers, authorization information, and message-delivery requests as necessary to provide the connected service.

If a user enables web push notifications on a supported device, LeadForge stores the push subscription endpoint and associated delivery keys needed to deliver notifications.

Delivery necessarily uses the browser, operating-system, or push-network services associated with the user's device.

Push subscription information is used for notification delivery and device-specific subscription management rather than for advertising.

A customer may choose to connect LeadForge to a provider account that the customer controls, such as a Google or Microsoft mailbox.

For those connections, the customer authorizes LeadForge to interact with the provider within the permissions granted through the connection.

The customer's own agreement with that provider may independently govern the provider's processing of the customer's information.

LeadForge seeks to limit provider access and data transmission to the information reasonably necessary for the applicable service or feature.

Different providers receive different categories of data based on their role. A payment provider does not need Meeting Intelligence content, and a video provider does not need subscription payment credentials merely because both support LeadForge.

Feature-specific context, authorization scopes, and provider APIs are used to reduce unnecessary transmission where reasonably practical.

LeadForge evaluates and manages providers according to the role they perform, the sensitivity of the processing, available contractual terms, and operational requirements.

Where LeadForge acts as a processor and engages a subprocessor for covered Customer Data, LeadForge uses contractual safeguards consistent with the applicable Data Processing Addendum and data-protection law.

The Security & Data Protection Policy describes LeadForge's current application and infrastructure security approach.

LeadForge may add, replace, or discontinue providers as the Service evolves, providers change their offerings, or LeadForge changes architecture.

This document will be updated when a material provider relationship changes in a way that affects the provider information described here.

Where an executed DPA, enterprise contract, or applicable law requires advance subprocessor notice or an opportunity to object, LeadForge will follow the applicable notice and objection procedure.

Some providers may process information in jurisdictions different from the location of the customer or user.

Where applicable law requires a transfer mechanism or additional safeguards, those requirements are addressed through the relevant provider terms, Data Processing Addendum, transfer mechanism, or enterprise agreement.

Customers with negotiated data-residency, vendor, or transfer requirements should rely on their executed agreement where it differs from this general provider information.

Questions about a provider, subprocessor notice, or enterprise vendor requirement may be submitted through LeadForge Support or the contact method made available in the Legal & Trust Center.

LeadForge LLC