Carpe Messaging Privacy Statement

Last Updated: November 7, 2026
Effective Date: November 7, 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 for ourselves, as those terms are defined under the CCPA/CPRA or any comparable state law, and we never have. As the merchant's processor, and only when the merchant connects their own Meta or Google advertising account and chooses an audience segment to send there, we send that account hashed identifiers for the people in that segment, on the merchant's instruction (Section 10.G). Where that transmission is a "share" under those laws, it is the merchant's, and the merchant decides whether to make it. (Amended October 14, 2026.)

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
• The store's public contact email — the address the merchant set in Shopify for customers to write to — read from Shopify and used only in the one automatic reply to a number with no profile (Section 9.B) (added October 8, 2026)
• 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
• The telephone number a merchant chooses for calls to their store's text-message number to be forwarded to (added October 5, 2026), entered in the store's text-message settings. It is sent to the text message carrier, which forwards the calls (Schedule B, Section B), and it is kept with the store's text-message record until the merchant clears it or the store is purged (Section 9.B). We receive and keep no record of the calls themselves

• We no longer accept reports of a merchant's past sending (withdrawn September 27, 2026). From September 26, 2026 a merchant could send such reports so that our team could decide whether the store's daily sending number could start higher; none was ever sent, and that door is closed. A store's daily sending number is now decided by the store's own sending record — the delivery history it imported from another email platform it connected (Section 3.E), and its own sends through the Service — and, because every store's email leaves through one shared sending account, by that account's overall bounce and spam-complaint rates, which include other stores' sends; no person at Carpe Messaging reviews or decides it

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.
• A team member's own mobile number for test texts (added October 13, 2026), entered by that team member when they choose to receive test copies of their store's text messages. To confirm it is theirs, the store's own text-message number sends it a six-digit code, which is stored only as a one-way keyed digest and only until it is used or expires ten minutes later. The number is used for nothing but test texts the store's team sends to it, and it is sent to the text message carrier with each one (Schedule B, Section B).
• An advertising account a team member connects (added October 14, 2026) (Section 10.G). When a team member signs in with Meta or Google to connect the store's advertising account, we receive an access credential for that account, the names and identifiers of the businesses and advertising accounts they choose from, the identifier Meta assigns to them for our app, and — for Meta only — the account's status and its last 30 days of totals (impressions, reach, clicks, spend and conversions), which we show on the connection's card. We use these only to send and keep current the audiences the merchant chooses, to tell the merchant when the account stops accepting them, and to show those totals. The credential is stored encrypted, is never shown to anyone, and is revoked and deleted when the account is disconnected or the app is uninstalled. We do not use any of it for advertising, do not share it, and do not use it to train any model.

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 birthday for a birthday offer, of which only the month and day are kept, never the year. (Amended October 14, 2026, to say that only the month and day of a birthday are kept.) A profile may also include its location — country, state or region, city and postal code — derived from the merchant's store records (the customer's default address in the merchant's Shopify store or, where there is none, the ship-to address of their latest order), from records the merchant imports, and, for country and region only, from onsite activity, so that a merchant can, for example, send to their customers in one state, and so that an advertising account the merchant connects can recognize the person (Section 10.G). Street addresses are not kept in profiles. (Amended October 14, 2026, to add the postal code.) The ship-to name and address of an order are kept in that order's events — the order placed, fulfilled and shipment events synchronized from the merchant's Shopify store, and the order history the merchant imports (Section 2.F) — so that a merchant can send a shipping notice to the address the order is going to, and they are erased with the person's other event history (Section 12.C). (Amended September 29, 2026.) The ship-to name and address a shopper enters at checkout are kept the same way, in that checkout's event, and erased the same way. Raw order webhooks from Shopify 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
• Every change to that status — from what, to what, by which source, and when — kept from the moment the history began to be kept for that store, which starts with where each person's consent then stood and who had last said so (added October 8, 2026)
• 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 and that history of changes are append-only (amended October 8, 2026): the database itself refuses any edit or deletion, so that a merchant can always demonstrate the origin of any recipient's permission. The exceptions are erasure — a data subject erasure request or a store purge removes it, as described in Sections 9 and 12 — and, for the history of changes alone, two records of the same customer being combined: the record folded into the other is removed with its history, and the consent it carried is recorded on the record that remains wherever it changes what that record holds (added October 8, 2026).

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 for marketing email, and clicks for all email, including the URL clicked and the user-agent of the requesting client (amended October 13, 2026)
• 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. When a person texts the store, we may quote their message in an email to the store's own team members who chose to be told, with their name and only the last four digits of their number; an image they sent is never put in that email (added October 8, 2026).

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

