Security
How your store keys are stored
Connecting App Store Connect or Google Play hands us a credential that can change your listing. This page says exactly what happens to it, in plain words, so you can decide with the facts rather than with trust. Last updated 8 September 2026.
Sealed per key
Every .p8 and service-account JSON is encrypted with its own random key, and that key is wrapped by a secret kept outside the application key and the database.
Opened in memory only
A key is unsealed for the milliseconds it takes to sign a token, never logged, cached, exported or shown again, not even to you.
Never submits
We save text and reply to reviews. We never submit for review, release, change price, availability or rollout, or delete anything.
- What we ask for
- App Store Connect: an API key (Issuer ID, Key ID, the .p8 file), ideally with the App Manager role and access limited to the apps you edit here; add the Sales and Reports role and your vendor number only if you want real downloads. Google Play: a service account JSON invited to your app in Play Console with Edit store listing and Reply to reviews, nothing else. We never ask for your Apple ID, Google account or any password, and we never see them: sign-in is by email code or Google, GitHub and Apple sign-in.
- How it is stored
- Envelope encryption. Each credential is sealed with a fresh 256-bit data key using XSalsa20-Poly1305 (libsodium secretbox). The data key is itself sealed with a server secret that lives in a root-owned file outside the web root and outside the application's configuration and database. A copy of the database, or of the application key, does not open the keys; the server secret and the database are never in the same backup. The secret can be rotated, and every key is re-wrapped without ever being written in the clear.
- How it is used
- Only when you act: opening the editor, pressing Save, replying to a review, asking the assistant to translate a listing, or the morning read of your own listing and sales report. The key signs a short-lived token (20 minutes for Apple, one hour for Google) in memory; the token is cached, the key is not. Requests go straight from our server to Apple's and Google's APIs over TLS. No third party ever receives the credential, and no employee reads it: there is no screen that shows it.
- What we never do with it
- Submit a version for review, release, expedite or withdraw one, change price, availability, pre-orders or phased release, upload builds or screenshots, change in-app purchases, or delete a locale, review, app or key. These are not disabled options; the code has no path for them. Every write is one of: save listing text for one locale, add a locale, reply to one review.
- Revoking
- Remove on the Connections page deletes the sealed row at once; nothing of it stays in logs or caches because nothing was ever written there. Revoke the key in App Store Connect (Users and Access, Integrations) or delete the service account key in Google Cloud and it is dead on both sides. Deleting your account deletes every key with it.
- Where and who
- One server at Hetzner in Germany, EU, GDPR applies; Cloudflare in front for TLS and bot filtering, with ModSecurity and the OWASP core rules on the server. Operated by Primož Cigoj s.p., Cesta Andreja Bitenca 68, 1000 Ljubljana, Slovenia: a small, named team, reachable at [email protected]. The full data list is in the privacy policy.
- If you would rather not store a key at all
- Everything except editing works without one: keyword reports, tracking, charts, estimates, the assistant. Connect only when you want to edit from here, and remove the key afterwards if you prefer; reconnecting takes a minute.
- Reporting a problem
- Found something? Write to [email protected]. We answer within a day, fix first and write it up here.