Privacy policy

Last updated · August 2026

1. Overview

MintMetric is a precious metals portfolio tracker. This policy explains what the app and the website collect, what we store on our servers, which third parties process data on our behalf, how long we keep each category, and what rights you have. It covers the MintMetric mobile app and mintmetric.app.

We have written it to be specific rather than reassuring. Where something does leave your device, this policy says so and says exactly what it is.

2. Information We Collect

Free tier — no account. No account is required to use MintMetric. Your portfolio — holdings, purchase prices, notes and storage locations — is created and kept on your device in an encrypted local database; your item photos are stored alongside it as image files on your device, not inside that database (§6). We do not receive any of it. The app does request spot prices from our API; those requests carry no account identifier and no portfolio data (§7).

Sync tier — optional account. If you create an account you provide an email address and a password, both handled by our authentication provider, Supabase. An account unlocks cloud sync, encrypted cloud backup, certificate lookups and spot price alerts. Three things leave your device when you use these features, and each is worth stating precisely:

• Your portfolio, as ciphertext. Holdings are encrypted on your device with a key derived from your sync passphrase before anything is uploaded. We store the ciphertext. We do not have your passphrase and cannot decrypt it.
• A certificate number, when you look one up. Sent from our servers to PCGS or NGC — see §7.
• Your account identifier, when you sign in. Signing in to your account sends your account identifier — a random UUID — to RevenueCat so that a subscription can be matched to your account; it is sent again when you make a purchase. This happens even if you never buy anything. See §8 and §10.

The website. If you join the waitlist we store the email address you submit, along with the referrer and any campaign parameters in the link you arrived from. Aggregate, cookieless page analytics are described in §8.

3. How We Use Your Information

• To operate the features you turn on: sync, encrypted backup, subscriptions, certificate lookups and spot price alerts.
• To email you before an encrypted backup is deleted after a subscription lapses, so you have time to resubscribe or export it.
• To keep the service available and resistant to abuse — rate limiting, error handling and capacity planning.
• To answer support requests and requests you make under this policy.

We do not use your information for advertising, profiling or automated decision-making, and we do not sell or rent it.

4. How We Store and Protect Your Information

The claims below describe what MintMetric's own code does. We do not restate our hosting providers' internal security measures as though they were ours; those are governed by the agreements listed in §10.

• Your portfolio database is encrypted on your device using SQLCipher. If the SQLCipher library is not present the app raises an error rather than silently writing a plaintext database.
• The database key is generated on your device— a 256-bit random value created on first launch and held in the platform secure store: the iOS Keychain, or Android's encrypted preferences. We never receive it in readable form. It leaves the device in one situation only: when you create a cloud backup it is wrapped with your passphrase-derived key and travels inside the encrypted archive, so that the backup can be restored on another device.
• You can lock the app with a PIN, and unlock it with your device biometrics if you enable that.
• Sync and backup are end-to-end encrypted. Your sync passphrase is stretched with Argon2id (64 MB of memory, 3 iterations) into a 256-bit key, and your data is encrypted with AES-256-GCM before it leaves the device. The passphrase itself is never sent to us.
• A cloud backup is encrypted before upload. Your encrypted database and your item photos are bundled into a single archive, and that archive is then encrypted with the same passphrase-derived key. What we receive is one opaque blob.
• Release builds refuse a non-HTTPS connection to our API.
• Our servers do not log IP addresses — see §7.
• Every authenticated request is scoped to your account. The account identifier is taken from a verified authentication token and database queries are restricted to it.

No security measure is absolute, and we do not claim otherwise. If you lose your sync passphrase we cannot recover your encrypted sync data or your backups for you — that is a direct consequence of not holding your key.

5. Data We Store on Our Servers

This is the full inventory of what MintMetric holds server-side. Where an entry says ciphertext, we hold the data but not a key that would let us read it — it is listed here because we do hold it.

