Murph Subprocessors, Model Providers, and Connected Services
Effective Date: April 29, 2026
Last Updated: August 20, 2026
This document lists subprocessors, model providers, and independent Connected Services that may process personal information or health data when a hosted feature, integration, or user-directed workflow uses that provider. Some providers apply only when you enable the related feature. Deployment-specific providers and processing regions may vary based on Murph's production configuration and the provider's infrastructure. A row's role identifies whether the provider generally acts for Murph, acts independently under its own terms, or may do either depending on the integration.
Material changes to Murph-managed providers that process health data will be reflected here and, where required by law or contract, notified to users.
| Provider | Service | Data categories | Country/region | Murph-authorized model training or secondary use? | Retention | Role |
|---|---|---|---|---|---|---|
| Vercel | Hosted web deployment, pointer-only Workflow-managed runner nudge retries, edge/runtime infrastructure, and optional web analytics. | Account, device/browser, operational, hosted-control-plane, opaque workflow input such as mailbox item identifiers and source labels, workflow event logs, and retry metadata. Provider webhook message bodies and verification secrets are not Workflow inputs. | United States / global infrastructure | No | Service logs, workflow state, and analytics per Vercel settings and Murph retention rules. | Subprocessor |
| Cloudflare | Hosted execution, Workers, Durable Objects, object storage, logs, and security. | Encrypted stored workspace data, transient execution content needed to run requested hosted workflows, execution metadata, runtime logs, and operational artifacts. | United States / global infrastructure | No | Execution artifacts and logs per Murph retention rules and deployment settings. | Subprocessor |
| incident.io | Public status-page hosting and the browser-readable incident summary used by Murph's footer availability indicator. | IP address; browser, device, request-time, and protocol metadata; and the Murph site origin under its strict-origin referrer policy. The fixed footer request sends no page path, query, fragment, account data, prompt, health content, or message content. | United Kingdom / European-region cloud infrastructure; provider subprocessors may operate in other regions. | No model training or unrelated secondary use authorized by Murph. | System logs and technical request metadata per provider service, security, and legal retention terms. Protected data is deleted or returned after service termination unless law requires continued storage. | Status-page provider / subprocessor; independent controller for provider-owned security or legal processing where applicable. |
| Deployment-specific Postgres provider | Hosted database selected by the deployment through DATABASE_URL. | Hosted member, routing, billing reference, mailbox, workspace checkpoint, consent, and operational records. | Deployment-specific | No | Per Murph retention targets and deployment-specific database backup settings. | Subprocessor |
| Deployment-configured Temporal service | Per-user workflow orchestration, retries, timers, and runtime coordination. | Member or workspace identifiers, mailbox item identifiers, source labels, workflow status, retry, timing, and other pointer-level operational metadata. Health-message bodies and workspace contents are not intended to be Temporal workflow inputs. | Deployment-specific | No model training or unrelated secondary use authorized by Murph. | Workflow history and operational metadata per deployment settings and Murph retention rules. | Subprocessor |
| Privy | Hosted authentication, identity tokens, linked accounts, embedded-wallet support, and passkey/MFA-backed sensitive actions. | Identity, account, linked-account, wallet, device, and authentication metadata. | United States / global infrastructure | No | Per Privy service settings and Murph account-retention and deletion rules. | Subprocessor |
| Stripe | Checkout, subscription billing, invoices, tax/accounting records, and payment events. | Billing contact, customer, subscription, checkout, invoice, payment status, and metering metadata. | United States / global infrastructure | No | Billing records retained for legal, tax, accounting, and dispute needs. | Subprocessor |
| Vercel AI Gateway | AI inference for requested assistant, summarization, extraction, and automation features. | Prompts, messages, files, health context, tool context, and outputs needed for the requested feature. | Provider-specific | No for Murph health data | Limited to service delivery, security, and troubleshooting where contract or configuration allows. | Model provider / subprocessor |
| Configured AI model providers | Underlying model providers configured through the hosted assistant gateway for requested AI features. | Prompts, messages, files, health context, tool context, and outputs needed for the requested feature. | Provider-specific | No for Murph-managed health data. Murph does not route health data to configured model providers unless no-training controls are in place. If a user supplies their own provider account, API key, or self-hosted configuration, that provider's own settings and terms may apply. | Limited to service delivery, security, and troubleshooting under applicable provider controls. | Deployment-configured model provider |
| Google (Gemini API) | On-demand analysis of one user-requested video attachment for the requested assistant response. | The selected video attachment, including any embedded audio and personal or health information it contains; the user's analysis question; generated analysis; and request and usage metadata needed to provide and secure the feature. | Provider-specific | No model training or unrelated secondary use authorized by Murph; hosted activation requires applicable no-training controls. | Video is sent inline for the request; Murph creates no Gemini Files API object. Provider-side processing and retention follow applicable Google terms and project controls. | Model provider / subprocessor |
| Kernel / OnKernel | Hosted browser sessions, browser automation, secure user handoff, and managed authentication connections for user-directed website actions. | Task instructions, websites and pages used, browser-session and action metadata, form content, files, authentication connection state, and personal or health information the user directs Murph to process through the browser. | Provider-specific | No model training or unrelated secondary use authorized by Murph. | Per enabled browser feature, provider settings, and Murph account-deletion and retention rules. | Browser provider / subprocessor |
| Retell AI | Automated or AI-assisted outbound phone calls, voice processing, call routing, status, and usage reporting. | Phone numbers, call instructions and briefs, call content needed to perform the request, dynamic variables, call status, duration, cost, and operational metadata. | Provider-specific | No model training or unrelated secondary use of Murph-managed health data authorized by Murph. | Murph requires basic-attributes-only storage for calls and deletes known provider call objects during account deletion; provider logs and backups may follow provider retention. | Voice provider / subprocessor |
| Junction / Vital | Apple Health and connected health-source authorization, synchronization, normalization, and webhook delivery. | Pseudonymous user identifiers, authorization and connection metadata, Apple Health or connected-source data authorized by the user, sync state, and webhook metadata. | Provider-specific | No model training or unrelated secondary use authorized by Murph; upstream source terms may impose additional limits. | Per active connection, provider policy and settings, and Murph disconnect, deletion, and retention rules. | Health-sync provider / subprocessor |
| Composio | Optional connected-app account routing, read-only tool discovery, and user-directed connected-app actions. | Pseudonymous user identifiers, connection and account metadata, search queries, tool inputs, and connected-app results needed for the requested feature. | Provider-specific | No model training or unrelated secondary use authorized by Murph. | Per enabled connection, provider settings, and Murph retention and deletion rules. | Connected-app provider / subprocessor |
| Linq | User-directed messaging, message delivery, attachment retrieval, and webhook ingress. | Messaging identifiers, routing metadata, message content, attachments, delivery status, and webhook metadata. | Provider-specific | No | Per enabled messaging feature, provider policy, and Murph retention rules. | Messaging provider |
| Telegram | User-directed Telegram messaging, file retrieval, delivery status, and webhook ingress. | Telegram identifiers, routing metadata, message content, attachments, delivery status, and webhook metadata. | Provider-specific | No | Per enabled messaging feature, provider policy, and Murph retention rules. | Messaging provider / independent connected service |
| Resend | Transactional and authorized operational email delivery. | Recipient email address, sender, subject, message content, template or operational metadata, and delivery status. | Provider-specific | No model training or unrelated secondary use authorized by Murph. | Per enabled email flow, provider policy, and Murph retention rules. | Email provider / subprocessor |
| Oura | Optional user-authorized wearable and wellness connection through Murph's approved processing path. | Connection metadata, provider account identifier, sleep, readiness, activity, body-state, and physiological data authorized by the user. | Provider-specific | No model training or unrelated secondary use authorized by Murph. Provider-specific restrictions continue to apply unless covered by written authorization. | Only as necessary for the enabled feature and subject to Oura consent, storage, opt-out, and deletion requirements. | Independent Connected Service |
| WHOOP | Optional user-authorized wearable, recovery, sleep, cycle, workout, profile, and body-measurement connection. | Connection metadata, provider account identifier, profile, body measurement, sleep, recovery, cycle, workout, and related authorized data. | Provider-specific | No training or unrelated secondary use authorized by Murph. Disclosure to model providers or other recipients requires the applicable user permission and a use allowed by WHOOP's terms. | Only as permitted by WHOOP, applicable cache controls, user authorization, and Murph deletion rules. | Independent Connected Service |
| Garmin | Optional user-authorized health and activity connection, directly or through an approved synchronization provider such as Junction/Vital. | Connection metadata, provider account identifier, activity, sleep, heart rate, stress, respiration, body, location-related, and other data authorized by the user. | Provider-specific | No model training or unrelated secondary use authorized by Murph. Processing depends on the applicable Garmin and synchronization-provider agreements and user consent. | Per the applicable Garmin and synchronization-provider contract, source permissions, and Murph deletion rules. | Independent Connected Service / upstream source |
| Strava | Existing user-authorized activity connection lifecycle support; new connections and reconnect offers are currently disabled. | Connection metadata, athlete identifier, activities, workouts, routes or location-related data, and related authorized metadata. | Provider-specific | No model training or unrelated secondary use authorized by Murph. Provider-specific restrictions continue to apply unless covered by written authorization. | Subject to Strava's applicable cache, display, revocation, and deletion requirements. | Independent Connected Service |
| Configured clinical-record providers | Optional user-authorized clinical-record connection and retrieval. | Patient-context and authorization metadata, clinical-record data and files requested by the user, retrieval status, and operational metadata. | Provider-specific | No for Murph-directed processing | Per active connection, provider policy and settings, and Murph retention and deletion rules. | Connected service / subprocessor or independent provider, depending on the integration |
| Mapbox | Optional routing, geocoding, directions, and map enrichment requested by the user. | Route inputs, approximate locations, directions requests, and operational metadata. | Provider-specific | No for Murph health data | Temporary request processing under Murph feature limits and provider policy. | Feature provider / subprocessor |
| Configured search providers | Optional user-requested search, retrieval, or source-discovery features. | Feature-specific search queries, result snippets, source URLs, health context needed for the requested feature, and operational metadata. | Provider-specific | Murph does not send health data to search providers unless the feature requires it, the user requests it, and applicable no-training/no-secondary-use controls are in place. | Limited to service delivery, security, and troubleshooting under applicable provider controls. | Deployment-configured feature provider |
| Deployment-configured transcription and parsing providers | Optional transcription, parsing, routing, or enrichment features requested by the user. | Feature-specific prompts, files, audio, extracted text, and operational metadata. | Provider-specific | No for Murph-managed health data when applicable no-training controls are in place. | Limited to service delivery, security, and troubleshooting under applicable provider controls. | Deployment-configured feature provider |
This register distinguishes Murph subprocessors from independent Connected Services. An independent Connected Service may receive information from you or Murph under its own terms and privacy policy, and its requirements may limit the features Murph can provide for that source.
User-selected healthcare, laboratory, wellness, retail, or portal services are not Murph subprocessors merely because you ask Murph to contact them or upload a lawful export from them. Murph does not represent that it is affiliated with or endorsed by those services. When a service prohibits automated extraction, Murph requires a provider-approved integration or a user-controlled export rather than scraping or robotic retrieval.
Connected services may also process data as independent providers under their own privacy policies when you choose to connect or share data with them. The Murph Privacy Policy explains those boundaries and how to exercise privacy rights.