Privacy Policy

This Privacy Policy explains how Meerlume LLC, a limited liability company registered in the Republic of Armenia (operator of the Meerlume service, “Meerlume,” “we,” “us”) collects, uses, shares, and protects personal data when you use our bot-building platform for WhatsApp, Telegram, the chat widget you can embed on your own website, and related channels. Depending on where you are and which laws apply to the processing, you may have rights over your personal data — section 9 describes the rights we honour and how to use them. Some of those we grant to everyone as a matter of policy rather than because a particular statute requires it, and section 9 says which.

Two roles are relevant to this policy:

• For your account information and your use of Meerlume, we are the data controller.
• For data collected by your bots from your end customers (their messages, phone numbers, names, booking details), you are the controller and we act as your processor. Our Data Processing Addendum contains the Article 28 processor terms and the transfer terms for EEA, UK and Swiss customers. Those form part of the Terms of Service automatically, as the Scope section of the DPA explains.

Account data. When you sign up we collect your email, name, and password (stored hashed). If you choose Google sign-in, Google authenticates your Google account and returns the basic profile information and tokens we need to create or open your Meerlume account. An email address and a password or linked Google account are necessary to create and run a Meerlume account; without them we cannot provide the Service.

Bot configuration data. Bot names, descriptions, flow definitions, prompts, instructions, channel settings, and any drafts you save while using the builder, including the chat transcript of your conversation with the AI builder, and, for about 48 hours, the files you attach in the builder (section 5).

Channel credentials. If you connect a WhatsApp Business or Telegram bot, we store the relevant identifiers and tokens: your WhatsApp Business Account (WABA) ID, phone-number ID, display phone number, and access token; and, for Telegram, the bot token. These credentials are encrypted at rest.

Notification settings. If you enable owner notifications, we store your notification preferences and the delivery details needed to reach you — for example, the Telegram chat identifier created when you link our notification bot, or a per-bot notification address. Notifications themselves contain submission details (such as the booking summary your template includes).

Support requests. If you contact support, we receive the email address, subject, category, and message you submit, and we retain that correspondence to resolve your request.

End-customer data your bots collect. When your end customers interact with your bots on WhatsApp, Telegram, Messenger, Instagram, or the chat widget on your website, we receive and store their messages, the phone numbers or usernames the messaging platform exposes where it exposes any, the structured answers they provide to your bot’s questions, conversation transcripts (including messages you exchange with a customer when you take over a conversation, and the photos, voice messages and files exchanged in the chat: those they send you while you have taken over, or send to a step of your bot that asks for one, and those you send them, including voice messages you record in the inbox), and any booking details they submit (including name, contact details, time slot, and notes). We process this data on your behalf to deliver the Service.

Website chat. If you embed our chat widget on your own site, we also receive a random session identifier the visitor’s browser creates and discards when the tab closes, the address of the site the widget is loaded on, and the IP address and request metadata involved in serving the chat itself. The widget also asks our servers for its appearance settings on every page it is embedded on, whether or not the visitor opens the chat, so we receive the IP address and request metadata of that page view too. From it we keep only a daily count of widget loads per bot, with nothing that identifies the visitor. Website chat does not require a visitor to give a name or an email address, and exposes no phone number or platform username. It is not anonymous, though: a session identifier, an IP address, request metadata, the site address and the message content may all be personal data on their own. What is true is that once the session identifier is gone we may be unable to tie a transcript to the person asking about it without more information from them or from you. The widget does not read your site’s cookies and does not follow visitors between sites.

Payment data. Subscription payments are processed by Paddle as Merchant of Record. We do not receive or store full payment-card details; we receive only transaction-level data such as plan, status, last four digits, and billing country needed to provision your subscription.

Technical data. Our backend automatically logs IP addresses and request metadata for security, debugging, and abuse-prevention purposes. When something fails, a scrubbed error report goes to our error-monitoring provider (section 5). We also use a small number of cookies and local-storage entries described in section 10.

