Legal
Last updated: 31 July 2026
To run Karibu we rely on the third-party services below ("sub-processors"). Each one is bound by a Data Processing Agreement (DPA) or equivalent contract, and each is listed here with what it does, the categories of data it touches, and where it is hosted. This is the granular companion to our Privacy Policy and Security pages.
Where the app runs and where your data physically lives.
Primary Postgres database, authentication (incl. native TOTP MFA), pgvector embeddings, and file storage. Effectively every row of customer and prospect data lives here.
Hosting and edge delivery for the web app (apps/web). Serves HTML, JSON reads, OAuth callbacks, and webhook ingestion. Also supplies the geo header used to pick a display currency.
Runs the background workers (apps/workers): scraping, enrichment, billing ticks, exports, rollups, and the recommendation engine. Connects to Supabase over TLS.
The processors that generate intel briefs, draft outreach, and enrich contacts.
Claude API — generates per-contact AI intel briefs, opener angles, and reply drafts. The primary inference provider.
GPT models — secondary / multi-model inference and classification (e.g. reply classification, Tier 3 adversarial verification) where the routing layer selects it.
Text embeddings (voyage-3) used for pgvector similarity — reply + intel-brief retrieval and contact matching in the network-learning worker.
Actor-based enrichment chain that gathers public business information from agency websites, maps listings, and public directories. LinkedIn enrichment is run through Apify actors (their IPs, their ToS chain) — never fetched directly by a Karibu worker (ADR 0001).
PCI-compliant processors that take payment. We never store card numbers.
Mobile-money and card payment processing for Uganda and Kenya. Handles checkout + IPN webhooks.
Payment processing for the rest of Africa and USD-denominated charges. Handles checkout + webhooks.
Card payment processing for USD / international customers. Handles checkout + webhooks.
Enterprise sign-in, outbound channels, and the tooling that keeps the service healthy.
Brokers SAML / OIDC single sign-on and SCIM 2.0 user provisioning for enterprise workspaces that connect their own identity provider (Okta, Azure AD, etc.).
WhatsApp Business outbound for workspaces that connect a WhatsApp channel. BSP-free, direct Cloud API.
Error tracking and performance monitoring for the web app and workers.
Structured application logging for the web app and workers (Pino → Axiom). Optional integration, enabled via environment configuration.
Uptime and availability monitoring. Polls the public /health endpoint and powers the public status page.
Product analytics and session replay / heatmaps on the web app, so we can see where the product is confusing and fix it.
We deliberately do not list LinkedIn as a sub-processor. We never scrape LinkedIn at scale and never store LinkedIn page content centrally. The Karibu Chrome extension reads only what you, the customer, are already viewing in your own LinkedIn session; programmatic enrichment that involves public profile context is routed through Apify actors, never a direct Karibu request to LinkedIn (see ADR 0001). No customer or prospect data is sent to LinkedIn by Karibu.
Customer data is primarily stored in the EU (Supabase, Frankfurt). Where a sub-processor operates outside the EEA — chiefly the AI and identity providers above — transfers rely on Standard Contractual Clauses and, where offered, the provider's EU data region or zero-retention terms. We minimise what leaves the EU: payloads to AI providers carry only the data needed for the task, and inference inputs are never used to train third-party models.
See how to request a DPA, or email legal@usekaribu.com for our DPA, this sub-processor list as a PDF, or a DPIA covering our network-learning aggregation. The founder reads procurement requests directly.