• Commerce events synchronized from the merchant's Shopify store: orders placed, products ordered, checkouts started, orders refunded, orders returned, and fulfillment progress including tracking numbers. (Amended September 28, 2026.) An order's events carry the order as Shopify sends it — its number, the items and quantities, the ship-to name and address, the shipping method, the carrier and tracking details, and its subtotal, shipping, tax, discounts and total. They never carry the billing address, payment details of any kind, or the shopper's browser, device or session details, which we remove before anything is stored — at every level of the order, including refunds and shipments, and however Shopify comes to name them. The same holds for order history a merchant imports from another email platform or reads back from their Shopify store: it carries the ship-to name and address and the order details too, and never the billing address, payment, browser, device or contact details. (Amended September 29, 2026.) The same rule covers checkouts and refunds. A checkout's event carries the checkout as Shopify sends it — the items, any discount codes entered, the ship-to name and address, the shipping method and its subtotal, shipping, tax, discounts and total — and the link that reopens the checkout once, so that the merchant's email can send the shopper back to it; it never carries the shopper's text-message consent or number, or the billing, payment, browser, device or contact details. A refund's event carries the refund — the items and quantities refunded, the amount, and the merchant's note — and never the payment it was returned to. A return's event carries the return — its status, the items and quantities returned and the reasons given, the note the shopper wrote when asking for it, any return shipping fee, and the reason the merchant gave for declining it — under the same rule.
• 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, the bot challenge and the server request logs described in Section 2.G (amended October 10, 2026, to add the server request logs).
• Discount codes issued to individuals and their redemption outcomes
• Which products a message selected for one individual, and whether it was sent. (Amended November 7, 2026.) 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 added to their cart, 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.

G. Technical and Service Data