Email sending records. When a bot emails one of your end customers, we record a keyed digest of the email address (not the address itself), the account and bot it came from, and the time. We use these records only to enforce sending limits, so the Service cannot be used to flood someone’s inbox, and delete them after 40 days. If our email provider reports that such an email bounced because the address does not exist, or that its recipient marked it as spam, we note that on the record and keep the digest of that address on a list of addresses the Service no longer emails. An account whose emails draw repeated spam complaints or bounces has its customer emails paused. Every such email ends with a link that stops further emails to that address, from that business or from every business on the Service; when it is used, we keep the digest of the address on that list for as long as the choice stands. The link itself contains the digest, not the address.

• To provide, operate, and maintain the Service.
• To authenticate you, secure your account, and prevent abuse.
• To deliver your bot’s messages to and from end customers via the chosen messaging platform.
• To send you the notifications you have configured about activity in your bots — in the dashboard, by Telegram, or by email — such as new submissions awaiting your review.
• To diagnose issues, and to improve the Service and develop new features — for that last purpose using the account and usage information we hold as controller, and information aggregated or deidentified so that it cannot reasonably be used to identify a person or a customer.
• To communicate with you about service updates, security notices, and (with your consent where required) marketing.
• To comply with legal obligations and respond to lawful requests.

• Contract — to provide the Service you have signed up for.
• Legitimate interests — to keep the Service secure and working, find and fix errors, prevent fraud, and improve our product.
• Consent — for any optional marketing communications and any non-essential cookies (we do not currently set any of our own; section 10 lists what third parties may set).
• Legal obligation — to comply with applicable law and respond to lawful requests from authorities.

This is our Provider List, referred to by the Data Processing Addendum. A small number of providers are involved in running the Service, and what we owe you for each depends on the role it actually plays, so they are grouped by role rather than listed flat.

Sub-processors we appoint. These process your data and your end customers’ data on our instructions, on our contracts, as our sub-processors. We give notice before this group changes — see below.

