Carpe Messaging Privacy Statement

Last Updated: September 23, 2026
Effective Date: September 23, 2026

Preamble

Carpe Messaging ("we," "us," or "our") is operated by Carpe Per Diem, Inc. We are committed to protecting privacy and to being transparent about how information is handled. This Privacy Statement explains how information is collected, used, stored, disclosed, and protected when you use our email and text message marketing platform for Shopify merchants (the "Service").

Carpe Messaging is a sending platform. Merchants use it to send email and text messages to people who have given that merchant permission to contact them. That fact shapes everything in this document. We hold two distinct kinds of information, and we hold them in two distinct legal capacities: information about the merchants and staff users who operate the Service, which is ours to govern; and information about those merchants' own customers and subscribers, which is the merchant's to govern and which we process only on that merchant's documented instructions. Section 1 explains this division, and it is the key to reading the rest of this statement.

Text messaging is being introduced to the Service. The commitments in this statement bind it from its first message. Where a practice differs by channel, the difference is stated.

By using Carpe Messaging, you agree to the collection and use of information in accordance with this statement. If you do not agree, you should not use the Service.

This Privacy Statement is incorporated into, and forms part of, our Terms of Service, and should be read together with our Sending Policy and our Text Message Policy, which govern who may be contacted through the Service and how, by email and by text message respectively.

Table of Contents

1. Our Two Roles: Controller and Processor
2. Information We Collect
3. How We Collect Information
4. How We Use Your Information
5. Consent: How It Is Captured, Recorded, and Enforced
6. Our Anti-Spam Commitment
7. Tracking, Analytics, and Cookies
8. Data Storage and Security
9. Data Retention and Deletion
10. Sharing and Disclosure of Information
11. Sub-Processors
12. Shopify-Specific Data Handling
13. Your Privacy Rights
14. Rights of Merchants' Subscribers
15. International Data Transfers
16. Children's Privacy
17. Changes to This Privacy Statement
18. Contact Us

Schedule A — Messaging and Privacy Laws We Recognize
Schedule B — Current Sub-Processors

1. Our Two Roles: Controller and Processor

Carpe Messaging handles two categories of personal information, and our obligations differ for each.

A. Merchant Data — We Are the Controller

This is information about the businesses that subscribe to the Service and the individual staff users who log in and operate it. We decide the purposes and means of processing this information. Under the GDPR and UK GDPR we are the controller; under the CCPA/CPRA and comparable US state laws we are a business.

B. Subscriber Data — We Are the Processor

This is information about the merchant's own customers, subscribers, site visitors, and prospects — the people who receive the merchant's messages. The merchant determines who is contacted, what is sent, and why. We do not. We process this information solely to deliver the Service the merchant has asked for, and only on that merchant's documented instructions.

Under the GDPR and UK GDPR we are the processor and the merchant is the controller. Under the CCPA/CPRA and comparable US state laws we are a service provider (or processor, as those laws term it), and we do not retain, use, or disclose subscriber data for any purpose other than performing the Service, and specifically not for any commercial purpose of our own.

C. What This Means in Practice

• The merchant owns the relationship with the subscriber. A subscriber's request to access, correct, or delete their information should be directed to the merchant whose store they subscribed to. We assist merchants in responding to those requests; we do not answer them independently, because we cannot verify a person's identity against a store we do not run. Section 14 describes this in detail.
• We never use one merchant's subscriber data for another merchant's benefit. Not for benchmarking, not for competitive intelligence, not for shared suppression, not to train models. This commitment is unqualified and it survives termination.
• Suppression, consent, and identity records are held separately for each merchant. We do not operate a cross-merchant suppression list. A person who unsubscribes from one merchant remains, as far as our system is concerned, a subscriber of any other merchant to whom they separately gave consent.
• We do not sell or share personal information as those terms are defined under the CCPA/CPRA or any comparable state law, in either capacity. We have never done so and we do not intend to.

D. Data Processing Terms

Where a merchant is subject to the GDPR, UK GDPR, or a US state privacy law requiring a written processing agreement, our Data Processing Addendum applies and is incorporated into the Terms of Service by reference. A copy is available at any time from ….

2. Information We Collect

A. Merchant Account and Business Information

• Business name, store domain, and any additional storefront domains
• Store timezone and currency
• Subscription and billing status, once billing is enabled
• Names and email addresses of staff users
• Roles and permissions assigned to each staff user
• The merchant's sending identity: "From" name, reply-to address, verified sending domains, and the physical mailing address that appears in every marketing message as required by law
• The merchant's business identity as it appears on a carrier registration for text messages, collected only when a merchant starts one and only from what they type into it: their legal business name and trading name, their business street address, their business registration or tax identification number (in the United States, the EIN), the kind of legal entity they are, and the name, email address and telephone number of the person at that business a reviewer should contact. It is the merchant's own declaration about their own business; a carrier will not approve a sending number without it, so it is sent to the text message carrier as part of the registration (Schedule B, Section B) and it is kept with the store's text-message record so the merchant can read and correct what they filed. It is never used for anything else, and none of it describes a subscriber

B. Merchant Authentication Data

• Email address and a hashed password (we never store passwords in readable form)
• Session tokens, and the IP address and browser user-agent recorded with each login session for security and fraud prevention
• Two-factor authentication secrets and backup codes, where a user has enabled two-factor authentication
• Shopify OAuth access and refresh tokens, held encrypted
• API keys we issue, stored only as irreversible hashes
• Credentials a merchant gives us for another email platform, so that we can read their own account there and bring their records across. These are the one credential we hold in a reversible form — held encrypted under keys we control, never displayed again after it is given, and never used to write anything. We record the last four characters so the merchant can tell one key from another, and nothing else about it. The merchant may disconnect at any time, and we ask them to revoke the key at that platform as well, because a key we no longer hold is still a key that exists.

C. Subscriber Profile Information (processed for the merchant)

For each person in a merchant's audience, we may hold:

• Email address
• Telephone number
• First and last name
• The merchant's own custom profile properties and the customer tags applied in their Shopify store
• Shopify customer identifier
• Identity verification tier and the basis for it (see Section 5.D)
• Date of last activity

We do not extract or retain subscribers' payment card numbers, bank account details, government identifiers, health information, or biometric data in their profiles. A profile may include details a subscriber chooses to share with the merchant — such as a date of birth for a birthday offer. A profile may also include coarse location — country, state or region, and city — derived from the merchant's store records and from onsite activity, so that a merchant can, for example, send to their customers in one state. Street addresses are not kept in profiles; they appear only inside raw order webhooks from Shopify, which are held briefly so that a failed webhook can be reprocessed and are erased within seven days.

D. Consent Records (processed for the merchant)

For each subscriber and each channel separately:

• Current consent status
• The timestamp at which that status was established
• The source and method by which consent was given or withdrawn
• Where applicable, the identifier of the form or system the consent came from, the completeness of the evidence, and the version of the policy in force at the time

Consent evidence is append-only: the database itself refuses any edit or deletion, so that a merchant can always demonstrate the origin of any recipient's permission. The single exception is erasure — a data subject erasure request or a store purge removes it, as described in Sections 9 and 12.

E. Message and Engagement Data (processed for the merchant)

