Subprocessors

Key providers that help operate TrendRise.

A lawyer-review-ready provider inventory covering infrastructure, database, authentication, billing, email, AI, source data, internal operations, provider roles, notice posture, transfers, and review items.

Purpose and status

This Subprocessors page lists key providers that may process customer, workspace, account, billing, Partner, support, source, generated-output, artifact, security, or operational data to help TrendRise operate the service. It supports the Privacy Policy, Data Processing Addendum, Security page, Cookie Policy, Partner Terms, and customer trust review.

  • This is a lawyer-review-ready operating draft and must be reviewed by counsel before it is treated as a final customer-facing subprocessor notice.
  • The exact production provider list, legal entity names, processing locations, transfer mechanisms, data categories, and notice periods must be confirmed before broad customer launch.
  • Providers may change as TrendRise matures, adds features, changes infrastructure, removes tools, or replaces vendors.
  • Enterprise customers may request additional notice, objection, security review, or DPA terms through a signed agreement or order form.
  • Questions should be sent to privacy@trendrise.io or legal@trendrise.io.

How to read this page

This page is an inventory and trust-review guide. It is not a guarantee that every provider processes every customer's data, and it does not replace a signed DPA or order form.

  • A provider may process data only if the relevant feature is configured, enabled, used, or required for operations.
  • Some providers process customer-controlled workspace data; others process only account, billing, support, security, or internal operations data.
  • Some providers may act as TrendRise subprocessors, some as independent controllers, some as payment processors, and some as internal operations vendors depending on the data and service.
  • Provider downstream subprocessors are controlled by the provider's own DPA, privacy terms, service-provider list, or subprocessor page.
  • Where this page says to confirm before launch, TrendRise should verify the claim against the active vendor contract and production settings.

Provider roles

A provider is not always a subprocessor for every data flow. The final legal classification depends on the product feature, contract, customer role, provider role, and applicable law.

  • Subprocessor: a provider that processes Customer Personal Data on TrendRise's behalf so TrendRise can provide the service to a business customer.
  • Service provider or contractor: a provider that processes personal information for a permitted business purpose under US state privacy laws.
  • Independent controller: a provider that determines some purposes and means for its own legally required processing, such as payment compliance, fraud prevention, tax, legal obligations, or account administration.
  • Customer-selected third party: a provider or platform the customer chooses to use outside TrendRise, such as Shopify, Etsy, Amazon, KDP, Gumroad, Google Drive, Notion, or a creator platform. Those are not automatically TrendRise subprocessors.
  • Provider downstream subprocessor: a vendor used by one of TrendRise's providers, such as the providers listed in Stripe's, Clerk's, Neon's, Resend's, OpenAI's, Apify's, or Vercel's own legal/trust materials.

Current data categories

Providers may process different categories of data depending on the feature used and the provider's function.

  • Account and identity data: user id, name, email, sign-in state, organization/workspace membership, role, and account settings.
  • Workspace and product data: opportunities, product profiles, product ideas, market notes, source notes, pipeline items, launch plans, generated outputs, artifacts, creator/deal records, and customer-submitted text.
  • Billing and credit data: plan, checkout session, Stripe customer/subscription/invoice references, credit grants, credit deductions, refund/dispute metadata, and policy-version stamps.
  • Partner data: Partner application records, Partner codes, referral links, click/sign-up/checkout attribution, commission ledgers, payout readiness, payout runs, and Partner settings.
  • Source and intelligence data: source queries, normalized public/source results, provider metadata, prompts, generated reports, drafts, model usage metadata, and source-search logs.
  • Support and legal data: emails, support messages, legal/privacy/security requests, attachments voluntarily provided, and response history.
  • Security and operations data: logs, IP/user-agent context where available, timestamps, request metadata, abuse signals, deployment/build records, error reports, and admin/audit actions.

Customer-controlled and TrendRise-controlled records

The DPA generally treats customer-controlled workspace content as Customer Personal Data when the customer determines the purposes and means. TrendRise-controlled operational records may be processed under the Privacy Policy instead.

  • Customer-controlled examples: imported product notes, creator notes, prompts, source search instructions, saved outputs, launch checklists, artifacts, deal notes, and customer-entered workspace records.
  • TrendRise-controlled examples: account administration, billing, payment metadata, refund/dispute records, security logs, fraud-prevention records, Partner attribution records, tax records, legal notices, and support operations not solely on the customer's behalf.
  • The same provider can process both customer-controlled data and TrendRise-controlled data in different contexts.
  • If a customer needs stricter data separation, custom data residency, provider exclusions, or high-risk regulated processing, this must be handled through a signed agreement before the customer submits that data.

