Privacy Policy

Effective date: October 2026

This policy describes the Pulse app and the hosted Pulse service at api.pulsenotifications.app. Pulse delivers a notification to your iPhone from an HTTP request, such as curl. It does not sell personal information. It does not use your information for tracking or advertising.

If you point the app at a server you run, that server receives the account and notification data for the session you sign in to there. This policy describes the app on your device and the hosted service. A server you operate follows the practices of whoever runs it.

Children

Pulse is not directed to children under 13. It is not in Apple’s Made for Kids category. The app does not ask for a date of birth and does not include an age check.

Information the hosted service stores

The hosted API keeps the following in its database so it can sign you in and deliver notifications. The iOS privacy manifest lists email address, user ID, device ID, and other user content. Each is linked to the account and used for app functionality. Tracking is off.

Account

• Your email address.
• A scrypt hash of your password, when the account has one. The password itself is not stored. An account that only uses Sign in with Apple, Sign in with Google, or an email sign-in code can have no password hash.
• Apple’s subject identifier, if you use Sign in with Apple. That value is the provider’s stable subject, separate from the email. Sign in with Apple is offered on iOS when the server has an Apple client id. The hosted configuration uses the app’s client id.
• Google’s subject identifier, if you use Sign in with Google. That value is the provider’s stable subject, separate from the email. When Google sign-in is not configured, the server does not accept it and does not store a Google subject. The app hides Sign in with Google until Google client ids are set.
• Whether the email is verified, and when the account was created and updated.

The account also has its own identifier on the server. That identifier, together with an Apple or Google subject when one of those sign-in methods is used, is the user ID described in the privacy manifest.

Sign-in secrets

Session tokens and refresh tokens are stored only as SHA-256 hashes. Email verification codes, password-reset codes, and email sign-in codes are stored only as SHA-256 hashes. The email that carries a code is sent by the mail provider below. The message contains the code. It does not contain your password.

Topics and messages

• Topic names you create or subscribe to.
• Notification content published to a topic: an optional title, the message, priority, tags, an optional click URL, and optional actions. The title and message are the “other user content” in the privacy manifest. The text is whatever the publisher of that topic sent.
• Which of your devices is subscribed, and whether that subscription is muted.
• For a topic you own, a scrypt hash of the publish secret. The server does not store the secret itself. The app shows it when the topic is created and keeps a copy in the device keychain.

Push delivery

• The Expo push token for a device you register. That token is the device ID in the privacy manifest. The server may also store a platform value (ios, android, or web) and when the device was last seen.
• A delivery record for a send: whether Expo accepted it, a ticket id when Expo returns one, a status, and an error string when delivery fails.

While the app is open, new messages also arrive on a server-sent events stream. On the phone, that stream sends the session in the Authorization header.

Not stored in the application database

The application database has no column for your name, phone number, location, contacts, photos, or payment information. The app does not include an analytics SDK, an advertising SDK, or a crash-reporting SDK. Its privacy manifest sets tracking to off, and the app does not show an App Tracking Transparency prompt.

Information on your device

On iPhone, the app stores the session (access token, refresh token, expiry, and the server address that session was issued for) and topic publish secrets in the iOS keychain. Those values are not written into the on-device notification cache. The app does not ask for Face ID to use that storage.

The on-device cache holds the channels you subscribe to, up to 100 cached notifications for the signed-in account, and the saved server. Quiet hours — whether they are on, and the start and end times — stay on the device. They are not an account setting on the server, and they remain after you sign out.

A browser build of the client keeps the same session keys in local storage, because the keychain store has no web implementation, and keeps the same cache in a JSON document in the browser. A browser stream cannot set Authorization, so that client can place the session on the request query string. The API redacts that value in its own logs.

How the information is used

• To create an account and sign you in, including email verification, email sign-in codes, and password reset.
• To show the channels you subscribe to and the messages published to them.
• To deliver those messages through Apple push, using the Expo push token, and over the open server-sent events stream while the app is open.
• To limit repeated sign-in and publish attempts, and to write operational logs.