• Neon (database hosting, EU — AWS eu-central-1, Frankfurt). Receives account data, bot configuration, and end-customer data your bots store.
• Railway (application hosting, EU region). Runs our backend API, the services that send and receive WhatsApp, Telegram, Messenger and Instagram messages, and the chat page that loads inside the website widget, so it processes everything those services handle, including message content and phone numbers.
• Cloudflare (static site hosting, DNS, CDN, and TLS termination for meerlume.com; file storage in Cloudflare R2, EU jurisdiction). Serves the dashboard, the marketing site, and the widget script your own site loads, and processes connection metadata such as IP addresses in that role. Through R2 it also stores the photos, voice messages and files exchanged in your chats: those your end customers send during a live chat with you or to a step of your bot that asks for one, and those you send them, including voice messages you record in the inbox. They are kept for 30 days on the Free plan or for the period the business chooses on a paid plan (up to one year), and deleted sooner if the conversation, bot or account is deleted; either way the files are removed from storage within minutes. When a paid plan ends, its longer period continues to apply for 14 days before the Free plan’s 30 days does. R2 also holds the files you attach in the bot builder, for about 48 hours, as described below. Apart from the files exchanged in your chats, your bots’ conversations are not stored by Cloudflare.
• Google (Gemini models, through the Gemini API or Google Cloud Vertex AI) for AI-assisted bot building. Receives your bot’s content and calendar setup, what you type or attach in the builder, and facts about your own account, such as your plan and which integrations you have connected. We reach it through OpenRouter, listed below, and directly when that route fails. On the paid terms these requests are sent under, OpenRouter’s or, when we call Google directly, our own, Google does not use them to train its models and may keep them for up to 55 days to detect abuse. Your end customers’ conversations are not sent to Google. Our direct calls are subject to Google’s API terms.
• Brevo for email delivery. For transactional email (support correspondence, notifications you configure, and the booking updates and reminders a bot emails to an end customer who left an email address, for example after a website chat or when a reminder cannot be delivered in the chat) it receives the recipient address and message content. If you opt in to product and marketing emails, we also sync your email address, first name, and consent state to Brevo’s contact list. If you later opt out, Brevo keeps your address on a suppression list so we cannot email you again by mistake.
• OpenRouter (AI gateway, United States). OpenRouter, Inc. passes AI requests from Meerlume to AI model providers. Every model provider we reach through OpenRouter is named in this entry, and we update it before a new one is used. OpenRouter has two uses.
  
  AI-assisted bot building, in use from October 7, 2026. Your bot’s content and calendar setup, what you type or attach in the builder, and facts about your own account go through OpenRouter to Google, listed above, and, when our request to Google’s models fails or times out, or has just failed, to OpenAI. Both are United States companies and process these requests outside the EU, mainly in the United States. OpenRouter is set not to store the content of these requests. We send them on terms under which neither provider uses them to train its models; each may keep them for a limited period to detect abuse (Google up to 55 days, OpenAI up to 30 days). Your end customers’ conversations are not part of this use.
  
  Helping live bots understand messages, in use from October 7, 2026. When an end customer types something the bot’s current step cannot use, for example a request for a person typed at a menu of services, or an answer a field rejected, such as a phone number it could not read, that message goes through OpenRouter to a model that tells the bot what the customer meant: whether they are asking for a person; describing one of the options the step offered, in which case the bot goes on as if they had tapped it; or asking something your bot already answers elsewhere, in which case the bot sends that answer from the flow you published and asks its question again. On a bot that takes bookings, such a message is also used for up to ten minutes, held in the conversation’s working session, and sent to the same model again for the booking lists the bot goes on to reach (its services, staff, days or times), each time together with that list, to see whether the customer has already said which one they want; where they have, the bot takes it and tells the customer what it understood, using your bot’s own labels. With the message go the bot’s own question, the options it offered, the bot’s name and description, the answers your bot holds, each as its menu label and the first part of its text, and, on a bot that takes bookings, today’s date and time where your calendar is and, at a list of times, the day the customer has already chosen. Messages the step can use, taps on buttons, and messages longer than 300 characters are not sent. The model classifies the message and writes nothing: the bot’s replies still come from the flow you published and our standard system messages. OpenRouter is set not to store the content of these requests either. For your end customers’ conversations we send requests only to model providers that OpenRouter publishes as not retaining the request and not training on it, and we configure each request to accept no other provider. Model provider for this use: TypeSafe (United States). The preview in the builder does the same with what you type while trying out a saved bot, using the draft you are editing. You can turn this off for a bot in its settings; its customers’ messages, and what you type in its preview, are then sent to no AI model.
• Sentry (error monitoring, United States; reports stored in Sentry’s EU region, Germany). Upcoming, not yet in use, and not before October 16, 2026. Functional Software, Inc. receives a technical report when something fails in the dashboard or the bot builder, in our backend, or in the services that run your bots: the error, where in our code it happened, and basic context such as the browser type. Before a report is sent we strip request contents and cookies and redact email addresses, phone numbers and credentials, and Sentry is set not to store IP addresses. Once you have opened the dashboard or the bot builder, if a page in that tab hits an error, your browser sends the report straight to Sentry, so Sentry sees your IP address in transit. A report can still contain fragments of the data being handled when the error happened, such as a name or part of a customer’s message. Sentry keeps reports for at most 90 days, and we have not allowed it to use them to train AI models. Sentry’s staff and its own sub-processors (listed on Sentry’s site) may reach reports from outside the EU, including the United States, under its EU-U.S. Data Privacy Framework certification, with Standard Contractual Clauses in its data processing terms as the fallback. We do not use Sentry for session recordings, performance tracing or usage analytics, and it sets no cookies.

Services you connect. These receive data because you switched them on. A provider in this group may act as your own processor, as an independent controller, or as our sub-processor — which one depends on the service and the contractual arrangement, not on who clicked connect. The rule we apply is functional: where we engage a provider to process your data on our behalf, it is treated as a sub-processor under the DPA and belongs in the first group, with the notice rules attached; where you contract with or instruct a provider directly, that relationship is yours. New integrations appear here as they ship.