• Account identity. Your email address, a randomly generated account identifier (UUID), and authentication sessions. Held by Supabase.
• Account email, in our own database. When you create a cloud backup we copy your email address into our database for one purpose: to warn you before that backup is deleted after a subscription lapses.
• Encrypted sync data. Versioned ciphertext blobs containing your portfolio, keyed to your account identifier.
• Encrypted backup archives and their metadata. The archive objects (ciphertext, containing your database and your item photos) are stored in DigitalOcean Spaces. A metadata row — identifier, storage key, size in bytes, status and timestamps — is stored in our database.
• Subscription and entitlement records. Tier, status, the RevenueCat identifier, and purchase and expiry timestamps.
• Spot price alerts. Metal, threshold, direction, whether the alert is enabled, and when it last fired.
• Push notification device tokens. A device token is an online identifier under GDPR Art. 4(1). The table records the token, the platform, your account identifier, and when the token was created and last seen. No shipping version of the app registers one and no push transport is provisioned, so nothing populates it today — we disclose it because the endpoint is deployed and reachable. Retention is in §12.
• Certificate lookup cache. PCGS and NGC responses, cached by certificate number. These rows are keyed by the certificate number alone and hold no account identifier.
• Certificate lookup quota counters. A per-account daily count of PCGS lookups, used to enforce a fair-use quota.
• Email suppression records. If mail to your address bounces or is marked as spam, we record the address and the reason so we stop sending to it.
• Backup retention warning records. That a warning was sent for a given backup, when, and to which address.
• Backup warning send-attempt timestamps.A per-account row recording when we last attempted to send you a backup-deletion warning, so repeat warnings are spaced out. It holds your account identifier and that timestamp only — no backup identifier and no email address.
• Waitlist emails. If you joined the waitlist on the website: the email address, the referrer, and any campaign parameters.

6. Your Holdings and Photos

An inventory of the precious metals someone owns — quantities, purchase prices, storage locations and photographs — is sensitive in a particular way. It is both a financial profile and, in the wrong hands, a theft risk. We treat it as the most sensitive category of data in the product.

• On the free tier, your holdings never leave your device.
• If you turn on sync or backup, they leave only as ciphertext, encrypted with a key derived from a passphrase we do not hold. What reaches our servers is an opaque blob. It is listed in §5 as data we hold, because we do — we simply cannot read it.
• There is no readable copy on our side. Our servers hold no plaintext holdings: your portfolio reaches us only as the encrypted sync blob and the encrypted backup archive, and we cannot read either.
• One thing about an item does reach us in the clear, and we would rather name it than let the line above read as an absolute: a certificate number, when you look one up (§7). That request is authenticated, so it is made under your account; the cached response is keyed by the certificate number alone and holds no account identifier.
• Item photosare stored as ordinary image files in the app's private storage on your device, not inside the encrypted database. They leave your device only inside an encrypted backup archive. Cloud sync does not upload them; it carries only the file references recorded against a holding.
• We do not sell or share your holdings, and we do not use them for advertising, profiling or automated decision-making.
• Crash reports, if crash reporting is ever enabled (§9), never carry holdings, portfolio values, your email address or your sync passphrase.

7. Spot Prices and Certificate Lookups

Spot prices. The app fetches spot prices from our API, which sources them from metals.dev. A spot price request is a market quote: it carries no account identifier and no portfolio data. metals.dev receives nothing about you at all — our server asks for the price, your device does not.

IP addresses. We do not log IP addresses. Our request log records a request identifier, the HTTP method, the path, the response status, the response size and the duration — and no client address. A client address is derived from the forwarded-header chain for exactly one purpose: an in-memory, per-client rate-limit counter that keeps the API available. It is never written to a log line, and no database table has a column for it.

Certificate lookups.If you look up a PCGS or NGC certificate number, the request goes to our servers and our servers call PCGS or NGC. The only thing that leaves is the certificate number you entered. PCGS and NGC see our server's IP address, not yours, and receive no account identifier, no email address and no holdings data. The app also offers a link to open a certificate on PCGS's or NGC's own website; following that link is an ordinary browser visit made from your device, in which the grader sees your device's IP address like any other visitor. We cache the response by certificate number for 30 days so that a repeat lookup does not leave our systems again; the cache row holds no account identifier. Certificate lookups require an account and an active Pro subscription.

8. Analytics

Website. mintmetric.app uses Plausible Analytics when it is enabled for a deployment. Plausible sets no cookies, collects no personal data and no cross-site identifiers, and is hosted in the European Union. We use it for aggregate page views, traffic sources, and a small number of anonymous events such as a waitlist submission. Plausible is not used in the mobile app.

Mobile app. The MintMetric app contains no analytics or advertising SDK — no Google Analytics, no Facebook SDK, no attribution or ad-network library, and no cross-app tracking of any kind. The third-party SDKs it does compile in are not analytics products. Its authentication client, Supabase, transmits your email address and password when you sign in or sign up, and is described in §2, §5 and §10. Two others — its purchase SDK and its crash reporter — are named here rather than glossed over:

