Privacy policy

1. Who we are

TillPulse is a product of TillAfrica, registered in Kampala, Uganda ("TillPulse", "we", "us"). For privacy questions: privacy@tillpulse.io.

2. Two roles, two data flows

TillPulse has two distinct roles depending on whose data we are handling.

(a) When you are a TillPulse customer

We are the controller of your account data — your email, name, organisation, billing details, audit log entries, and the data you put into the dashboard yourself.

(b) When end-users hit your app and our SDK reports an event

We are the processor. You (the developer who installed our SDK) are the controller of your end-users' data. We process it on your behalf under the Data Processing Addendum.

3. What we collect from you (TillPulse customers)

• Account: email, name, hashed password, optional TOTP secret (encrypted), backup codes (hashed).
• Workspace: organisation name, slug, projects, team membership, roles.
• Authentication metadata: last login, IP address of session, user-agent, refresh token issue/rotate timestamps.
• Usage telemetry: page views, feature usage events, error reports from the dashboard itself, all aggregated and identified by your user ID.
• Audit log: privileged actions taken in your workspace (creating projects, rotating DSNs, deleting issues, changing roles).
• Support correspondence: emails, tickets, and notes from any conversation with our team.

4. What our SDKs collect from your end-users

Our React Native and Flutter SDKs run in your app and capture observability events. By default, the SDK collects:

• Crash and error data: exception type, message, stack trace, breadcrumbs (last ~100), device model, OS version, app version, locale, timezone.
• Performance data: cold-start time, ANR events, frame jank counts, transaction durations, network request timings (URL host only by default — query strings stripped).
• Network context: connection type (2G/3G/4G/wifi), carrier (if exposed), reachability.
• Battery context: level, charging state.
• Friction signals: rage taps, dead-zone taps, ghost taps — coordinates relative to the screen, not screenshots.
• Security signals: rooted-device / jailbreak heuristics, overlay-app presence, certificate-pinning failures.

By default, the SDK does not collect:

• End-user IP address (stripped at the ingest API)
• Device advertising identifier
• Screen contents, screenshots, or input field values
• Email, phone, or any other PII pattern (auto-scrubbed)

Customers can configure additional capture (e.g. sendDefaultPii: true), which is their choice and their responsibility under the DPA.

5. PII scrubbing

Before any event leaves the device, the SDK scrubs known PII patterns: emails, phone numbers in NG/KE/ZA/GH/RW formats, payment card numbers (Luhn-checked), NIN, BVN, M-Pesa references, Bearer tokens in Authorization headers, IPv4 in payloads. The ingest API runs the same scrubber a second time before any event reaches the database. We will never see a customer's user's email address unless the customer explicitly disables the scrubber.

6. Why we collect it

• To provide the service. Delivering crash reports, alerts, and analytics — we cannot do that without the underlying events.
• To secure the service. Detecting abuse, rate-limit evasion, credential stuffing, and SDK tampering.
• To improve the service. Understanding which features are used and what fails.
• To bill the service. Aggregating event volume per workspace.
• To meet legal obligations. Tax, accounting, lawful requests where binding.

The lawful bases are: contract (delivering the service you signed up for), legitimate interest (security, fraud prevention, analytics), consent (cookies described below, marketing emails), and legal obligation where applicable.

7. Where data is stored

Each project pins to a data region, which determines where its event data is stored:

• af-south-1 — Africa (Johannesburg)
• eu-central-1 — Europe (Frankfurt)
• us-east-1 — North America (Virginia)

Account data, audit log, and team metadata live in our primary control plane in the EU. We use sub-processors with appropriate transfer mechanisms — see DPA, Annex II.

8. How long we keep it

9. Your rights (data subjects)

Depending on your jurisdiction (GDPR, POPIA, NDPA, etc.), you have rights to: access, rectify, erase, restrict, port, and object. To exercise them as a TillPulse customer, email privacy@tillpulse.io.

If you are an end-user of an app that uses TillPulse, the app's developer is the controller of your data. Contact them first; we will assist them in responding to your request.

10. Sub-processors

We use a small set of vetted sub-processors to deliver the service:

• Cloudflare — edge hosting, DDoS, WAF
• Neon — managed Postgres for account + workspace data
• ClickHouse Cloud — analytics store for event data
• Meilisearch Cloud — full-text search
• Resend — transactional email
• OpenRouter / Moonshot AI — large-language-model inference for Ask Pulse and TillMind. Per-request only; no training on customer data, zero retention beyond the response.
• MaxMind — local GeoLite2 database for IP-to-region (no calls per request)

Caching, rate-limit counters, and the issue-summary index run on infrastructure we operate ourselves rather than third parties. Full list, location, and purpose: DPA, Annex II.

11. Cookies

Strictly necessary cookies only: tp_access, tp_refresh, tp_sso_pkce (10 min during SSO), tp_csrf. We do not use third-party advertising or marketing cookies. See Cookies.

12. Security

Bcrypt-hashed passwords (12 rounds), JWT RS256, refresh-token rotation, AES-256-GCM at-rest encryption for TOTP secrets and OAuth credentials, PII scrubbing both client- and server-side, optional TOTP, optional SSO, audit log, signed and replay-protected webhooks. See Security.

13. Children

TillPulse is a B2B developer tool not intended for use by anyone under 16. We do not knowingly collect personal data from children. If you become aware that a child has provided us with personal data, please contact us so we can delete it.

14. Changes to this policy

We may update this policy. Material changes will be announced in-product and emailed to workspace owners at least 14 days before they take effect.

15. Contact

Questions, requests, complaints: privacy@tillpulse.io. If you are not satisfied with our response, you may complain to your local data protection authority.