• Meta Platforms (WhatsApp Business / Cloud API, Messenger, and Instagram) for message routing on the Meta channels you connect. Receives the messages, phone numbers or account identifiers, and metadata necessary to send and receive those conversations.
• Telegram FZ-LLC for message routing on Telegram. Receives the messages and user identifiers necessary to operate your Telegram bot and, if you enable Telegram notifications, the owner notifications we deliver to you through our notification bot.
• Stripe, if you connect your Stripe account to take payments in a bot. Receives the amount and currency, the payment description you wrote (including any customer answers you placed in it), and our internal references for the payment. The payer enters their email and card details on Stripe’s own page. We never receive the full card number. Stripe’s payment confirmations to us include the payer’s email and the card’s brand and last four digits, and we delete those records after 30 days.
• Slack, if you connect a workspace. Receives, in the channel you chose, the events you selected: the submission’s answers, the contact, and the booking where there is one.
• Notion, if you connect a workspace. Receives the submission, contact, and booking details, written as a page in the database you chose: the fields you mapped fill its columns, and every answer is listed in the page itself.
• Webhooks, if you add an endpoint. The same submission, contact, and booking details are sent to the URL you entered, which you control. A request step in a flow sends the values you placed in it to the URL you set for that step.

Our own business operations. These process your account and billing details, where we are the controller. None of them receives your end customers’ data.

• Paddle as our Merchant of Record for billing, invoicing, and tax compliance. Receives transaction and billing-country data. Our home page, our pricing pages and most dashboard pages also load Paddle’s script to show prices in your local currency, so Paddle receives the IP address of a visitor to those pages, signed in or not.
• Google (Sign in with Google), if you choose it to sign in. Google authenticates your Google account and returns the profile information and tokens we need to create or open your Meerlume account. This is separate from Google’s Gemini models above, which are a different service and receive different data.

When this list changes. Before we appoint a new sub-processor in the first group, we update this section and give at least 10 calendar days’ written notice (15 calendar days for a notice we sent before October 7, 2026) to the account administrator before the provider receives personal data, except for an urgent security or service-continuity change — you do not have to subscribe to anything to be told. You may object during the notice period on reasonable, documented data-protection grounds, and we will work with you in good faith to find a commercially reasonable alternative; if none is reasonably available, either of us may terminate the affected part of the Service, with any refund governed by the Terms. AI model providers reached through an AI gateway named above are handled as a group: they are named in the gateway’s entry, which we update before a new one is used, though we do not write to you separately about it, and the notice period applies to the gateway rather than to each model provider. Your right to object to a named model provider is not confined to a notice period: you may raise it at any time while it is listed. Providers in the second group arrive when you connect them, so there is nothing for us to announce in advance. Section 5 of the Data Processing Addendum is the contractual version of this.

We do not sell, rent, lease, or trade your personal data or your end customers’ data, we do not share it for advertising, ad targeting, ad measurement, or cross-context behavioural advertising. We do not use it to train any model of our own, and we do not send it to a third-party AI provider to train theirs. Your end customers’ conversations are run by our own flow engine, which takes every reply from the flow you published and our standard system messages; no AI model writes a reply during a conversation. Where a typed message is one the flow cannot use, an AI model reached through OpenRouter (entry above) is asked what the customer meant, on the no-retention, no-training terms that entry describes, unless you have turned that off for the bot. The AI providers used for bot building, Google and, as its backup, OpenAI, receive only your bot’s content and calendar setup, what you type or attach in the builder, and facts about your own account, on the terms the Google and OpenRouter entries above describe.

Files you attach in the builder. When you attach a menu, price list, brochure or photo on our home page or while describing or editing a bot, the file is uploaded to our own storage (Cloudflare R2, EU jurisdiction) as soon as you attach it. We keep it for about 48 hours and then delete it. It is sent to an AI provider only when a build or an instruction uses it: to Google, and also to OpenAI when our request to Google’s models fails or times out, or has just failed, as the Google and OpenRouter entries above describe. A file you attach and then abandon is sent to no AI provider. We do not link the stored file to your account or your bot: your browser holds the reference to it while you build, and only the file’s name and size remain in your builder chat.