• RevenueCat handles in-app purchases and is active in release builds. When you sign in it receives your MintMetric account identifier — a stable UUID — so a purchase can be matched to your account, together with purchase and entitlement data. It does not receive your email address, your holdings, or any portfolio data.
• Sentry is a crash reporter. It is compiled into the app but switched on only by a build-time configuration value, and the builds shipped today do not supply one. See §9.

9. Crash Reporting

Sentry is present in the app binary but inert unless a build supplies a Sentry DSN at build time. Builds without it never initialise the SDK: no network calls are made and nothing is reported. The builds we ship today do not supply one, so no crash data leaves your device.

If we do enable it, this is what would be sent: the exception type, its message, the stack trace, and the app and OS version. The SDK is configured with default personal-information collection switched off and performance tracing disabled, and every event passes through a scrubbing step before it is sent. Holdings, portfolio values, your email address and your sync passphrase are never attached.

We will update this policy before shipping a build with crash reporting enabled, so that a build-time flag cannot quietly change what leaves your device.

10. Sub-Processors and Third-Party Services

We share data with the parties below only as needed to operate the service. Where no data processing agreement is in place, the table says so rather than implying one.

Each provider processes data under its own privacy policy. Apple and Google appear here as distribution and purchase-processing platforms; the app itself is also subject to their respective policies when you download it.

11. International Data Transfers

Where we transfer personal data to a sub-processor that handles it on our behalf — the parties in §10 we have a data processing agreement with — we rely on appropriate safeguards: for EU and EEA transfers, the EU Standard Contractual Clauses; for UK transfers, the UK International Data Transfer Agreement or Addendum; for Australian users, the cross-border accountability requirements of APP 8; and for users in Singapore, we take reasonable steps to ensure that overseas recipients provide a standard of protection comparable to the Singapore PDPA.

That does not cover every recipient in §10, and we will not imply otherwise. Apple and Google process App Store and Google Play transactions as independent controllers under their own terms, not as processors for us — we are not the exporter for those transactions, so there is no safeguard of ours to rely on. PCGS and NGC receive only a certificate number you supply, sent from our servers with nothing attached that identifies you, and metals.dev receives nothing about you at all. For those recipients we have executed neither a data processing agreement nor Standard Contractual Clauses, and §10 says so in each row rather than naming a mechanism we do not hold. §10 is the authoritative per-recipient position; where it and this section could be read differently, §10 governs.

We do not rely on your consent as a transfer mechanism.We also do not rely on the EU–US Data Privacy Framework.

Your personal information may be stored or processed in the United States and, for website analytics only, in the European Union.

12. Data Retention

• Account identity: kept for as long as your account exists.
• Account email in our database: once written, this row is kept indefinitely — nothing removes it on a schedule today, and it is not deleted when the backup it was recorded for is deleted. You can have it removed at any time by emailing [email protected], and it is purged by account deletion (§14).
• Encrypted sync data: kept while sync is enabled. Superseded intermediate versions are compacted away automatically; the most recent snapshot is retained so a new device can restore from it.
• Encrypted backup archives and metadata: kept while a subscription that grants sync is active. If it lapses, backups are held for a 60-day grace period, after which we email a warning and open a further 14-day notice window before deletion — around 74 days in total. Resubscribing during that window restores them. If we cannot deliver the warning email, the backup is not deleted.
• Backup retention warning records: removed together with the backup they relate to, or when a resubscription rescues that backup.
• Backup warning send-attempt timestamps:kept for 30 days from the last attempt, then purged, or removed when your account is erased — whichever comes first. Unlike the warning records above, this row carries no backup identifier; it is a per-account timestamp used only to throttle repeat warnings.
• Subscription and entitlement records: kept while your account exists, so entitlements can be restored across devices and reinstalls.
• Spot price alerts: kept until you delete the alert, or until the account is purged.
• Push notification device tokens: retained for the life of the account. A device that re-registers replaces its own row rather than adding one, and the table records when a token was created and last seen. There is no shorter automatic expiry today. Nothing populates this table at present (§5), and when you request account deletion, tokens are deactivated at once and purged with the account (§14).
• Certificate lookup cache: 30 days from the lookup, then purged. Keyed by certificate number only, with no account identifier.
• Certificate lookup quota counters: 90 days, then purged.
• Email suppression records: 12 months from the date recorded, then purged. These are kept on the basis of our legitimate interest in not repeatedly mailing an address that has bounced or complained, and they are not removed by account deletion — see §14.
• Waitlist emails: kept until you ask us to remove them ([email protected]). There is no automatic expiry for these today.
• Server logs: two kinds, and they differ. Our HTTP request logs contain no IP address and no account identifier — only a request identifier, method, path, status, response size and duration. Our application logs are separate, and they do record significant account events against your account identifier, including when a deletion is requested and when one is reversed. Where an email address appears in them at all it is redacted before it is written: the part before the @ is replaced with asterisks and only the domain remains, so the full address is never logged. Both kinds are retained by our hosting platform under its own log retention settings rather than by us.
• Deletion records: retained indefinitely. Two survive a purged account: a marker row holding your account identifier — a UUID — and the timestamps for when deletion was requested, scheduled and completed; and a tombstone, written for every completed purge, being an HMAC-SHA256 keyed hash of the email address on the account — or, where no email address was ever stored, of the account identifier — held in an append-only log that holds no account data and no plaintext identifier. Neither stores your email address, your name or any other account data — see §14.
• RevenueCat subscriber records after account deletion: retained by RevenueCat rather than purged, deliberately — see §14 for what remains, why, and how to have it removed.