• Server logs generated in the course of operating the Service. (Amended October 10, 2026.) Every request to the Service — including a storefront form's request, a signup, and the question a signed-in shopper's forms ask the store (Section 7.C) — writes a log line that records the requesting IP address, the address requested together with its query string (which can carry, for example, a signed-in customer's identifier, a browser's visitor identifier and the store's address), the browser's user agent, the time, and the response. Our hosting provider keeps these logs for 1 day. It also copies every log line to a log service, named in Schedule B, which keeps them for 30 days, so that we can investigate failures, abuse and security incidents. These logs are used to operate and secure the Service and for nothing else: they are not joined to any profile, not used to build a browsing record, and not used for analytics or advertising. Neither the uninstall purge nor an individual erasure request reaches them; they are deleted when those periods end (Section 9.B).
• 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 starts when the form is shown on the page, so that a person who asks is answered without waiting (amended October 28, 2026). 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 in a profile, beyond the seven-day raw-webhook retention described in Section 2.C (a profile's location — country, state or region, city and postal code — is kept, and an order's ship-to address is kept in that order's events; see Section 2.C) (amended October 14, 2026)
• 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, fulfillment events, and returns
• Products, variants, collections, and discounts, with any rollout a discount is part of
• Store domains and configuration, the store's online store pages, and the published theme's settings and files (read only)

(Amended October 7, 2026.) We request the following Shopify access scopes and no others, each for the purpose beside it:

write_customers is used for three purposes, all described in Section 10.B: to write a subscriber's consent change back to the merchant's store; to correct a customer's first or last name when a member of the merchant's team corrects it in the Service; and, since September 23, 2026, to delete a customer from the merchant's store at the merchant's direction — only as a result of the merchant deleting that person in the Service, and only when the customer has placed no order in that store. Where the merchant chose, when deleting, that the people deleted can never be contacted again, a customer with one of those addresses who later appears in the store is deleted there again, on the same condition (added October 7, 2026). 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
• Sending an audience segment, as hashed identifiers, to a Meta or Google advertising account the merchant connects, and keeping it current, when the merchant chooses to (Section 10.G) (added October 14, 2026)
• 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 — including a spam report recorded by an email platform a merchant imports from (added September 26, 2026) — when a subscriber is redacted under a legal erasure request (for text messages, until the person's own START, unless their text messages were already Suppressed, a complaint was on record, or the redaction was before October 30, 2026 — Section 12.C (amended October 30, 2026)), when an address is found invalid, or at the merchant's explicit direction.

Suppression is terminal, with one exception. It is enforced in the database itself, not in application logic a merchant could bypass. The one exception (added September 26, 2026): where an email address hard-bounced, the store’s owner — and no one else, never our team — may release it once, and only when the store itself later saw the mailbox in use: an order, a checkout, or a signup on one of the store’s own forms, dated after the bounce. A release restores what the store says now about the person’s email consent, or leaves them unsubscribed where the store holds no customer record for them; it never subscribes anyone. It is never available where the person has ever reported a message as spam, where the address was found invalid or was suppressed at the merchant’s direction, where the person was erased, or where the address carries a never-contact record. The owner must give a reason, which is kept with the record of the release, and the email provider’s own block on the address is lifted at the same time. An address can be released only once, ever: if it bounces again, it stays suppressed for good.

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 has its links rewritten for click tracking in the same way, and carries no open pixel. (Amended October 13, 2026.)

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). Visitor identity is Shopify's own first-party visitor identifier, which Shopify sets and controls. (Amended October 7, 2026.) The pixel sets one cookie of its own, _carpe_vid: a first-party analytics cookie on the merchant's storefront that carries that same store analytics visitor identifier to the Service's signup forms on that storefront. The forms use it for these things only: to recognize a returning visitor, so that the merchant's forms can choose what to show them and offer a one-tap back-in-stock request; to record which forms a visitor saw or closed; to join a signup to the browsing that came before it; and to limit how often one browser can submit a form. It holds nothing but that identifier and is set to last up to one year (some browsers, including Safari, keep it for less); if a browser clears it, the pixel writes Shopify's same identifier back on a later page. It is set only while the visitor allows analytics and marketing cookies and has not opted out of the sale or sharing of their data; while it is withheld, the forms send no visitor identifier at all. (Amended October 8, 2026.) When the visitor withdraws that permission or opts out, the pixel removes the cookie if it runs on that page; otherwise the Service's signup forms remove it on the next page that shows one of them, and until then it stays in the visitor's browser. 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.

(Added October 9, 2026.) A shopper signed in to the merchant's store. When a shopper is signed in to the store with a customer account, the Service's signup forms on that storefront ask the store which customer is signed in. Shopify answers on the store's own behalf: it adds the signed-in customer's identifier to the question and signs it, so the answer is the store's and not the browser's. What comes back to the forms is a sealed string that names the matching profile without revealing it, works only for the browser that asked, and expires after thirty minutes. The forms use it for three things only: to decide which of the merchant's forms that shopper sees, under the merchant's own rules; to let a link the store already made between that browser and that same customer — at checkout or on a form — carry their recognition to a later step of a form and to the shorter back-in-stock request; and (added October 10, 2026), when the shopper submits a form with the email address their own profile carries, to record that signup as theirs and link that browser to their profile, so a later step of the form saves to it. While a shopper is signed in, that recognition is never carried from a link the browser has to anybody else, and when the store cannot say who is signed in, it is not carried from any link. The Service keeps no record of the question; like every request, it appears in our server logs (Section 2.G), carrying the signed-in customer's identifier and the browser's visitor identifier. The forms ask only under the same permission as the cookie above: while the visitor has not allowed analytics and marketing cookies, or has opted out of the sale or sharing of their data, they do not ask. (Added October 10, 2026.) The boxes a signed-in shopper finds filled in. For a shopper signed in to the store, the storefront page Shopify renders for that shopper carries their own email address, first name and last name, and the forms put them into the matching boxes. Their telephone number is never written into the page or filled into a form. That happens in the shopper's browser from the store's own page: nothing is sent to the Service, and nothing is recorded, until the shopper changes what they like and submits the form.

(Added November 6, 2026.) A shopper who signs up on a form. When a shopper submits one of the merchant's signup forms with an email address or telephone number, or asks with their email address to be told when a product is back in stock, that browser's visitor record is linked to the profile it belongs to, whether a new profile or one the store already has, the same way an email address typed at checkout links it. Their browsing on the store before and after is then recorded to that profile, and the merchant's form rules apply to them. The record notes when that link was made. A link made this way never shows that browser anything already on the profile and never lets a form change what the profile already holds, unless the shopper is signed in to the store with that address or confirms a code sent to a telephone number the profile already had.

(Added November 6, 2026.) The boxes a shopper finds filled in after signing up. The forms keep, in the shopper's own browser (the store site's local storage), the email address and first name typed into their most recent signup or back-in-stock request, so a later form can fill those boxes in. We keep no copy. The browser sends us only a code computed from the store, its visitor identifier, the time of that signup and the profile it was then linked to; it contains nothing the shopper typed. We answer only whether the browser has since been identified as somebody else, and if it has, the browser deletes what it kept. It is kept only under the same permission as the cookie above and removed when that permission is withdrawn. It has no time limit, and clearing the site's data in the browser removes it.

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, apart from the video player on our homepage described below. 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. (Added October 10, 2026.) Our server keeps its own request logs, with our hosting provider and a log service named in Schedule B, to operate and secure the Service (Section 2.G); they are not analytics, and nothing runs in a visitor's browser to make them.

(Added October 19, 2026.) The video on our homepage. Our homepage carries a video hosted on YouTube, a service of Google LLC, in YouTube's privacy-enhanced mode. The player loads with the page, so YouTube receives each visitor's IP address and information about their browser. If a visitor plays the video, YouTube may also store information in their browser, under Google's own privacy policy. No merchant, team member, profile or subscriber data is involved, and YouTube is not a sub-processor of ours.

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

We do not sell or share personal information for ourselves and do not engage in cross-context behavioral advertising of our own, so there is no sale or sharing of ours for a Global Privacy Control signal to opt out of. A merchant who sends an audience segment to their own advertising account (Section 10.G) makes that decision as controller. When the merchant's Shopify store records that a person has opted out of the sale or sharing of their data, we never send that person to any advertising account, and we remove them from any audience they were already in. We honor opt-out preference signals where a state law requires it. Merchants remain responsible for honoring such signals on their own storefronts, and for recording there, or excluding from what they send, any other request not to use a person's information for advertising. (Amended October 14, 2026.)

8. Data Storage and Security

A. Where Data Is Stored

All persistent data is stored in the United States, in managed PostgreSQL infrastructure, in object storage and, for server request logs, at a log service (added October 10, 2026), operated by the providers listed in Schedule B. Two providers keep limited copies under their own retention, as Schedule B describes: our address-check provider processes the addresses it checks in the European Union and keeps them for a limited period, and our bot-challenge provider keeps the signals it receives under its own terms. (Added October 22, 2026.) 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, which flags actions that may touch customer data. (Amended October 28, 2026.)

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 of an actual or suspected breach without undue delay and within 24 hours of becoming aware of it, so that merchants — as controllers of their subscribers' data — can meet their own notification obligations. (Amended October 1, 2026.)
• 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. A merchant's own assistant is not a sub-processor of ours, so the notice in Section 11.B 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, where the store had once released that address from “Do not email” after a bounce, a one-way keyed digest of it with which team member released it and when, so that the address can be released only once, ever (Section 9.B) (amended September 26, 2026); and, where the store once sent its one automatic reply to a number of theirs before any profile carried it, a one-way keyed hash of that number with the time of the reply, so that the number is never answered twice (Section 9.B) (added October 8, 2026); and, where the erasure is the echo of the merchant’s own deletion of that person, the one-way coded form of their email address that keeps a later import from another email platform from bringing them back (“Profiles a merchant deleted”, Section 9.B) (added October 28, 2026) — 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, was already on the never-contact record, or had a spam complaint on record (amended October 30, 2026); 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. The person's own new consent is the one exception (added October 30, 2026): a START texted to the store from a telephone number that carries such a record removes the record for that number (Section 12.C), whether or not any profile still carries that number, unless the merchant chose to make it permanent, the record was written before October 30, 2026, or, when the person was erased or deleted, their text messages were Suppressed or a complaint was on record. 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, and the record of what each store was billed through Shopify for its plan and usage — how many of each kind of message or check were counted, when, and our own reference for each report we sent, 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 for ourselves 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. None of them is a sale or a share of ours; Section 10.G describes the one disclosure a merchant may direct to their own advertising account, and why that decision is the merchant's. (Amended October 14, 2026.)

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 three ways, all described below: consent changes; a name correction made by the merchant's team; and — at the merchant's direction — deleting a customer. (Amended October 7, 2026.) Beyond customer records, we write to the store only as the scope table in Section 3.B describes: the Service's web pixel, day-dated copies of a discount the merchant chose and the codes under them, the text sign-up page the merchant asks for, and the list of the merchant's published embedded forms.

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.

Correcting a name (added October 7, 2026). When a member of the merchant's team corrects a person's first or last name in the Service and that person is a customer in the store, we write the corrected name to the store too, so the store's next update of that customer does not put the old name back. We write the two name fields and nothing else. An email address cannot be corrected this way, and a store customer's telephone number is changed by the merchant in the store, never by us.

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. And if it arrives as a customer in the merchant's Shopify store, we delete that customer there again, under the same order check described next, trying at most once a day; a customer the Service still holds as somebody else is left alone (added October 7, 2026). 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. The one exception is the merchant's own instruction: hashed identifiers sent to an advertising account the merchant connects and chooses to send to (Section 10.G). (Amended October 14, 2026.)
• 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, and is subject to confidentiality obligations. Some actions taken in the Service are recorded in an audit log, among them a change to a person's name or telephone number, the deletion of a person, an export of a store's audience, an erasure or data request received from Shopify, a change to a store's team, and each visit our staff make into a store to help, with its stated reason and the requests made during it. (Amended October 1, 2026; October 28, 2026.)

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 and, when a merchant attaches one to a text message, delivered by the text-message provider and the phone companies. Both must be able to load them without authentication. (Amended October 14, 2026.) 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.

G. An Advertising Account the Merchant Connects

(Added October 14, 2026.) A merchant's team member may connect the store's own Meta advertising account (for Facebook and Instagram) or Google advertising account, and choose audience segments to send to it — to show ads to those people, or to keep ads away from them. These are the merchant's own advertising providers, chosen by the merchant and governed by the merchant's own terms with them; they are not sub-processors of ours. Nothing is sent unless a team member connects an account and chooses a segment.

What is sent. For each person in a chosen segment: their email address, telephone number, first and last name, city, state, postal code and country — normalized and, except where the provider requires a postal code or country to be sent as written, converted to a one-way hash before it leaves our systems — and nothing else: no consent record, no message or browsing history, no order, and not the segment's name. The provider uses them only to find matching accounts on its own service, under its own terms with the merchant.

Who is never sent. A person who has been erased or deleted; a person whose identity we have not verified; a person whose record in the merchant's Shopify store says they opted out of the sale or sharing of their data; a person who has complained about the merchant's email, to any audience meant to show them ads; and anyone who appears to be in the European Economic Area, the United Kingdom or Switzerland — judged from the country on their profile, the country of their telephone number, or the country of their email address's domain. This feature is not offered to a store located in those places.

How it stays current. About once an hour we add people who joined the segment and remove people who left it, were erased, or opted out. To be able to remove someone, we keep the hashes we last sent for them, for the periods in Section 9.B.

Ending it. A merchant may stop sending a segment, or disconnect the account, at any time; we then stop all updates, revoke our access, and delete the hashes we kept. People already sent remain in the audience in the merchant's advertising account until the merchant deletes it there. Uninstalling the app does the same.

The merchant's responsibility. As controller, the merchant decides whether to send anyone, and is responsible for a lawful basis; for telling the people in their audience, in the merchant's own privacy notice, that their information may be shared with advertising providers — which those providers' own terms also require; and for honoring a person's request not to be used for advertising, by recording it in their Shopify store or by excluding the person from what they send.

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 tell merchants before a new sub-processor begins processing subscriber data, or before an existing one is replaced, and give them a reasonable time to object.

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 each profile we hold for that person (amended October 2, 2026), its current consent status in each channel, every change to that status that we hold (added October 8, 2026), its full event history, every message sent to it, any pauses applied, any release of their address from “Do not email” and the reason the store gave (added September 26, 2026), the one automatic reply the store sent to a telephone number of theirs before any profile carried it (added October 8, 2026), 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. (Added September 26, 2026.)

• 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, the history of changes to them (added October 8, 2026) and consent evidence, their pause records, the reason the store gave for any release of their address from “Do not email” and everything else that record said about them — keeping only a one-way keyed digest of the address, with which team member released it and when, so that an address can be released only once, ever (Section 9.B) (amended September 26, 2026) — 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, whether an offer from a form was given to their email address or telephone number, and any telephone number of theirs waiting to rejoin a store’s text messages (added October 8, 2026), any reply to them that was held for their quiet hours to end (waiting, or already settled), the record of whether a text from them was answered or marked done, and by which team member (added October 8, 2026), the store's decision about whether their email address looked like a mistyped copy of another (added September 27, 2026) — where it was instead another record's address that looked like a mistyped copy of theirs, that decision survives, as internal identifiers only, because it is what keeps the other address from being emailed —, 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 that merchant cannot message the erased address again — with one exception, for text messages (added October 30, 2026): if the person later texts START to the store from a telephone number we erased, that is their own new consent, and we remove the never-contact record for that number. A START does not remove a record the merchant chose to make permanent when deleting a person, nor one written when the person's text messages were Suppressed or a complaint was on record, nor one written before October 30, 2026 (Sections 5.B and 10.B). 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 for ourselves, we do not use it for targeted advertising of our own, and we do not profile anyone toward decisions producing legal or similarly significant effects. A merchant may send an audience segment to their own advertising account (Section 10.G). An opt-out of sale or sharing recorded in the merchant's Shopify store is honored automatically; any other request not to be used for advertising is a request to the merchant, who honors it by recording it in their store or by excluding the person from what they send. 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. (Amended October 14, 2026.)
• 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 our own persistent data is stored there, apart from the limited copies two providers keep under their own retention (Section 8.A). 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.

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: October 28, 2026.

A. Message Delivery — Email

B. Message Delivery — Text Messages

(Amended October 5 and October 7, 2026.) The provider below carries the Service's text messages. It delivers the messages a store sends, receives the replies people send back, including STOP and HELP, and returns delivery receipts; and, for a store that sets a number for calls to be forwarded to, it connects each call made to the store's text-message number to that number. What it handles is the recipient's or caller's telephone number, the content of each message, the time of each call, delivery receipts and inbound keywords, together with the merchant's own registration identity and forwarding number described below.

Two things reach the carrier from the merchant rather than from a subscriber. 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. And a merchant who sets a number for calls to be forwarded to sends that number to the carrier (Section 2.A), and from then on the carrier forwards each call to the store's text-message number to it — so the carrier handles the calling number and the time of each call from anyone who rings that number, as any telephone carrier does to connect a call. We receive and keep no record of those calls; the forwarding number itself is kept with the store's text-message record until the merchant clears it or the store is purged.

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 of ours receives any subscriber data at any time, because we engage none. A Meta or Google advertising account that a merchant connects is the merchant's own provider, like the merchant's Shopify store (Section E), and receives only what Section 10.G describes, on the merchant's instruction. (Amended October 14, 2026.)
• 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. (Added October 10, 2026.) We do use a log service, named in Section C: our hosting provider copies the Service's server request logs to it, and it keeps them for 30 days so that we can investigate failures, abuse and security incidents (Section 2.G). No code of that service runs on any page or in any visitor's browser, and the logs are used for nothing else. 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.
• Bouncer Sp. z o.o.'s (name corrected October 22, 2026) 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