Dictation. The microphone button in the builder and on our home page uses your browser’s own speech recognition, and Meerlume never receives your audio. Where your browser can transcribe on your device we ask it to, and the audio then never leaves your computer at all. Where it cannot, the browser sends the audio to its own vendor’s speech service to be transcribed, under that vendor’s terms. Either way, nothing reaches us until you press Build or send the message.

Where you connect a WhatsApp channel, Meerlume receives and processes data from Meta’s WhatsApp Business Platform (the WhatsApp Business / Cloud API) on your behalf, as your processor. This section states in one place how we handle that Platform Data.

What we receive and store. Inbound and outbound message content, including the photos, voice messages and files an end customer sends while you are handling the conversation yourself or when a step of your bot asks for one; the end customer’s WhatsApp phone number and profile name; message and conversation identifiers and delivery status; the structured submission payloads your bot collects (form answers, booking details, names, contact details, notes); and your channel identifiers and credentials — WABA ID, phone-number ID, display phone number, and access token.

Why we process it. Solely to run the conversational flow you configured — receiving each inbound message, evaluating it against your flow, asking an AI model what the customer meant where the flow cannot use a typed message (unless you have turned that off for the bot), and sending the reply — and to deliver the resulting submissions to you in your dashboard and through the notification channels you enable. We do not process Platform Data for our own independent purposes.

How long we keep it. Conversations and submissions remain available while your account is active, because they are the record of your customer relationships and you decide when they go; you can delete any conversation, contact, or bot at any time. Deleting your account in the dashboard removes the account and the records attached to it immediately; a request you send us by email is handled on the timetable in section 9. Three things outlive deletion: delivery records in our notification outbox, which can contain submission details such as a customer name and a booking time and are pruned after a short retention period; isolated copies in our database provider’s recovery window, until it rolls forward over them; and error reports held by our error-monitoring provider, which can contain fragments of a conversation and are kept for at most 90 days. None is used for ordinary product purposes. Photos, voice messages and files exchanged in a chat (those customers send during a live chat or to a step that asks for one, and those you send them, including voice messages you record in the inbox) are kept for 30 days on the Free plan, or for the period you choose on a paid plan (up to one year); the message stays in the conversation, and the file itself is removed from storage within minutes of that period ending or of the conversation, bot or account being deleted. When a paid plan ends, its longer period continues to apply for 14 days before the Free plan’s 30 days does. Server access and security logs are kept for a limited period.

What we never do with it. We do not sell, rent, lease, or trade Platform Data. We do not use it for advertising, ad targeting, or ad measurement. We do not use it to train machine-learning or AI models, and no provider we appoint to store or process it on our contracts may train on it. The platforms that carry your messages, and the services you connect yourself (Stripe, Slack, Notion, or your own webhook endpoint), handle what they receive under their own terms. Your end customers’ conversations are not sent to the AI providers used for bot building (Google and, as its backup, OpenAI), which see only your bot’s content and calendar setup, what you type or attach in the builder, and facts about your own account. A typed message the flow cannot use is sent to the model provider named in section 5’s OpenRouter entry, on the no-retention, no-training terms that entry describes, so the bot can tell what the customer meant; you can turn that off for a bot in its settings.

Who else sees it. Two groups. The sub-processors in section 5 that are needed to operate the channel: Neon (storage), Railway (the services that run the flow), OpenRouter and, through it, TypeSafe (a typed message the flow cannot use, unless you have turned that off for the bot), and, where you turn it on, Brevo to deliver notifications to you. And the destinations you instruct: where you connect Stripe, Slack, Notion, or a webhook to a bot, or turn on Telegram notifications, that service receives what section 5 describes. Section 5 also lists one recipient that does not receive it yet: Sentry, whose error reports can contain fragments of it. When it does, this paragraph will name it. We do not share Platform Data with any other third party except where required by law.

Where it lives. Primary application and database hosting is currently configured in the European Union. Authorised access from Armenia, and processing by the providers listed in section 5, may occur elsewhere — see section 7.

