Effective 18 October 2026 · Frederick James Dev Ltd
Privacy policy
This policy explains how Frederick James Dev Ltd handles information about website visitors, business customers, support agents and people who contact an app’s team through the Reception SDK.
1. Who is responsible
Operator: Frederick James Dev Ltd, a private limited company registered in England and Wales. Legal and privacy email: [email protected].
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.
2. Information we handle
- 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, the business name, billing email, address and business tax ID entered at Stripe checkout (stored with Stripe, which sells the service as merchant of record, collects tax and issues the invoices), plan, subscription status and renewal dates. 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, Apple Push credentials, Telegram bot/chat configuration, and the Slack workspace name and ID, encrypted Slack bot token, channel and thread references. These enable the connections you choose and are not public profile data.
- Slack replier details: for teammates who reply to customers from a connected Slack channel, Slack supplies their Slack user ID, display name, profile image link and email address. We keep the user ID, name and image link to show who replied, and use the email address to match them to a team member. Images they attach in Slack are stored with the conversation.
3. Our website support chat
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.
4. Sources and purposes
We receive information from you, your authorised team, the apps using the Reception SDK, 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.
5. Legal bases where applicable
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.
6. Who receives information
- Your organisation’s authorised admins and members 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. They act under contracts that require them to protect it.
- Google provides Google sign-in and supplies the permitted profile/account information. Google also handles information under its own privacy terms.
- 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.
- Cloudflare carries all website and API traffic to our servers and, as part of that, tells us the approximate city and country of a signing-in dashboard user’s IP address. We store that location with the session for session security. No separate location service receives the address, and app chat users are not located this way.
- DataFast provides our website analytics.
- 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 images, and app/user context; people with access to the chosen Telegram chat may see and reply to it. Slack receives message text and images, the app name, the customer’s display name, the fields an admin adds to the card, and answers sent from the service, with the answering teammate’s name or email address; people with access to the chosen Slack channel 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.
7. Cookies and device storage
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.
We use analytics on our website to understand how visitors find us and which pages they use. For this we use DataFast (datafa.st), which sets cookies to recognise returning visitors and receives information such as the pages viewed, the referring site, browser and device type, and approximate country. We do not use advertising trackers. Blocking essential storage may prevent sign-in or reliable chat operation; browser and device settings let you manage local storage.
8. Retention and deletion
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, we keep account and support records while the account or organisation exists, until they are removed with the deletion controls or the organisation is deleted. Logs are kept only as long as needed for security and troubleshooting. Billing and accounting records are kept for as long as tax and company law requires, which may outlast use of the service. Copies in backups are removed as those backups expire. Removing data here does not remove copies already received by an app, device or connected service.
9. Security
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.
Traffic to the service is encrypted in transit. Further measures are described in the DPA security schedule. They are not certifications, and no service can promise absolute security.
10. International processing
Our hosting providers, Google, Stripe, Cloudflare, DataFast, Apple, Telegram, Slack and other selected providers may process data in more than one country, including outside the UK and EEA.
Where a restricted international transfer takes place, we rely on an applicable transfer mechanism, such as an adequacy decision or approved contractual safeguards with any required assessment. Contact [email protected] for details of the safeguards that apply.
11. Your choices and rights
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 [email protected] 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.
12. Children and updates
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. This policy is effective from 18 October 2026.