13. Your Rights

You have the right to access your data, to have it corrected, to have it erased, to restrict or object to processing, and to receive it in a portable form. For users in the EU and EEA these are the rights in Articles 15–22 of the GDPR; equivalent rights apply in the UK. Send any request to [email protected] and we will respond to a verified request within 30 days. An access request returns everything §5 records about you — §5 is the authoritative inventory, and the scope of an access request is defined by it rather than by any shorter list here. That includes the categories people are most often surprised we hold: your backup metadata rows, your push device tokens, your certificate lookup quota counters, any email suppression record and backup retention warning record against your address, and, if you joined the website waitlist, that entry with the referrer and campaign parameters captured with it (§14). We return it decrypted where we hold it in the clear, and as ciphertext where we do not. Your holdings are the second case: your sync blobs and backup archives are end-to-end encrypted (§4), so an access request returns those objects as ciphertext and cannot include your holdings in decrypted form. We do not hold the key that would decrypt them, and we hold no other copy of your portfolio.

Correcting your data. Your holdings, purchase prices, notes, storage locations and photos can be edited directly in the app at any time, and on the sync tier the corrected version replaces what we hold on the next sync. To correct the email address on your account, email [email protected].

Portability. The app exports your portfolio in machine-readable form — CSV and JSON — from its export controls; a PDF export is also available if you want something to read rather than to re-import. Those exports are produced on your device from your own data, so they are the fastest route to a portable copy. For anything an export does not cover, email [email protected] and we will provide it in a structured, commonly used, machine-readable format.

Erasure.The primary route is in the app: Settings → Delete Account requests deletion of your account and the server-side data that the deletion job purges. §14 lists exactly which categories that covers and what remains afterwards — it is not everything inventoried in §5, and we would rather point you at the real list than imply a wider sweep than the job performs. The request stays reversible for 30 days — sign in again during that window and it is cancelled. You can also email [email protected] from the address on the account.

Restriction and objection. To ask us to restrict processing (Art. 18), or to object to processing we carry out on the basis of legitimate interest (Art. 21) — those cases are listed below — email [email protected]. Email is the mechanism for both; there is no in-app control for either.

California residents (CCPA/CPRA).If you live in California you have the right to know what personal information we collect and how we use and disclose it — §2, §5 and §10 set that out in full, and you can request the same information for your own account by email. You have the right to delete personal information we hold about you, the right to correct inaccurate personal information, and the right not to be discriminated against for exercising any of these rights: we will not deny you the service, charge you a different price, or give you a lesser level of quality because you made a request. The mechanisms are the ones already described here — Settings → Delete Account in the app, or [email protected] — and the exceptions in §14 apply to a California deletion request in the same way.

We do not sell or share your personal informationas those terms are defined by the CCPA and CPRA — we do not sell it, and we do not share it for cross-context behavioural advertising. There is accordingly no “Do Not Sell or Share My Personal Information” mechanism for us to offer you, because there is nothing to opt out of. The sub-processors in §10 receive data only to run the features you turn on, under the agreements listed there.

