Privacy policy

Operator: PLACEHOLDER. Registered address and country: PLACEHOLDER. Legal and privacy email: PLACEHOLDER. Product’s final legal name and domain: PLACEHOLDER.

For account administration, service security, our own customer relationships and billing, including conversations sent to our own website support team, the operator is the controller. For conversations and related end-user information handled on an app business’s instructions, that business is normally the controller and we act as processor. If you used chat inside an app, contact that app’s operator first about its use of your information. Our Data Processing Agreement covers that processing.

• Account and team information: names, email addresses, Google account identifiers and profile images supplied during sign-in, uploaded profile photos, organisation membership, roles, invitations and app settings.
• Support content: messages, screenshots and other uploaded images, conversation status and timestamps, delivery/read information, typing signals, review-request and review-link click records, app-reported paywall ids and titles, paywall cards and paywall-open records, and agents’ replies. A review-link click does not tell us whether a review was submitted. A paywall open does not tell us whether a purchase occurred; we do not process those purchases.
• End-user and device details: an app-provided name, email or user ID when supplied, and whether the app operator's server verified it; support device identifiers; custom metadata chosen by the app; app version/build, platform, OS and device model, language, timezone, chat-activity timestamps, push tokens and notification delivery status. Metadata may include subscription information if the app supplies it.
• Sign-in and technical information: IP address, user agent, approximate sign-in location, session times and expiry, request information and operational/error logs needed to run and protect the service. For abuse limits, network addresses of app and website chat requests are kept only as keyed hashes in short-lived counters. A device’s region setting is not precise physical location.
• Billing information: organisation and Stripe customer/invoice references, payment status, billing periods, immutable statements and audit records. Apple's App Store Connect sales reports supply daily App Store revenue through a customer-authorised key limited to the Sales and Reports role. Reports cover the whole developer account; we keep daily totals per currency for connected apps only and discard all other rows immediately. No individual purchase or end-user revenue identifiers are imported. Such a key can also list the account's apps and team members; we read only the app list. Payment details entered in Stripe’s checkout are handled by Stripe; our application does not store full card numbers or card security codes.
• Integration credentials and settings: App IDs, hashed device session credentials, encrypted identity-verification secrets and App Store Connect keys, Apple Push credentials and Telegram bot/chat configuration. These enable the connections you choose and are not public profile data.

Our website chat lets you contact our own team. It stores your messages, our replies, any reply images, conversation timestamps and a random support identifier. Signed-in conversations are linked to your account and use the name and email from that authenticated account; visitors do not have to provide an email address. Access to these conversations is limited to explicitly authorised Reception agents, independently of customer organisation membership.

We use this information to answer your request and maintain its conversation history, under the contract or legitimate-interest bases described below as applicable. This chat does not send message content to website analytics or implement email reply notifications. Our production providers, controller contact details and legal review remain subject to the placeholders in this draft.

We receive information from you, your authorised team, the apps using ReceptionKit, end users who send messages, authentication/payment services and the devices or infrastructure making requests.

We use it to authenticate users, manage organisations, deliver conversations and notifications, display troubleshooting context, administer accepted payments, answer support requests, investigate misuse and maintain the service. Access to customer content for troubleshooting must be limited to an authorised purpose. We do not sell customer support content or use it for third-party advertising. The current application does not send support messages to an AI model; a coming-soon feature is not an active data flow.

For our controller activities, account and service administration relies on performance of a contract with you, or our legitimate interest in administering a business customer’s account where you act for that customer. Security, sign-in location and troubleshooting rely on legitimate interests in protecting accounts and operating a reliable service, subject to the required balancing assessment. Accounting and legally required records rely on legal obligations. Optional activities that require consent will use consent, which you may withdraw without affecting earlier lawful processing.

The app business chooses and documents the legal basis for its end-user support data. Installing the SDK or accepting these terms does not itself substitute for a legally required notice or consent.

• Your organisation’s authorised owners and agents can access its apps, end users and conversations according to their permissions. Replies and attachments are delivered to the intended app user.
• Hosting, database, object-storage and backup providers process information needed to operate the service. Their legal entities, locations and contractual safeguards are PLACEHOLDER — undecided pending production configuration.
• Google provides Google sign-in and supplies the permitted profile/account information. Google also handles information under its own privacy terms.
• Apple receives authenticated read requests for the customer's App Store Connect sales reports and app list. We use the authorised key, vendor number and app identifiers to fetch that data for estimates, billing and audits.
• Stripe processes payments when paid billing is enabled and can act under its own legal obligations for payment and fraud-prevention activities. Its role depends on the activity; it is not automatically a processor for all information.
• ipapi.co receives a signing-in dashboard user’s public IP address to return an approximate city and country for session security. Private/local addresses are not sent by this lookup. This is a dashboard sign-in flow, not a lookup of every app chat user.
• If enabled by the app business, Apple Push receives a device push token and notification payload, which may contain reply text. Telegram receives configured chat identifiers, message text and app/user context; people with access to the chosen Telegram chat may see and reply to it. Settings can reduce notification content or disable the connection.
• We may disclose information where law requires it, to defend legal claims or protect safety, and to professional advisers under appropriate confidentiality. A business transfer may involve relevant records with applicable safeguards and notice.

