Cardinal — Privacy Policy

Cardinal has no account or login. Your collection is stored on your device. Optional network features use random per-install or trader identifiers so Cardinal can join records belonging to the same installation or trading profile without requiring a real name, email address, or Cardinal account. These identifiers are pseudonymous and linked. Cardinal does not use them to track you across apps or websites.

Data stored on your device

Cards you own, conditions, purchase prices, folders, wishlists, target prices, trade drafts, and scan history are stored locally. Scanning uses Apple Vision on the device. Captured camera pixels and imported card photos are not uploaded. Cardinal downloads public catalog data, reference images, and market references. Device backups, if enabled, are handled by the device platform.

Stack and Binder scanning also keep unfinished scan sessions, source photos, card regions and corrections on your device so you can resume and review them. Full-resolution Stack photos are released when their entries are saved or discarded. Binder page photos remain available for adding missed pockets until you finish the scan session; smaller previews remain with scan history. Deleting a scan session removes that session's local records and previews without removing cards already saved to your collection.

Catalog and market-reference providers

Search and reference lookups may send card names, search terms, card identifiers, and language information to Scryfall, the Pokémon TCG API, or TCGdex. Direct request recipients can see the network IP used for the connection. Some catalog and pricing requests pass through Cardinal's service to Scrydex; those requests use Cardinal's service connection rather than forwarding the end-user IP. Providers process requests under their own policies. Cardinal does not control their retention or deletion practices, and their published information does not provide a fixed retention or deletion period for these API requests.

For Pokémon, card data, images, and market references are primarily provided by Scrydex, whose market references reflect TCGplayer market data, with additional coverage from the Pokémon TCG API and TCGdex. Magic: The Gathering data, images, and market references come from Scryfall.

When you use live search for a Pokémon card name, Cardinal sends the normalized card name to Cardinal's service. The service uses the term to return matching cards and stores a reversible form of it in a shared result-cache key. Matching results are configured for reuse for up to six hours and empty results for up to five minutes. Expiry limits cache reuse; it is not a guaranteed deletion deadline. The search term can also appear in Cloudflare Workers invocation logs because query-string redaction is disabled. Cloudflare documents a maximum retention of seven days for Workers Logs. Cardinal does not use search terms for advertising or tracking.

Optional network features

Live trades and Trade Night

When you start or join a live trade, Cardinal sends the offered cards, a self-chosen display name, trade state, and a random trader identifier to Cardinal's service. Live room state, participant tokens, and confirmations are scheduled for deletion after two hours from the latest room activity, or two minutes after a committed trade. Scheduled deletion can be delayed or fail, so these are not guaranteed deletion deadlines.

A committed trade also creates separate market-reference facts that can include a room or trade ID, side, card and variant identifiers, value basis, reference amounts, cash amount, and time. These facts do not include a trader-name field, but can be correlated with other room-linked records. They remain after room cleanup and currently have no scheduled expiry.

Trade Night event storage is scheduled for deletion at the earlier of the event end plus six hours or creation plus 24 hours. Ending an event schedules deletion six hours later. Event push associations have separate expiry and deletion paths. These rules do not delete global push-token records.

Matchmaking, reputation, and notifications

If you enable Find Matches, Cardinal sends the For Trade and wishlist card lists, display name, random trader identifier, and the coarse location used by the feature. Coarse location can include a request country or a metro you enter yourself; Cardinal does not use GPS or precise location. Published lists and trader metadata are eligible for deletion after 75 days without refresh when maintenance runs. Publishing empty lists removes the current lists and profile. Trade requests, global push tokens, and block relationships do not have a timed expiry.

Post-trade ratings and rating-capability records do not have scheduled cleanup. A rating capability becomes unusable after seven days, but that expiry does not delete its record. If you allow trade alerts, the push token is stored with the random trader identifier.

Community market observations

If you contribute a purchase or sale observation, Cardinal sends the amount, currency, condition, card identifier, variant, purchase-or-sale kind, time, and random trader identifier to Cardinal's service. These records support community market references and currently have no scheduled expiry. Displayed prices are estimates or point-in-time references and can vary by source, printing, finish, condition, region, and time.