Notice and objection posture

TrendRise may add, replace, or remove subprocessors as the product changes. The default public-page posture is that material provider changes should be reflected on this page and in relevant privacy/DPA documentation.

  • TrendRise should update this page before or around adding a materially different provider that processes Customer Personal Data.
  • Enterprise customers may request email notice, advance notice, and objection procedures through a signed DPA or order form.
  • A customer's objection should be based on reasonable data-protection grounds and handled under the signed agreement where one exists.
  • If TrendRise cannot reasonably provide the service without a provider and no alternative is commercially reasonable, the customer may need to stop using the affected feature or terminate the affected service under the agreement.
  • Emergency provider changes for security, service continuity, legal compliance, provider failure, or incident response may happen before a public-page update where necessary.

Vendor review posture

Before treating this page as final, TrendRise should complete a vendor review for each provider that may process Customer Personal Data.

  • Confirm the active contract, DPA, service terms, privacy policy, subprocessor list, security page, and transfer terms.
  • Confirm what production features actually send data to the provider.
  • Confirm whether provider data is stored, logged, trained on, used for abuse monitoring, retained after deletion, or disclosed to downstream subprocessors.
  • Confirm processing locations, transfer safeguards, certifications, security claims, breach-notice terms, and deletion/return terms.
  • Record the review date and keep provider evidence links in internal operations documentation.

Vercel

Vercel is the current hosting, deployment, runtime, edge/network, logging, and infrastructure provider for the Next.js web application and related production deployments.

  • Function: public website, legal pages, docs routes, protected app routes, API routes, middleware, deployments, build/runtime logs, edge/network routing, hosting security, and related observability.
  • Possible data: request metadata, route paths, IP/user-agent context where available, app logs, error context, deployment metadata, environment references, limited account/workspace data included in requests, and private artifact files if Vercel Blob is enabled.
  • Feature dependency: core service operation.
  • Role posture: likely subprocessor/service provider for hosting customer-facing app and API traffic; also independent controller for Vercel account/platform administration under Vercel's own terms.
  • Location/transfer posture: global edge/cloud infrastructure; exact processing locations and transfer mechanisms should be confirmed from Vercel's active DPA, legal, security, and subprocessor materials.

Vercel Blob or equivalent storage

TrendRise may use Vercel Blob or an equivalent storage provider for private artifact, export, file-version, PDF, SVG, ZIP, Markdown, or generated-delivery files where enabled.

  • Function: store private product artifact versions and beta export files.
  • Possible data: exported files, generated outputs, artifact metadata, workspace and opportunity references, review status, storage paths, and authenticated download references.
  • Feature dependency: Product Builder export/artifact workflows where configured.
  • Role posture: likely subprocessor/service provider for stored customer files.
  • Current limitation: local beta can fall back to protected local filesystem storage; public customer delivery and storefront publishing remain separate future work.

Neon or hosted Postgres provider

Neon or another hosted Postgres provider is the expected application database provider when DATABASE_URL is configured for hosted environments.

  • Function: store application records, workspace data, user/workspace mappings, subscriptions, credit ledgers, opportunities, source-search cache metadata, generated-output records, product profiles, artifacts, Partner records, payout records, and operational state.
  • Possible data: most structured application data, excluding raw card numbers and raw bank details that should remain with Stripe or the payout provider.
  • Feature dependency: core service operation in hosted environments.
  • Role posture: likely subprocessor/service provider for hosted application database storage.
  • Current evidence note: Neon's public subprocessor page lists its own subprocessors and says it is incorporated into its DPA/terms; TrendRise should confirm the active Neon/Databricks legal entity and region settings before broad launch.

Clerk

Clerk provides authentication, user identity, sessions, sign-in/sign-up workflows, account-profile surfaces, and protected-route identity context.

  • Function: account creation, sign-in, sign-up, sessions, user identifiers, workspace-user mapping inputs, email verification, account profile, and authentication security.
  • Possible data: names, emails, user ids, organization or workspace identity context, session metadata, authentication events, device/browser context, and security-related records.
  • Feature dependency: account access and protected app routes.
  • Role posture: likely subprocessor/service provider for TrendRise authentication; Clerk may also process some records under its own legal/privacy obligations.
  • Provider evidence note: Clerk publishes a subprocessor list with providers such as Cloudflare, Datadog, Sentry, Google, Twilio/SendGrid, Stripe, Svix, and Vercel. TrendRise should verify the active Clerk configuration, especially email/SMS settings, before launch.