• A ledger of every message sent, attempted, or refused: recipient address, subject line, sending stream, status, and — where a message was refused — the specific reason
• Delivery outcomes reported by our sending providers, including bounces, complaints, and failures
• Opens and clicks for marketing email, including the URL clicked and the user-agent of the requesting client
• For text messages: delivery receipts, opt-out keywords received, and carrier error codes
• Text messages people send TO the store's number, received through our message provider: the message itself, the number it came from, and any image attached to it. A person texts a store to stop hearing from it, to ask for help, or to ask about their order, and each of those is a message we receive and hold on the merchant's behalf. We hold the provider's own record of the message as it arrived as well as our reading of it.

F. Onsite and Commerce Activity (processed for the merchant)

• Commerce events synchronized from the merchant's Shopify store: orders placed, products ordered, checkouts started, and fulfillment progress including tracking numbers
• Product catalogue data: titles, variants, SKUs, prices
• Onsite browsing events collected by our Shopify web pixel: page views, product views, add-to-cart, checkout started, and contact information submitted at checkout
• Form interactions: impressions, step views, submissions, and dismissals
• A standing request to be told when something is back in stock, and the record of how we answered it. Somebody asks a store to let them know when one product comes back; that ask is held against the address they typed, often before any profile for them exists. It carries the email address and the first name they gave, the page they asked from, the product and the exact wording of the variant as it was shown to them, what our mailbox check concluded about the address and why, the version of the disclosure they were shown, and a record of the choice offered beside the ask — whether a marketing box was shown, how it was set when they met it, how it was set when they sent it, and the country we derived from the requesting IP address in order to decide which of those was lawful where they were. It is one ask about one product and it is not marketing permission; the box beside it is the separate choice, and Section 5 explains how the two are kept apart. We also hold the record of each message we sent in answer to it, and whether it was sent, refused, or failed.
• A visitor record keyed to Shopify's own first-party visitor identifier, with coarse geographic data only — country and region. We read the requesting IP address in order to derive that country and region, to enforce rate limits, and — at the moment someone asks to be notified that a product is back in stock — to pass to the bot-challenge provider described in Section 2.G, which uses it to decide whether that request came from a person. We never associate an IP address with a visitor's profile or browsing record. IP addresses are not stored against a visitor; they appear only in the abuse-prevention counters and the bot challenge described in Section 2.G.
• Discount codes issued to individuals and their redemption outcomes
• Which products a message sent to a saved audience selected for one individual, and whether it was sent. A merchant may build a message whose product block fills itself from that person's own activity in their store — what they looked at, what they left in a checkout, what they bought — or from what customers of that store buy together. We record the products selected, the rule that selected them, and the products as they were at that moment, so the merchant and the individual can both be told what was chosen. The selection happens before the message is sent, so a record can exist for a person the sending rules then declined to mail — Section 12.C says which, and the report says of every record whether the message actually went out. It is derived from the commerce and browsing activity above and from nothing else; no data is bought, no third-party source is consulted, and it is never used to decide anything about a person beyond which products a marketing message shows them. This record is kept for messages sent to a saved audience. A message sent by an automation — one a person's own action starts — chooses its products in the same way, and we do not keep a per-individual record of that choice.

G. Technical and Service Data

• Server logs generated in the course of operating the Service
• Error and performance diagnostics
• Rate-limiting and abuse-prevention counters, which reference an IP address or a keyed hash of an email address. These counters exist to stop automated abuse of signup forms and authentication endpoints. They are not linked to any profile and are not used for any other purpose.
• A bot challenge on the back-in-stock form. Where a store shows a form asking to be notified when a product comes back into stock, a challenge runs in the visitor's browser on that page. It is invisible in the ordinary case and asks the person to tick a box only where it is unsure. It is operated by a bot-challenge provider, named in Schedule B, which receives the visitor's IP address, signals about their browser, and the address of the page the form is on — not the person's email address, not their name, not anything else typed into the form, and nothing about any profile. We receive back a yes or no and store none of it. That provider states that it processes those signals solely to detect and block bots, and not to identify, profile or target any individual. The challenge sets no cookie on the store's site. The widget issues a single-use token and nothing else; the provider's optional feature that would set a cookie is off by default and is not used by this Service. Where a store shows no such form, no challenge runs and nothing is sent.
• Audit logs recording administrative actions, including an explicit flag for any action that touched customer data

H. Information We Do Not Collect

• Subscriber payment card or bank account information
• Subscriber street addresses, beyond the seven-day raw-webhook retention described in Section 2.C (coarse location — country, state or region, and city — is kept; see Section 2.C)
• Social Security numbers, driver's license or passport numbers, and any government-issued identifier belonging to an individual
• Health, genetic, or biometric information
• Precise geolocation
• Advertising identifiers, or any data obtained from data brokers, list vendors, or appending services

One clarification, because the line above used to be broader. We do not collect a tax identification number belonging to any individual, and we never ask a subscriber for one. We do collect a merchant's business registration or tax identification number, and only where that merchant chooses to start a carrier registration for text messages, which cannot be filed without it (Section 2.A).

We do not purchase, rent, license, or otherwise acquire personal information from any third-party data source. Every subscriber record in the Service originates from the merchant's own store, the merchant's own website, the merchant's own upload, or the merchant's own account with another email platform that they connect and instruct us to read (Section 3.E).

A connected email platform is not a data source in the sense this paragraph refuses. It is the merchant's own account, holding records the merchant already controls, opened to us with a credential the merchant creates for that purpose and can revoke. We do not buy it, we are not sold access to it, and we read it only while the merchant has connected it.

I. Sensitive Information in Merchant-Supplied Fields

Merchants may write arbitrary custom properties onto subscriber profiles. We do not inspect, use, or interpret the contents of those fields. Merchants are responsible for not placing special-category data — health information, precise location, government identifiers, or information about children — into them, and the Terms of Service prohibit doing so.

J. Early-Access Requests

When someone asks for early access on our public website, we collect what they typed in that form: their store URL, their email address, the platform they use today, the size of their list, and roughly how much they send each month. We do not record the IP address or the browser user-agent of that request, and we never visit the store address they gave us.

We use it to get in touch about early access and to understand who is asking. An early-access request is not marketing consent — it never adds anyone to a mailing list, and we write back only about early access. Retention is in Section 9.B, and deletion is by request to ….

3. How We Collect Information

A. Directly From the Merchant

Information provided at registration, entered into the Service, or configured in Settings — including sending identity, physical mailing address, segment definitions, message content, and form designs.

B. From the Merchant's Shopify Store

With the merchant's authorization, and using only the access scopes they granted at installation, we receive:

• Customer records, including the marketing consent state Shopify holds for email and for SMS
• Orders, checkouts, and fulfillment events
• Products, variants, and discounts
• Store domains and configuration

We request the following Shopify access scopes and no others: read_products, read_orders, read_customers, read_fulfillments, read_customer_events, read_discounts, write_pixels, and write_customers.

write_customers is used for two purposes, both described in Section 10.B: to write a subscriber's consent change back to the merchant's store; and, since September 23, 2026, to delete a customer from the merchant's store at the merchant's direction — only when the merchant deletes that person in the Service, and only when the customer has placed no order in that store. We do not use it to alter any other customer field.

C. From the Merchant's Website

