Notifai Privacy Policy
How to read this policy: it describes what the Notifai service actually does with your data today, including its limits. It does not turn planned work into promises. Where a provider controls something — how long a hosting log lives, when Apple deletes a purchase record — this policy says so instead of inventing a guarantee.
1. What Notifai does
Notifai relays notifications from a machine or software agent you authorized to a Companion App you registered, and returns your replies to the session that asked. The service keeps enough Account, pairing, Device Installation, Notification Request, Delivery, reply, Agent Acknowledgement, and subscription information to authenticate the parties, route a notification, support replies, report delivery evidence during the server retention period, and decide whether your account has active access. Companion history is stored separately on the device.
The canonical policy URL is https://app.notifai.sh/privacy, served from the
dashboard origin. https://notifai.fly.dev/privacy remains reachable as an
unadvertised infrastructure alias and is not used in a release or store submission.
2. Data the service processes
Examples below describe the fields the current implementation uses. A notification is your content even when a software agent generated it. We do not sell this data, use it for advertising, or use it to train models.
| Area | Examples | Why it is needed |
|---|---|---|
| Account | Supabase auth user ID, email address, account ID, creation time. | Create and identify an account, authenticate requests, and scope data to the account. |
| Authentication and sessions | Email one-time-code requests; Supabase-managed authentication records; browser session state; Companion App access/refresh tokens and expiry in the OS keystore. | Create or sign in to an Account, keep a signed-in session, and authorize the dashboard and Companion Apps. The Notifai server validates access tokens; it does not receive a password. |
| Machine and pairing | Machine name, machine credential hash, pairing code and polling-verifier hashes, pairing status, and pairing timestamps. | Pair an authorized sending machine with an account. Raw machine credentials and raw polling verifiers are not stored by the server. |
| Device and companion | Installation ID, platform, display name, app version, notification permission state, alert setting, enabled state, last-seen time, and APNs or FCM registration data. | Register a companion, choose delivery targets, and send a notification to the right installation. Push tokens are hashed for lookup and encrypted for use. |
| Project | Project identifier, display name, settings, last-seen time, and a reference to a custom avatar. | Identify which project sent a notification and display its avatar or generated project image. |
| Notification | Request and delivery IDs, idempotency key, event name, project and target snapshots, title, plain-text summary, optional Markdown body, reply choices, accepted/reply deadlines, and lifecycle timestamps. | Deduplicate, route, present, answer, and report delivery of a requested notification. |
| Media | Uploaded image bytes, private storage key, media type, size, checksum, account, status, and expiry. | Deliver an attachment or project avatar. Media is stored in a private bucket and accessed with short-lived signed URLs. |
| Replies and Agent Acknowledgements | Reply text, selected choice ID, source, client reply ID, an optional agent-authored acknowledgement, request/delivery/device/account links, and timestamps. | Send an answer back to the originating notification, prevent duplicate replies, and show that the sending agent read the answer. |
| Subscription and entitlement | Purchase channel; the seller's opaque subscription identifier (Apple original transaction ID or Paddle subscription ID); Paddle customer ID; bound-at time; subscription state; period and grace end dates; auto-renew flag; price identity; last verified evidence time; monthly usage counters. | Decide whether your account has active access, detect a restore collision, apply the monthly allowance, and reconcile with the seller after an outage. |
| Financial records | Per charge, as the seller reported it: the seller (Apple or Paddle), the provider transaction or statement ID, the billing-period start and end, and the amount and currency. | Keep the minimized bookkeeping evidence the law requires a business to retain. These records are append-only: a wrong fact is corrected by newer seller evidence or a further audited action, never by editing the record, and the records are not used to make decisions about you. |
| Commercial audit trail | For each consequential commercial action — a support-assisted transfer of a purchase between accounts (a relink), a support-initiated refund, a payment exemption, a deletion-triggered cancellation attempt, a support export, or a denied attempt at any of these — an immutable event with the actor, the subject (account, purchase-binding, or opaque support-ticket reference), the action, its recorded reason, result, and timestamp. A relink always records the reason and the opaque support-ticket reference. | Prove afterwards who did what to a subscription or purchase and why. The trail never contains a payment instrument, a submitted email address, or notification content. |
| Evidence and operations | Delivery state, attempts, provider status/reason/ID, evidence stage and source, request/installation/registration IDs, timestamps, service error or request metadata, and short-lived provider webhook envelopes. | Operate the queue, diagnose delivery, prevent abuse, and show delivery evidence. Delivery-evidence rows intentionally do not contain notification body or media bytes. |
| On-device companion data | Local notification history, title, summary, optional Markdown body, cached images, project avatars, reply history, reply outbox, pending replies, installation/device IDs, and local session material. | Show the inbox offline or later, render a notification, and retry a reply. This data is held in the Companion App's local container and OS keystore, not only on the server. |
3. Payment data we deliberately never hold
Apple and Paddle sell the subscription and take the payment. Checkout happens on the seller's own surface, not in a card field on a Notifai page, and each seller is an independent controller of its own transaction data under its own privacy policy.
The Notifai service never stores:
- Card numbers, security codes, card expiry dates, track data, PINs, or any other cardholder data.
- Billing addresses, tax identifiers, or invoice documents.
- Your payment provider's customer email as the key that links a purchase to your account. Access is bound to your Notifai account, not to a payer email.
- Raw provider payloads as a long-lived record. A verified webhook envelope is kept only long enough to reconcile, then deleted.
What we keep is the minimized set in the table above: an opaque seller identifier, the projected subscription state, the dates we need to decide access, and — for bookkeeping — the seller's own transaction reference with the amount and currency of each charge as the seller reported it. To see or change your payment method, billing address, or invoices, use the seller's own surface — the Paddle management page linked from your dashboard Account, or your Apple Account subscription settings.
4. Purposes and use
We use the data above only to provide, bill for, and protect the notification relay: account authentication; machine pairing; device registration; notification routing and presentation; media delivery; reply handling; delivery evidence; subscription and allowance decisions; the bookkeeping records the law requires and the audit trail of consequential commercial actions; deduplication, expiry, abuse prevention, troubleshooting, and service operation.
The service has no advertising SDK, cross-app or cross-site tracking, marketing program, analytics service, or crash-reporting service. We do not use notification content to advertise, profile, or train a model.
5. Retention
These are implementation observations, not a promise that a hosting, authentication, storage, or platform provider will retain its own logs for exactly these periods. The worker runs bounded cleanup every hour.
| Data | Current behavior |
|---|---|
| Notification Requests, replies, Deliveries, delivery evidence, Agent Acknowledgements, and request-scoped media references on the server | The whole request graph becomes eligible at seven days after request acceptance and is hard-deleted in dependency order by the hourly bounded retention sweep. The service does not keep a redacted request, reply, Delivery, or evidence row after that deletion. Aggregated usage totals and commercial records are not request-history rows and follow their own rules below. |
| Ordinary uploaded notification media | A ready private object remains available for the full seven-day window measured from upload-grant creation, even after every referencing Delivery is terminal. The object and its media-metadata row become eligible at the exact seven-day edge. Object deletion happens before metadata deletion; if remote deletion fails, the metadata row remains as a retry coordinate and cleanup retries it. A signed media URL lasts about 1 hour. An active custom project avatar is exempt only while a project references it. |
| Provider webhook evidence from Apple or Paddle | A verified envelope is kept for 90 days from ingest and then deleted. That window outlasts the sellers' own retry and replay windows so a reconciliation sweep can repair a missed or reordered event after an outage. |
| Account, machine, device, project, access, and subscription data | No seven-day rule applies to these records while an account remains open. Self-service account deletion removes the account and its owned machine, pairing, device, provider-registration, project, media-metadata, notification, Delivery, evidence, reply, Agent Acknowledgement, request-media-reference, subscription, and access-grant rows. References where the deleted account acted on another account's grant are anonymized rather than deleting the other account's record. |
| Purchase tombstone | After deletion, a record that a given opaque seller purchase identifier was once bound to a now-deleted account is kept with no scheduled expiry. It exists so a later restore of that same purchase is recognized as a collision rather than silently resurrecting access. It holds no notification content and no personal profile. |
| Financial records kept for accounting duties | The financial records described in section 2 — seller, provider transaction or statement ID, billing-period dates, amount, and currency — survive account deletion where bookkeeping law requires it, and are deleted at the end of the period that law requires. On deletion each record is detached from your account onto a one-way digest. Because Apple and Paddle are the sellers, the retained row is a pointer to the intermediary rather than a buyer invoice: it contains no name, address, payment instrument, or notification content, is never edited in place, and is not used to make decisions about you. |
| Commercial audit trail | The immutable audit events described in section 2 — including a relink's recorded reason and opaque support-ticket reference — survive account deletion for the same accountability purpose and are deleted at the end of the period that law requires. |
| Deletion recovery record | Notifai retains a one-way digest derived from the authentication subject, deletion status, attempt count, timestamps, and generic failure stage/code without a scheduled expiry. The record briefly holds the internal account ID until the database purge and holds an encrypted authentication subject until provider cleanup completes. Temporary cleanup ledgers hold only Notification Request IDs and media storage key/upload-expiry pairs until queue and storage cleanup succeeds. Those recoverable identifiers and ledgers are erased on completion. |
| Browser and companion authentication | Sessions normally remain until token expiry, sign-out, revocation, or OS/app removal. Account deletion hard-deletes the Supabase Auth identity and immediately blocks existing tokens at the Notifai server. The initiating client clears its local session when deletion completes; another offline client clears when it next contacts the server and learns the account was deleted. |
| Companion App local history | History is capped at 500 entries and reply-origin history at 500 entries, with no time-based purge or separate clear-history control. The Companion App clears its local history, cached detail, attachments, project avatars, and OS notifications as soon as the server confirms deletion started, then blocks late pushes from recreating that history until a fresh Account passes the service access check. An offline Device Installation can retain its physical-device copy until it next contacts the service, the app is uninstalled, or the OS removes its data. |
| Local reply delivery | The reply outbox and pending queue are each capped at 50 items. Retries are bounded for a given failure, while transient pending items remain until a later flush or local cleanup. A Companion App that starts account deletion clears and closes both queues until a fresh account passes the service access check. |
| Service and provider logs | Operational logs and platform/provider records may contain request IDs, statuses, timestamps, or errors. Their retention is controlled by the hosting and platform providers and is not specified or guaranteed by this service. |
6. Lock-screen previews and notification content
Push payloads include the notification title and plain-text summary. Apple's push service transports that payload to a selected iPhone, and Google's transports it to a selected Android device; the operating system may show it on a lock screen, banner, or notification centre according to your settings. Notifai does not redact, encrypt end-to-end, or guarantee that a preview is hidden.
Never send passwords, API keys, access tokens, private keys, recovery codes, financial credentials, health information, or other highly sensitive work or personal content through a notification. This prohibition applies to titles, summaries, bodies, images, replies, and project names. Use a notification as a prompt to open a properly secured system, not as a secret container.
7. Security limits
The implementation uses HTTPS/TLS, hashes machine credentials, protects push registration data for server use, keeps media in private storage, uses short-lived signed media URLs, and verifies the authenticity of every provider webhook against its raw body before accepting it. These measures are not a security certification or a guarantee of a particular provider's controls. Notification content and account data are not end-to-end encrypted between the sender and the companion; transport, database, storage, operating-system, and provider encryption do not change that limitation.
8. Service providers
The service depends on these providers for the stated functions:
- Supabase: authentication, PostgreSQL database, and private object storage for the service's account, operational, notification, reply, subscription, and media records.
- Fly.io: hosting for the web and worker processes that receive requests, run delivery and retention jobs, and serve the dashboard.
- Apple: the push service transports payloads to Apple devices, and Apple's operating systems control local presentation. Apple also sells and bills App Store subscriptions as an independent controller, and App Store Connect distributes builds.
- Paddle: merchant of record for web subscriptions. Paddle runs checkout, holds the payment method, issues invoices, handles tax, and provides the subscription management page, as an independent controller of that transaction data.
- Google: Firebase Cloud Messaging transports payloads to Android devices, and Firebase App Distribution delivers Android test builds to invited testers.
- GitHub: public hosting for the versioned Android Package (APK) release assets used by Notifai's stable direct-download route.
No analytics, advertising, crash-reporting, or model-training subprocessor is enabled. Provider terms, locations, operational logs, and provider retention are outside Notifai's control; this policy does not promise a region, a deletion service level, or a provider security certification.
9. Your rights
Subject to local law, you can ask for a copy of the personal data the service holds about you, ask to correct it, ask to delete it, object to or restrict certain processing, and complain to your data protection authority. Deletion is available to you directly and immediately, as described below. For anything else, ask through Support.
For payment data held by Apple or Paddle — invoices, payment methods, billing addresses, tax records — exercise your rights with that seller, because Notifai does not hold it.
10. Deleting your account
Self-service Account deletion is available in the dashboard and the Companion
Apps, including for an authenticated Account without an active plan. Open
Account settings, choose Delete account, and type DELETE. The
server independently requires an explicit confirmation and authentication within the
preceding ten minutes. Signing out, uninstalling the app, removing a Device Installation,
or letting a pairing expire is not Account deletion.
Deletion first checks account-level safety invariants and creates a credential barrier. Once accepted, it snapshots the request IDs and media coordinates needed for remote cleanup and removes or anonymizes the account-owned PostgreSQL records described above in one transaction. This immediately removes sending machines and push registrations and prevents an in-flight mutation from adding new account data. It then cancels queued work, deletes private media objects, and hard-deletes the Supabase Auth identity. A background worker retries an observable queue, storage, identity, or database failure.
Deletion is not cancellation of an Apple subscription. As part of deletion the service asks Paddle to stop auto-renewal at the end of the current period and retries that until it succeeds. It cannot cancel an Apple subscription on your behalf. If you subscribed on your iPhone, cancel in your Apple Account subscription settings as well, or Apple may keep charging you.
The initiating browser clears its local session after the server reports completion. The initiating Companion App clears its content, reply queues, device identifiers, and OS notifications as soon as the server confirms deletion started; it keeps only the session needed to retry until completion or local sign-out. Notifai cannot erase data from another physical device while it is offline; that companion's server credentials are already unusable, and it clears its local copy when its still-valid session next reaches Notifai and learns the account was deleted. Uninstalling the app or OS data removal is the fallback for that device copy. Operational hosting, authentication, storage, and platform logs remain subject to provider retention and are not covered by a guaranteed deletion time.
11. Contact and changes to this policy
For questions about your account, your data, or this policy, email hello@raidiant.io. See Support for other help. We update this policy when the implementation changes, and the date at the top reflects the version you are reading.