Stripe

Stripe provides Checkout, Billing, payment processing, invoices, customer portal, refunds, disputes, tax/payment metadata, webhook events, fraud/payment security, and Stripe Connect onboarding or payout readiness where enabled.

  • Function: subscription checkout, plan billing, invoice records, payment status, customer portal, refunds, disputes, webhook delivery, payment fraud prevention, and Partner payout onboarding/readiness where configured.
  • Possible data: customer email, billing address, payment method metadata, Stripe customer/subscription/invoice ids, transaction status, refund/dispute records, tax/payment metadata, fraud signals, Partner attribution metadata sent to Checkout, connected-account ids, payout readiness metadata, and provider event records.
  • TrendRise should not store raw payment card numbers or raw bank-account details in its own application.
  • Feature dependency: paid plans, billing portal, refunds, disputes, credit grants, Partner commission/payment workflows, and Stripe Connect readiness.
  • Role posture: mixed. Stripe may act as payment processor, service provider, subprocessor, and/or independent controller for payment, compliance, fraud, tax, and legal obligations under Stripe's own terms.
  • Provider evidence note: Stripe publishes a service provider, subprocessor, and affiliate list and describes subprocessor due diligence and updates. TrendRise should avoid copying Stripe's full downstream list and instead link customers to Stripe's current legal page where needed.

Resend

Resend provides transactional email delivery for account, admin, support, Partner, notification, and product workflow messages where enabled.

  • Function: send transactional emails, Partner invitations, payout/setup notifications, admin test emails, support replies, and product/account messages.
  • Possible data: email address, recipient name where provided, message subject/body, template variables, delivery metadata, bounce/suppression metadata, unsubscribe or suppression records, and limited support context included in emails.
  • Feature dependency: email delivery and Partner/admin messaging workflows.
  • Role posture: likely subprocessor/service provider for transactional email delivery.
  • Provider evidence note: Resend publishes a legal page and subprocessor list. TrendRise should confirm production sender domains, retention, tracking settings, and whether open/click tracking is enabled before launch.

Business email provider

TrendRise may use Proton Mail or another business email provider for company inboxes such as support, legal, privacy, billing, security, and Partner operations.

  • Function: receive and respond to customer, privacy, legal, billing, refund, security, support, and Partner emails.
  • Possible data: sender/recipient details, email content, attachments, support context, legal notices, privacy requests, billing/refund details, security reports, and response history.
  • Feature dependency: company operations and customer support.
  • Role posture: likely service provider/subprocessor for inbox handling where emails involve Customer Personal Data, and provider may have its own controller obligations for account/service administration.
  • Launch review item: confirm the exact provider, DPA availability, retention, encryption posture, admin access, and export/deletion workflow.

OpenAI or compatible model providers

OpenAI or compatible model providers may process customer-requested prompts, workspace context, source excerpts, generated-output instructions, and model metadata to produce reports, summaries, drafts, product briefs, scripts, creator outreach, launch plans, and other intelligence outputs where enabled.

  • Function: generated reports, product briefs, source summaries, scripts, copy, outlines, launch materials, creator outreach, and other intelligence workflows.
  • Possible data: prompts, workspace context, source snippets, product notes, generated outputs, action metadata, model/provider status, token usage, error information, and abuse/safety metadata depending on provider settings.
  • Feature dependency: credit-confirmed generation and intelligence workflows where a provider key/base URL is configured.
  • Role posture: likely subprocessor/service provider for customer-requested AI processing; provider may also process certain abuse, security, support, or legal records under its own terms.
  • Provider evidence note: OpenAI publishes a DPA and subprocessor list for Customer Data. TrendRise must confirm whether the exact model/provider path uses customer data for training, abuse monitoring, retention, or service improvement before launch.

Apify