Pulse does not use notification text to build an advertising profile. While the hosted demo is on, an announcements topic can be read without that topic’s publish secret. Messages there are written by the service. A private topic you own is not public.

IP addresses

The API uses the request IP as the key for in-memory rate limits on authentication and on publish attempts that are not allowed. It also writes that IP into the process log, together with the HTTP method and a redacted URL. The log redacts Authorization, X-Pulse-Token, and the token, session, and tokens query values.

Those rate-limit counters live in process memory. They are not written to the application database, and they are not shared across server processes. Pulse does not set a log-retention period in the application. The host that runs the API may keep its own access logs, which can include IP addresses.

Selling, sharing, and tracking

Pulse does not sell personal information. It does not share personal information for advertising or for tracking across apps and websites. The app has no advertising.

Pulse sends information to the processors below only so they can provide the service: hosting, transactional email, push delivery, and the sign-in provider you choose.

Processors

• Render hosts the API and the database for the hosted service.
• Resend sends transactional email (verification, password reset, and sign-in codes) over SMTP. The message includes your email address and a single-use code.
• Expo receives the push token and the notification title and body at its push service so the alert can be delivered. Apple Push Notification service delivers it to an iPhone.
• Apple, when you use Sign in with Apple. The server checks the identity token with Apple and stores the subject described above.
• Google, only if Sign in with Google is configured and you use it. The server checks the identity token with Google and stores the subject. When it is not configured, that sign-in is unavailable and no Google subject is stored.

A review of the hosted API observed Cloudflare in front of Render. That layer can see ordinary request metadata, including IP addresses, as part of serving the API. Pulse does not run an analytics product on that path.

If you save a different server in Settings, later sign-in and notification data go to that server. Switching servers signs you out. The hosted session is not sent to the new host.

Retention

Account information is kept until you delete the account.

Notification messages are kept until the topic is removed. Deleting the account removes topics that account owns, and the messages on them. An optional maintenance command can delete notifications older than a chosen number of days. When that command is run without a number, the window is 30 days. The application does not run the command by itself, so messages are not deleted on a fixed schedule unless an operator runs it.

Email codes expire. By default, a verification code lasts 24 hours, a password-reset code lasts 15 minutes, and a sign-in code lasts 10 minutes. Each code is single-use. Codes for the account are deleted when the account is deleted.

Sessions expire. By default, an access session lasts 12 hours and a refresh token lasts 30 days. Signing out revokes that session. Resetting the password revokes every session for the account. Changing the password revokes the other sessions. Deleting the account removes them.

IP addresses used for rate limiting are not stored in the application database. How long a host keeps process or access logs is up to that host.

Deleting your account

In the app, open Settings, then Account, then Delete Account, and confirm. The app sends the deletion to the server you are signed in to.

On that server, deletion removes:

• The account, including the email, the password hash, and any Apple or Google subject stored on it.
• Sessions, email verification codes, password-reset codes, and email sign-in codes for that address.
• Push tokens registered to the account, and that account’s subscriptions.
• Topics that account owns, including their messages and delivery records. The publish-secret hash on those topics is removed with them.

A topic the account does not own stays. On the hosted service, the announcements topic belongs to a reserved address and is not removed when you delete your account.

On the device, deletion removes the session from the keychain and clears that account’s cached channels and notifications, and the demo publish token. Quiet hours remain on the device. The saved server remains, so the next sign-in uses the same server. The current deletion path does not include a separate pass over every topic-secret item in the keychain. The server only stored a hash of that secret, and that hash is removed with the topics the account owns.

Forget this server, also in Settings, removes that server and its local session and cache from the device. It does not delete the account on the server.

Security

The hosted service is served over HTTPS. Passwords and publish secrets are stored as scrypt hashes. Session tokens and email codes are stored as SHA-256 hashes. The iPhone app keeps the session and publish secrets in the keychain.

The app uses standard HTTPS. It does not add its own end-to-end encryption. Request logs redact the credentials described above. Authentication responses are sent with a Cache-Control: no-store header.

Changes

If this policy changes, the effective date at the top of this page will change with it.

Contact

Questions about this policy: support@pulsenotifications.app.