• Onsite forms. Signup forms the merchant builds and publishes on their storefront. Every form panel that collects an email address or telephone number must carry a consent disclosure; the Service will not publish one that does not.
• The onsite pixel. A Shopify web pixel extension running in Shopify's strict sandbox, which observes the five commerce events listed in Section 2.F and nothing else. Its delivery is governed by the merchant's Shopify customer-privacy settings, so in jurisdictions where a consent banner is required, no data is collected until the visitor consents through that banner.
• Back-in-stock requests. Where the merchant has published one, a block on their own product page lets somebody ask to be told when that product comes back. The ask is collected from the merchant's storefront, at the moment the person presses the button, and it is held whether or not they also accept the separate marketing choice offered beside it.

D. From a File the Merchant Uploads

A merchant may bring people over from another platform by uploading a file of their own — a spreadsheet with one person per row. We read the columns we recognize (an email address, a name, a telephone number, what the merchant recorded about consent and when), and we keep any column we do not recognize as a field on that person's profile, spelled the way the merchant's file spells it.

Before an upload is imported, the merchant confirms three things in their own name — that these people gave them permission, that the list was not bought, rented, or scraped, and that they will honor a request to stop. We record who confirmed it and when, and that record is kept as a compliance record under Section 9.B. The file itself is not: the rows are held only as long as the import needs them, on the clock stated in that same section.

E. From Another Email Platform the Merchant Connects

A merchant leaving another email platform may connect their own account there so that we can bring their records across. They create a credential in that platform for this purpose and give it to us; we confirm which account it opens and ask the merchant to say, in their own name, that it is the account they are migrating from. Nothing is read until they do.

What we read is the merchant's own audience and the record of what that platform did with it: the people on it and their contact details, what that platform recorded about each person's consent and when and how it was given, the history of messages sent to them and what those messages did, the lists and audience rules the merchant built, their message designs, and their automated message sequences. Images referenced by those designs are copied into the merchant's own image library. We also keep that platform's own copy of each message design we import, exactly as it was stored there, so that the merchant can later rebuild the design here as editable content; it is never rendered, never sent, and never shown to anyone. We read the people who asked never to be contacted first, before anything else, so that nothing brought across afterwards can put them back on a mailing list.

We only read. The credential is used for retrieval and nothing else; there is no operation in the Service that writes to a connected platform, changes anything in it, or deletes anything from it. The connection is not a synchronization: it copies once, it can be re-run to catch up on what changed while the merchant is still using both tools, and it is expected to end in disconnection. Because it is not a synchronization, an opt-out recorded here does not travel back to that platform — the merchant is told so on screen, and the Service gives them a file of everyone they must not email so they can carry it across themselves.

The credential's custody, the retention of what is read, and the merchant's control over it are described in Sections 8.B and 9.B.

F. From Our Sending Providers

Delivery outcomes, bounce notifications, spam complaints, opt-out keywords, and carrier responses, received through cryptographically verified feedback channels.

And text messages sent to the store's number. Where a store has a text message number, our message provider passes us every message people send to it — the message, the number it came from, and any image attached — over the same verified channel. We receive it because the store's own number received it; we do not go looking for it anywhere else.

G. Automatically

Server logs, session records, and diagnostic data generated as the Service operates.

H. From Someone Asking for Early Access

The five fields of the early-access form on our public website, as described in Section 2.J. Nothing else about that request is stored.

4. How We Use Your Information

A. Delivering the Service

• Sending the merchant's email and text messages to the recipients the merchant has selected
• Checking every recipient's consent immediately before each send, and refusing the send if consent does not permit it
• Building and counting audience segments
• Rendering, previewing, and validating message content
• Synchronizing commerce and consent data with the merchant's Shopify store
• Issuing and attributing discount codes
• Recording delivery, engagement, and refusal outcomes

B. Account and Access Management

• Creating and maintaining merchant accounts and staff user access
• Authenticating users and enforcing role-based permissions
• Detecting and preventing unauthorized access

C. Compliance and Enforcement

• Enforcing consent, suppression, and identity requirements before a message can be sent
• Reviewing bounce, complaint, and opt-out rates for each merchant and intervening where they indicate a list problem
• Maintaining the records a merchant needs to demonstrate lawful consent
• Investigating reports of abuse

D. Service Improvement and Support

• Diagnosing and fixing faults
• Analyzing aggregate, non-identifying usage patterns to improve the product
• Responding to support requests

We do not use subscriber data to improve the Service beyond the merchant it belongs to, and we do not train machine-learning models on any merchant's customer data.

E. Communication With Merchants

• Service updates, security notices, and billing notifications
• Responses to support enquiries

F. Legal Compliance

• Complying with legal obligations, responding to lawful process, and enforcing our Terms of Service

G. Legal Bases for Processing (GDPR / UK GDPR)

Where we act as controller of merchant data:

Where we act as processor of subscriber data, the legal basis is determined by the merchant as controller. Our processing rests on the merchant's documented instructions and on the Data Processing Addendum between us.

5. Consent: How It Is Captured, Recorded, and Enforced

Consent is the foundation of this Service. This section describes the mechanism, because a promise about consent is only as good as the machinery behind it.

A. Consent Is Held Separately for Each Channel

Permission to send marketing email is not permission to send marketing text messages, and neither implies the other. A telephone number given for order notifications does not become permission to send marketing. We hold one consent record per person per channel, and each is evaluated independently.

B. Consent States

Each record carries one of three states:

• Subscribed — the person has given the merchant permission to send marketing in this channel.
• Unsubscribed — the person has withdrawn permission, or never gave it. The withdrawal is written back to the merchant's Shopify store as well as recorded here, so it cannot drift between the two. Our Terms of Service prohibit a merchant from re-subscribing anyone who has opted out; where we are told that has happened, we apply a suppression, which is irreversible.
• Suppressed — the person must never be contacted again in this channel. Applied automatically when an address hard-bounces, when a recipient reports a message as spam, when a subscriber is redacted under a legal erasure request, when an address is found invalid, or at the merchant's explicit direction.

Suppression is terminal. It is enforced in the database itself, not in application logic a merchant could bypass, and there is no interface through which a merchant can reverse it.

C. Consent Evidence

Alongside the current state, we keep an append-only evidence record: what was asserted, when it occurred, which system and method it came from, the form or external identifier involved, how complete the evidence is, and the policy version in force. This record exists so that a merchant challenged about a recipient's permission can show where it came from.

D. Identity Verification Before Sending

Consent alone is not sufficient. Before a merchant may send marketing to an address or number, that identity must be corroborated by real activity in the merchant's own store — a synchronized Shopify customer record, a verified onsite form submission, or a purchase. Identities that appear without corroboration are held back and cannot be messaged. This is a deliberate defense against list injection, typo-squatting, and imported addresses of unknown origin, and it fails closed: if verification cannot be established, no message is sent.

E. The Sending Gate

Every message passes through a single checkpoint before it leaves the system. In order, that checkpoint confirms: sending authority; that a deliverable address exists; that the recipient is not suppressed; that the recipient is not on a permanent never-contact record; that marketing consent exists for the channel; that identity is verified; that the merchant has not paused the recipient; that a valid sending configuration exists; and that the message is within size limits. Consent is then checked once more, immediately before the message is handed to the sending provider.

For marketing email, the gate additionally refuses to send any message whose rendered content lacks a working unsubscribe link, or whose plain-text version lacks either that link or the merchant's physical mailing address. The message editor blocks these omissions at design time as well; the gate is the backstop.

If the suppression check itself is unavailable for any reason, the send fails rather than proceeds.

Every refusal is recorded with its reason and is visible to the merchant.

F. Opting Out

