Resources
Privacy and data
Which data the SDK sends, what Reception stores and shares, and what deletion removes.
What the SDK sends
The SDK registers a support device when your app is active after configure, and again on each foreground until it succeeds (SDK 1.6 and later; before that, only the first valid send attempt registered). Registration sends the device details below and nothing the person typed. Opening an unused chat, drafting text, or selecting photos sends nothing more.
Published appearance can be fetched before registration. 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 (Android: package name); SDK and iOS or Android versions; device model; locale, time zone, selected app language, whether Reception may set the app icon badge, your app’s chat appearance settings (colors, text, icon and font names, never images), and the IDs of the screens your app lists for link cards. |
| 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. |
| Store purchases | Whether the person has paid access in the App Store (SDK 1.5 and later) and the original transaction IDs of those purchases (SDK 1.7 and later), so automations can skip subscribers and App Store notifications reach the person. On Android, only whether the person has an active Google Play purchase, and only when your app includes Google Play Billing; no transaction IDs or purchase tokens. No prices, products or receipts. |
| Optional push registration | An APNs token and its development or production environment, or on Android an FCM registration token. |
| 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. |
The SDK doesn't collect location, advertising identifiers or contacts, and reads purchases only for the paid access and transaction IDs above; the paywall files you add check more. 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.
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 | Always, because the SDK reports paid access and App Store transaction IDs |
| 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.
The SDK 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 the SDK declares.
Google Play data safety
For an Android app, add Reception's data to the Data safety form in Google Play Console. Reception's data is collected, encrypted in transit, and processed by Reception on your behalf; Google Play does not count data sent to a service provider acting for you as shared. People can ask for deletion through your app's deletion flow. If your app already declares a type, add Reception's purpose there.
| Data type | Select it | Purposes |
|---|---|---|
| Messages → Other in-app messages | Always | App functionality |
| Photos and videos → Photos | Always, because customers can attach photos | App functionality |
| Device or other IDs | Always, for the support session and push token | App functionality |
| App activity → App interactions | Always, for chat activity, read status and card taps | App functionality, Analytics |
| App info and performance → Diagnostics | Always, for app version, Android version and device model | App functionality |
| Personal info → Name, Email address, User IDs | When your app passes them to identify | App functionality |
| Financial info → Purchase history | When your app includes Google Play Billing, because the SDK reports paid access | App functionality |
| The matching type for any other user detail | For example Phone number | App functionality |
With paywall cards, also select Advertising or marketing for App interactions and Purchase history. The SDK doesn't collect location, advertising IDs or contacts, and declares no permission for them; its manifest adds INTERNET, ACCESS_NETWORK_STATE and POST_NOTIFICATIONS.
Local storage
The SDK keeps session credentials in the device Keychain; on Android, encrypted with a key in the Android Keystore that never leaves the device. 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 (on Android it lives in the app's no-backup storage). 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 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, rather than app uninstall, when support data must be removed.
Privacy manifest
The SDK includes PrivacyInfo.xcprivacy. It declares UserDefaults access for app functionality, every data type in 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.
Android has no privacy manifest; the Data safety form is where you declare the same data.
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 and Events.
What Reception stores
Reception operates the hosted service and image storage. Your workspace’s admins and members can view its support records through the 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.
The organization’s Stripe customer and subscription status. Invoices and payment details stay with Stripe.
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, Firebase service-account keys and identity secrets you upload are additionally encrypted before they are stored.
How the SDK authenticates
Your public App ID selects the app; it cannot read conversations by itself. The SDK manages a separate device session and stores its credentials in the Keychain (on Android, encrypted with an Android Keystore key). Remote sign-out can be delayed while offline.
Names, emails, and IDs supplied through identify(userId:name:email:) are unverified labels. Identity verification 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
The SDK 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.
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 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
With push notifications, Apple APNs receives the device token, app identifier, and notification content; on Android, Google's Firebase Cloud Messaging receives the FCM registration token 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.
Offer pushes send the card message, custom button label, or translated “See your discount” fallback through APNs or FCM, using your notification templates. Turn off Show message in push settings to replace reply and offer previews with a generic prompt.
With Telegram enabled, Reception forwards customer text and images, the app name, and the customer’s display name to the selected chat. Images are uploaded to Telegram as files; storage links are never shared. People in that chat can read notifications and reply to customers, including with images, which Reception stores with the conversation. Pausing, disconnecting, or deleting Reception data does not erase Telegram history.
With Slack connected, Reception posts customer text and images, the app name, the customer’s display name, any fields you add to the card, and your team’s answers to the selected channel. People in that channel can read them and reply to customers, including with images, which Reception stores with the conversation. Reception keeps the name and profile photo link of Slack users who reply. Pausing, disconnecting, removing Reception, or deleting Reception data does not erase Slack history.
With an MCP connection, Reception returns what the agent asks for (conversations, people's details, numbers, AI knowledge and automations) to that client, which passes it to its AI provider, such as Anthropic, OpenAI or Cursor, under that provider's terms. Each connection belongs to one person and reaches only what that person can see in the workspace. Members list and end their own connections under Settings → Connections.
Other service recipients include the object-storage provider for photos, Google for dashboard sign-in, Stripe, which sells Reception as merchant of record through Managed Payments and handles payment methods, billing details, tax 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.
The privacy policy lists the service providers. Review who can access your workspace and any connected Telegram chat or Slack channel.
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.
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
| 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 app
Await Reception.shared.deleteData() (Android: Reception.deleteData() from a coroutine) 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 for code and completion behavior.
Reset support
An admin 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
Admins 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 admin must remain. Messages you wrote in retained workspaces remain without the deleted author-account link. Review the confirmation in Settings → Account → Delete account. See 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, Slack and other connected services.
Your responsibilities
Describe the data your integration sends in your privacy notice, App Store disclosures and Google Play Data safety form.
Send only useful support context. Keep passwords, authentication secrets, and payment-card details out of messages, metadata, and screenshots.
Review team access, Telegram and Slack channel 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, terms, and Data Processing Agreement. 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.