bGuru

bGuru Sub-Processor List

Version 0.1.16published

Last updated: 2026-09-14

bGuru Sub-Processor List

This is the public list of all third-party sub-processors that bGuru engages to provide the Service. We update this list when a sub-processor is added, removed, or replaced — see the Changelog at the bottom of this page.

For the legal framework that governs these relationships, see:

  • Privacy Policy §5 (Sub-processors)
  • GDPR Art. 28 (Processor obligations) — applies for users in the EU/EEA
  • UK GDPR Art. 28 — applies for users in the UK
  • Israeli Privacy Protection Law 5741-1981 + Amendment 13 — applies for users in Israel
  • Comparable obligations under CCPA / CPRA / VCDPA / CPA / etc. for US users; under APPI / PIPA / PDPA / POPIA / etc. for users in other jurisdictions

If you have a question about any sub-processor, contact legal@bguru.app. We commit to responding within one month per GDPR Art. 12(3) and equivalent obligations.

Active sub-processors (MVP)

1. Supabase, Inc. — backend platform

  • Purpose: Postgres database, authentication, storage, edge functions, real-time subscriptions.
  • Data categories processed: account data (email, hashed password, OAuth identifier, display name), avatar and group images (user-uploaded, stored as files; or, for a user's Google-linked avatar, a link to the provider's picture, stored as a URL — not a copy), prediction data (picks, scores, conviction values), social data (groups, follows, comments, reactions), session tokens (JWT).
  • Data residency: Frankfurt, Germany (eu-central-1). bGuru migrated to Frankfurt on 2026-05-29 specifically to maintain EU data residency.
  • Sub-processor of Supabase: AWS (infrastructure layer; AWS Frankfurt).
  • Legal basis for transfer to Supabase: For EU/UK users: data stays in Frankfurt (no international transfer). For US/Israel/rest-of-world users: contractual processor relationship under each jurisdiction's local law.
  • DPA: Supabase's standard DPA (GDPR Art. 28 + UK Addendum); see https://supabase.com/legal/dpa.
  • Privacy Policy of provider: https://supabase.com/privacy

2. OneSignal, Inc. — push notification delivery

  • Purpose: Delivery of push notifications to user devices (iOS APNs + Android FCM).
  • Data categories processed: OneSignal player_id (a unique device identifier issued by OneSignal), push token (issued by Apple APNs or Google FCM), notification preferences (opt-in/opt-out, topic subscriptions), notification delivery telemetry (sent / received / clicked).
  • Data residency: United States (primary); EU mirroring optional.
  • Legal basis for transfer to OneSignal: For EU/UK users: International Data Transfer Agreement (IDTA) / EU Standard Contractual Clauses (SCCs) Annex I-III per Implementing Decision (EU) 2021/914, supplemented by OneSignal's EU-US Data Privacy Framework certification. For Israeli users: PPL Regulations (Transfer of Data Abroad) 2001 with DPA-equivalent contractual protections.
  • DPA: OneSignal's standard DPA; see https://onesignal.com/dpa.
  • Privacy Policy of provider: https://onesignal.com/privacy_policy