• Email. Every marketing email carries a one-click unsubscribe honored by mail clients (the List-Unsubscribe and List-Unsubscribe-Post headers, RFC 8058), a visible unsubscribe link in the body, and the sender's physical mailing address. Unsubscribe identifiers travel in the URL path rather than in query parameters, so that link-privacy features in modern mail clients cannot strip them and silently break the opt-out.
• Text messages. Every marketing text identifies the sender and states how to stop. Replying STOP (or any recognized equivalent) ends marketing texts from that merchant; replying HELP returns the sender's identity and contact details. Opting out stops all marketing texts from that merchant, not a single campaign.
• Timing. Opt-outs take effect immediately in the channel in which they were made. We do not rely on the ten-business-day grace period permitted under FCC rules; the record is written on receipt, pushed back to the merchant's store, and honored by the sending gate on the next send.
• Permanence. An opt-out does not expire. Reversing one is a breach of our Terms of Service, and on request or report we convert it to a suppression, which no one — merchant or platform — can undo.

G. Marketing Versus Transactional Messages

Transactional messages — order confirmations, shipping notices, password resets, and comparable operational communications — are not marketing and are not gated on marketing consent, because they are the fulfillment of a transaction the recipient initiated. They are, however, subject to the same identity and suppression checks, they may never contain marketing content, and they are never used as a pretext to reach someone who has opted out of marketing. Marketing content in a transactional message makes it a marketing message, and our Terms of Service treat it as one.

6. Our Anti-Spam Commitment

This section is a statement of what we will and will not permit, and it binds us as much as it binds the merchants who use us.

No message is sent through Carpe Messaging to anyone who did not consent to receive it in that channel. This is not an aspiration; it is enforced at the point of sending, on every message, without exception and without an override.

We do not permit, and the Service will not knowingly deliver:

• Messages to purchased, rented, scraped, harvested, or appended lists
• Cold outreach of any kind, in any channel
• Marketing text messages to a number given for another purpose
• Messages with misleading sender names, subject lines, or headers, or any attempt to disguise who sent the message
• Text messages that fail to identify the sender or fail to state how to stop
• Any design that makes opting out harder to find or harder to use
• Malware, phishing, or credential harvesting
• Content promoting illegal goods or services

We review delivery, bounce, opt-out, and complaint rates for merchants in both channels, and we reserve the right to throttle or stop any merchant's sending where it puts recipients, other merchants, or our standing with mailbox providers and carriers at risk. Serious or repeated violations end the account. Nothing in this section obliges us to review any particular account or message, and our failure to detect a violation is neither a waiver nor an endorsement.

We would rather lose a customer than contact someone who did not ask to hear from them.

Reports of abuse should be sent to …. We investigate every report.

7. Tracking, Analytics, and Cookies

A. Email Open and Click Tracking

Marketing email sent through the Service carries:

• A small transparent image which, when a mail client loads it, records that the message was opened, together with the requesting user-agent. Many mail clients now pre-load images automatically, so opens are an approximate signal, not a certain one.
• Rewritten links, so that a click can be attributed to the recipient and the campaign. The unsubscribe link is deliberately excluded from rewriting, so that opting out never depends on our tracking infrastructure being reachable.

Transactional email is not link-rewritten and carries no open pixel.

Merchants can see this engagement data for their own subscribers. We do not aggregate it across merchants.

B. Text Message Tracking

Text messages carry no open tracking; the channel does not support it. Where a text contains a link, that link may be shortened and attributed in the same manner as email clicks. Delivery receipts and carrier status codes are recorded.

C. The Onsite Pixel

Our Shopify web pixel runs inside Shopify's strict sandbox and observes five commerce events only (Section 2.F). It sets no cookie of its own. Visitor identity is Shopify's own first-party visitor identifier, which Shopify sets and controls. Delivery of the pixel is governed by the merchant's Shopify customer-privacy configuration, which means that in jurisdictions requiring consent for analytics or marketing cookies, the pixel does not collect until the visitor has consented through the merchant's banner.

Events observed before a visitor is identified are held separately. If the visitor later identifies themselves — by submitting a form or entering an email address at checkout — that earlier activity is associated with their profile. If they never identify themselves, the record is deleted after 730 days and is never linked to a person.

D. Cookies on Our Own Website and Application

We protect against cross-site request forgery using origin checks and request headers rather than a cookie.

We use no advertising cookies, no third-party tracking cookies, no analytics cookies, and no social media pixels on our own website or in the application. We run no session-replay or error-monitoring service of any kind on our website or in the product, and no analytics of any kind in the product.

Page-view counts on our public website. Our public website (not the application) counts page views through a cookieless analytics feature of our hosting provider, named in Schedule B. It records the page visited, the referring page, the visitor's approximate location (country, region and city), device type, browser and operating system, and the time. It sets no cookie. A visit is told apart from other visits by a hash computed from the request, which that provider discards after 24 hours, so a visitor cannot be recognized across days; the provider states that the data is anonymous, aggregated, and not tied to or associated with any individual or IP address. It runs on no page of the application, and no merchant, team member, profile or subscriber data is involved. Our web fonts are self-hosted, so loading a page of ours does not disclose your address to a font provider. Disabling essential cookies prevents use of the Service.

E. Do Not Track and Global Privacy Control

Because we do not sell or share personal information and do not engage in cross-context behavioral advertising, there is no sale or sharing for a Global Privacy Control signal to opt out of. We honor opt-out preference signals where a state law requires it. Merchants remain responsible for honoring such signals on their own storefronts.

8. Data Storage and Security

A. Where Data Is Stored

All persistent data is stored in the United States, in managed PostgreSQL infrastructure and in object storage operated by the providers listed in Schedule B. Application code and static assets are served through a global content delivery network with edge locations worldwide; that network does not store merchant business data or subscriber data.

B. Security Measures

• Encryption in transit. All data is transmitted over TLS.
• Encryption at rest. Our database and object storage providers encrypt data at rest. In addition, we apply a second layer of application-level AES-256-GCM encryption, under keys we control, to every stored Shopify access token, refresh token, and webhook secret, and to every credential a merchant gives us for another email platform — so that a database disclosure alone does not yield credentials to any merchant's store, or to any account of theirs elsewhere.
• Credential hygiene. Passwords are hashed and never recoverable. API keys we issue are stored only as irreversible hashes. A credential a merchant gives us for another email platform has to be readable to be used, so it is encrypted rather than hashed, and it is fenced instead: exactly one place in our code can decrypt it, it is never returned to a screen or written to a log, it is refused once the merchant disconnects, and it is erased from the record the moment they do. We cannot verify what such a credential is unable to do — the platforms that issue them do not let a holder ask — so we do not claim it is restricted. We record what we were in fact able to read with it and show the merchant that, described as what happened rather than as a limit. Permanent never-contact records store a keyed, irreversible hash of the address rather than the address itself, so that the record survives erasure of the profile without retaining the personal data it protects.
• Webhook authentication. Every inbound webhook from Shopify is verified by HMAC-SHA256 signature against the raw request body; unsigned or mis-signed requests are rejected. Delivery feedback from our sending providers is cryptographically signature-verified before it is accepted.
• Access control. Role-based access control with four roles and granular capabilities. Sending, consent mutation, deletion, and billing are restricted to specific roles. Access to merchant accounts by our own personnel is limited to named individuals under confidentiality obligations, and only where necessary to operate or support the Service. Our staff cannot cause a message to be sent, alter a consent record, or delete data — those capabilities are blocked outright in our systems, not merely by policy. One narrow operational exception, stated rather than implied: where a merchant has uninstalled the app, a member of our staff can run the erasure of that store's data early — from a terminal, naming the store, and only for a store that has actually uninstalled. It cannot be run against a live store by any means, and it sends no marketing message; the notice the account owner receives about their own store's deletion is system mail about the account's lifecycle, not a message to anyone's subscribers. It exists so that a merchant who asks for their data to go sooner than the 30 days can be answered.
• Authentication. Self-service signup is disabled; accounts are created only by invitation. Minimum password length of twelve characters, mandatory email verification, and optional time-based two-factor authentication.
• Request protection. Strict origin checking on every state-changing request, content-security-policy headers restricting where the application may be framed, request size caps, and rate limiting at both the network edge and within the application. A store's back-in-stock form additionally runs the bot challenge described in Section 2.G, so that a standing request to be emailed cannot be created by automated traffic.
• Export files. When a merchant asks for a copy of their own audience, the files are held in object storage under a 24-hour deletion clock and are reachable only through an authenticated, capability-checked request — the person asking must be signed in to that store, hold the permission that allows an export, and present a link issued for that one export. The storage location has no public hostname, so no file in it can be reached by guessing an address.
• Auditing. Administrative actions are recorded in an audit log that flags every action touching customer data.