Usage sharing

When usage sharing is enabled, Cardinal sends product-interaction events with a stable random install identifier, session, app build, operating-system version, device model, coarse request country, and, for some events, a public card identifier. Turn usage sharing off in Settings to stop future app usage events. Turning it off does not delete previously stored server records.

With usage sharing enabled, Stack and Binder scanning send bounded counts and categories describing captured regions, recognition results, saves, corrections and interruptions. These new scanning events do not include your scan images, OCR text, card identifiers or a persistent scan-session identifier. Purchase events include the chosen Pro plan, entry point and outcome, including cancellation, pending approval, restoration or a verified purchase. These events use the same random install and session identifiers as other usage sharing. A verified purchase may begin a free trial; it does not establish that a payment was collected. Apple transaction identifiers are not included in these app usage events.

Usage events and first-event milestones currently have no scheduled deletion. Bounded event fields are also sent to Analytics Engine and written to object storage. Daily compaction combines small event objects into raw daily archives and deletes the small source objects, while preserving the event records. Completed raw archives and dated rollups currently have no configured expiry. Analytics Engine data and any separate backups or exports do not have a confirmed deletion period.

Purchases

Apple StoreKit supplies products, purchase, restoration, and entitlement state in the app. Apple processes payment; Cardinal does not receive payment-card numbers, bank details, billing addresses, or Apple Account credentials.

Apple sends verified App Store Server Notifications directly to Cardinal's service. For production events, Cardinal stores selected pseudonymous Founder and subscription-event fields, including transaction identifiers, notification identifiers and types, product, environment, event time, expiry, and latest status where applicable. These records currently have no scheduled expiry. The app does not upload Apple's signed purchase record. Accepted signed payloads are parsed without storing the raw payload through this path. Rejected deliveries retain a fingerprint, bounded reason, timestamps, and attempt count and can produce diagnostic logs. These server records do not control the StoreKit entitlement.

Invites

Invite links and manual code redemption use random per-install referral codes. Redeeming a code sends the two random codes to Cardinal's service and creates a pseudonymous link between the installations. The service stores a hashed invitee code, inviter code, pending status, and timestamp without a scheduled expiry. Invite display, share, and copy events can be included in usage sharing.

Network addresses, logs, and access

Cardinal's service uses the request IP supplied by its network platform to select rate-limit counters. Those counters have scheduled cleanup after twice the configured rate-limit window. This creates short-lived IP-derived security state; it does not mean Cardinal assigns one raw IP to one physical device.

Cloudflare Workers invocation logs are enabled for Cardinal's service. These logs can include request, response, and related metadata, including a request method and URL. Query-string redaction is not enabled. Cloudflare documents a maximum Workers Logs retention period of seven days. That limit applies to Workers Logs; it does not apply to object storage, Analytics Engine, database records, backups, or exports.

Participant tokens control access to live trade rooms. Matchmaking participants can see other participating traders' display names, country, and overlapping cards. Protected service routes use access keys or signed service requests where applicable.

Controls and deletion

You can turn off future usage sharing in Settings. You can remove the current published matchmaking lists and profile by publishing empty For Trade and wishlist lists. Live rooms and Trade Night records use the scheduled deletion rules described above. These controls do not delete every previously stored record. Cardinal does not provide an in-app control that deletes all server records at once; other record types follow the retention behavior described in this policy.

Random identifiers, contribution records, completed-trade facts, referral records, ratings, global push tokens, and selected purchase-notification records can remain without a scheduled expiry. A scheduled deletion is a cleanup mechanism rather than a guarantee that deletion completes at an exact time.

Website referrals

Valid referral visits can record open, App Store, visit, or join events. Server-observed open and App Store rows use a daily pseudonymous key derived from referral code, network IP, user agent, and UTC day. Those event rows do not store the raw IP; they include time, country, and path and expire after 180 days.

Email updates and the Android waitlist

A submitted email address, list type, optional referral code, time, user agent, and request country are stored by the first-party website service. The current service has no automatic deletion path for those records.

Contact

Questions about privacy? Email support@selforbit.com.