How to have it deleted. Account owners can delete in-app from Settings, and anyone — including an end customer who messaged one of your bots — can write to [email protected]. Our Data Deletion page sets out both routes, what is removed, and the timelines above.

Your account data, bot configuration, conversations, and the data your bots collect are held in hosting currently configured in the European Union. Authorised remote access from Armenia, and processing by the providers in section 5, may occur elsewhere subject to applicable safeguards. Our database runs on Neon in AWS eu-central-1 (Frankfurt, Germany), our application services run on Railway in an EU region, and the photos, voice messages and files exchanged in a chat (those end customers send and those the business sends) are stored in Cloudflare R2 under its EU jurisdiction. We currently operate no other storage or compute region.

Our own access from Armenia. Meerlume is operated from Yerevan, and our personnel reach the systems above remotely to run, support, and debug the Service. Armenia is not covered by a European Commission adequacy decision, so that access is a transfer out of the EU even though the data itself never leaves the EU. Our Data Processing Addendum incorporates the 2021 EU Standard Contractual Clauses for EEA-established customers in section 11 and completes them in its EEA transfer schedule, with the UK and Swiss provisions and the Armenia transfer assessment and supplementary measures in the sections that follow it. Access is limited to the people who operate the Service, who can use our administration tools only if two-factor authentication is switched on for their account. Section 4 of the Data Processing Addendum sets out how our staff can access a customer account and the limits on it.

Some processing also happens outside the EU because the service connects to platforms and providers that operate globally: Meta routes WhatsApp, Messenger and Instagram messages, Telegram routes Telegram messages, Cloudflare terminates connections at the edge location nearest the visitor, Brevo delivers email, Paddle processes payments, builder prompts are answered outside the EU, mainly in the United States, by Google or, as its backup, OpenAI, reached through the AI gateway in section 5 (itself in the United States) or, for Google, directly; the typed messages a live bot asks a model about are processed by that gateway and the model provider named in its entry in the United States; and, from the date in Sentry’s entry in section 5, Sentry’s staff and sub-processors may reach the error reports Sentry stores in the EU from the United States and elsewhere. For a provider we appoint as a sub-processor, its applicable data-processing terms must cover the processing before we give it customer data. Where a provider or onward recipient processes data in a country without adequacy, we rely on the transfer mechanism applicable to that recipient and service — for example a qualifying Data Privacy Framework certification for a US recipient, or Standard Contractual Clauses in the provider’s DPA. Services you connect directly remain governed by your agreement and transfer arrangements with that service.

We retain personal data only for as long as needed for the purposes described in this policy.

• Account data is retained while your account is active. When you delete your account in the dashboard we delete it immediately, along with your bots, conversations, and end-customer data; files exchanged in those conversations are removed from storage within minutes. Three categories outlive the account: delivery records in our notification outbox, which can still contain a customer name or booking time and are pruned after a short retention period; isolated copies in our database provider’s recovery window, until it rolls forward over them; and error reports held by our error-monitoring provider, which can contain fragments of a conversation and are kept for at most 90 days. None is used for ordinary product purposes. Separately, files you attached in the builder are not linked to your account and are deleted about 48 hours after you attached them.
• Bot configuration and end-customer data is retained until you delete it, close your account, or give us a valid documented instruction to delete it. After that, active records are removed on the timetable described here, subject to the notification-outbox and backup lifecycle above. Files exchanged in a chat (those customers send, during a live chat or to a step that asks for one, and those the business sends, including voice messages recorded in the inbox) are the exception: they are kept for 30 days on the Free plan, or for the period the business chooses on a paid plan (up to one year), and are removed from storage within minutes of that period ending, or sooner if the conversation, bot or account is deleted. When a paid plan ends, its longer period continues to apply for 14 days before the Free plan’s 30 days does.
• Server access and security logs are retained for a limited period, and delivery records for no longer than needed to complete and troubleshoot delivery. Email sending records (section 2) are deleted after 40 days; the digest of an address that bounced, reported spam or used a stop link is kept for as long as we refuse to email it.
• We may retain limited information for longer where necessary to comply with legal obligations, resolve disputes, or enforce our agreements.