Apify may be used for source-search adapters and public/source-provider marketplace, social, ad, creator, trend, or product listing collection where configured.

  • Function: run configured source actors, collect public or authorized source results, support source-search workflows, and help normalize marketplace/distribution evidence.
  • Possible data: source queries, URLs, keywords, run metadata, actor configuration, public/source results, dataset references, provider cost/request logs, and normalized source records.
  • Feature dependency: Apify-backed source-search tests and configured source adapters.
  • Role posture: likely subprocessor/service provider for source-search workflows, but TrendRise and the customer remain responsible for lawful source selection, data minimization, use, retention, and platform-rule compliance.
  • Provider evidence note: Apify publishes legal terms and a DPA describing subprocessor authorization, strict-data exclusions, security incidents, international transfers, audits, retention, and data-subject requests. TrendRise should confirm actor-specific risks before enabling each source.

Source providers and public-data platforms

TrendRise may use Google, YouTube, Etsy, Amazon, Meta, TikTok, Reddit, RapidAPI, official APIs, public feeds, authorized data sources, third-party providers, or configured adapters to gather market, product, creator, ad, trend, or distribution evidence.

  • Function: collect source evidence for Trend Radar, Research Center, opportunity scoring, product validation, creator fit, competition checks, and launch analysis.
  • Possible data: customer search terms, source URLs, public listings, public posts, public profile fields, public engagement metrics, public ad/library records, trend records, source metadata, and normalized evidence records.
  • Feature dependency: source-search features and configured provider credentials.
  • Role posture: varies by provider and integration. Some providers may be independent controllers, API providers, data licensors, or subprocessors depending on the agreement and source.
  • TrendRise should prefer official APIs and public/authorized data sources and should not use source providers to bypass access controls, scrape prohibited data, or collect unnecessary personal data.
  • Launch review item: each active source provider needs a separate legal/terms/privacy review before production customer use.

GitHub

GitHub supports source control, deployment integration, CI workflows, engineering collaboration, issue/PR history, and change traceability.

  • Function: repository hosting, code review, workflow automation, deployment integration, and engineering change history.
  • Possible data: source code, commit metadata, issue/PR text, deployment workflow logs, run output, and operational documentation.
  • Feature dependency: engineering and deployment operations.
  • Role posture: primarily internal operations provider; may process Customer Personal Data only if such data is accidentally included in code, logs, issues, docs, screenshots, or support artifacts.
  • TrendRise should not commit secrets, customer records, private workspace content, raw provider payloads, or regulated data to GitHub.

Notion

Notion is used for internal company memory, implementation decisions, legal/trust summaries, support knowledge, runbooks, and operating notes.

  • Function: internal documentation, support knowledge, legal/trust summaries, implementation history, vendor review notes, and company memory.
  • Possible data: operational summaries, support learnings, policy decisions, task notes, vendor review notes, and limited customer examples if intentionally added.
  • Feature dependency: internal operations and support knowledge.
  • Role posture: internal operations provider; may be a subprocessor if Customer Personal Data is copied into Notion for support or operations.
  • TrendRise should not put secrets, API keys, private keys, raw payment data, health data, government identifiers, or unnecessary Customer Personal Data into Notion.

Slack

Slack is used for live team coordination, support escalation, alerts, operational discussion, incident coordination, and internal notifications.

  • Function: internal team communication, alerts, support escalation, security/incident coordination, and operational discussion.
  • Possible data: alert content, support snippets, incident notes, operational metadata, customer issue summaries, links to internal records, and message history.
  • Feature dependency: internal operations and live coordination.
  • Role posture: internal operations provider; may be a subprocessor if Customer Personal Data is copied into Slack for support or incident response.
  • TrendRise should keep customer-sensitive data out of Slack unless necessary for support, security, legal, or incident work, and should summarize rather than paste raw data where possible.

Figma, Pencil, and design tools

Figma, Pencil, and similar design tools may be used for design references, product-design collaboration, logo work, mockups, and visual QA planning.

  • Function: design collaboration, product mockups, design references, brand assets, visual QA, and implementation handoff.
  • Possible data: screenshots, mockups, design notes, brand assets, route references, and limited product context.
  • Feature dependency: design and product operations.
  • Role posture: internal operations providers, not normal subprocessors for customer workspace processing unless customer data is placed into a design artifact.
  • TrendRise should avoid placing Customer Personal Data, secrets, raw billing records, or sensitive support details into design files.

Future analytics and observability providers