C. Tenant Isolation

The Service is multi-tenant. Each merchant's data is scoped by a store identifier present on every record, and cross-store references are made structurally impossible by composite database constraints rather than by application logic alone. No merchant can query, export, or receive another merchant's data.

D. Security Limitations and Breach Notification

No system is completely secure. In the event of a personal data breach:

• We will notify affected merchants without undue delay and within 72 hours of confirming the breach, so that merchants — as controllers of their subscribers' data — can meet their own notification obligations.
• We will notify relevant supervisory authorities where required by law.
• Notifications will describe the nature of the breach, the categories of data affected, our assessment of likely consequences, and the measures taken in response.

E. An AI Assistant a Merchant Connects

A merchant's team member may connect an AI assistant of their own choosing to their store. The assistant is the merchant's own tool, selected by them and operated by a provider they have their own relationship with; it is not software we supply and its provider is not a sub-processor of ours. Nothing is connected unless a team member signs in here and approves it on our own screen, and the merchant may end the connection at any time.

What a connected assistant can reach. The store's own working material — campaigns, automations, segments and their counts, lists, email designs and templates, and reports in aggregate. Reports are aggregate; no facility returns a list of message recipients.

Reading an individual profile: not yet, and what it will be when it arrives. A connected assistant cannot read an individual person's profile today. No such facility exists and nothing a merchant connects can ask for one. We are building it, and the three paragraphs that follow describe what it will return and the bounds it will carry — stated here before the first record moves rather than afterwards. What it will return, one record at a time, is a single profile: consent per channel, whether the identity is confirmed, when the person was last active, and the names and dates of their most recent events.

What it cannot do, structurally. A connected assistant cannot send or schedule a message, publish or enable anything, cancel or pause a live program, delete anything, export data, alter a consent record, or change a setting. These are refused by the same permission layer that governs our own staff, checked before anything else, and no function exists through which the assistant could attempt them. It produces drafts, which a person reviews and acts on.

A profile read will be a disclosure to the merchant's chosen provider, on the merchant's instruction. When that facility arrives and a connected assistant reads an individual profile, that record leaves our systems and reaches the provider of the assistant the merchant connected. That transmission happens because the merchant instructed it, to a provider the merchant selected; the merchant decides whether to connect an assistant at all, which one, and on what terms that provider may process what it receives. As controller of their subscribers' data, the merchant is responsible for that choice, including any notice or legal basis it requires and any international transfer it involves. We give merchants at least 30 days' notice before adding a sub-processor of our own (Section 11.B); a merchant's own assistant is not one, so that notice does not apply to a connection the merchant makes themselves.

The bounds it will carry. Profile lookup will be by exact email address or exact full name; partial matches will return nothing, and there will be no wildcard, no pagination and no bulk read. A search will return at most ten minimal results. Across every assistant connected to a store, no more than 200 distinct profiles may be disclosed in a day; further lookups will be refused until the next day. Every disclosure will be recorded by profile identifier and time, and never by address or name. Event payloads are never returned.

Accountability. A connection is bound to one team member's seat at one store and carries that member's permissions and no more; a viewer's assistant can only read. Every draft the assistant writes is recorded against the connection and the member it acted for. Removing or deactivating that team member revokes the connection permanently, and revoking a connection takes effect immediately.

9. Data Retention and Deletion

A. While an Account Is Active

Merchant data and subscriber data are retained for as long as the merchant's account is active and the Service is in use, except where a shorter period is stated below.

B. Specific Retention Periods

The periods above are the maximum for which we retain each category. Deletion is carried out by purge processes; a category may persist briefly past its stated period until the next purge completes.

Two exceptions, stated rather than implied: early-access requests and assistant registrations are deleted by hand. There is no automated purge for either, and in both cases the reason is the same: the record is attached to no store, so nothing in the uninstall purge or an individual erasure reaches it. We delete an early-access request, the copy of the notification we sent ourselves about it, and that notification in our own mailbox, when the person asks us to at …, and otherwise when we clear the queue at the retention period above. We delete an assistant's registration when we clear the registrations nobody ever connected, and a merchant who wants their own assistant's registration removed can ask us at the same address.

C. Why Suppression Records Are Kept Forever

When a person is erased from our system, we retain an irreversible cryptographic hash of their address and nothing else. When a merchant deletes a person instead (Section 10.B), that hash is retained as a never-contact record only where the person had withdrawn their consent or was already on the never-contact record; a person deleted while subscribed, or never asked, is not barred from being contacted again — unless the merchant chose, when deleting them, that the people deleted may never be contacted again, in which case the hash of each of their email addresses and telephone numbers is retained as a never-contact record for good. This is the only way to guarantee that an erased address is never mailed again — if the record were deleted with the rest, a subsequent import could resurrect the address and message someone who had asked never to be contacted. Retaining the hash is a data-minimizing measure taken in the data subject's own interest, and it is the basis on which we retain it.

D. Uninstallation and Account Deletion

When a merchant uninstalls the app from their Shopify store:

• Immediately. The connection is marked disconnected, stored Shopify access and refresh tokens are blanked, all staff sessions for that store are invalidated, and all memberships are deactivated. No further data is received and no message can be sent.
• For 30 days. Data is preserved, so that a merchant who reinstalls does not lose their profiles, consent history, content, and reporting. This period also allows us to meet record-keeping obligations for messages already sent. The 30 days run from the uninstallation itself.
• Reinstalling calls it off. A merchant who installs the app again inside the 30 days keeps everything, and nothing has to be restored, because nothing was deleted. A store that leaves again later starts a fresh 30 days from that day.
• After 30 days. All data for that store is permanently purged, and all associated media files are deleted from object storage. Staff user accounts belonging solely to that store are deleted. A minimal shell is retained by design: the store record itself, the record that the store was purged, receipts for any privacy requests we discharged, never-contact records as described in Section 9.C, and the record of what each paid address check cost the merchant — a count, a rate and a total, together with how that check came out as counts (how many addresses could then be emailed and how many still could not), naming no address and nobody.
• Reinstalling stops a purge that has begun; it does not reverse it. Where the 30 days had run out and the purge had started before the merchant returned, whatever it had already deleted is gone. Media files are the most visible case: the record of an image can outlive the file itself, so the merchant may see an image that no longer loads. We tell a merchant what was reached, on request to ….
• Not recoverable. Once purged, data cannot be restored.