Our Data Deletion page sets out how to request deletion, what is removed, and the billing records we must keep.

Subject to applicable law, you have the right to:

• access the personal data we hold about you;
• request correction of inaccurate data;
• request deletion of your data;
• request restriction of, or object to, certain processing;
• request a portable copy of your data;
• withdraw any consent you previously gave (without affecting the lawfulness of prior processing);
• lodge a complaint with your local data-protection authority.

We do not make decisions about you based solely on automated processing that produce legal or similarly significant effects.

California residents have additional rights under the CCPA/CPRA, including the right to know what personal information we collect, the right to delete it, and the right to opt out of “sale” or “sharing” — note that we do not sell or share personal information as those terms are defined under the CCPA.

To exercise any of these rights, email us at [email protected]. We will respond within one month, extended where applicable law permits it — for a complex request, or a high volume of them, by a further two months, and we will tell you why. If your request concerns data your bot collected from one of your end customers, that customer should contact you (the controller) directly; we will support you in fulfilling such requests under the DPA.

We use only strictly necessary and functional storage:

• A session cookie we set to keep you signed in.
• A small sidebar_state cookie that remembers whether you collapsed the dashboard sidebar.
• meerlume-teaser-dismissed:<code> — one sessionStorage entry per bot, keyed by that bot’s share code, written on the site hosting the widget. It remembers that a visitor closed the greeting so it is not shown again in that tab. This is a display preference, not something the chat needs in order to work: if storage is unavailable the widget still runs, and the greeting may simply reappear.
• meerlume-session — one sessionStorage entry written on the chat frame’s own origin, which is ours rather than the host site’s. It holds the identifier that ties a visitor’s messages to their conversation, so a chat the visitor asked for cannot continue without it. Cleared when the tab closes.
• Browser localStorage entries that hold your theme preference, calendar view choice, a flag recording whether you are signed in (used only to avoid a flash of the wrong layout), and the drafts, AI chat history and count of AI edits you build up in the bot builder before you sign up.
• Browser sessionStorage entries in the dashboard, cleared when the tab closes: the reply or internal note you have typed in the inbox but not yet sent, kept per conversation so it survives a page change, an identifier that stops a reply being sent twice, and your marketing-email choice while you finish signing up.

Some pages load resources from third parties, which receive your IP address as any web request does and may set storage of their own: Paddle’s script on our home page, the pricing and billing pages and most dashboard pages; brand icons from cdn.simpleicons.org and svgl.app on our features, pricing and changelog pages and in the dashboard; emoji data from cdn.jsdelivr.net in the dashboard; and Meta’s JavaScript SDK, which can set Meta’s cookies, only while you connect a WhatsApp or Messenger channel.

From the date in section 5, once you have opened the dashboard or the bot builder, if a page in that tab hits an error, your browser sends a report directly to Sentry, our error-monitoring provider, which receives your IP address with it but is set not to store it. Sentry sets no cookies or storage.

We do not use analytics, advertising, session replay, or cross-site tracking cookies of our own.

If you embed the chat widget, note that the two entries above sit on different origins — the teaser flag on your own site, the session identifier on ours — and serve different purposes. Describe them in your own site’s notices as your obligations require.

Meerlume accounts require the minimum age stated in section 3 of the Terms. The data your bots collect is yours as controller, and you must not configure a bot to target children.

We use appropriate technical and organisational measures including TLS in transit, encryption at rest for sensitive credentials (such as your WhatsApp access tokens and Telegram bot tokens), access controls, and production access restricted to the people who operate the Service. No system can be guaranteed perfectly secure; if we become aware of a breach that affects you, we will notify you as required by applicable law.

We may update this Privacy Policy from time to time. The “Effective date” at the top of this page reflects the latest revision. If a change is material we will provide reasonable notice (for example, by email or through the Service) before it takes effect.

Questions, requests, or complaints about this Policy can be sent to [email protected]. See also our Terms of Service, Refund Policy, and contact page.

The data controller is Meerlume LLC, a limited liability company registered in the Republic of Armenia.