The dashboard uses authentication/security cookies and preferences such as theme and sidebar state. The landing theme and some interface preferences use browser local storage. The SDK uses device storage, including a session credential in the Keychain that stays on that device and local conversation state, to maintain support access and synchronisation. These identifiers are not anonymous merely because they do not contain a name.

For visitors who are not signed in, the first website chat send creates a necessary first-party HttpOnly cookie containing a random chat credential. It lasts 24 hours and permits access to that guest conversation; opening an unused chat alone does not set it. Signed-in chat uses the existing authentication session. Cookie expiry ends guest access but does not itself delete the transcript. These support credentials are not advertising identifiers.

The reviewed app code contains no advertising tracker or general website analytics script. Any hosting-layer analytics or later optional tracking must be inventoried before this policy is finalised and, where required, enabled only after consent. Blocking essential storage may prevent sign-in or reliable chat operation; browser and device settings let you manage local storage.

Customer support records are kept to provide conversation history until a supported deletion instruction is completed or the agreed retention period expires. Closing a conversation does not delete it. Account, device, app and organisation deletion have different scopes; deleting one team member does not necessarily remove the organisation’s shared records.

Our own website support devices and their conversation histories become eligible for deletion after 90 days without a new message, measured from the latest message in any of their conversations, or registration when no conversation exists. Reading a chat does not extend this period. The daily cleanup job removes the device, conversations and associated images; failures are retained for retry. Deleting your account also removes the website conversations linked to that account, and authorised Reception agents can manually delete a conversation’s device and history. This does not establish a retention period for customer apps’ conversations.

The cleanup job is designed to remove unused pending uploads older than 24 hours, expired sessions and invitations, and retry pending deletions. This is eligibility for cleanup, not a guaranteed 24-hour destruction deadline; execution and storage failures affect completion.

Apart from the website support rule above, production retention periods for messages, active/inactive accounts, logs, billing records and backups are PLACEHOLDER — undecided. Before this policy becomes effective, we will specify periods or objective criteria for each. Necessary legal/accounting records may outlast service use. Backup erasure and legal-hold handling must be documented separately. Removing data here does not remove copies already received by an app, device or connected service.

The application uses organisation-scoped access checks, role-based controls, hashed device session credentials, short-lived access tokens, server-side validation and expiring image-access links. Apple Push private keys and identity-verification secrets are encrypted in the database. These measures do not mean that all stored fields are encrypted or that chat is end-to-end encrypted.

Production transport protection, infrastructure access, encryption at rest, backups, patching and incident response require verified operational configuration. Details are recorded in the DPA security schedule; unverified measures are not represented as certifications or guarantees. No service can promise absolute security.

Our production processing locations and remote-access locations are PLACEHOLDER — undecided. Google, Stripe, Apple, Telegram and other selected providers may process data in more than one country.

Before any restricted international transfer, the responsible party must establish the applicable transfer mechanism, such as an adequacy decision or appropriately completed contractual safeguards and any required assessment. A vendor’s general statement of compliance is not itself our transfer arrangement. The final provider/location schedule will identify the arrangements that actually apply.

Depending on the law that applies, you may request access, correction, deletion, restriction or portability, object to processing based on legitimate interests, and withdraw consent where consent is used. Rights are subject to legal conditions; reasonable identity verification may be needed. Contact PLACEHOLDER for our controller records. For an app’s support records, contact the app operator; we assist it with requests under the DPA.

You may complain to your local data protection authority, including the ICO in the UK or the relevant EEA supervisory authority. We do not use the reviewed service to make solely automated decisions producing legal or similarly significant effects about you.

The business dashboard is not intended for children. App operators decide whether their apps serve children and must meet the associated notice, lawful-basis and consent requirements before using support chat for them. Do not send unnecessary sensitive or children’s information.

Material changes will be communicated through the service or the confirmed account contact as appropriate, with consent obtained where required. The effective date and contact details will be completed before this draft is put into effect.