TrendRise may use analytics, observability, error monitoring, uptime, or performance providers in the future. These should be added to this page before production use if they process customer or visitor personal data.

  • Possible functions: route analytics, product analytics, funnel analytics, error monitoring, performance monitoring, uptime checks, log search, and alerting.
  • Possible data: route activity, device/browser context, IP-derived location, user/workspace ids, events, errors, stack traces, performance metrics, and support diagnostics.
  • Consent posture: optional analytics should remain aligned with the Cookie Policy and consent banner where consent is required.
  • Current status: exact production analytics providers still need final confirmation before broad customer launch.

Future support, CRM, and customer communication tools

TrendRise may add support desks, chat widgets, CRM tools, customer success tools, survey tools, or knowledge-base tools later. These should be added to this page before production use if they process customer or visitor personal data.

  • Possible functions: support tickets, chat, help center, customer success notes, account management, surveys, onboarding emails, and support analytics.
  • Possible data: account email, workspace context, support messages, attachments, ticket metadata, product usage context, and response history.
  • Consent/cookie posture: chat or support widgets that set cookies or track visitors must be aligned with the Cookie Policy and banner.
  • Current status: the public support page exists, but a dedicated production support platform has not been finalized in this subprocessor draft.

External product platforms

Customers may use Shopify, Etsy, Amazon, KDP, Gumroad, Stripe, Meta, Google Ads, TikTok, YouTube, Notion, Canva, Google Drive, or similar platforms outside TrendRise for their own products, storefronts, ads, or workflows.

  • These external platforms are not automatically TrendRise subprocessors simply because TrendRise helps a customer plan a product, analyze a market, or prepare launch materials.
  • If TrendRise later offers direct integrations, imports, exports, or connectors for these platforms, the provider role and subprocessor status should be reviewed and documented.
  • Customers remain responsible for their own accounts, contracts, privacy notices, refund policies, tax obligations, ad compliance, customer support, and platform terms on external platforms.
  • TrendRise should not claim to manage or control external-platform privacy obligations unless a specific integration and agreement says so.

Provider limits

TrendRise aims to share only the information each provider needs for its function. Customers should not place secrets, raw payment card data, bank details, highly sensitive personal data, or confidential third-party data into prompts, support tickets, URLs, screenshots, exports, or workspace fields unless TrendRise has expressly approved that workflow in writing.

  • Provider access depends on product configuration, feature use, support activity, and the customer's own inputs.
  • Some provider logs, backups, abuse records, fraud records, tax records, and security records may be retained under provider terms even after customer deletion requests.
  • TrendRise may withhold security-sensitive provider details where disclosure would create risk.
  • Provider availability, retention, regions, subprocessors, and security controls can change; customer-specific commitments should be written into signed agreements.

High-risk data exclusions

The default TrendRise product and this subprocessor draft are not designed for high-risk regulated data unless TrendRise signs a separate written agreement expressly allowing it.

  • Do not submit protected health information, raw payment card data, children's data, government identifiers, biometric identifiers, criminal-conviction data, precise location data, financial account credentials, private keys, passwords, API secrets, or other high-risk regulated data into normal TrendRise workflows.
  • Do not use source-search, AI, support, design, or operations tools to process prohibited data.
  • If sensitive data is accidentally submitted, contact privacy@trendrise.io or security@trendrise.io so TrendRise can assess reasonable mitigation.
  • Counsel should finalize the exclusion wording in the DPA, Privacy Policy, Terms, and this page before launch.

International transfers

Providers may process data in the United States, EEA, UK, and other countries depending on their infrastructure, support model, customer location, region settings, and downstream subprocessors.

  • Where required, TrendRise should rely on lawful transfer mechanisms such as adequacy decisions, Standard Contractual Clauses, UK transfer terms, Swiss adaptations, Data Privacy Framework participation where applicable, provider transfer terms, or another lawful mechanism.
  • Provider transfer mechanisms should be checked against the active provider DPA and trust materials before customer launch.
  • Customers needing strict data residency, EU-only processing, or provider-specific exclusions should contact legal@trendrise.io before submitting Customer Personal Data.
  • The DPA contains the main transfer-language draft and should be finalized by counsel together with this page.

Questions and notices

Questions about subprocessors, provider changes, DPAs, privacy, transfers, security reviews, or enterprise notice terms should be routed to TrendRise.

  • Privacy and subprocessor questions: privacy@trendrise.io.
  • DPA and contract questions: legal@trendrise.io.
  • Security questions: security@trendrise.io.
  • General support: support@trendrise.io.