3. Functional Software, Inc. (dba Sentry) — crash reporting + performance monitoring

  • Purpose: Application error tracking, crash reporting, performance monitoring.
  • Data categories processed: device model, operating system + version, app version, error stack traces, network request metadata (URL only, no body), performance metrics (route render times, etc.). No user identifier of any kind is sent — not your email, not your display name, not your account ID, and not a device ID. bGuru's integration never calls Sentry's user-identification API, and the Sentry SDK does not generate a device or installation ID of its own to take its place. No IP address is sent either — Sentry's IP-address inference is disabled at the SDK level. No prediction content is sent.
  • Data residency: EU region (sentry.io/eu). Specifically chosen to maintain bGuru's EU data residency posture (matches Supabase Frankfurt).
  • Sample rates at MVP: errors 100% (capture all), performance 10%, session replay 0% (off).
  • Retention: 30 days (Sentry's default; matches the free Developer tier).
  • Legal basis for transfer to Sentry: For EU/UK users: data stays in EU (no international transfer). For Israeli users: PPL adequate-country list (EU = adequate). For US users: standard processor relationship under CCPA Art. 1798.140(o).
  • DPA: Sentry's standard DPA (GDPR Art. 28); see https://sentry.io/legal/dpa/.
  • Privacy Policy of provider: https://sentry.io/privacy/

4. API-Football (API-Sports) — sports data feed

  • Purpose: Sports fixtures, results, statistics, team data, league data.
  • Data categories processed: None of bGuru's user personal data is transmitted to API-Football. This is a one-way ingest from API-Football to bGuru's servers (Supabase Frankfurt). API-Football has no view of bGuru's users.
  • Data residency: France (API-Football's servers).
  • Why on the sub-processor list: For transparency. API-Football is technically not a personal-data sub-processor (no personal data flows), but listing here makes the data-flow architecture fully visible.
  • DPA: Not required (no personal data processed by API-Football on bGuru's behalf).
  • Privacy Policy of provider: https://www.api-football.com/privacy

5. Apple, Inc. — App Store distribution + platform services

  • Purpose: iOS app distribution, App Store / TestFlight, push notification routing (APNs), platform-level telemetry (crash reports via Apple's built-in mechanism, install metrics, etc.), and, on account deletion, asking Apple to revoke bGuru's access to the user's Apple ID.
  • Data categories processed: Apple ID (account-creation identity), device identifiers (vendor identifier per IDFV, NOT IDFA — bGuru does not request IDFA at MVP), platform crash logs (Apple's built-in mechanism, in addition to Sentry), and — only when an account that signed in with Apple is deleted — a one-time authorization code used solely to request revocation; not stored.
  • Data residency: Worldwide (Apple's infrastructure).
  • Legal basis for transfer to Apple: Standard platform-tier processor relationship. Apple's data handling is governed by Apple's own Privacy Policy.
  • DPA: Apple's developer terms include data-processing provisions.
  • Privacy Policy of provider: https://www.apple.com/legal/privacy/

6. Google LLC — Play Store distribution + platform services

  • Purpose: Android app distribution, Play Store, Google Play services (push notification routing via FCM, Play Integrity, etc.).
  • Data categories processed: Google account (account-creation identity), Android advertising identifier (GAID — not read by bGuru at MVP), platform crash logs (Play Console Vitals, in addition to Sentry). For users who sign up via Google OAuth: bGuru saves a link to the user's Google profile picture at first sign-in and displays the picture from that link. bGuru does not copy or store the image itself — it continues to be hosted by Google. A user can replace this at any time by uploading their own image directly in bGuru, which is then stored on bGuru's own infrastructure (Supabase Storage, Frankfurt) instead.
  • Data residency: Worldwide (Google's infrastructure).
  • Legal basis for transfer to Google: Standard platform-tier processor relationship.
  • DPA: Google Play's developer terms include data-processing provisions.
  • Privacy Policy of provider: https://policies.google.com/privacy

7. Cloudflare, Inc. — mini-site CDN + DDoS protection

  • Purpose: Hosting of the public mini-site (bguru.app) including the Terms of Service, Privacy Policy, Cookie Policy, Community Guidelines, sub-processor list page, and (later) share-link SSR pages. CDN, DNS, DDoS mitigation, Web Application Firewall.
  • Data categories processed: IP address (transient, for routing + bot-detection), browser User-Agent string (transient), Cloudflare's bot-detection cookie (essential function only, not behavioural).
  • Data residency: Worldwide (Cloudflare's edge CDN); EU edge nodes serve EU visitors per Cloudflare's data residency commitments.
  • Legal basis for transfer to Cloudflare: For EU/UK users: EU SCCs + Data Privacy Framework. For Israeli users: PPL DPA-equivalent contractual protections.
  • DPA: Cloudflare's standard DPA; see https://www.cloudflare.com/cloudflare-customer-dpa/.
  • Privacy Policy of provider: https://www.cloudflare.com/privacypolicy/

Sub-processors used by sub-processors (transitively disclosed)

For transparency, bGuru's primary sub-processors above themselves rely on the following infrastructure-tier providers:

  • AWS (Amazon Web Services) — used by Supabase for Frankfurt-region database + storage hosting.
  • Apple APNs / Google FCM — used by OneSignal for the actual push delivery transport.
  • Stripe — NOT currently used (no payment processing at MVP). Will be added in a future version if/when paid tiers ship.

Inactive / not-yet-used sub-processors (for transparency)

  • Stripe / Paddle / other payment processor — NOT used at MVP. Will be added when a paid Premium Tipster tier ships in a future version.
  • Google LLC (AdMob) — advertising (NPA Phase 1 and personalized Phase 2) — NOT active at MVP; planned for v1.1+. The AdMob SDK (react-native-google-mobile-ads) was removed from the MVP codebase on 2026-06-08 (branch chore/remove-admob-mvp). No ad data of any kind is transmitted to Google AdMob at this version of the Service. The re-introduction plan is documented in docs/features/feature-13-admob-rollout-plan.md. Phase 1 (NPA-only, npa=1, no IDFA, no GAID, no behavioral profile) is the first milestone; Phase 2 (personalized/behavioral advertising) is a further future step. When Phase 1 activates in v1.1+: the Google AdMob entry will be moved to the active section above, the material-change notice described in the Cookie & Ad-Tech Policy §9 will be issued before any ad serves, and the Privacy Policy and Sub-processor list will be updated to name AdMob as an active processor with full data-category disclosure.
  • k-ID / PRIVO / SuperAwesome KWS / Yoti (parental-consent providers) — NOT used at MVP. Will be added when Brazil / India / Canada / Quebec / Belgium markets are opened in v1.1.
  • Translation services — NOT used at MVP. Will be added when French / Dutch / German translations are commissioned for v1.1 Canada / France / Belgium re-opening.

How we choose sub-processors

For every prospective sub-processor, bGuru evaluates:

  1. Data minimisation — the sub-processor must process only the data necessary to perform its function.
  2. Data residency — preference for EU-region providers where available (matches our Frankfurt Supabase posture).
  3. Contractual protections — GDPR Art. 28-compliant DPA, UK GDPR equivalent, PPL-equivalent contractual protections, equivalent obligations under all other applicable laws.
  4. Sub-processor transparency — the sub-processor must publish its own sub-processor list and notify of changes.
  5. Security posture — current SOC 2 Type II report, ISO 27001 certification, or equivalent.

How to be notified of changes

We update this page when sub-processors change. For users who want active notification of changes:

  • EU / UK / Israel users — material additions of sub-processors (a category-of-data change, a data-residency change) are subject to the standard Terms of Service §16 material-change notice flow (an in-app notice, published on the effective date shown in the header).
  • Other users — same notification mechanism applies.
  • Continuous monitoring — you may also subscribe to this page directly via the bGuru changelog feed (planned for v1.1).

Changelog

Date Change
2026-09-14 v0.1.16. Entry #5 (Apple) extended: on account deletion, bGuru asks Apple to revoke its access to the user's Apple ID, using a one-time authorization code that is not stored. Companion: Privacy Policy v0.1.27.
2026-09-13 v0.1.15. "How to be notified of changes" corrected to match the same-day Terms of Service 0.1.22 change-notice rewrite — points at ToS §16 once instead of restating the old 30-day/banner/email mechanism in its own words, and fixes a pre-existing stale cross-reference in the same sentence (it cited "ToS §15," which has been Governing law since the ToS gained a new §11 in 2026-08-17 — Changes to these terms has been §16 since that renumbering, and this sentence was evidently missed when every other stale §15/§16 pointer was fixed at the time). A wider grep run found the same "30-day" figure surviving in the inactive-AdMob entry above ("the 30-day material-change notice described in the Cookie & Ad-Tech Policy §9"), also dropped in this pass — that entry now matches Cookie & Ad-Tech Policy §9's own corrected wording, which no longer has a day-count. Companion: Terms of Service 0.1.22, Privacy Policy 0.1.26, Cookie & Ad-Tech Policy 0.1.13.
2026-09-13 v0.1.14. Entry #1 (Supabase) extended: a Group's own picture is stored the same way a user-uploaded avatar is (as a file in Supabase Storage) — it was previously described only under "avatar images." No change to entry #6 (Google), which already correctly describes only the user-avatar link mechanism. Companion: Privacy Policy v0.1.25.
2026-09-13 v0.1.13. Facebook sign-in and its SDK removed; entry #7 (Meta Platforms, Inc.) deleted in full — Meta is not a sub-processor of any kind. Cloudflare renumbered from #8 to #7. Entry #6 (Google) corrected: the avatar picture is linked from Google, not copied and stored by bGuru — the previous "fetches and stores" description was wrong. Companion: Privacy Policy v0.1.24.
2026-08-27 v0.1.12. Cloudflare entry (#8) reverted to CDN + DDoS + WAF only. The approximate-location lookup added in v0.1.11 (2026-08-26) was removed the next day: the founder decided to remove connection-based location detection entirely, rather than fix or extend it, and use device GPS (with an explicit permission prompt, only from the future local-standings screen) instead. No location lookup of any kind — IP-based or otherwise — exists anywhere in bGuru's infrastructure at this version of the Service. Companion: Privacy Policy v0.1.23. Full reasoning: _research/decisions-log.md, "User location — all collection removed; GPS-only opt-in deferred to local standings (2026-08-27)."
2026-08-26 v0.1.11. Cloudflare entry (#8) extended: since G12 (2026-08-26), Cloudflare's per-request geolocation metadata also powers bGuru's new approximate-location feature — the mobile app calls bGuru's own /api/geo endpoint, Cloudflare attaches its estimate of the requesting connection's country/city/region/approximate coordinates, and bGuru's endpoint keeps only country and city (never the IP address, never the coordinates) before returning them to the app. No new sub-processor added — this is an additional use of the CDN relationship already in place, not a new third party. Companion: Privacy Policy v0.1.21 §3.1/§4.1/§4.2/§5/§7/§8.1.
2026-08-10 v0.1.10. Corrected the Sentry entry (#3): the mobile app's Sentry integration was rewritten the same day (PR #512) to send no user identifier at all — no email, display name, account ID, or device ID — rather than the "anonymised user identifier" this list previously described. Also stated plainly that no IP address is sent to Sentry (Sentry's IP-address inference is disabled at the SDK level) — a fact not previously disclosed here. This is a narrowing of what's collected, not an expansion, so no 30-day material-change notice is required. Companion correction: Privacy Policy v0.1.11 §3.1/§3.2/§4.2 and Cookie & Ad-Tech Policy v0.1.9 §1/§2.2/§6.
2026-06-08 v0.1.9. Google LLC (AdMob) removed from the active sub-processors section. AdMob SDK removed from MVP codebase on 2026-06-08 (branch chore/remove-admob-mvp); no ad data is transmitted to AdMob at this version of the Service. AdMob entry moved to the "Inactive / not-yet-used" section with a description of the v1.1+ re-introduction plan. Cloudflare renumbered from #9 to #8.
2026-06-02 v0.1.8. Refined the Google AdMob (#8) under-18 ad-treatment description to use generic public wording rather than naming a specific Google SDK flag. The substantive behaviour is unchanged. Collapsed the public changelog's pre-launch drafting iterations into a single summary entry for clarity.
2026-06-02 v0.1.7. Refined the AdMob category-blocking description to match what's currently in place (Google AdMob console + kill-switch process). Reserved the word "contractually" until a written commercial agreement with Google is in place.
2026-06-02 v0.1.6. Refined the Google AdMob (sub-processor #8) data-category descriptions to focus on what bGuru transmits to AdMob rather than what AdMob internally accesses. "NOT processed: IDFA, GAID..." reframed as "bGuru does not pass to AdMob: IDFA, GAID, bGuru account ID, email address, display name, Picks, group memberships..."
2026-06-02 v0.1.5. Google LLC (AdMob) moved from inactive to active sub-processor (#8) — used for non-personalized contextual advertising at this version of the Service. NPA mode (npa=1 at every request): no IDFA, no GAID, no behavioral profile. Age-restricted ad-treatment settings applied for users registered as 16 or 17. Gambling-adjacent ad categories blocked. Kill-switch via Supabase platform_config. Inactive section updated to clarify NPA AdMob is now active, while personalized/behavioral mode remains inactive.
2026-06-02 v0.1.4. Updated the 'Inactive / not-yet-used' section to identify Google AdMob specifically as the planned future advertising sub-processor (currently not active). Described the data categories that will flow to Google at AdMob activation, the gambling-category block requirement, and the 30-day notice obligation before activation. No change to any active sub-processor.
2026-05-31 → 2026-06-01 Pre-launch drafting iterations (v0.1.0-draft through v0.1.3-draft). Multiple internal drafting iterations during the pre-launch review period. The substantive provisions described above were drafted, refined, and consolidated through this period.