# Privacy and data Which data ReceptionKit sends, what Reception stores and shares, and what deletion removes. ## What the SDK sends {#what-the-sdk-sends} ReceptionKit registers a support device on the first valid send attempt. Opening an unused chat, drafting text, or selecting photos does not register a device. Registration can succeed even if the message later fails. Published appearance can be fetched before the first send. These requests reach Reception and its network infrastructure, but do not create a support device. To use only local appearance, set `Reception.shared.usesRemoteAppearance = false`. | Data | What is included | | --- | --- | | App and device details | App version, build and bundle identifier; SDK and iOS versions; device model; locale, time zone, selected app language, and whether Reception may set the app icon badge. | | Optional identity | The user ID, name, and email your app supplies. With identity verification, Reception receives your signed token and retains its accepted identity claims, not the token. | | Optional metadata | Custom string fields your app supplies, such as a plan. The RevenueCat paywall file, if you add it, sends subscription status, plan and renewal or expiry date by default. | | Optional push registration | An APNs token and its development or production environment. | | Messages and photos | Text and selected photos, with attachment information such as format and dimensions. | | Chat interactions | Message delivery and read progress, chat activity, typing status, and review or paywall action taps. | | Optional paywall list | IDs and titles of the paywalls your app currently offers in chat. With a paywall file, this shows whether a customer already owns an offer. | ReceptionKit doesn't collect location, advertising identifiers or contacts, and doesn't read purchases by itself; only the paywall files you add check them. The displayed region comes from the device locale. Your metadata, messages and screenshots may contain more information. Each registration has its own history. Using the same user ID on several devices does not combine their conversations. See [Users & accounts](/docs/accounts#connect). ## App Store privacy {#app-store-privacy} Add Reception's data to your app's answers in App Store Connect under **App Privacy**. For Reception's data, select **Linked to the user: Yes**, **Used for tracking: No**, and the purpose **App Functionality** for each type below. If your app already declares a type, add the purpose there and keep the answers your app's other features need. | Data type | Select it | | --- | --- | | Customer Support | Always | | Photos or Videos | Always, because customers can attach photos | | Device ID | Always, for the support session and push token | | Product Interaction | Always, for chat activity, read status and card taps | | Other Diagnostic Data | Always, for app version, iOS version and device model | | Other Data Types | Always, for language, locale and time zone | | User ID, Name, Email Address | When your app passes them to `identify` | | Purchase History | With paywall cards, or when your [user details](/docs/accounts#metadata) include a plan or purchases | | The matching type for any other user detail | For example Phone Number for a phone number | For Product Interaction, also select **Analytics**: the dashboard counts review and paywall card opens. With paywall cards, also select **Developer's Advertising or Marketing** for Product Interaction and Purchase History, and **Analytics** for Purchase History, because the cards promote your products. ReceptionKit doesn't track users across apps or companies, and doesn't collect location or advertising identifiers. Xcode's privacy report for an archive lists the types ReceptionKit declares. ## Local storage {#local-storage} ReceptionKit keeps session credentials in the device Keychain. These credentials do not transfer to a different device through a backup. Identity verification tokens remain in memory only. The device also stores supplied identity and metadata, push registration, unread and conversation state, text drafts, and recent chat history, including pending or failed messages and their photos. Unsent photo selections do not survive relaunch. Local persistence is best effort; received photos may be unavailable offline. Only the chat history cache is excluded from device backups. Identity, metadata, push registration and drafts are stored separately and can be part of a backup. Public appearance is saved separately and survives logout. [Logout](/docs/accounts#logout) clears the local support session and asks Reception to end its remote access. It does not delete server history or guarantee secure erasure of storage and backups. Use the [deletion flow](/docs/accounts#delete-data), rather than app uninstall, when support data must be removed. ### Privacy manifest {#privacy-manifest} ReceptionKit includes `PrivacyInfo.xcprivacy`. It declares UserDefaults access for app functionality, every data type in [App Store privacy](#app-store-privacy), linked to the user and not used for tracking, and no tracking domains. Declare the other types your user details contain in your app. ### Activity and review receipts {#activity-and-review-receipts} The dashboard shows recent chat activity, live chat presence, message delivery/read status, and reported action taps. These signals do not prove someone read every message, completed a review, or made a purchase. Opening an unused chat and checking unread counts do not report chat activity. See [Chat features](/docs/chat-features) and [Events](/docs/events). ## What Reception stores {#what-the-server-stores} Reception operates the hosted service and image storage. Your workspace’s owners and agents can view its support records through the [dashboard](/docs/dashboard), according to their permissions. Stored information includes: - Support identities, device details, metadata, conversations, messages, photos, delivery/read information, and chat-action history. - App settings, appearance, integration credentials, and customer-management choices such as team-assigned names and blocks. - Workspace membership, invitations, dashboard profiles, sign-in information, and session activity. Dashboard sessions can include IP address, browser information, and approximate sign-in location. - Revenue-provider connections, daily revenue, billing statements, invoices, and billing audit records. Revenue reporting uses app totals rather than end-user purchase records. - Network information associated with service requests, plus diagnostic information used for security and abuse prevention. **Chat is not end-to-end encrypted:** Reception can read support content to show it to your team. Connections use HTTPS. APNs keys, identity secrets and App Store keys you upload are additionally encrypted before they are stored. ## How ReceptionKit authenticates {#security} Your public App ID selects the app; it cannot read conversations by itself. ReceptionKit manages a separate device session and stores its credentials in the Keychain. Remote sign-out can be delayed while offline. Names, emails, and IDs supplied through `identify(userId:name:email:)` are unverified labels. [Identity verification](/docs/accounts#verified-users) lets your server prove an identity with a secret that stays on your server. Verification does not grant access to another device’s history. ## Images {#images} ReceptionKit converts selected photos to JPEG, up to 2,048 pixels on the longest edge and 1 MiB per image. Transparency becomes white, and original files or animations are not preserved. A message can contain up to five photos. See [Chat features](/docs/chat-features#photos). Photos are stored by Reception’s object-storage provider. Temporary image links grant access to anyone who has the link while it remains valid and the file exists. Treat copied image links as private. Deleting support data cannot remove photos someone already downloaded or copied. Profile photos uploaded to the dashboard are validated and re-encoded before storage. Google profile photos load directly from Google. App icons are also stored by Reception. With [team display](/docs/remote-appearance#team-photos-and-names) enabled, **Show team names** displays teammates' first names to customers, and **Show team photos** displays their uploaded profile photos beside replies. Team photos are served through temporary links. ## Where data goes beyond Reception {#external-services} With [push notifications](/docs/push-notifications), Apple APNs receives the device token, app identifier, and notification content. Notifications can contain reply previews, unread badge information, a conversation identifier, and sound preferences. They do not contain photo files or image links. Optional [offer pushes](/docs/push-notifications#offer-pushes) send the card message, custom button label, or translated “See your discount” fallback through APNs, using your notification templates. Turn off **Show message** in push settings to replace reply and offer previews with a generic prompt. With [Telegram](/docs/telegram) enabled, Reception forwards customer text, the app name, and the customer’s display name to the selected chat. Notifications can mention a photo, but photo files and links are not forwarded. People in that chat can read notifications and send text replies to customers. Pausing, disconnecting, or deleting Reception data does not erase Telegram history. Other service recipients include the object-storage provider for photos and invoice PDFs, Google for dashboard sign-in, Stripe for payment-method setup and invoices, and Cloudflare, which carries traffic to the service and supplies the approximate dashboard sign-in location from a public IP address. That location is separate from SDK device registration. Connecting the App Store authorizes Reception to read your account's daily sales reports with a Sales and Reports key. It keeps daily totals per currency for the connected apps only; see [Connect revenue](/docs/connect-revenue). The [privacy policy](/privacy-policy) lists the service providers. Review who can access your workspace and any connected Telegram chat. ## Retention and cleanup {#retention-and-cleanup} Closing a conversation does not delete its history. SDK conversations, registered devices, and attached images currently have no automatic age-based deletion. App and workspace deletion can continue in the background; confirmation does not guarantee that every file has already been removed. Billing statements, audit records, archived invoices and free-access records, including the email address access was granted to, can remain after app, workspace or dashboard-account deletion. Reception doesn't promise a deadline for removing data from backups and logs. Contact Reception if you need confirmation that a purge has completed. ## Deleting data {#deleting-data} | Operation | Effect | | --- | --- | | `Reception.shared.logout()` | Clears the local session and requests remote sign-out. Server history remains. | | Dashboard **Reset support** | Removes the selected device’s conversations and photos, while retaining its registration and identity. | | `Reception.shared.deleteData()` | Requests deletion of the current registration and its support content, then resets locally on completion. | | Dashboard device deletion | Removes the selected registration and its support content. | | App or workspace deletion | Removes the selected scope and its support content; billing records can remain. | ### From your iOS app Await `Reception.shared.deleteData()` **before logout or account switching**, while the current session can still authorize deletion. For an active session, deletion covers its conversations, messages, photos—including agent photos and unfinished uploads—and associated action history. Completion and `.dataDeleted` are not proof of historical erasure. With no session, an ended session, or an unavailable App ID, the SDK can complete locally without deleting earlier records. After logout, remove retained registrations through the dashboard. The call covers only the current registration, not every device sharing a user ID. Failures preserve the session for retry. Some photos may already have been deleted when a storage failure occurs. Keep the session available and handle the error in your app. See [Delete data](/docs/accounts#delete-data) for code and completion behavior. ### Reset support {#reset-support} An owner can reset a device’s support conversations and photos, clear its block, and clear chat activity. Its identity, metadata and push registration remain, along with the date of the last review request and which paywalls were sent, so repeat warnings still apply. Sent cards are deleted with the messages. The SDK clears old history, drafts, pending sends, and unread state when it next synchronizes. Offline devices learn about the reset after reconnecting. Reset is not account deletion. ### From the dashboard Owners can delete a device from customer details, an app from app settings, or a workspace from Organization settings. Device deletion failures require retrying the action. App and workspace deletion hides the deleted scope immediately while Reception completes its purge. Other workspaces and personal dashboard accounts remain. Deleting your dashboard account also deletes workspaces where you are the only member. Shared workspaces retain their content; another owner must remain. Messages you wrote in retained workspaces remain without the deleted author-account link. Review the confirmation in **Settings → General → Delete account**. See [Dashboard](/docs/dashboard). Deletion covers Reception’s live support records and image storage. It does not erase backups, exported files, downloaded photos, notifications already delivered, or copies in Telegram and other connected services. ## Your responsibilities {#your-responsibilities} - Describe the data your integration sends in your privacy notice and App Store disclosures. - Send only useful support context. Keep passwords, authentication secrets, and payment-card details out of messages, metadata, and screenshots. - Review team access, Telegram membership, and notification previews. - Connect account deletion to the support deletion flow, handle failures, and cover all relevant device registrations and external copies. Read the [privacy policy](/privacy-policy), [terms](/terms), and [Data Processing Agreement](/dpa). They are still drafts. ## Paywall actions Reception stores available paywall IDs and titles, sent cards, the sending agent, and the first reported open. These support conversation history and chat-action analytics. Opening a card does not confirm presentation or purchase; your app handles purchases.