A merchant may request an earlier purge at any time by writing to … from an authorized account, and we carry it out rather than waiting for the 30 days to run.

An individual’s own erasure request is never held for this period. Where a person asks the merchant to erase them, or the merchant’s store sends us that instruction on their behalf, we carry it out when it arrives — during a store’s 30 days or outside them. The period above protects a merchant’s ability to return; it delays nobody’s right to be forgotten.

E. Legal Retention

We may retain certain records beyond these periods where required by law — financial records for tax purposes, security and audit logs, and suppression records as described above. Aggregated data that no longer identifies any person may be retained indefinitely.

F. Backups

Data present in automated backups is removed in the ordinary backup rotation following deletion, and in no case later than 30 days after the purge completes.

10. Sharing and Disclosure of Information

We do not sell, rent, trade, or share personal information as those terms are defined under the CCPA/CPRA or any comparable state privacy law. We disclose information only in the circumstances set out below, and none of these disclosures constitutes a sale or a share.

A. Sub-Processors

We engage the service providers listed in Schedule B to operate the Service — to send messages, host the application, store data, and perform specific technical functions. Each is contractually bound to process data only on our instructions, to maintain confidentiality and appropriate security, and never to use the data for its own purposes. Section 11 governs how this list changes.

B. The Merchant's Own Shopify Store

We exchange data with the merchant's Shopify store as necessary to provide the Service. We read customer, order, product, discount, and fulfillment data, and we register the webhooks and storefront configuration the Service requires. We write to the store's customer records in exactly two ways, both described below: consent changes, and — at the merchant's direction — deleting a customer.

