What your RevenueCat key can do here

We ask for a RevenueCat v2 secret key with two read scopes and nothing else: Charts metrics → Charts set to Read, and Project configuration → Apps set to Read. Overview is optional: grant it for sharper current numbers, or leave it off.

Charts is what the board is built on: new customers, MRR, revenue, active subscriptions, trials and churn. Project configuration → Apps is read for one reason only, to list the apps in the project and check one of them is the listing being claimed. That check is what the word verified means here.

The key cannot create, change or delete anything in your project. It cannot read individual customers, receipts, or personal data. If you grant it more than the scopes above, we still only ever call those endpoints.

Keys are encrypted with AES-256-GCM before they touch the database, under a server secret that is not stored in the database. The API never returns a key, in any response, to anybody, including the account that connected it. There is no screen that shows it back to you.

Somebody who steals a copy of the database gets ciphertext. Without the server secret it does not decrypt, and the secret lives in the server environment, not in a table.

Somebody who steals the whole server, database and secret together, gets the plaintext key. This is why we ask for a read-only key: the worst case is that an attacker reads the same charts you can, and cannot change your products, prices or entitlements.

Two ways, and you do not need us for either.

1. 1In RevenueCat: Project settings, API keys, find the key, delete it. It stops working immediately. Our next pull fails, the listing is marked Key expired, and it stops ranking until a working key is connected.
2. 2Here: open your listing while signed in and choose Let this listing go. That deletes the stored key and releases the claim in one action. We do not ask you for the old key to do it, because the account is the proof, and an owner who rotated a key they no longer have must not be locked out of their own listing.

Rotating rather than revoking works too: connect a new key for the same project and it replaces the old one.

The owner of a verified listing can remove it from the board entirely. Removal hides the listing from the board, from search and from the sitemap, and releases the claim. The history stays in the database rather than being deleted, so a milestone link somebody already shared keeps working.

Anybody can report a listing from its profile, signed in or not, including someone who believes their app was claimed by the wrong account.

• Adding listings: 30 per IP per UTC day.
• Refreshing a listing: 60 per IP per UTC day.
• RevenueCat key attempts: 20 per IP per UTC day.
• Reports: 5 per IP per UTC day.
• Usage beacons: 500 ingest calls per IP per UTC day, shed silently past that.

Counters reset at midnight UTC. Nothing here stores an IP address as a record: the rate-limit table holds a counter per address per day and nothing else.

The encryption secret can be rotated, and rotating it makes every stored key undecryptable by design. Owners see Key expired on the next pull and reconnect with a fresh key; no stored ciphertext survives the rotation in a usable form. We would rotate it if we had any reason to think the server was compromised, and we would say so on this page and by email to every affected owner.

Aggregate counters per kind, subject and UTC day, held on our own server: no IP addresses, no user agents, no user ids, no raw event log. Separately, Google Analytics measures page traffic with Google's cookies only after you accept the cookie banner. Rejecting it, or withdrawing consent later from Cookies in the footer, keeps that off. There is no advertising cookie. The only first-party session cookie is the sign-in session, and only after you sign in.