Withdrawing consent. Where we rely on your consent — the website waitlist is the only such case — you can withdraw it at any time by emailing [email protected]. Withdrawal does not affect processing that took place before it (Art. 13(2)(c)).

Complaints. You have the right to lodge a complaint with your supervisory authority, or with the European Data Protection Board (Art. 13(2)(d)).

Legitimate interest. Where we rely on legitimate interest (Art. 6(1)(f)) we have weighed that interest against your rights and freedoms (Art. 13(1)(d)). Those cases are narrow: rate limiting, which processes a client address in memory and never stores it; suppression records, which hold an address and a reason so we stop mailing someone who has bounced or complained; cookieless aggregate website analytics; and fault diagnosis if crash reporting is ever enabled.

Whether providing data is required. Providing an email address and a sync passphrase is a contractual requirement of the sync tier — without them we cannot provide sync, backup or subscription management. It is not a statutory requirement, and nothing obliges you to provide it: the free tier works with no account at all (Art. 13(2)(e)).

Legal basis for each processing activity:

14. Data Deletion

What is true today. Account deletion is available from inside the app. This section says plainly what it does, what it does not do, and what survives it.

• Deleting the app from your device removes the local database and the photo files stored with it. On iOS, key material held in the system Keychain can survive an app deletion; the app detects and reconciles that on the next install. Deleting the app does not remove anything from our servers: if you have used an account, the data listed in §5 remains.
• Inside the app you can delete individual holdings. The backup controls in Settings let you create, list and restore cloud backups; they do not yet offer a control to delete an individual backup.
• Turning sync off clears the sync key material from your device. It does not by itself remove blobs already stored on our servers.
• To have your account and its server-side data removed, open Settings → Delete Account in the app. You can also email [email protected] from the address on the account, and we will action the request and confirm when it is done. Either route is subject to the exceptions set out below: if mail to your address has bounced or been marked as spam we keep a suppression record (§12), and your RevenueCat subscriber record is retained unless you ask us to remove that as well. Separately, deleting your account does not cancel a paid subscription — a subscription bought through the App Store or Google Play is cancelled in your App Store or Google Play subscription settings, which neither the in-app control nor emailing us can do.

How account deletion works.Settings → Delete Account requests deletion of your account. Here is the sequence it sets in motion.

• Requesting deletion does not delete immediately. The request is accepted — the API answers with HTTP 202 — and returns the date on which deletion is scheduled.
• Access is cut off at once: session tokens are revoked, push device tokens are deactivated, and authenticated endpoints are closed to the account.
• Deletion remains reversible for 30 days. Signing in again during that window cancels the scheduled deletion and restores your access, with nothing destroyed.
• After 30 days a background job purges, in one transaction: your encrypted sync blobs, your encrypted backup archives together with their metadata and the record of any retention warning sent for them, your subscription and entitlement records, your spot price alerts, your push device tokens, your certificate lookup quota counters, the timestamp of the last backup-warning attempt we recorded against you, the audit rows recording any reactivation, your account email row, and your authentication user. It is not a sequence — everything named goes in the same transaction. That is the whole of what §5 records against your account, apart from the items listed below as remaining. The certificate lookup cache appears in neither list because it is keyed by certificate number alone and holds no account identifier (§5) — there is nothing in it tied to you to delete. The quota counters that are deleted record only how many lookups you made on a given day, never which certificates you looked up.

Some things will remain after that purge. Account deletion is therefore not the same as erasure from every system that has ever touched your data, and we would rather say so here than let you discover it later. These are the exceptions we know of, in our own systems and at the sub-processors listed in §10:

• Email suppression records. If mail to your address has bounced or been marked as spam, that record stays for its 12-month retention (§12). It is kept on the basis of our legitimate interest in not mailing an address that has told us to stop.
• Records evidencing the erasure.Two of these are kept indefinitely, and they are complementary by design — neither on its own links a purged account back to an email address. The first is a marker row keyed by your account identifier: the UUID, and the timestamps for when deletion was requested, when it was scheduled and when the purge completed. If you reactivate instead, those two timestamps are cleared rather than kept. A separate audit row does record each reversal while your account exists, but the purge deletes that too — so in our database a purged account's marker row carries no history of how many times deletion was requested and reversed along the way. That is a statement about our database and not about our logs: as the next item sets out, the application log lines recording those same events are not ours to purge. We retain it as the record that the erasure ran, and it is what stops a late subscription webhook from recreating data for an account that no longer exists. The second is a tombstone — an HMAC-SHA256 keyed hash appended to a log that holds no account data and no plaintext identifier, and that cannot be reversed without the key. One is written for every completed purge, without exception. What it hashes is the email address on the account — or, where no email address was ever stored, the account identifier. That second case is the common one, because we only ever copy an email address into our own database when you upload an encrypted backup (§5). Where the subject is the account identifier, the tombstone is a hash of a value the marker row already holds, so it widens nothing: it adds no way to re-identify you beyond the record we were keeping anyway. Neither record stores your email address, your name, your holdings or any other account data, and once your account and your authentication user are deleted, the identifier in the marker row no longer maps to you on our systems.
• Your RevenueCat subscriber record. RevenueCat will keep the subscriber record — an app_user_id, which is your account identifier, and the associated purchase history. We leave it in place deliberately: deleting a MintMetric account does not cancel a subscription bought through the App Store or Google Play, and if you return with the same store account, destroying that history would leave you paying for an entitlement you could no longer restore. There is no self-serve control that deletes it. If you want it removed anyway, email [email protected] and we will arrange it with RevenueCat.
• Your waitlist email address. If you joined the website waitlist, that row — the email address, the referrer and any campaign parameters (§2, §12) — is stored separately from your account and is keyed by the email address rather than by your account identifier. The account purge does not reach it, and it is kept until you ask us to remove it (§12). To have it removed, email [email protected] from the address you signed up with, or use the same address in a request under §13, and we will delete it and confirm when it is done.
• Application log lines. Our application logs record significant account events against your account identifier — when a deletion was requested, when one was reversed, and when a request was refused — each with the time it happened (§12). The purge empties our database, but it does not reach the logs: they are held by our hosting platform under its own retention settings, and they age out on that schedule rather than on ours. So for as long as those entries live, they carry the reversal history the marker row above does not. Alongside the identifier and the event they hold limited technical detail about it — the date a deletion was scheduled for, the sign-in method a refused request presented, or the error that caused a step to fail. They never contain your email address, your name, your holdings or your IP address.
• Transactional email we already sent you. Any email we sent before you deleted — in practice the backup retention warnings described in §3 and §12 — stays in the sending history held by our email provider, Postmark (§10), along with the address it went to and the message content. The purge does not reach into that history; nothing in our systems can delete it. If you want it cleared, email [email protected] and we will arrange it with Postmark.

Beyond that list, records held by parties who are not processing on our behalf sit outside this purge altogether. Apple and Google keep their own record of App Store and Google Play transactions as sellers of record (§10), under their own policies and retention periods. We cannot delete those for you, and asking us will not reach them — they are requested from Apple or Google directly.

15. Children's Privacy

MintMetric is not directed at children under 13. We do not knowingly collect information from children. If you believe a child has provided us with personal information, contact [email protected] and we will remove it.

16. Cookies and Local Storage

The website sets no advertising or analytics cookies — Plausible is cookieless by design (§8). One short-lived cookie is used only if you access a password-protected preview build of the site, to remember that you entered the password.

The app uses your device's local storage for the encrypted portfolio database, your item photos, your preferences, and the key material described in §4. None of it is transmitted except as set out in §2 and §4.

17. Changes to This Policy

We may update this privacy policy from time to time. Changes will be posted on this page with an updated revision date. Where a change alters what data leaves your device — for example enabling crash reporting (§9) — we will update this page as part of that change rather than after it. That is how the account deletion copy in §14 was updated when the feature landed.

18. Contact

Data controller. The controller of the personal information described in this policy is Nimbus Foundry, LLC (a Wyoming limited liability company); its registered agent is in Sheridan, Wyoming, United States. MintMetric is a product of Nimbus Foundry, LLC.

Registered Agent:

Mailing Address:

Data protection requests — access, correction, erasure, portability, restriction, objection and withdrawal of consent — go to [email protected]. The same company details, and a form if you prefer one, are on our contact page.

• [email protected] — all data protection matters: access, erasure, portability, objection, withdrawing consent, and any question about this policy. This is the correct address for every request described above.
• [email protected] — general product support, including App Store and Google Play matters.
• [email protected] — terms of service and legal notices.

There is no named data protection officer. [email protected] is a monitored role address and is the route for every request under this policy.