Consent synchronization runs in both directions. We read the consent state held in the merchant's store and honor it, and we write consent changes back — so that an opt-out recorded in either place is honored in both. When someone unsubscribes from a message we sent, or replies STOP, that withdrawal takes effect in the Service immediately — no message we deliver will ever go to them again — and is written to their record in the merchant's store promptly, with automatic retries until the store accepts it. Until that write completes (for example, while a merchant's authorization or Shopify itself is unavailable), the store's own record may briefly lag ours; ours is the one our sending obeys.

Deleting a person, at the merchant's direction (added September 23, 2026). A merchant's owner may delete a person from the Service — one profile at a time, or everyone in an audience segment or a list at once. A deletion carries out the same erasure described for customers/redact in Section 12.C, with one difference in what it leaves behind: where the person had withdrawn their consent in a channel, or was already on the never-contact record, we first write an irreversible never-contact record for that channel, exactly as an erasure does; where they had not — they were subscribed, or had never been asked — we write none, because a merchant tidying their own audience has made no statement that the person must never be contacted, and a mistaken deletion should not become a permanent ban. For such a person we keep only the same irreversible hash of each address we left free, for the reason given in Section 12.C. A merchant may instead choose that the people deleted can never be contacted again (added September 23, 2026) — the confirmation offers it, already chosen when the people are the Service's own "Probably not a person" segment, which exists to catch automated checkouts: then we write an irreversible never-contact record for every email address and telephone number of every person deleted, whatever their consent, and none is left free. That record is a one-way fingerprint, cannot be turned back into an address, and blocks the address for good: if it reaches the store again — through a signup, an order or an import — nothing the merchant sends is delivered to it. We then delete the corresponding customer in the merchant's Shopify store, but only where that customer has placed no order there. We ask the store how many orders the customer has before asking it to delete anyone, and a customer with any order is left untouched, because the store's own sales record is not ours to destroy. A person who is not a customer in the store is not looked for there. If the store does not confirm that it deleted the customer — it cannot be reached, it refuses, or it cannot find them — the deletion in the Service still happens, and the customer may remain in the store; we send again a store request that was cut off before the store answered, but once the store has answered we never ask it to delete that customer again — we retry only passing on a withdrawal of consent the store had not yet received. For a deletion of a segment or a list, the merchant is shown how many customers we could not confirm were deleted there.

C. Legal Requirements

We may disclose information where required by law or valid legal process, including court orders, subpoenas, and lawful regulatory requests, and where necessary to protect rights, property, or safety, or to investigate fraud or abuse.

Where we are compelled to disclose a merchant's data, we disclose only the minimum required, and — where legally permitted — we give the merchant prompt notice beforehand so they may seek protective relief.

D. Business Transfers

If we undergo a merger, acquisition, financing, or sale of assets, data may transfer as part of that transaction. We will give notice before any data becomes subject to a different privacy statement, and the acquiring party will be bound by commitments no less protective than these.

E. Confidentiality of Merchant Data

All merchant business data — audience lists, consent records, segment definitions, message content, campaign performance, and subscriber information — is treated as confidential and proprietary to the merchant.

• We will never voluntarily disclose, share, license, or make available any merchant's data to any third party, including other merchants, competitors, data brokers, researchers, advertisers, or analytics providers.
• We will never use one merchant's data to benefit another merchant, to generate competitive intelligence, to produce cross-merchant benchmarks, or to train models on identifiable data.
• Internal access is limited to personnel who require it to operate, maintain, or support the Service, is logged, and is subject to confidentiality obligations.

This commitment survives termination of the account.

F. Publicly Accessible Media

Images and files a merchant uploads to their media library are served from a public content domain so that they can be displayed inside email messages, which must be able to load them without authentication. Anyone who knows or guesses the URL of an uploaded file can retrieve it. Merchants should not upload confidential material, personal information, or anything they would not be willing to publish.

11. Sub-Processors

We publish the full list of our sub-processors in Schedule B, and we keep it current.

A. What We Require of Them

Every sub-processor is engaged under a written contract that requires it to:

• Process data only on our documented instructions
• Maintain confidentiality and security measures appropriate to the data
• Assist us in meeting our obligations to merchants and to data subjects
• Delete or return data at the end of the engagement
• Refrain from using the data for any purpose of its own

Where personal data leaves the EEA, the UK, or Switzerland, the engagement includes Standard Contractual Clauses or another approved transfer mechanism.

B. Changes to the List

We will give merchants at least 30 days' notice by email before a new sub-processor begins processing subscriber data, or before an existing one is replaced. A merchant who reasonably objects on data-protection grounds may raise the objection with us; if we cannot resolve it, the merchant may terminate the affected part of the Service without penalty.

C. Our Responsibility

We remain fully responsible to the merchant for the acts and omissions of every sub-processor we engage.

12. Shopify-Specific Data Handling

A. Access and Authorization

We access the merchant's store exclusively through Shopify's official Admin API, under the access scopes the merchant granted at installation and listed in Section 3.B. Installation uses Shopify's managed installation flow with token exchange. Access tokens are encrypted at rest and are never shared, exported, or used for any purpose beyond serving that merchant.

We comply with Shopify's API Terms of Service, Partner Program Agreement, Protected Customer Data requirements, and app store policies.

B. Protected Customer Data

Our use of Shopify Protected Customer Data is limited to providing the Service described in this statement. We collect the minimum fields required, retain them only as long as necessary, encrypt them in transit and at rest, and apply the access controls and audit logging described in Section 8.

C. Mandatory Compliance Webhooks

All three of Shopify's mandatory privacy webhooks are implemented, HMAC-verified, and acted upon:

• customers/data_request — We compile a report covering the profile we hold, its current consent status in each channel, its full event history, every message sent to it, any pauses applied, and — where a message contained a product block chosen for that individual — which products were selected for them, why, whether the message was actually sent, and what those products were at the moment of selection. The report is provided to the merchant, who — as the controller — delivers it to the customer. On request we supplement it with the consent evidence record, the engagement events, and the staged browsing events we also hold.

• customers/redact — We erase the customer. In a single transaction, we delete their event history, their staged browsing events and the record that linked that browsing to a checkout, their consent records and consent evidence, their pause records, their engagement events, the record of which products were selected for them in any message, the record of any automation that declined to enter them, any automation still running for them and any event waiting to start one, when they were next due to be messaged, their place in any export a merchant had asked us to prepare, their place in any batch of newly imported people waiting for their first email, any request they made to be told when something was back in stock and the record of how we answered it, their membership of every list they were on, any text messages they sent to the store, the record of when and why a text message to them was held back, the record that they had been sent the store's text message program terms, the count of recent marketing text messages held against their telephone number, any unfinished text-message sign-up they had started, including the code we texted them, and — once a facility to show an assistant an individual person's profile exists at all (Section 8.E) — the record of which days an assistant connected to the store was shown them; we unlink their visitor records; we overwrite the recipient address and subject line on every email previously sent to them, and the recipient number and the message itself on every text message; and we clear their name, email address, telephone number, custom properties, and Shopify identifier from their profile. Before erasing, we write an irreversible never-contact record, so the erased address can never be messaged again by that merchant. Any failure is retried until it succeeds and is escalated for manual intervention if it does not. One thing an erasure cannot reach is a file already written. An export of a merchant's audience is written once and never rewritten — rewriting it would make the record the merchant checked it against untrue — so where the erased person was in one, we retire that export immediately: the download stops working from that moment, and the files themselves are permanently deleted by the process that clears every export within 24 hours of it being asked for. A copy the merchant had already downloaded is in their hands, not ours. Two kinds of file an erasure does reach, and it reaches them the moment the records naming them are gone: any picture or recording the person sent to the store's telephone number is permanently deleted from storage immediately after their text messages are erased. What survives, and why: the record that a message was sent, that an audience was selected for a send, and that a discount code was issued to that audience — and, for a text message, the record that it was charged for and what it cost, with the delivery report's own copy of the number and the message cleared from it. These are records of what we did, not descriptions of the person — once the profile has been erased they carry no name, address, telephone number or Shopify identifier, only an internal identifier that no longer resolves to anyone. They are retained for the same reason the message ledger is: a merchant must be able to demonstrate what was sent and what was offered. Anything that is instead a statement about the person as they are now — their list memberships among them — is deleted. One further record survives, and it is the store’s own commerce record rather than ours: where an order was paid for with a discount code the store handed out, the record of that redemption — the act, the order it belongs to, and the amount — is kept, because it is part of what the store sold and of what the store’s own reports say about offers it has already made; an erasure that deleted it would silently rewrite the results of sends that had already happened. That record keeps the act, the order and the amount, and no longer carries the email address the order was placed under: the erasure clears it with the rest. One exception to the never-contact record, and only one (added September 23, 2026): when a merchant has deleted a person in the Service (Section 10.B), the store may send us this request afterwards for that same person — ordinarily our own deletion of the matching customer arriving back. Where it arrives within 30 days of a deletion that deliberately wrote no never-contact record for an email address, we do not write one for that address now either. Everything else in this paragraph applies to that request unchanged.

• shop/redact — We purge every record belonging to that store across the entire system, delete all associated media from object storage, deactivate all memberships, and delete staff user accounts belonging solely to that store. We carry this out when the 30-day period described in Section 9.D ends, which is inside the 30 days the platform allows us from the moment the request arrives, because that period is measured from the uninstallation and the request reaches us about two days after it. Where we hold a record of the store but not of when it left, we ask the platform once whether the store is still there. If the app has gone from it, the 30 days run from two days before the request arrived — the day the uninstallation we never received must have happened — so the period still ends inside the time the platform allows us. If the store answers, the merchant has returned and we treat the request as withdrawn by that return. If we cannot get an answer at all, we change nothing, the request stays open, and we try again — and where the attempts run out, a person takes it up — because acting on a guess here would mean deleting a store that never left. If the merchant has installed the app again by the time we would carry the request out, we treat it as withdrawn by their return, record that on the request itself, and the ordinary retention in Section 9.A applies again.

D. Uninstallation

The app/uninstalled webhook triggers the sequence described in Section 9.D.

13. Your Privacy Rights

This section concerns merchants and their staff users, for whom we are the controller. Rights of merchants' subscribers are addressed in Section 14.

A. GDPR and UK GDPR Rights

If you are in the European Economic Area, the United Kingdom, or Switzerland, you have the right to:

• Access — obtain a copy of the personal data we hold about you
• Rectification — correct inaccurate or incomplete data
• Erasure — request deletion, where no overriding obligation requires retention
• Restriction — limit how we process your data
• Portability — receive your data in a structured, commonly used, machine-readable format
• Object — object to processing based on legitimate interests
• Withdraw consent — at any time, where consent is the basis, without affecting prior processing
• Complain — lodge a complaint with your supervisory authority, or with the UK Information Commissioner's Office

B. United States State Privacy Rights

Residents of states with comprehensive privacy laws — listed in Schedule A — have rights that generally include:

• The right to know what personal information we collect, use, and disclose
• The right to access and to obtain a portable copy
• The right to correct inaccurate personal information
• The right to delete personal information
• The right to opt out of sale, sharing, targeted advertising, and certain profiling. We do not sell or share personal information, we do not use it for targeted advertising, and we do not profile anyone toward decisions producing legal or similarly significant effects. What a merchant's marketing message contains may be selected from the browsing and purchase activity that merchant already holds about that individual — which products to show them — and Section 2.F describes it. We will confirm any of this in writing on request.
• The right to limit the use of sensitive personal information. We do not collect sensitive personal information as defined by those laws.
• The right to non-discrimination for exercising any of these rights. We will never deny service, charge a different price, or provide a lesser quality of service because you exercised a privacy right.
• The right to appeal a denied request, where the applicable state law provides one. Our denial will explain how to appeal.

C. Canadian Rights

Under PIPEDA and, in Québec, under Law 25, you have the right to access your personal information, to request correction, to withdraw consent, to data portability, and to complain to the Office of the Privacy Commissioner of Canada or the Commission d'accès à l'information du Québec.

D. How to Exercise Your Rights

Write to … with "Privacy Rights Request" in the subject line, telling us what you are asking for and giving us enough information to verify your identity. We will not ask for more information than is necessary to do so.

We respond within 30 days, or within the shorter period any applicable law requires. Where a request is complex we may extend once, and we will tell you why before we do.

An authorized agent may submit a request on your behalf with proof of authorization.

14. Rights of Merchants' Subscribers

If you received an email or text message sent through Carpe Messaging and you want it to stop, or you want your information removed, the fastest route is the merchant who sent it.

A. Why We Direct You to the Merchant

The merchant chose to contact you, holds the relationship with you, and is the controller of your information. We are their processor. We cannot verify your identity against a store we do not operate, and answering your request directly would mean acting on a store's data without that store's instruction. So we route your request to the merchant and we assist them in answering it.

B. What You Can Do Immediately, Without Anyone's Help

• Email: use the unsubscribe link in any marketing message, or your mail client's own unsubscribe button. It takes effect immediately and permanently.
• Text message: reply STOP. It takes effect immediately and permanently. Reply HELP for the sender's identity and contact details.

Neither requires you to contact us or the merchant. Your opt-out is recorded immediately — it governs every message from the moment you act — and is written back to your record in that merchant's own store, with automatic retries until it lands. A merchant may not lawfully reverse it. If you believe a merchant has re-subscribed you without your permission, write to … and we will place you on a permanent never-contact record for that merchant, which no one can reverse.

C. If You Cannot Reach the Merchant

If you have tried and cannot reach the merchant, or you believe a merchant is ignoring your request or has contacted you without your consent, write to us at … (or … to report a message). We will:

1. Suppress you from that merchant's sending immediately, so that no further message can reach you while the matter is open.
2. Identify the merchant and require them to respond.
3. Where a merchant fails to honor a lawful request, act on it ourselves and take enforcement action against that merchant under our Terms of Service.

You do not need to prove anything to us to be suppressed. We will act first and investigate afterwards.

D. Shopify Customers

If you are a customer of a Shopify store, you may also exercise your rights through Shopify's own privacy mechanisms. Requests that reach us through Shopify's mandatory privacy webhooks are handled as described in Section 12.C.

15. International Data Transfers

The Service is operated from the United States, and all persistent data is stored there. If you or your subscribers are located elsewhere, information will be transferred to and processed in the United States.

A. Transfer Mechanisms

For transfers of personal data from the European Economic Area, the United Kingdom, or Switzerland to the United States, we rely on:

• Standard Contractual Clauses approved by the European Commission, together with the UK International Data Transfer Addendum where the UK GDPR applies
• Supplementary technical and organizational measures, including encryption in transit and at rest, application-level encryption of credentials, and strict access controls
• A transfer impact assessment, available to merchants on request

B. Sub-Processor Transfers

Every sub-processor engagement involving personal data leaving the EEA, UK, or Switzerland incorporates Standard Contractual Clauses or an equivalent approved mechanism.

C. Merchant Responsibilities

Merchants sending to recipients outside their own jurisdiction remain responsible for the lawfulness of that sending under the recipient's local law. Schedule A lists the regimes we recognize; it is not legal advice, and merchants should take their own.

16. Children's Privacy

The Service is a business tool and is not directed to children. We do not knowingly collect personal information from anyone under 18 in the operation of merchant accounts.

Merchants are prohibited by our Terms of Service from using the Service to send marketing messages to anyone under the age of 13, and from uploading to the Service personal information about anyone under 13. Merchants whose own customers may include minors are responsible for compliance with the Children's Online Privacy Protection Act and equivalent laws in their markets.

If you believe we hold information about a child under 13, write to … and we will delete it.

17. Changes to This Privacy Statement

We may update this statement to reflect changes in our practices, our sub-processors, or the law.

• Minor changes. We revise the "Last Updated" date at the top.
• Material changes. We notify registered merchants by email at least 30 days before the change takes effect.
• New sub-processors. We give at least 30 days' notice, as described in Section 11.B.

We keep prior versions of this statement and will provide any of them on request. Continued use of the Service after a change takes effect constitutes acceptance of the revised statement.

18. Contact Us

For questions, concerns, or requests regarding this Privacy Statement or our data practices:

Carpe Messaging
Operated by Carpe Per Diem, Inc.

Website: carpemessaging.com

Mailing Address:
Carpe Per Diem, Inc.
365 W 125th St, UNIT 2666
New York, NY 10027
United States

For GDPR requests: email … with "GDPR Request" in the subject line.
For US state privacy requests: email … with "Privacy Rights Request" in the subject line.
For a copy of our Data Processing Addendum or Standard Contractual Clauses: email ….

All requests are answered within 30 days, or sooner where the law requires.

Schedule A — Messaging and Privacy Laws We Recognize

We built Carpe Messaging to satisfy the strictest applicable standard rather than the most convenient one. The regimes below inform the design of the Service. This list is illustrative and not exhaustive; it describes laws we have taken into account, does not limit our obligations under any other law, and is not legal advice to merchants, who remain responsible for their own compliance and should take their own counsel.

A. United States — Messaging

B. United States — Privacy

The California Consumer Privacy Act as amended by the California Privacy Rights Act, together with the comprehensive state privacy laws now in effect in:

Virginia · Colorado · Connecticut · Utah · Texas · Oregon · Montana · Delaware · Iowa · Nebraska · New Hampshire · New Jersey · Tennessee · Minnesota · Maryland · Indiana · Kentucky · Rhode Island

We also account for the Florida Digital Bill of Rights, which imposes comparable obligations but applies only to businesses above a substantial revenue threshold.

We monitor laws enacted and not yet effective — Oklahoma and Louisiana (both January 1, 2027), Alabama (May 1, 2027), and Vermont (January 1, 2028) — and we track amendments to the laws above.

Related regimes we account for: the Children's Online Privacy Protection Act, Washington's My Health My Data Act and comparable consumer health data laws, and state data breach notification statutes.

C. Canada

D. European Economic Area and United Kingdom

E. Other Jurisdictions

F. Platform Requirements

We comply with Shopify's Partner Program Agreement, API Terms of Service, App Store Requirements, and Protected Customer Data requirements, and with the acceptable-use and anti-abuse policies of every provider listed in Schedule B.

Schedule B — Current Sub-Processors

Last reviewed: August 31, 2026. We give merchants at least 30 days' notice before adding or replacing any sub-processor that processes subscriber data (Section 11.B).

A. Message Delivery — Email

B. Message Delivery — Text Messages (engaged as text messaging is introduced)

Text messaging is being introduced to the Service. The providers below will carry it. No text message provider is processing subscriber data today, and we will give merchants at least 30 days' notice before any of them begins to, in accordance with Section 11.B.

One thing does reach the carrier before that: a merchant who chooses to start a carrier registration sends their own business identity with it (Section 2.A). That is the merchant's own information, given deliberately by the merchant, and it describes no subscriber.

C. Infrastructure

D. Specific Functions

E. Platform

F. Notes

• No sub-processor is permitted to use merchant or subscriber data for its own purposes, to train models on it, or to disclose it.
• No sub-processor receives subscriber personal information except where the table above says so. In particular, no analytics, advertising, or data-enrichment provider receives any subscriber data at any time, because we engage none.
• We do not use any error-monitoring, session-replay, product-analytics, advertising, or customer-data-platform service, and therefore none receives any data from us. The public website's cookieless page-view counts (Section 7.D) are provided by our hosting provider, run on no page of the application, and involve no merchant, team member, profile or subscriber data.
• Usebouncer's stated processing location is the European Union. Where that engagement involves a transfer, it is covered by the mechanisms in Section 15.
• An AI assistant a merchant connects is not on this list, and is not a sub-processor of ours (Section 8.E). It is the merchant's own tool, chosen by them and connected by one of their team members, and what it reads reaches its provider on the merchant's instruction rather than on ours. We neither select it nor engage it, so the notice period in Section 11.B does not apply to it; the bounds we place on what any such assistant can reach are in Section 8.E.

© 2026 Carpe Messaging. All rights reserved.

Carpe Messaging is a product of Carpe Per Diem, Inc.
Made with ❤️ in New York City, USA