Privacy
This policy covers the pingground iPhone app, the dashboard at pingground.app, and the send API. Last updated 9 September 2026.
What pingground does not do
- No advertising, ad networks, or ad identifiers.
- No analytics or tracking SDK in the app, and no analytics or tracking script on this site.
- No selling or renting your data. Image requests and infrastructure processing are explained below.
- No profiling, cross-app tracking, or building a picture of you beyond running the service.
- No marketing email. Your address, if pingground has one at all, is used to reach you about your own account or a support request you started.
What is collected, and why
Only what the service needs to authenticate you, address a notification with your consent, and show you what the provider did with it.
- Your Apple account identifier
- Sign in with Apple is the only way to sign in. pingground stores the stable identifier Apple issues for you — as a keyed digest for lookup, encrypted if the raw value is needed for Apple account lifecycle handling — so it can recognise you on your next sign-in. Apple's authorization code and identity token are used in memory for the exchange and are never written down.
- Your name and email, if Apple sends them
- Apple offers these only on your first authorization, and the email may be a private relay address. They are optional, used to label your account and to reply to you, and never used to decide what you are allowed to do. An absent name or email is a fully supported state.
- Your devices
- When you enable notifications, the app registers that installation along with the delivery address Apple issues for it. That address is encrypted at rest, never returned by any listing or history API, and discarded when you unregister the device, when Apple reports it is no longer valid, or when you delete your account.
- Notifications you compose, send, and receive
- Drafts you save as templates are kept until you delete them. Sends are kept with their content and send details — request time, target count, the provider's request identifier, HTTP status, and any rejection reason — because inspecting exactly that is the point of the product. Notification content can appear on a Lock Screen or a paired device, so treat it as you would anything visible to a bystander: do not put secrets in a payload.
- Applications, credentials, and consent
- If you create an application, pingground stores its name and settings. API credentials and recipient keys are shown exactly once at creation and stored only as keyed digests — pingground cannot recover or re-display them, only compare against them. A subscription records that you consented to let a given application notify you, together with the caps and mute switch you set.
- Sign-in sessions
- Session tokens are stored only as digests, alongside their creation and expiry times and the kind of client that signed in (app or web). The account screen shows this list; it never contains a token, an IP address, or a device identifier.
- Operational logs
- Requests to the service produce infrastructure logs with a request identifier, route, status, and timing. Network metadata such as an IP address or browser user-agent string is used transiently for abuse prevention and is not persisted into the application's own records. Credentials, keys, and notification payloads are excluded from logs by construction.
- Cookies
- This site sets cookies only for signing you in and keeping you signed in: a session cookie, a matching request-forgery token, and a five-minute, identity-free cookie that ties an Apple sign-in callback back to the browser that started it. There are no advertising or analytics cookies. Signing out clears them.
- Theme preference
- This dashboard stores a non-sensitive
pingground-themevalue in this browser's local storage. Its value is light, dark, or system; it contains no identity, is never sent to either Worker, and survives sign-out until you change it or clear this site's data.
What a sender can see about you
Consent is the only address. An application can notify you only through a subscription you created from your own signed-in surface.
- An application's owner never receives your name, email, Apple identifier, device name, or installation identity. Your devices appear to them only as random per-subscription aliases that cannot be matched up with the aliases any other application sees.
- They can see that a send to one of their subscriptions was accepted, rejected, refused because you muted or revoked them, or had no reachable device — the provider outcome, not who you are.
- You always see who sent you a notification: attribution naming the sending application is attached by the server and cannot be altered by the sender.
- You set hourly and daily caps per subscription (down to zero), can mute it, and can revoke it in one action. Revocation refuses further sends immediately, without contacting the push provider at all.
How long data is kept
| Data | Retention |
|---|---|
| Hosted notification images | 30 days after upload, or until deletion disables access; byte cleanup is retried separately |
| Private device inbox cache | Up to 1000 received messages and 200 sent summaries within 30 days; images use a 100 MiB budget |
| Local draft, navigation, search and read markers | On this device until sign-out, account deletion, or definitive session invalidation |
| Account record and connected devices | Until you delete the account or unregister the device |
| Saved templates | Until you delete the template or the account |
| Send history and received notifications, with their content | 30 days, then purged automatically |
| Sign-in sessions and their metadata | Up to 30 days, or until you sign out |
| Sign-in challenges | Five minutes, then consumed or expired |
| Account-deletion receipt (a nonreversible digest, no personal data) | 24 hours, so a lost response can be replayed safely |
| Applications, API credentials, and subscriptions | Until you delete them or the account |
One exception: if you delete your account while other people still hold a 30-day record of notifications your application sent them, that record keeps your application's name so their history still shows who sent it. Nothing else about you survives.
Who else is involved
- Apple — provides Sign in with Apple, and operates the push notification service that carries a notification to a device. A notification's content passes through Apple to be delivered, which is inherent to how notifications work on iPhone. Apple's own privacy policy governs what Apple does with it.
- Cloudflare — hosts the service and stores its database, acting as an infrastructure processor on pingground's behalf. Data may be processed on Cloudflare's global network, which means it can be handled outside your own country.
- External image hosts chosen by a sender receive image requests from your device and may see its network address. The dashboard shows external images as links. Hosted image URLs are unguessable download capabilities: anyone holding one can download it until expiry or deletion. Downloaded copies cannot be recalled.
Offline reading on your device
The app keeps protected, account-scoped message snapshots, image files, navigation, search, read markers, and unfinished drafts for offline use. These files are excluded from backups; credentials stay in Keychain. Transient connection failures preserve cached content. Sign-out, account deletion, or definitive invalidation clears account data on that device. Other offline devices clear it when they learn the session is invalid.
Your choices
- Notifications — permission is requested only after you sign in, and denying it is a supported state you can change at any time in iOS Settings.
- Stop a sender — mute, lower the caps on, or revoke any subscription from the app's Settings tab or the dashboard.
- Remove a device — unregister an installation to remove its delivery address.
- Sign out everywhere — from the account screen, which invalidates every session.
- Delete your account — in the app's Settings tab or on the dashboard's account screen. pingground revokes its Sign in with Apple authorization and then removes your account, sessions, devices, templates, applications, credentials, subscriptions, and history in one operation. It is immediate and cannot be undone. If Apple's revocation endpoint refuses the stored authorization, pingground still deletes your data and tells you to remove the authorization yourself in your Apple Account settings — it never claims a revocation that did not happen.
- Ask a question, or ask for a copy — email support@pingground.app and say what you would like. Depending on where you live you may have a legal right to access, correct, export, or erase your data; these routes are open to everyone regardless.
How data is protected
- Everything travels over HTTPS. Tokens are never accepted in URLs, so they cannot leak into request logs. Hosted image URLs are a separate download capability; keep them private when their contents are private.
- Secrets that must be replayed to Apple are encrypted at rest with a versioned, rotatable key; secrets that only need verifying — sessions, API credentials, recipient keys — are stored as keyed digests and compared in constant time, so a database disclosure alone does not hand anyone a usable credential.
- The website tier holds no policy of its own: it cannot reach the database, the signing keys, or the push provider, and an automated audit proves that on every change.
- No system is perfectly secure. If a breach affects your data, pingground will tell you what happened as directly as it can.
Children
pingground is a developer tool and is not directed at children under 13, and it does not knowingly collect their data. If you believe a child's data has reached the service, email support@pingground.app and it will be removed.
Changes to this policy
If this policy changes, the date at the top of the page changes with it, and a change that materially affects what is collected or how long it is kept will also be called out in the app's release notes. Using pingground after a change means the current version applies.
Need help rather than a policy? Support.