Privacy Policy

Operator: PalomaFinTech LLC, a limited liability company doing business as PalomaCEO.ai (“Paloma”, “we”, “us”). Postal address: 2590 Hollywood Blvd, Hollywood, FL 33020, United States. Contact: privacy@palomaceo.ai. Effective September 5, 2026. Last updated October 22, 2026.

1. Who this policy is for

Paloma is sold to businesses. This policy covers three groups: merchants who install Paloma (including from the Clover App Market), people who work at those merchants and use the app, and callers and customers whose calls, messages, orders and table bookings Paloma handles on the merchant's behalf, including guests who sign in on a merchant's ordering page. Section 2 also says what we receive about the couriers who deliver orders placed with Paloma, and for how long we keep it.

For merchant business data, caller and customer data, and the guest accounts of a merchant's ordering page we act as a processor (service provider): the merchant decides what happens to it, and we act on the merchant's instructions. For the accounts of the people who sign in to our app, and for the requests, feedback and chats with the assistant that people send us from this website or the app (section 4), we act as a controller.

2. What we process on behalf of merchants

Point-of-sale data obtained through the Clover APIs, the Square APIs or the PalomaPOS Platform API with the merchant's authorization: business profile, locations, hours, order types and tax rates; catalog items, prices, modifiers and stock; orders, line items and refunds; payment metadata (amount, status, tender type and, for Square, the card brand — never card numbers; for a business that runs rewards, also the card reference described under the business's rewards below, held only in memory); customers, including their name, phone number and email address; employees and shifts. From PalomaPOS we only read, and only this: the account and its locations (name, address, phone number, opening hours and time zone); the catalog, menus, stop list and links to item pictures; orders with their lines and notes, their payments and refunds with the amount and payment type, and the phone number of the guest on an order; customers (name, phone number and email address); and employees (name and position). It is stored in that merchant's own database.
A menu kept in Paloma and its orders: for a business that keeps its menu in Paloma instead of connecting Clover or Square, the menu its owner and managers give the assistant — items, prices, descriptions, categories, options, which items are sold out, taxed or age-restricted, and the sales tax rate of each location — and the orders guests place from it, with the items, notes, pickup time, total and tax, how the order is paid and what the guest gave for it, such as their name and phone number. This menu comes from the merchant, not from a point-of-sale system, and its orders are kept only in that merchant's own database: we send them to no point-of-sale system. To start the menu, an owner or manager may attach a photo of the menu in the conversation, or give the assistant the address of a page of the business's own website: our server then reads that page — and, if the menu is on another page of the same site, that page — as a browser would, at most 20 pages a day for a business. The language model reads the photo or the page's text to propose the menu on a card; that text is kept only as part of the conversation (below), and nothing from it becomes the menu until an owner or manager approves the card.
Calls: audio recordings (with any message the caller left when the business's phone was not answered, section 3), transcripts, the summary card of what the caller wanted and what the assistant did, the caller's phone number, and the language of the conversation. With each call's card we also keep a one-way keyed code of the caller's number, made with a secret key of that business, which cannot be turned back into the number; it is used only to recognise that an order placed later from the same number followed a call, and the number itself is not stored anywhere new for this. When someone at the business marks a call as handled, we keep whether they called the caller back, the caller became a customer, or no action was needed. When the phone network tells us that a call was forwarded to the Paloma number from another line — usually the business’s own — the assistant uses that during the call only to confirm that the business’s forwarding works and to avoid passing the caller back to the line that forwarded them; we keep only the time the first forwarded call arrived, never the number it was forwarded from. When the phone network hides the caller's number and the caller says a number for the payment link, we count the links texted to numbers given that way — by a keyed code of the number made with a secret key of our platform, never the number — so that only a few such links a day go to one number, across all businesses on Paloma, and from one business; once that day's limit is reached, no link is texted and the order is paid at pickup. These counts are deleted by a daily cleanup once three days have passed.
Messages: text messages about a guest's own order — the payment link, confirmations, courier and delivery updates and refund notices — the pickup deadline of an item a store holds at a guest's request, the confirmation of a table a guest booked with a link to cancel it and a notice if the booking is cancelled, the answer to a catering request a guest sent — confirmed with a link to pay for it, declined, or not confirmed in time — and the one-time sign-in codes a guest asks for, each with the number it went to; and opt-out records: the number, when, and whether the guest asked by text (STOP or other words) or a business recorded the guest's request (below). Replies to our texts: when a guest replies to one of these texts with anything other than STOP, START, HELP or another request to stop the texts, we pass the reply to the business that texted that number about an order, a catering request, an item hold or a table booking in the last 72 hours (sign-in codes and texts to a business's own alert number do not count); when more than one business did, only to the one whose latest text came at least two hours after the latest text of every other, and otherwise to no business. The reply is kept in that business's own database as a card in its Inbox: the words of each message (up to 1,000 characters), when it came, how many pictures came with it, the last four digits of the number, the whole number encrypted with a key of our platform (never shown to anyone, and used only to stop texts to it, below) and the order the text was about. Only the business's owners and managers can read the words, in the Inbox; everyone on its team who has these notifications on gets a notification that a guest replied, with the order number and without the words or the number. Pictures are counted, never retrieved or shown. To know which business texted a number, we keep, for each such text, a keyed code of the number made with a secret key of our platform — never the number or the words — with the business, the order, the location, the language and when the text was sent, for 72 hours. Paloma does not answer these replies, does nothing on its own because of them, does not give them to an AI model, and does not watch for them as they arrive: a guest with something urgent should call the business. If a reply asks not to be texted in words Paloma did not recognize as a request to stop, an owner or manager of that business can record the request from the card: the number goes into our opt-out records, as if the guest had replied STOP, and gets no more texts from any business that uses Paloma, payment links and sign-in codes included. Only the guest can turn texts back on, by replying START; the business cannot. The guest gets no text about it. Messages to the business's team: when the owner connects the team's own Telegram group, a message about each new order goes to that group through Telegram, and a follow-up about an order that needs the team — for example, one the point-of-sale system did not take, so that the team calls the guest back — the order number, whether it is for pickup, delivery or from a marketplace, the time it is due, the items, the total and whether it is paid, the guest's first name and note, and a link to the order's page for the team. It never contains the guest's phone number, surname or address. When a table is booked or cancelled, the group gets one line: how many guests, the day and time, whether it was booked on the booking page, by phone or in the app, and, for a business with more than one location, which one — never the guest's name, phone number or request. When a guest sends a catering request, the group gets one line: the day and time, the food total and, for a business with more than one location, which one — never the guest's name, phone number or note. Texts to the business's alert number: when the owner sets a mobile number in the app to be texted when an order needs a person, we text that number about such an order — for example, an order that did not reach the point-of-sale system or was not printed, an order with age-restricted items, or a courier that could not be booked, costs more than on the order, was cancelled, or does not appear at the delivery company. The text names the order and, where the business needs them to act, the guest's name as given and the delivery address; it never contains the guest's phone number.
WhatsApp messages: when the owner connects the business's own WhatsApp Business number — the number it keeps using in the WhatsApp Business app on its phone — we receive, through Meta's WhatsApp Business Platform, the messages guests send to that number from the moment of connection: the words; who wrote — the guest's WhatsApp number and the ID WhatsApp assigns that guest for this business only (a guest who uses a WhatsApp username may reach the business by that ID alone, with the number hidden from the business and from us; we never read or keep the username); the profile name the guest set in WhatsApp; when it was sent, and whether it carried a picture, a voice message or another file; the replies the business sends from the WhatsApp Business app, so that Paloma knows a person has already answered; and whether each reply was delivered and read. We keep them in that business's own database as conversations in its Inbox, one for each guest; on the way there, a working copy is held in our job queue for at most a day. Numbers that look like a payment card number are removed from a guest's message before it is kept or read by a model. Pictures and voice messages are not copied to our storage: when an owner or manager opens one, our server fetches it from WhatsApp for that moment; voice messages are not transcribed. For each new message from a guest, our language model provider (section 10) drafts a reply from the business's own information — its menu and prices, opening hours, address and ordering page, and the status of an order placed from that same number (none when WhatsApp hides the guest's number) — and the draft is a card in the Inbox. Nothing is sent to the guest until an owner or manager approves the card, and they can change the words first. Only the business's owners and managers can read these conversations and their reply cards, and only in the app: not other staff, and not an AI tool or software the business connects with an API key. Paloma never sends a WhatsApp message by itself, never writes to a guest first, and replies only within the 24 hours WhatsApp allows after the guest's last message. A guest's WhatsApp messages, number, WhatsApp ID and profile name are not added to the business's guest list or its point-of-sale customers, are not used to build profiles of guests or for marketing, and are not passed to the team's Telegram group, our texts or emails, marketplaces, couriers or social platforms; a notification about a new message carries only the business's name and a fixed line. We do not bring in the business's earlier chats or the contacts in its WhatsApp Business app: WhatsApp requires the app that connects a number to start a one-time synchronisation of them within 24 hours, or the connection ends, so Paloma starts it, and discards what arrives without storing it, writing it to our logs or showing it to anyone or to any model; old chats and contacts stay only in the business's app. To start the connection, we fill in Meta's sign-up window with the business's own details — its name; the business's email address from its point-of-sale system or, if it has none, the confirmed email address of the person who added the business; its own website or its ordering page; and the address, phone number and time zone of its location — which the owner can change in that window before going on; no guest data is sent for it. The access Meta gives Paloma for the number is kept encrypted and lasts 60 days; a week before it ends we remind the owner in the app to connect again, and when it ends, guests' new messages still reach the Inbox, but Paloma drafts and sends nothing until the owner connects again. While a business is asked to be deleted — including when its last point-of-sale connection is removed — its WhatsApp connection is paused: Paloma does not take in guests' new messages, which reach only the WhatsApp Business app, and drafts and sends nothing; if the business is restored or its point of sale reconnected within the 30 days, the connection resumes as it was, without the messages from the pause, and once the business is deleted we take our app off the number and delete our access. Disconnecting WhatsApp in the app stops receiving and sending at once and deletes our access; the number, its account at Meta and the WhatsApp Business app on the phone stay as they are, and the business can also disconnect in the WhatsApp Business app (Settings → Account → Business Platform). WhatsApp itself carries these messages under the business's own agreement with Meta and the guest's own agreement with WhatsApp. When a business is marked as a healthcare practice whose calls Paloma does not take (sections 2 and 8), we keep none of the WhatsApp messages sent to or from its number — no words, numbers, names or conversations — and draft no replies: Meta's notice of each message is acknowledged and discarded after at most a day in our job queue, and the business reads and answers them only in its WhatsApp Business app.
Marketplace and delivery orders: orders from marketplaces the merchant connects through OrderOut (such as Uber Eats, DoorDash and Grubhub), including the customer's name and phone number; and, when a courier is booked for an order placed with Paloma, the order as the customer placed it — its items with their options and notes, its amounts and the courier tip — with the customer's name, phone number, delivery address and delivery instructions. We book that courier through OrderOut or through a delivery dispatch service — Cartwheel or First Delivery. To show a delivery price before the order is placed, Cartwheel or First Delivery receives only the pickup location and the delivery address. OrderOut receives the whole order and passes what a driver needs to deliver it — such as the customer's name, phone number, delivery address and delivery instructions — to the delivery company that takes the delivery (for example Grubhub, DoorDash, Uber or Relay). Cartwheel and First Delivery receive only what a courier needs: the business's name and the pickup location's address, phone number and pickup instructions; the customer's first name, phone number, delivery address and delivery instructions, and whether to leave the order at the door; the order's amount before tax, fees and tip; and the courier tip — never the order's items, the customer's email address or payment details. Cartwheel passes the delivery to a delivery company with which Paloma has its own agreement — Uber (Uber Direct) or DoorDash (DoorDash Drive) — and that company gets from Cartwheel what its driver needs. First Delivery passes the delivery to a delivery company in its network — such as Uber, DoorDash or Relay — and that company gets from First Delivery what its driver needs. The delivery company may text or call the customer about that delivery, and handles this information under its own terms and privacy policy. First Delivery's own texts to customers are turned off for our account: it does not text or call the customer for us. If the delivery company finds no driver, the business may have that courier called off and the delivery booked with the next delivery company, which then receives the same details. While the courier of such an order is on the way, we read the delivery's progress from OrderOut about every 30 seconds, or receive it from Cartwheel or First Delivery as it changes and check it about once a minute — the stage, the delivery company, the driver's name as that company shows it (for example, a first name and an initial), the kind of vehicle, the driver's latest positions, the points on the map of the restaurant and of the delivery address, and the expected pickup and delivery times — and show them to the guest on the page of that order, drawn by our own page, on a map made from OpenStreetMap data that we keep on our own servers: the guest's browser does not contact OrderOut, Cartwheel, First Delivery, the delivery company or any map service for it. The business's own staff see, on its order tablet and on the order's page for the team, the stage, the delivery company, the driver's name and kind of vehicle as that company gives them, the expected pickup and delivery times, how far the driver is from the restaurant or, after pickup, from the guest, in straight-line miles, and how long the delivery company has been looking for a driver — never the driver's positions on a map; in the business's app, on the order's page for the team and on the order tablet, its staff can also open the delivery company's own tracking page for that delivery (inside our page, while the courier is on the order, where that company allows it; otherwise on that company's site), which their browser loads from that company directly, without our address as the referrer, and which may show the driver on that company's map; for a delivery booked through Cartwheel or First Delivery, the order's page for the team also links to that service's tracking page for that delivery. When the delivery company has found no driver ten minutes after the courier was called, the business's owners and managers get a notification and its Telegram group, if connected, gets a line — the order number, the delivery company and the minutes, with no guest details. We never keep or use the driver's phone number, and of what Cartwheel sends we also never keep the driver's photo, the number and code for calling the driver, or a photo, signature or identity-document details taken at the door, and of what First Delivery sends, the photo taken at the door or the name of whoever cancelled the delivery. The driver's name, vehicle and positions and the two points are removed from the order once the delivery ends — delivered, cancelled or booked again — and in any case within about half an hour after the last reading (section 11).
The business's order tablet: an owner or manager can connect a tablet or other device as the business's order screen, with a code from the app that works once and for 15 minutes. The device then keeps a random key in a cookie (paloma_tablet) that our server reads only on the order screen's own addresses, and that opens nothing else: no account, conversation, settings, menu editing or money. We keep only a one-way hash of the code and of the key, the device's name, who connected it and when, when it last reached our server (at most once a minute), and when it was disconnected. The screen shows the business's orders of the last 12 hours and those placed for a later time, from 12 hours before that time until 12 hours after it — the items with their options and notes, the guest's note, the guest's first name on orders placed with Paloma, the total and whether it is paid, where the order came from (the website, a phone call, a guest's AI assistant, the team or a marketplace), and the courier's progress described above — and lets whoever is at it accept an order, mark it ready, pause or call the courier, ask to cancel it and mark items sold out. The guest's phone number and address — and the delivery company's tracking page of the order, which shows them — appear only after someone taps “Show contacts”; each such tap is written to the account security log with the device and a one-way code of its browser's user agent, and so is each order accepted or marked ready there, with the device; the other buttons are recorded in the business's log of actions, as when they are pressed in the app. When a new order is not accepted on the screen within three minutes, the business's owners and managers get a notification and its Telegram group, if connected, gets a line — the order number only, with no guest details. So that a new order is heard while the screen is minimised or closed, the screen asks its browser for permission to show notifications at the first tap on it, never when it opens; once that is allowed, we keep with the device the push subscription its browser issues — the address at the browser's push service and its encryption keys — and, for each new order, send it one notification with the business's name, “New order”, the order number and the marketplace the order came from, if any — never the guest's name, phone number or address, the items or the amount — encrypted for the device and delivered through the push service of its browser (see Sub-processors). We delete the subscription when the device is disconnected, when the push service reports that it no longer exists or refuses five sends in a row, and with the business; notifications can be turned off at any time in the device's settings. Disconnecting the device in the app stops its key at once; the cookie is needed for the screen to work and is not used for analytics or advertising.
Content the merchant gives the assistant: knowledge base entries, assistant settings, approval decisions, and images attached in a conversation. When the owner or a manager tells the assistant how the business makes money — whether guests order, customers book a time, or the business wins jobs from requests — what a new customer is worth to it, how many customers it can take in a week, and what it wants most now, we keep these only in that business’s own database and use them only in what the assistant tells and proposes to that business, such as how many customers it won and, when a value was given, what they are worth. When the owner or a manager tells the assistant that the business is a healthcare practice, we keep that mark, with who said it and when, in the same database, and use it only to keep the business’s calls away from Paloma; it is a fact about the business, not about any patient. When an owner or manager asks for an illustration of a menu item, or of an option guests choose for it (such as a topping or a milk), and attaches a picture as a sample of how it should look — a picture of the item itself, or of the style they want for the items they name — or asks for the style of a picture already on another of the business’s items (a photo the business added or a drawing we made, never an Open Food Facts photo), that picture goes, with their words about the look, to the image provider that draws it (section 10); we first re-encode it so that it carries no metadata, such as where or with what camera it was taken. If people are in the picture, we ask the provider never to draw a person’s face, and we derive no face geometry or other biometric data from it; a picture with a stock-photo watermark over it is not sent. An owner or manager may also write the web address of a picture in their own message and ask for it on a menu item, on the business’s website or in a post: our server then downloads that one file, as a browser would but without cookies or sign-in, and keeps a copy with the pictures attached in the conversation; pages and posts show only our copy, never the address. We download only an address the person wrote in their message — the assistant never looks for pictures on the internet by itself — and the site that holds the picture sees a request from our server, not who asked. We do not copy a file whose own record names a photo agency, or anyone other than the business or the person who asked, as its author or rights holder.
Conversations with the assistant in the app: the messages in each thread, the assistant's replies, the results of the tools it used to answer, and a short summary of earlier turns in a long thread. A thread is shown in the app only to the person who started it; the business owner's data export includes every thread of the business. When a user sends a thumb down on an answer, a copy of that answer and of the question it replied to goes to our team (section 4).
What the assistant notices and does: notes the assistant writes from the business's own data — for example low stock, an unusual sales day, a call still waiting for a person, or a payment link that expired — which may include the last four digits of a caller's or customer's phone number; and a log of the assistant's actions, each kept as a one-line summary.
Visits to the merchant's ordering page: without cookies for analytics, we count page views, searches, items opened and added to the cart, checkouts and orders, the device type (phone, tablet or desktop), where the visit came from (a campaign tag, a QR code or the referring website), the language the page was shown in, the visitor's preferred browser language as a language code only (such as "es"), whether the guest was offered and followed the page's language suggestion, and whether the guest asked for delivery where the business does not offer it, whether a visit came from the business's app on the Home Screen, and, where the browser reports it (Android), that the app was added. A visitor is identified only by a hash of a server secret, the IP address and the browser's user agent that changes every day, so a visit cannot be linked to the same person on another day and the IP address is not stored. A language choice the guest makes is remembered in the pl_lang cookie; the only other cookie an ordering page sets is pl_guest, and only after a guest signs in (see guest accounts below). The same counting covers every page of the merchant's site, not only the menu: which page a visit happened on is recorded, and nothing more about the visitor is.
Table bookings: when a business takes table bookings, a guest can book a table on the business's booking page, by phone with its assistant, or by asking the business, whose owner or manager then books it in the app. For each booking we keep, in the business's own database: the guest's first name and mobile number (on a call, the number the guest is calling from — the assistant does not take another), the number of guests, the location, the day and time, the language, any request the guest types or says (up to 200 characters), whether it was booked on the booking page, by phone or in the app, whether it is confirmed or cancelled and by whom, and a one-way hash of the random key in the link we text the guest; the key itself is kept only to send that text, and for no more than a day. We ask for no email address, and a booking puts no one on an email list. The guest gets the texts described under “Messages” in this section. The business's owners and managers see each booking, with the guest's name, number and request, in the app and through its assistant; the notification of a new booking on their devices carries no name or number, and the line in the team's Telegram group is described under “Messages to the business's team”. Anyone with the link in the text can see that booking — the day and time, the number of guests, the first name, the location and the request — and cancel it; on a call, the assistant finds and cancels only bookings made from the number calling. We do not ask about health. If a guest mentions a food allergy or another need in a request, it is passed to the business only to serve that booking; it is shown to the business's owners and managers, not sent to the kitchen, so a guest with an allergy should also tell the staff on arrival. Bookings are not used for marketing, are not sold, and go to no one other than the business and the sub-processors in section 10 that run its calls, texts and assistant.
Catering requests: when a business takes catering, a guest can send it a request for a catering order to pick up on a later day, on the business's ordering page. Nothing is charged when the guest asks: the business confirms or declines the request first, and only a confirmed request can be paid, on the same payment page as any order. For each request we keep, in our platform's database as part of the business's account: the guest's name and mobile number, the email address on the terms described under “Guests' email addresses” below (a box ticked to get offers takes effect only if the request becomes an order), the items and the food total, the day and time of pickup, any note the guest types, the language, the location, whether the business confirmed or declined it, by whom and when, or that it expired, and a reason for declining if the business gives one, which is kept for the business and never sent to the guest. The guest gets the texts described under “Messages” in this section. The business's owners and managers see each request — the guest's first name, the day and time, the items, the total and the note — in the app, where they confirm or decline it; the notification of a new request on their devices carries no name or number, and the line in the team's Telegram group is described under “Messages to the business's team”. Anyone with the link to a request can see it — the day and time, the items and total, the name the guest gave, the location and the note — and pay for it once it is confirmed. A paid request becomes an order like any other. Catering requests are not used for marketing, are not sold, and go to no one other than the business and the sub-processors in section 10 that run its texts and ordering pages.
Guest accounts on the merchant's ordering page: a guest may choose to sign in on a merchant's ordering page with a mobile number from the United States or Canada; signing in is never required to place an order. We text a one-time six-digit code to that number. The code works for 10 minutes and for no more than five wrong tries, and asking for a new code cancels the previous one. We keep the code only as a keyed hash, together with the number, a keyed code of the requester's IP address that changes every day, and when the code was requested and used; until the text is sent the code is also held encrypted, and that copy is erased as soon as the text is sent or cannot be sent. A code record is deleted automatically a day after the code expires. A new guest gives a first and last name. The guest's account at that business holds the number, the name, the language of the page, when they signed up and last signed in, up to 10 delivery addresses saved from their own delivery orders (when an eleventh is saved, the one used longest ago is removed), and, for each device they signed in on, a hash of the session token, a short device label (such as "Safari on iPhone") and when the session started, was last used and expires. A signed-in guest sees their saved addresses and the orders placed with Paloma for that business from their number over the last 12 months — online, by phone and through the voice assistant, not orders at the register or from marketplaces; an order placed from that number before the account existed shows only its items, location and date. Signing in sets one functional cookie, pl_guest, holding a random session token of which we store only a hash; it is HttpOnly, Secure and SameSite=Lax, is sent only to that business's pages, and expires 90 days after it was last used (renewed at most once a day) and in any case 365 days after sign-in. A guest account belongs to one business: the same number at another business is a separate account in that business's own database. A code is texted only when the guest taps the button that asks for it; typing the number sends nothing. To stop abuse of codes, we limit how many codes a number, an IP address, its network and a business can get in a given time, and count codes requested, codes held back by those limits and wrong codes typed across all businesses in a separate record that holds only keyed codes of the number, the IP address and its network, never the number or the address itself; we delete those counts once they are 48 hours old. When a limit holds a code back, our server log notes which limit it was and only the last four digits of the number; server logs are kept no longer than 30 days. The guest can sign out, which deletes that session and clears the cookie; delete a saved address; or delete the account, which at once deletes the account, its saved addresses and all its sessions, and the rewards its number holds at that business (below). The orders stay with the business as its records, with the phone number they were placed with, but are no longer linked to an account, so signing in again with the same number shows them again. The business's owners and managers — not other staff — can ask the Paloma assistant, in the app or through a tool connected to Paloma, about the business's guests: how many signed up and came back, and for one guest the name, the last four digits of the number, when they signed up and last signed in, how many addresses they saved, and their orders with Paloma over the last 12 months. Saved addresses themselves are shown to no one but the guest.
A business's rewards: a business can run its own rewards program for its guests: points back — 1 point is a 1-cent discount at that business — on purchases at its register and on orders placed with Paloma. Only the business's owner can turn it on, on a card in the app, and only purchases made after that earn points; marketplace orders and items sold only to adults (such as alcohol or tobacco) earn none. The program is the business's own, and we run it for the business. To find who earns, for an order paid at the register we ask the business's Clover or Square account who paid: the customer the cashier added to the order, with that customer's phone number, and, for each card payment, a reference to the card — from Square, the card's fingerprint, an identifier Square gives a card number within our app; from Clover, the card type with the first six and last four digits of the card number. We hold that reference only in our server's memory and store only a one-way keyed code of it, made with a key that belongs to that business alone: the same card gives unrelated codes at two businesses, and we never connect a card or a guest across businesses. We never store the digits, the fingerprint or the cardholder's name. When an order carries both a phone number and a card, the card's code is linked to that number at that business, and a later purchase there with the same card and no number earns for that number; a card linked to two numbers earns for neither until a number is given again. Because Clover gives only the card type and some of its digits, two different cards can rarely look the same, and a purchase with one may then earn for the number linked to the other. For each number we keep its balance in points, when it last bought, and each change with the order it came from — points earned, points taken back when the order is refunded, and the balance that goes after the program's period without a purchase (6 months unless the business sets another) — and which orders the program has already looked at. We send guests no texts, emails or notifications about points. The business's owners and managers — in the app or through a tool connected to Paloma — see only totals: how many guests hold points, the points they hold, the points earned in the last 30 days and how many guests came back; a guest's balance and record only when the owner looks up that guest's number to answer the guest's own request to know or delete them — the owner alone, in the chat, and erasing them takes the owner's approval on a card. The owner's download of the business's data includes, for each number, its balance and its record and the numbers that left the program — never the card codes — so that the business can answer its guests' requests. The card codes are used only to earn points, never for analytics, marketing or the assistant's answers. A guest sees and spends points only after signing in on the business's ordering page with the code we text and agreeing to the program's terms, which the business offers there together with its notice of financial incentive; we keep which version of the terms they agreed to, in which language and when. The guest then sees only their balance and the date it expires — never the purchases behind it. At checkout the guest can apply points as a discount on the items before tax — never on tax, tips, delivery or other charges, and never on an order that includes an item sold only to adults, and at least $1.00 of the items always stays to pay; we record the points applied to the order, hold them until it is paid, return them if it is never paid (a few hours after its payment link expires, or soon after the order fails to start), and return the points spent on a refunded order in proportion to the refund. When the business turns the program off, guests have 30 days to spend what they hold. A guest can leave the program at any time with "Leave rewards" in their account on the ordering page: the balance, its record, the agreement and every card linked to their number are erased, and we keep only the number with the time it left, so that its purchases there stop earning until the guest agrees again. A guest who deletes their account on the ordering page also deletes their rewards at that business — the balance, its record and every card linked to their number; a later purchase with that number starts a new balance, which the guest sees only after agreeing to the terms again. A guest who never made an account can sign in on the ordering page with their number — signing in makes the account — to see their rewards, leave the program or delete them, or, without any account, ask the business or write to privacy@palomaceo.ai.
A business's promo codes and Promo Cards: a business can give its guests a discount on online orders placed on its ordering page — for example, "$10 off your first order of $30 or more" — through a code, a link and printed cards with a QR code that opens the offer's own page. Only the business's owner can start an offer, and pause, end or extend it, each time on a card in the app; Paloma sends these offers to no one, and no email from Paloma carries a promo code. The discount is the business's own: it comes off the items of the order before tax — never off tax, tips or delivery — never on an order that includes an item sold only to adults, and never together with the business's rewards. When the owner chose so, a guest gets the offer by giving an email address on the offer's page — or at checkout, when entering the code — and ticking the box to get the business's offers and news by email; the page then shows the business's notice of financial incentive, and we record that choice as described under guests' email addresses below, with the offer it was made for. The offer's page asks for nothing else: no phone number and no name. To keep an offer for new guests to new guests, and every offer to one use per guest, at checkout we compare the phone number and email on the order with the business's earlier orders — those placed with Paloma and those its point-of-sale system holds with a customer's phone number or email — and with earlier uses of its offers; the guest is told only that the offer does not apply to that phone number or email, never which order matched, and the offer's page checks nothing. For each use we keep the offer, the order, the discount and the phone number and email of that order, as long as the order itself; a use is returned if its order is never paid. If the business ends or pauses an offer early, a guest who joined its email list for it on the offer's page can still use it for 14 days after joining, but not after the date the offer was to end. The business's owners and managers see each offer's totals — uses, the discount given, the sales of those orders and how many guests joined the email list through the offer — never the guests' addresses. Paloma charges nothing for offers.
A business's gift cards: a business that uses Square can sell its own eGift cards on a page we run for it, once its owner turns that on, on a card in the app. Each card is the business's own Square gift card: the business issues it, its balance is kept in the business's Square account, and the buyer pays on the business's Square payment page, so the money goes to the business and never to us; we charge nothing on a card. The buyer gives an email address, which goes to Square with the payment for its receipt, and may add a “From” and a “To” name, up to 40 characters each; we ask nothing else about the person the card is for. In the business's own database we keep, for each card: Square's identifier of the card, the last four characters of its code, its value, the buyer's email address, the From and To names, one-way keyed codes of the card the buyer paid with — made from Square's reference to that card — and of the buyer's device, each with a key that belongs to that business alone and used only to keep the daily limit on gift card purchases; for one day, a code made with the same key from the network the purchase was started on — only the first part of the IP address (the first three of its four numbers, or the first three groups of an IPv6 address), never the address itself — used only to keep cards started and left unpaid from closing the business's sales to other buyers; the language of the page, and the card's activity: when it was sold, activated, used, refunded or cancelled, the amounts, the balance after each, and the location or order. The activity of the business's Square gift cards sold or used at its register comes from Square into the same record. We do not store a card's code: the card's page reads it from Square each time it is opened, and the code never goes into our logs, the assistant, tools connected to Paloma, Telegram or our admin pages, which show at most its last four characters. After paying, the buyer returns to the card's page, at an address only they have — we keep only a one-way hash of its key; it shows the business, the value, the balance, the code and the From and To names — never the buyer's email address, phone number or order — and the buyer shares it themselves. We send no email, text, push or WhatsApp message about a card to the buyer or to anyone else. A guest can enter a card's code at checkout on the business's ordering page: we look the card up at Square and, if its balance covers the whole order, ask Square to charge the card for it; wrong codes typed are counted only in our server's memory, for at most a day, to stop guessing. The business's owners and managers see its cards with the last four characters of their codes only, and the totals of sales, redemptions and balances left; the owner's download of the business's data includes the cards and their activity, without codes. The card's terms are the business's, published on its ordering page.
The merchant's app on a guest's Home Screen: a guest may add a merchant's ordering page to the Home Screen of their phone (or install it on a computer), where it opens like an app under the business's name and icon. Adding it is the guest's choice; nothing is downloaded from an app store, and the app is the same ordering page. To open quickly and when the connection drops, the page keeps copies of the business's menu and site pages, its item pictures (no more than 300) and the page's typefaces in the browser's storage on the guest's device. It never keeps the pages of a guest's order, sign-in, account, checkout or payment, or anything a guest sends us. These copies stay on the device — we cannot see them — are replaced by each new version of the page, and are removed with the app or when the guest clears the browser's data for the site. When a guest closes the offer to add the app, the page remembers that on the device for 30 days so as not to ask again. On an iPhone or iPad, an app added to the Home Screen does not share Safari's storage, so that a guest who is signed in, or has just placed an order, finds it in the app, the page that shows how to add the app creates a one-time key that works once and for 10 minutes and points only to that guest's account at that business, to the order they came from (placed in the last 24 hours), or to both — never to the phone number, an address or the Safari session. We keep only a one-way hash of the key with what it points to and when it was created, expires and was used, and delete it in a daily cleanup once it has expired; the key is not written to our logs. When the app opens for the first time, the key is used up: a signed-in guest gets a new session on that device, listed with their other devices (see guest accounts above), and the app opens on that order. On Android, Chrome may ask Google to build the app from the page's public description — the business's name, icons, colours and addresses, nothing about the guest; that is a feature of the browser. Notifications about an order: on an order's status page a guest may tap “Notify me” to be notified about that order on that phone or computer; on an iPhone or iPad this works only in the app added to the Home Screen. The browser asks for the guest's permission only after the tap, never when the page opens. We then keep, in the merchant's database, the push subscription the browser issues — the address at the browser's push service and its encryption keys — with the language of the page, the order or, if the guest is signed in, the guest's account at that business, and when the subscription was created and when a notification last reached it. A notification goes only when the order reaches a stage the merchant has not switched off: ready for pickup (when the business marks a pickup order ready), courier picked up, delivered, or a refund issued. It carries the business's name, a fixed line for that stage and, where known, the courier's estimated arrival time — never the guest's name, phone number or address, the amount or the items, and never marketing — and it is encrypted for the device and delivered through the push service of the guest's browser (see Sub-processors). When a push service accepts the “courier picked up” notification of an online order, we do not send the text message about the same stage; every other text message still goes. Without sign-in, the notifications for an order end two days after the order, or after its scheduled time if that is later; for a signed-in guest they cover that guest's orders at the business until turned off. A guest can turn them off at any time with “Turn off” on the status page or in the phone's settings, and signing out on that phone turns them off there too. Anyone who opens an order's status page from its link can turn them on for that order, on no more than five phones. We delete the subscription when the guest turns it off on the page or signs out on that phone, when the push service reports that it no longer exists, two days after the order for a guest who did not sign in, at once with the guest's account, and after 180 days in which no notification reached it.
Orders placed through a guest's AI assistant: a guest can ask an AI assistant they use — such as ChatGPT, Claude or Gemini — to order pickup or delivery from a business that allows it, through the business's ordering service, which takes the order the same way as the business's ordering page. The assistant sends us only what the order needs: the guest's name and mobile number, the items with their options and notes, a note for the business, the language and, if the guest gives one, an email address for the receipt (below); for delivery, also the delivery address with any instructions for the courier and the courier tip the guest chose. To price a delivery before the order, the assistant sends us the delivery address alone, with any instructions for the courier, and, as for the ordering page, the delivery company or dispatch service receives for the quote only that address, those instructions and the pickup location, never the guest's name or number; when the order is placed, the courier is checked and booked as described under “Marketplace and delivery orders” above, and the delivery company gets the guest's name, phone number, delivery address, instructions and tip as that item describes. Our service gives the assistant, to tell the guest before the order is placed, that the delivery company gets their name, number, address and instructions and may text or call them about the delivery. We handle the order as one placed on the ordering page, with the texts about it described under “Messages”, and, as on the page, we limit how many orders one number and one network address can place in a short time. What our service answers goes to the assistant and its provider, who handle it under the guest's own terms with them, not under this policy: the business's menu with its prices, hours, address and phone number, the delivery fee and the minutes to the door for the address given, and, for the guest's order, what its page shows — the items and totals, the name given, the order's stage and ready time, for delivery the address, the courier's stage and expected times and the delivery company's support ID, and a link to the order's page — never card details, and never the driver's name, vehicle or positions on the map. We do not run, see or keep the guest's conversation with the assistant, and the assistant's provider is not our sub-processor. The terms for ordering this way are at palomaceo.ai/terms.
Guests' email addresses and their choice about offers: when a guest places an order on a merchant's ordering page and pays online, the page asks for an email address for the receipt; when the order is paid at pickup, the page asks for one only for the offers described below and keeps it only if the guest ticks the box. When the order is paid online, we pass the address to the merchant's payment provider — Clover, Square or Stripe (section 5) — with the payment page for that order (at Square, as the contact of the person picking up the order, which the merchant also sees on that order in its Square account), so that the guest does not have to type it again where the provider shows it; the provider uses it for the receipt and may keep it with the merchant's customer records under its own terms. Next to the address the page offers a box, never ticked in advance, to get the merchant's offers and news by email; once an order paid online is paid, the page of the order offers the same choice again, and a guest who chose the offers can stop them on the page of their order at any time. A business's offer may be given only to guests who make that choice (see promo codes above). The ordering page remembers the address, with the name and phone number typed, in the browser's own storage on the guest's device so that it is filled in next time; that copy stays on the device. An AI assistant that places an order for a guest through the merchant's ordering service may pass the guest's email address for the receipt in the same way, but it can never make the choice about offers for the guest. We keep the address with the order it was given for — in the record our service keeps to take the order through payment, and in the merchant's own database — and, in the merchant's own database, for the merchant's email list, the address, the name and phone number the guest gave on that order and each choice — to get the offers or to stop them — with when it was made, on which page and for which location, in which language, which version of the wording the guest saw, and a keyed code of the guest's IP address that changes every day, never the IP address itself. A box left unticked is not recorded as a choice. The list is the merchant's: we keep it for the merchant and use it for nothing else. Only guests who ticked the box are on it for offers and news; we never use the address of a guest who did not tick it to send them offers or news. The merchant's owner can have Paloma email the guests on this list, one kind of email at a time, each turned on by the owner in the app: an invitation to order again a week after a guest's first online order when there is no second one; an invitation to come back when a guest's last online order was a number of days ago that the owner chooses; a reminder, an hour after the payment link of an order the guest started on the ordering page expired unpaid, with the items of that order and a button that puts them back in the cart; and, the day after a guest's first online order is handed over or delivered, thanks with a link to review the merchant on Google, the same for every such guest. Before the first of these emails, Paloma sends each guest who ticked the box — on the ordering page, on the page of an order or on a business's offer page — one email, without any offer, asking them to confirm that the address is theirs; only a guest who confirms with its link within 30 days gets the merchant's emails, and a guest who does not confirm gets nothing more. These emails carry the merchant's name as the sender, are sent through Amazon Web Services (Amazon SES, section 10) from Paloma's mail domain, carry the postal address and phone number of the merchant's location, say why the guest gets them, and have a link that unsubscribes at once, which also works in one click from the email program; a guest gets at most one of them a week. They are written from a fixed template with only the merchant's name and details, the guest's first name and the items of the guest's own order — at a store, only in the reminder about an unpaid order — never an item sold only to adults, and there is no reminder about an order that has one; they carry no promo code. To send them we use the guest's address, first name and language from the list and the guest's own orders with the merchant on Paloma; the reminder also uses the items of the unpaid order the guest started with the same address. We keep a record of each email — its kind, the address, the location, the language, the subject, what it was sent for, whether it was delivered, bounced or marked as spam, and when — and, when the guest places an order from a button in one of them, a note on that order of which email it came from, so that the merchant sees the orders its emails brought and their total. We do not track whether an email is opened, the emails carry no tracking images, and a click on a button is recorded only as part of an order placed from it. An address whose mailbox rejects our emails for good, or whose owner marks one as spam, is taken off the list as if the guest had unsubscribed. Paloma sends no such emails for a merchant whose owner has not turned them on, and none to an address that came from the merchant's point-of-sale system. We do not put a guest's email address in text messages, messages to the team's Telegram group, courier or marketplace orders, social posts or our emails to merchant users, and we do not sell or share it. The address and the choices are kept while the merchant's account is active: a guest who stops the offers stays on the list only as unsubscribed, so that no offers are sent to them again; a guest can ask the merchant to delete their address (section 13); and the list is deleted with the business (section 11).
Social posts: when a business connects its own Facebook Page, Instagram account, Google Business Profile, TikTok account, YouTube channel, LinkedIn company page or Threads account, we send to that platform only what the owner approved on the posting card or, for a kind of post the owner set to publish automatically, what Paloma drafted from the business’s point-of-sale data under the rules the owner turned on, shown in the app before it goes out — the text, the picture or pictures or the video, the title, and the posting settings the owner chose there (privacy level, interaction settings, commercial-content disclosure, visibility, "made for kids") — and, when the picture was drawn by an AI model or the video holds such a picture or a scene made by AI, the label the platform offers for AI-generated content. We tell that a picture was drawn by AI from its own file, which records it in its metadata (the IPTC digital source type); every copy we make of such a picture to post it keeps that record, so a platform that reads it can label the picture itself. A video Paloma makes for the business ends with a card showing the business's name and its ordering page, unless the owner asked for an atmosphere video without it; because TikTok does not allow apps to add a name or a link to what is posted there, TikTok receives a video with that closing card without it, and the other platforms receive it as the posting card showed it; a video made without the card goes to every platform as it is. When TikTok is connected through our own app, the owner may instead choose on the card to send the post to the account's TikTok inbox as a draft: TikTok then receives only the video, or the picture with the post's text, and nothing is public until the owner finishes the post and publishes it in the TikTok app, where TikTok itself asks for the sound, who can see it and the commercial-content disclosure; we stop following a draft once TikTok confirms it reached the inbox. A picture or a video made by AI goes to TikTok only when we post it directly with TikTok's AI label: never as a draft, and a picture never through Zernio (section 8), which cannot put that label on a photo. A picture drawn by AI never goes to a Google Business Profile, directly or through Zernio, because Google's rules for Business Profile media ask for photos taken with a camera; the posting card leaves Google out of such a post and says why. We do not read followers, comments, direct messages or analytics from those platforms. To show the owner which account a post goes to, we read the name of the connected TikTok account or YouTube channel and, for TikTok, the nickname and the posting options TikTok allows it, each time the app shows them, and we do not store them. Where a channel is connected through our own app, we store the platform account's own id and the access token, encrypted; where it is connected through Zernio, our publishing bridge (section 8), Zernio holds the platform's access and we store only the ids of the account at Zernio. A video sent in the conversation or made by Paloma (with, for a video Paloma made, its copy for TikTok) stays in the business's storage for 30 days after it was sent or made, and longer only while a post that uses it still waits to go out; then it is removed. If the owner turns on reposting, we also read the Instagram account’s own new posts — caption and media — to offer each one as a card for the owner’s other channels, and the text and time of the Page’s own recent posts only to check that Meta has not already shared that post to the Page, so it is not published twice; we do not store the Page’s posts. If the owner turns on post drafts from the point of sale, Paloma uses the business’s own catalog — item names, categories, descriptions, real photos, whether an item is on sale, its price and when the price changed — and how many of each item sold in the last 30 days to choose what to show and to draft posts about the business’s menu; the words of a post are written by our language model provider (section 10) from the item names, categories and descriptions only, and no information about guests, staff or orders is used. While post drafts are on, we also keep a copy of the discounts kept in the point-of-sale system — each one’s name, what it takes off, the items it is on, its hours and dates, and whether it is only for some customers or above a minimum order, never which customers — and, if the owner turns on promotion posts, fill in a post about a discount the register applies to every guest from those terms with a fixed template, without a language model; a happy hour the owner describes in the conversation is drafted by the assistant from the owner’s words. An approved series of happy-hour reminders keeps its words, accounts and hours in the business’s database, like the business’s other posts. Each drafted post is sent to a platform only as described above, after the owner approves it or, from October 20, 2026, for a kind of post the owner let go out by itself, no sooner than two hours after we notify the owner, who can cancel it; posts about prices and promotions always wait for the owner’s approval. Only the owner can turn this on, with a card in the app; we keep the owner’s yes — who gave it and when — in the business’s settings and in our audit log, and every later change there too. The owner can stop it at any time; stopping withdraws waiting drafts and cancels drafted posts not yet published.
The merchant's own domain: when a merchant asks for their site to answer at a domain of their own, we keep the domain name, which business it belongs to, and whether it is verified and answering. We do not register, buy, renew or host domains, we run no mail for them, and the merchant keeps the domain at their own registrar. A certificate for it is issued by Let's Encrypt, as for our own addresses.
The merchant's site in Google Search: for each site we serve for a merchant and have verified in Google Search Console (Terms of Service, section 4), we read from Google once a day its figures of how the site appeared in Google Search — by day, how many times it was shown and clicked and its average position, for the whole site, for each of its pages and for each search it was shown for, as Google counts them — and, for the pages in the site's list of pages, whether Google has each in its index and when Google last read it. The searches are words people typed into Google; Google gives them without saying who searched, leaves out rare ones, and sends us nothing about any person. We keep them in the business's own database and show them to the business in the app and to its assistant; the assistant may tell the owner when a page leaves Google's index, Google cannot read a page, or clicks from Google fall by half in a week, and suggest a new title or description for a page, which changes only when the owner approves it. Our team gets a line naming the business's address in Paloma, the counts and the paths of the pages concerned, never the searches. On a merchant's own domain, and only when its owner asks for it and approves it, we send Google the Google account address the owner names (at most three), so that Google makes it a delegated owner of our property of that domain; Google shows that address to the property's other owners. Once a property is opened that way, we read once a day the addresses Google lists as its owners and record those we did not add (people added there after it was opened), only while the home page shows our tag. Owners Google listed there before we first sent an address for that business are not ours: we keep them only as one-way codes made with our secret key, never the addresses, so that we never record or take them off, and delete those codes when we give up our verification of the site. We keep these addresses in our own control database, with the site's address, the business and the dates, only to take them off at Google: those the owner named when the owner asks, when the domain leaves the business or when a business being deleted is erased (until then, up to 45 days from the last time we read our tag, it keeps them, as it may be restored with its domain); any other only when the owner asks while the home page shows our tag (otherwise we change nothing at Google and stop keeping the address), since Google does not tell us who added it, and we erase its address once we give up our own verification of the site. We treat the domain as having left an active business when that public page, read once an hour, has not shown our own tag for two weeks and still shows none; a page we cannot read counts the same once four weeks have passed since we last saw the tag, and a suspended business, or one being deleted, keeps its domain up to 45 days from the last time the tag was read. Once the domain leaves, or after a business being deleted is erased, we give up our own verification of the site, and Google ends the remaining access after its own grace period unless someone else verified the site at Google. We never open the shared ordering address to anyone outside Paloma, and never open, verify or read for another business a property opened to one; we keep for good which business each own domain we verified was held by and when (no personal data), and do not open a property to a business's owner while we verified or read it for another business within the last 16 months, the time Google keeps a property's figures; our team gets a line naming the business and the domain so closed to it, never the addresses.

3. What we collect from callers

The caller's phone number, their voice during the call, the order they place or the table they book, and pickup or delivery details they give. When a caller asks for delivery from a business whose couriers Paloma books — the same delivery its ordering page offers — the address they give is sent to that courier service to get a delivery price, and before they confirm, the assistant tells them the delivery fee, the courier tip and about how long the delivery takes; the order they then place goes to the courier as section 2 describes and is paid only through the payment link we text. When the assistant answers a call, the first thing it says is that it is an AI assistant and that the call is recorded, before anything else is said, so the caller can hang up or ask for a person. Only calls the assistant takes are recorded. Recording starts as the assistant answers, so that this statement is on the recording itself; if the statement does not play to its end — for example, because our voice service fails at that moment — the recording is never made available to the business and is deleted automatically within two hours of the start of the call. Whenever a call is passed to the business's phone — because the caller asks for a person, the assistant cannot help, the call reaches its time limit or the assistant stopped responding — the recording stops before the handover, and no AI listens to the rest of the call. If the caller asks not to be recorded, the recording stops as they ask, and nothing said after that is kept, in the recording or in the call's transcript; the call's card notes when they asked, its short note of the call is made only from what was said before that, and an order or booking they place is kept as usual. A message they choose to leave later on that call, after being told again that it will be recorded, is kept as described below. A call it does not take — because the merchant's balance or account limits do not cover it, too many calls ring at once, the same number has called too many times within an hour, or our voice service is unavailable — is not recorded, and no AI listens to it: it is transferred to the business's own phone, or the caller hears that the line uses an AI assistant, or an automated message from the business, and where to order online or to call back later. The one exception is a message the caller chooses to leave: when the assistant cannot take or go on with a call because our voice service fails or too many calls ring at once, and nobody at the business can be reached, the caller of a business whose calls are recorded may instead hear — after the statement that the line uses an AI assistant and that the call is recorded, or, when our voice service is down, after an automated message from the business — that they can leave a message after the tone and that it will be recorded, and leave one of up to two minutes. What is said after the tone is kept as that call's recording, or added to the end of it, and deleted with it (section 11); a part of the call recorded before the statement about AI and recording played to its end is not kept; our phone carrier's copy of the message is deleted once we have stored it. To apply these limits we count calls by the one-way keyed code of the caller's number described in section 2, never by the number itself (section 11).

Calls passed to the business's phone. The business's phone shows the caller's own number, or the Paloma number when the caller has hidden theirs. The person who answers may first hear a short automated line that the caller does not hear: that this is a Paloma call for the business, the caller's first name — only when the phone network vouches for the caller's number and the business knows it — and up to ten words on why the caller asked for a person; the line is spoken by the text-to-speech of our phone carrier, Twilio, and is not recorded. If nobody at the business answers within about 20 seconds, the line is busy or it cannot be reached, the caller is told where to order or to call back later; or, on a call the assistant took — or one our phone carrier answered because our voice service was down — for a business whose calls are recorded, the caller may hear that they can leave a message after the tone and that it will be recorded, and leave one of up to two minutes. That message is added to the end of the call's recording, or kept as the call's recording when there is none, made available to the business with it and deleted with it (section 11); our phone carrier's copy of it is deleted once we have stored it.

Who processes a call. A call may be run by an AI voice model that listens, answers and speaks in one step — xAI's or OpenAI's (section 10), in the order we set to keep calls answered, which can change at any time — or by our speech recognition (Deepgram), language model (Anthropic) and speech synthesis (Cartesia, or Deepgram as a backup), for a business whose calls we run that way and, while we keep it as a fallback, when neither voice model can take a call. Which one runs a call depends on the business, including the voice chosen for it, the language and whether the provider is available. If the voice model running a call stops responding during it, another of them may take the call over while the caller stays on the line; it then also receives, as text, what was said in the call so far. When none of them can take a call, the call is handled as one the assistant does not take (above): it is not recorded and no AI listens to it. A voice model provider receives, for the length of the call, the caller's voice as it is spoken — so anything the caller says, such as a name, a phone number, an address or an allergy, reaches it; the assistant's instructions for that business — its name and rules, its menu with prices and choices when the menu is small enough to give whole, and, when the phone network vouches for the caller's number and the business knows that number, the caller's first name, how many orders they placed by phone, the items of their last order and the language they spoke last time; and what the assistant looks up during the call, such as the menu, prices, opening hours and the order being placed. It returns the assistant's voice and a written transcript, which becomes the call's transcript (section 2). The assistant's first words are the fixed sentence above, spoken from the text of that sentence alone by the speech synthesis of the provider running the call or by Cartesia or Deepgram — Cartesia first when that provider's synthesis does not stream speech as it is made, and otherwise if it fails; so are its other fixed sentences, such as the one that passes a call to the business's phone. The audio of a fixed sentence that names no caller — such as the first words, which name the business and the assistant, or a goodbye — may be kept on our own storage with that business's data and played again on its later calls, until the business is deleted; a sentence with a caller's first name is spoken for that call only and its audio is not kept. When none of these can say a fixed sentence, or the assistant does not take the call, the sentence may instead be spoken from its text alone by the text-to-speech of our phone carrier, Twilio. Neither we nor any provider make a voiceprint or try to tell who is speaking from their voice: we recognise a returning caller only by the keyed code of their number (section 2). The providers do not use calls to train their models; xAI runs our calls with zero data retention and keeps nothing once each reply is delivered, and OpenAI may keep a copy for up to 30 days only to detect abuse of its service (section 11).

4. What we collect from merchant users

Name, email address, role in the business, sign-in events, and product usage logs used to operate and secure the service; and, from the person who adds a business (and from our team members, and, through October 18, 2026, from the people of the one customer business whose owner asked us to test its launch week this way), their own mobile number (below). In addition:

Voice input. When a user taps the microphone in the app, the audio is passed through our servers to Deepgram for transcription. We do not store the audio: it is not written to disk, to logs or to traces. The recognized text appears in the message box, and only the text the user chooses to send becomes part of the conversation.
Notifications. When a user turns on notifications on a device, we store that device's push subscription — the address and encryption keys the browser issues, a device label (such as “Safari on iPhone”), the browser's user agent and the notification language — and the user's notification choices for each business. A subscription is deleted when the user removes the device in the app, when the push service reports that it no longer exists, or when the user's account is deleted.
Signing in with Google. A user can sign up, sign in or accept an invitation with a Google account instead of a password. We ask Google only for basic sign-in information (the openid, email and profile permissions): Google tells us the account's email address, whether Google has confirmed it, the name, a link to the profile picture and the Google account's identifier. We keep the identifier to recognise the user the next time, and, when the Paloma account is created through Google, the name and the picture link as the account's own. We do not keep Google's access, refresh or ID tokens, and we never contact Google on the user's behalf. If the address belongs to a Paloma account whose address was never confirmed, the Google sign-in takes that account over: its password is removed, its sessions and API keys stop working, and this is recorded in the account security log. Information received from Google is used only to sign the user in and to run their Paloma account; it is not sold, not shared with other merchants or third parties, not used for advertising, and not used to train, fine-tune or evaluate AI models. Paloma's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Since we hold no Google token, removing Paloma from the Google Account's third-party access page changes nothing on our side; to unlink the Google account from a Paloma account, or to delete the account, write to privacy@palomaceo.ai.

Signing up and activation. Anyone can create an account, with an email address and a password or with Google, and add a business. To keep the sign-up form from being abused, we limit how many accounts can be created from one IP address and from its network; those counts are kept only in our server's memory, for at most a day. We also limit how many new businesses waiting for activation can be added in a day from one IP address (for IPv6, its /64 block) and from its network; for that we keep a count for each day under a keyed code of the address and of the network, made with a secret key of our platform — never the address itself — and a daily cleanup deletes it once three days have passed. The sign-up form and “Text me a code” also have the browser work out a short calculation in the background — nothing for the person to solve or click, and nothing sent beyond the request itself — and the form turns away a submission made faster than a person could fill it in, or one that fills in a field people do not see. When a daily limit for all of Paloma is reached, our staff get a note in Telegram that names only the limit. A new business opens its AI features, calls, texts, guests' orders and paid services once it is activated. It is activated automatically, without a review by our staff, as soon as the person who added it has confirmed both their email address — with the link in our email, or by signing in with Google, which has confirmed it — and their own mobile number, with a code we text to it (below). Our staff can also activate a business themselves, for example when our email or our text cannot reach the person, and can decline to activate one; a business they declined is not activated by the confirmations. A business whose Clover account is connected through our app in the Clover App Market is activated by that install instead (Clover has verified the merchant), once for each Clover merchant account; the account security log records that the install activated it, with the Clover merchant ID. For each new business our staff get a message in a Telegram chat of Paloma's staff (section 10) with the business's name and address name on Paloma, the email address of the person who added it with everything but its first letter and its domain hidden, and which of the two confirmations are done — never a phone number — repeated until a staff member marks it seen or for at most three days, and one more message when the business is activated, saying how. Until a business is activated, our staff can see in our own admin tools the business's name, type and when it was added; the founder's email address, whether it is confirmed, the mobile number they confirmed, whether the account was made with a password or with Google, when it was made, and the person's other businesses on Paloma and their state; the point-of-sale account the business connected — the provider, the merchant id, the state of the connection and whether the same merchant account is connected to another business on Paloma; and, from the business's own database, the name, address and phone number of its location as the point-of-sale system gives them, how many items it has and when it last synced. When in doubt, our staff call the business's phone number from the point-of-sale system, or the founder's mobile number, to check that the person runs the business. We use this only to activate businesses, to help a person who is stuck on the way, and to prevent fraud and abuse. Each activation — by the founder's confirmations, by our staff or by a Clover App Market install — and each decision of our staff not to activate, with the reason our staff record for it, is kept in the account security log (section 11); the app tells the owner the decision, not the reason.

Your mobile number. To activate a business, the person who added it confirms a mobile number that is their own. A member of our team can also confirm theirs in the app's settings, the same way, on Paloma's own businesses, which our team uses for tests, and on a customer business they are a member of; so can, through October 18, 2026, the people of the one customer business whose owner asked us to test its launch week this way. They can ask for the code only once their email address is confirmed, and a code is sent only when they tap “Send me a code” — within limits for an account, for a number, for an IP address and its network, and for all of Paloma each day. The code is created, sent and checked by Twilio Verify, a Twilio service (section 10): we send Twilio the number and the language of the app and, to check it, the code the person types. A number from the United States or Canada gets the code by text message, which reads “Your PalomaCEO verification code is:” followed by the code. A number from anywhere else, Puerto Rico and the other United States territories included, gets it by WhatsApp from Paloma's own WhatsApp business account: Twilio passes the number and the message with the code to Meta's WhatsApp Business Platform, which delivers it (section 10). We send no code to a number of a country or region under comprehensive United States sanctions, or of a country WhatsApp codes cannot reach. The code is not charged to the business; Twilio may hold back a message that its fraud checks find suspicious. The code works for 10 minutes and for no more than five wrong tries, and asking again within those 10 minutes sends the same code. We do not keep the code; Twilio keeps its own record of each verification, including the number, under its terms with us. Once the code is right, we keep the number encrypted with a key of our platform, a keyed code of the number that lets us make sure one number is confirmed on only one Paloma account, its last four digits to show in the app, and when it was confirmed; a newly confirmed number replaces the previous one. We use the number only to confirm that it is theirs, to activate the businesses they add, to keep one number to one account, so that our staff can call them about their account, and, on Paloma's own businesses, on a customer business a member of our team belongs to and, through October 18, 2026, on that customer business, to tell a test call placed from it from a call by anyone else (section 6) — never for marketing; we do not sell or share it, and only Twilio, the carriers that deliver a text and, for a code sent by WhatsApp, Meta receive it. Our staff can see the whole number in our own admin tools; our messages to staff in Telegram never carry it. The account security log records each code sent and each number confirmed with only the last four digits — and, for 48 hours, a keyed code of the IP address the code was asked from, which counts the daily limit for that address, and our server logs note only the last four digits. The number is deleted when the account is deleted. A number that replied STOP to one of our texts gets no code until it replies START.

Opening Paloma from the Clover App Market. When someone opens Paloma from the Clover dashboard in a browser that is not signed in to Paloma, and that Clover merchant account is not connected to a business on Paloma, we ask Clover to authorize our app and, with that authorization, read three things: the business name, and the name and email address Clover has for the person opening Paloma — or for the merchant account's owner, when Clover does not tell us who is opening it. We use them only to fill in the sign-up form and the name of the business, which the person can change or clear before submitting. They are kept only in our server's memory, for at most 30 minutes, and only the browser that opened Paloma can read them back, with a random ticket in a cookie (paloma_clover_launch, HttpOnly, sent only to the one address of ours that returns them, and expiring with them). The access Clover gave for this reading is not stored, and nothing is saved unless the person submits the form; the business's Clover connection itself is made afterwards, once the business exists.

Requests for help to the Paloma team. An owner or manager can ask our team for help in the conversation with the assistant or with “Get help” in the app, which also works before the business is activated and is how a business tells us which other point-of-sale system it uses, or that it has none. The request — the user's words and, when it comes from the conversation, a short note from the assistant on what it already checked — is kept in that business's own database; email addresses, phone numbers and card-like numbers in it are replaced with placeholders before it is kept. Our support staff read it, together with the name and email address of the person who asked, only to answer it; the notification that tells them a request is waiting names no business and carries none of its words. Our reply is kept in the same database and appears in the Inbox of the business's owners and managers, with a notification that does not include its text. The business's security log records who at Paloma answered and when, not what was said. Requests and replies are part of the business's data export and are deleted with the business. When a request comes from the conversation, the assistant also marks, from fixed lists, what kind of request it is (something does not work, a feature the business wants, a how-to question or an account matter) and which part of Paloma it concerns, and the request keeps how the tools in the conversation's last answers ended: each tool's name, its outcome and, if it gave one, our own short error code. Once an hour our system reads only these marks and outcomes — never the words — into our own records: for each kind of problem, how many requests and ratings there were and from how many businesses, our internal identifiers of up to three of those businesses, and which request or rating it was, kept until 90 days after the last request or rating of that kind. When our system itself recorded a failure around the request — a tool in the conversation that failed, or an error in our servers or a problem our checks found for that business shortly before — the AI agents that help us build Paloma (they work in our code repository at GitHub and use Anthropic's models, section 10) get the tool, the error code, the part of Paloma, the counts, the dates and those internal identifiers — never the words, the business's name or who asked — and try to fix our code. Once the fix is live and the failure has not come back, the business's owners and managers get a short message from us in the Inbox — always the same words, with only the date of the request filled in — saying that we found and fixed an error in Paloma related to it; the request itself stays open for our staff. Requests for features are counted the same way in our product plans, without the words or the business. Please leave customers' personal details out of a request: we do not need them to help.

Rating the assistant's answers. A user can rate an answer of the assistant in the app with a thumb up or down. A thumb up keeps only the rating, who gave it and which tools the answer used. A thumb down, once the user sends it, also keeps the answer, the question it replied to and anything the user writes about what was wrong; email addresses, phone numbers and card-like numbers in them are replaced with placeholders before they are kept. Ratings are kept in that business's own database. Our team reads them, together with the business's name, only to find and fix what the assistant got wrong; the notification that tells them a thumb down is waiting names no business and carries none of its words. With a thumb down we also keep the language of the app and, if a tool of the answer failed, which part of Paloma that tool belongs to. The automated agents that help us build Paloma see only a rating, which tools the answer used, how each ended, our own error code, the part of Paloma and our internal identifier of the business — never the words; a thumb down on an answer whose tool failed is counted, and can lead to a fix and a message in the Inbox, the same way as a request for help (above). What a user writes with a rating, the question and the answer are never shown to the assistant or sent to a model provider (section 9). The question and the answer are deleted with their thread; the rest is kept while the merchant's account is active, is part of the business's data export and is deleted with the business. Please leave customers' personal details out of what you write: we do not need them to fix an answer.

Requests from this website. Sign-up itself is in the app. The request form on palomaceo.ai — to have us set Paloma up with you, to hear it on your menu, to see your menu as a site, or to restore access — collects your name, email address and business name and, if you add them, a phone number, city and message, together with the language and the page you sent it from. We use them only to answer your request and to let our operator know a request is waiting. The same form is how a user who cannot sign in asks us to restore access to an existing account while password reset by email is not switched on: we then use the details to check, against what we already hold about that business, that the account is theirs — for example by calling the business's phone number on file — and to restore access; nothing else on the account changes. The operator's notification carries none of your details. The request is kept on our own servers until we have handled it and for 12 months after, then deleted automatically, and we never add you to a marketing list without your consent.

Feedback to Paloma. Anyone can tell us what is unclear, missing or not working — with the Feedback button on any page of palomaceo.ai, or with “Send feedback” in the app, or with “Send to the team” in the assistant on this website (below). We keep the message, the kind of feedback if one was chosen, the language, the page of this website or the screen of the app it was sent from — from this website also the part of the page and, from its assistant, the pages and parts of pages the messages were written from — and the version of Paloma; email addresses, phone numbers and card-like numbers in the message are replaced with placeholders before it is kept. Feedback from this website is kept on our own servers without your IP address, your browser or any account; you can leave an email address if you would like a reply, and we use it only to reply to that message, never for marketing. To keep the form from being abused, the browser works out a short calculation in the background — nothing for the person to solve or click — the form turns away a submission made faster than a person could fill it in, or one that fills in a field people do not see, and we limit how many messages can be sent in a day from one IP address and from its network, counted under a keyed code of the address and of the network, never the address itself (section 11). Feedback from the app is kept in that business's own database with who sent it, their role and the app's version, is part of the business's data export and is deleted with the business; when our team answers it, or changes something because of it, the business's owners and managers get a message from us in the Inbox. Our team reads the words of feedback in our own admin tools, only to decide what to change in Paloma and to reply; the notification that tells them feedback is waiting carries only where it came from, its kind, the page or screen and, from the app, the sender's role — never its words, an email address, a person or a business. The AI agents that help us build Paloma (section 10) and our engineering records at GitHub get only the kind, the page or screen, counts, dates and our internal identifiers — never the words or an email address; the words of feedback are never shown to the assistant in the app or sent to a model provider — messages typed to the assistant on this website go to Anthropic only as part of that chat, to answer them (below). We never publish feedback or present it as a review or testimonial. Feedback from this website is deleted 12 months after our team has handled it, or 12 months after it was sent if nobody did, and an email address left with it as soon as we have replied or decided not to. Please leave personal details out of feedback — your customers', and your own apart from the email address: we do not need them.

Ask Paloma, the assistant on this website. palomaceo.ai has an AI assistant, “Ask Paloma”, that answers questions about Paloma from what this website says. It is not a person: its answers are written by a language model of Anthropic (Claude), reached through Anthropic's commercial API on our behalf. The window says so, and what happens to the chat, before your first message; sending a message is your agreement to it. It knows only the public pages of this website and nothing about any merchant, it can be wrong, and it cannot make offers, agreements or promises for us — our Terms and this policy say what we do. When you type a question, we send Anthropic your message, the earlier messages and answers of the same chat, the page of this website and the part of it you asked from, and the text of our public website, to write the answer; email addresses, phone numbers and card-like numbers in your message are replaced with placeholders before it is sent or kept. The ready-made questions shown by parts of this website are answered in your browser from this website's own text and are not sent to us. We keep the chat — your messages, the answers, the language, the page and the part of the page you were on with each message, and how many questions it could not answer — on our own servers, without your IP address, your browser or any account, and delete it automatically 30 days after its last message; the chat's identifier stays only in your browser tab's storage and is gone when you close the tab — we set no cookie. Our team reads chats in our own admin tools to see what this website leaves unclear and what people are missing; the notices our team gets about chats, and what the AI agents that help us build Paloma (section 10) and our engineering records at GitHub get, are counts by page and part of the page — never the words. Anthropic deletes what we send within 30 days of receiving it, unless it has to keep it longer to enforce its usage policy or to comply with the law, and does not use it to train its models; we do not use chats to train, fine-tune or evaluate models either (section 9). To keep the assistant from being abused, a new chat starts only after the browser works out a short calculation in the background — nothing for you to solve — a chat holds at most eight of your messages of up to 500 characters each, and we limit how many messages and new chats can come in a day from one IP address and from its network, counted under a keyed code of the address and of the network, never the address itself (section 11). If you press “Send to the team”, your own messages in that chat — never the assistant's answers — with the pages and parts of pages you wrote them from become feedback, kept for 12 months as described above; it carries no way to reach you, so we cannot reply to it — for a reply, use the Feedback button and leave an email address. Please do not type personal details into the assistant.

The business scanner. palomaceo.ai has a scanner that shows how a restaurant or store looks to guests and to Google, and a business on Paloma can run the same check from the app. It looks only at public information about a business, never at the person using it, and no AI model takes part in it.

What you give it. The name of a business. While you type, the letters go from our server to Google Maps Platform, which suggests matching places; when you pick one, we receive Google's identifier of that place (its place ID). Google receives the letters and a random code for that search from our server — never your IP address, your name or a way to reach you.
What it reads. (1) The business's listing as Google's Places service returns it: its name, kind, address, phone number, opening hours, website, price level, rating and number of reviews, how many photos it has, whether it offers dine-in, takeout or delivery, and the dates of its newest reviews — Google's answer carries up to five reviews, of which we use only the dates: their words and authors are dropped at once, and photos are never fetched. (2) Businesses of the same kind nearby, with their names, ratings and numbers of reviews, and where the business stands in Google Maps for a few searches such as “georgian restaurant in Aventura”, which our servers run; a person's own phone may show a different order. (3) The public pages of the business's own website named in its Google listing — the home page and at most two more pages of the same site that the home page links to — its first menu or ordering page and its “about us” or FAQ page, or a second menu or ordering page when there is no such page — up to one megabyte each — read by our own reader, which introduces itself as PalomaCEO-scan/1.0 (+https://palomaceo.ai), follows the site's robots.txt (a site that disallows PalomaCEO-scan is not read), opens only public addresses and never signs in or gets past a protection. It does not open marketplace, delivery, social, booking, review or link-in-bio sites or Google's own pages: when Google names one of them as the business's website, the report says so and reads nothing there. (4) Google PageSpeed Insights, which receives only the address of that website and tells us how it loads on a phone, with a picture of its screen.
What we keep. Google's identifier of the place and our own results: which checks passed or failed, the score, the searches with the business's place in each as a number, the phone speed result, and when the scan ran. We keep no words, pictures or files from the website. Google's content — the business's name, address, phone number, rating and number of reviews, the businesses nearby and which one leads each search — and the picture of the phone screen are shown with the report for one hour after the scan finishes, then are no longer shown and are erased by an hourly cleanup within two hours; the report keeps showing our own results without them. A scan that does not belong to a business on Paloma is deleted 90 days after it ran. A scan a business runs from its account in Paloma is kept while the business is with us, and so is a scan you ran on this website if, within 48 hours, you sign up from its report with “Let Paloma fix this” and the business you then add takes it as its first scan — nothing from Google, not even the name or address, is copied into that business. While a business is with us, Paloma checks its scanned place again about once a week, under the same rules, to show what changed (section 11).
Who sees a report. Anyone with its link: the link carries a long random code, and the report asks search engines not to index it. Our team sees the list of scans in our own admin tools. A business, or someone acting for it, can ask us to correct or remove a report about it at privacy@palomaceo.ai, and we do so within five business days.
How we use it. Only to show the report, to keep the scanner from being abused and, for a business whose scan it is, to show it what is left to fix. We never use a phone number, address or website the scanner finds to call, text or email a business, and never add them to a list. In the app, the assistant receives the score, the checks and the business's places in Google Maps as numbers — never Google's content, which the owner sees on the report page. Information from Google is shown in the report with Google's attribution, under Google's terms.
Your visit. Until you sign up, we keep nothing about you for the scanner — no account and no cookie. If you press “Let Paloma fix this”, the report's identifier and a code showing that your browser ran the scan go with you to sign-up and are kept only in that browser, for at most 48 hours, so that the business you add can take the scan as its own; the code is never part of the report's link, so someone you share the link with cannot take the scan. To keep it from being abused, the page works out a short calculation in the background — nothing for you to solve — turns away a request made faster than a person could or one that fills in a field people do not see, and we limit how many scans can start from one IP address in an hour, counted only in our server's memory, and in a day from one IP address and from its network, counted under a keyed code of the address and of the network, never the address itself (section 11).

5. Payments — card data never reaches us

Payments for orders made online are completed on a payment page hosted by the provider the merchant uses: Clover Hosted Checkout or Square's online checkout for the merchant's point-of-sale account, or Stripe Checkout. Stripe Checkout runs on the merchant's own Stripe account, connected through Stripe Connect, so the money goes to the merchant directly; an order paid at pickup is paid to the merchant at its counter, and that payment never passes through us; only for businesses operated by PalomaFinTech LLC itself may it run on our own Stripe account. The merchant can disconnect Stripe in the app at any time: payment links stop using that account at once and we revoke Paloma's access to it at Stripe; the same happens when the business is deleted. To create the page we send the provider the order's items, prices and tax, the customer's phone number and email address (section 2) and the page to return to after paying; for Clover also the name the customer gave, for Square the name the customer gave, which goes with the phone number and email address on the order as the person picking it up, and a short order note, and for Stripe the business name and our order reference. Card numbers, CVV and expiry are entered only on the provider's page and never reach our systems; we keep the payment's status, amount, tender type and the provider's payment reference. For a business that runs rewards (section 2), we also read, for a payment at its register, a reference to the card — Square's card fingerprint, or Clover's card type with the first six and last four digits — only in our server's memory, and store only a one-way keyed code of it made with that business's own key. When a guest spends a business's rewards on an order (section 2), the provider gets the item prices after the points, marked "Paloma points", or a discount of that name — never the guest's balance. A business's gift card (section 2) is not a payment card: the buyer pays for it on the business's Square payment page, for which we send Square the card's amount and the buyer's email address; from that payment we read Square's reference to the paying card only in our server's memory and keep only a one-way keyed code of it, made with that business's own key. When a guest pays an order with a gift card, its code passes from the guest's browser through us to Square only to find the card, is not stored, and Square charges the card by its identifier. When an order uses a business's offer (section 2), the provider gets the item prices after the discount, marked "Promo" with the offer's code, or a discount of that name. The assistant never accepts a card number by voice. If a caller starts reading a card number aloud, the assistant stops them and sends a payment link instead.

Paying Paloma: adding funds to the balance. A merchant that adds funds to its prepaid balance (for AI and paid services) outside the Clover App Market pays on a Stripe Checkout page on our own Stripe account. We send Stripe the business name, the owner's email address for the receipt, the amount and our internal reference for the business; the card is entered only on Stripe's page and never reaches our systems. We keep the amount, the payment status and Stripe's payment reference. A merchant that installed Paloma from the Clover App Market does not add funds this way: its payments to Paloma go only through Clover's billing, and adding funds through Clover is not available yet. If a Stripe payment for a business arrives after the business was connected through our Clover app, we do not add it to the balance; we keep the amount, the status and Stripe's reference, and refund it.

Paying Paloma for couriers: a saved card. A merchant whose guests pay through Clover or Square — other than one that installed Paloma from the Clover App Market, for which we do not book couriers for now — pays for the couriers of its delivery orders with a card it attaches in the app (Terms, section 3). The card is entered only on a Stripe Checkout page on our own Stripe account, and Stripe keeps it as a saved payment method of the business; its number never reaches our systems. We keep Stripe's references to the business as its customer and to the card, the card's brand, last four digits and expiry, which user attached it and when, and whether it works (with the decline code Stripe gives, not the bank's message). For each delivery we send Stripe the amount, our internal references for the business and the order, and a description such as “Courier · order #123” — never the guest's name, phone number or address — and we keep the amounts of the charge (the delivery price, the tip and the total), the payment's status and Stripe's payment reference. A card that is replaced or removed, the card of a deleted business, and the card of a business that then installs Paloma from the Clover App Market are detached from our Stripe account and cannot be charged again.

6. How we use the data

Only to provide the service the merchant asked for: answer calls, place and fulfil orders, send payment links and confirmations, pass a guest's email address for the receipt to the payment page, keep the merchant's list of guests who chose to get its offers and news by email and send them the emails the merchant's owner turned on (section 2), let guests sign in on a merchant's ordering page to reuse their saved addresses and order again, run a business's own rewards program — earn its points for a guest's phone number from purchases at its register and on orders placed with Paloma, with the keyed code of a card used for nothing else, and show a signed-in guest who agreed to its terms their balance and let them spend it online (section 2), sell a business's own gift cards, show their buyer the card and let guests pay with one on its ordering page, with the keyed code of the paying card used only for the daily limit on purchases (section 2), check whether a business's offer applies to an order — to new guests and once per guest — against its earlier orders (section 2), answer the merchant's questions about its own business, draft posts about the merchant's own menu from its point-of-sale data once the owner turns that on (section 2), answer visitors' questions about Paloma with the assistant on this website and learn from those chats what the website leaves unclear (section 4), learn from feedback sent to us what to change in Paloma (section 4), pass a guest's reply to our texts to the business that sent them, receive the messages guests send to the business's own WhatsApp number and draft the replies the business approves (section 2), tell the merchant's team about things that need them, find and fix what went wrong in Paloma when a user rated an answer or asked our team for help (section 4), and keep the service secure and reliable. We do not sell personal information, and we do not share it for cross-context behavioural advertising.

Mobile numbers and text messages. We use a caller's or guest's phone number only to send the messages described in our SMS terms for the business the person called or ordered from, to pass a reply to those messages to that business (section 2), to stop texting a number whose owner asked us to — by replying STOP, in other words, or through the business that read the request in a reply (section 2) — and, if a guest signs in, to sign them in. The mobile number a user confirms in the app is used only as section 4 describes. We do not sell mobile numbers, and we do not share mobile numbers or text-message opt-in data and consent with third parties or affiliates for their marketing or promotional purposes; only Twilio and the mobile carriers that deliver the messages receive them.

AI tools the business connects. An owner or manager can connect an AI tool the business chooses to Paloma in one of two ways. They can create an API key in the app for a tool such as Claude Code, Cursor, Grok Build (by xAI) or the business’s own software; the tool can use only the assistant’s tools that the key’s role allows, under the same rules as the assistant in the app, including approvals, and a key never has more rights than the person who created it. Unlike the connection below, such a tool receives whatever those tools return to that person, which can include details of the business’s guests, such as their names, orders and messages, and the names and words of reviewers. Or, from ChatGPT (by OpenAI), Claude (by Anthropic, in any of its apps, including Claude Code on their own computer), Grok Bot (by xAI) or Cursor (by Anysphere), they can add PalomaCEO.ai — directly or by installing our plugin for Claude, Grok Bot or Cursor — and allow it for one business on our consent page; that connection can use only the areas the person allows on that page — the business’s social media, its menu in Paloma, its website and ordering page, its online ordering and delivery settings, and its sales and reports (read only). Within them it can read and prepare; every change it asks for that guests or the public would see, or that changes how the business takes orders or delivers — such as a post, a dish or price, a published page, a promo code or courier settings — waits in the app until an owner or manager approves it there (a post can also be approved by the person tapping Publish on our post card that ChatGPT shows them, a button only the person can press; the AI cannot). It cannot change the business’s point-of-sale system, refund or charge anyone, write to the business’s guests, spend the business’s balance, or change its team, phone or payment settings, and it never receives the names, phone numbers, email addresses, addresses or messages of the business’s guests or staff, or the names or words of reviewers. The connection stops working when the person who allowed it leaves the business, is no longer its owner or manager, or resets their password. To set up that connection, our server reads the public description that ChatGPT or Claude publishes about itself on chatgpt.com or claude.ai (for Grok Bot and Cursor nothing is read: their sign-in address is set in advance); nothing about any person is sent in that request. When the user attaches a photo in ChatGPT, or ChatGPT makes a picture at the user’s request, and the user asks for it to be used, ChatGPT gives our server a temporary link to that file on OpenAI’s file storage; our server downloads the file once from that link, sending nothing about any person, checks it as it checks a picture link written in the app’s chat — it does not keep a picture whose own file names someone else as its author or rights holder, and at most 20 such pictures a day per business — and keeps it unchanged among the business’s pictures in the business’s own storage, where it is handled like a picture uploaded in the app (section 11). A picture that its own file marks as made by AI, or that the AI tool reports it made, is kept marked as AI-made and is labeled as AI-made where it is published. What the tool receives from Paloma — such as channel names and accounts, the words, times and status of posts, links to the business’s pictures and videos, the posts left this month, the menu with prices and photos, the website’s pages and visit counts, ordering, delivery and promo settings and courier prices, sales totals, top items, stock levels, month-by-month totals, the orders behind the value report (time, order number, channel and amount), the AI balance, the business’s name and, in ChatGPT, a code valid for one hour that lets only our post card approve that one post — is sent at the business’s direction; the tool’s provider handles it under the business’s own agreement with that provider, not under this policy, and is not our sub-processor. Grok Bot and Cursor both connect through Cursor’s connector service (Anysphere), which keeps the sign-in we give the connection until it is disconnected and passes the requests and what the tool receives; in Grok Bot, xAI’s models process it. We do not send the tool the user’s email address or phone number. Owners and managers can see each key and each connection, when it was last used, and revoke it in the app at any time.

7. Data obtained through the Clover, Square and PalomaPOS APIs

Data we receive through the Clover APIs or the Square APIs is used solely to provide Paloma to that merchant, in line with the Clover Developer Agreement and App Market policies for Clover data and Square's developer terms for Square data. It is not sold, not shared with other merchants, not combined into products for third parties, and not used to train models. When a merchant revokes access or disconnects the account in the app, we stop using that account's access at once. When a merchant uninstalls Paloma in Clover, we stop as soon as Clover confirms the uninstall to us — when Clover's record of our app shows it is no longer installed for that merchant, Clover refuses our access, or Clover marks the app inactive. We check when Clover tells us of the uninstall and once a day for every account; if Clover has not confirmed an uninstall it told us of within about a week, our team looks into it. If Clover stops renewing our access to an account without confirming an uninstall, the app and an email to the business's owners ask them to connect Clover again; if it is still not reconnected 30 days after the first such email, or once 60 days have passed since Clover stopped (30 days, if we cannot reach any owner by email), whichever comes first, and it is the business's last point-of-sale connection, we treat Paloma as uninstalled for that account and stop using it at our next daily check after that period, never earlier. Disconnecting in the app first stops it at once. If it was the business's last point-of-sale connection, the business's data is deleted as described in section 11; if the business still has another point-of-sale connection, the locations of the disconnected account stop taking orders and the history it already provided stays with the business.

PalomaPOS. PalomaPOS is a point-of-sale system that we, PalomaFinTech LLC, also offer. It is a separate service: this policy covers Paloma, and how PalomaPOS handles a merchant's data as its point-of-sale system is governed by the merchant's agreement for PalomaPOS, not by this policy. Paloma connects to PalomaPOS the way any other app can: only through PalomaPOS's public Platform API, after the merchant's owner signs in at PalomaPOS and approves, on PalomaPOS's own consent screen, the access Paloma asks for — to read the account and its locations, catalog, orders, customers and staff, and to keep that access until the merchant ends it. Paloma has no other access to PalomaPOS's systems or data; being one company gives it none. For now Paloma only reads: we send PalomaPOS nothing but the requests to authorize Paloma, to renew and to end that access, and to read the merchant's own data, and no data about the merchant's guests, staff or orders goes from us to PalomaPOS. Data we read from PalomaPOS is used solely to provide Paloma to that merchant, and the rest of this section applies to it as to data from Clover and Square. We never pass to PalomaPOS data we receive from Clover, from Square or about any other merchant. When the merchant disconnects PalomaPOS in the app, we stop reading it at once and end Paloma's access at PalomaPOS; when the merchant removes Paloma at PalomaPOS, or PalomaPOS ends our access, we stop as soon as PalomaPOS refuses it. Either way the PalomaPOS locations are closed in Paloma and the history already read stays with the business as its records until the merchant deletes the business (section 11); disconnecting PalomaPOS does not by itself start the deletion described there.

A merchant may connect its Facebook Page, the Instagram professional account linked to it, and its Google Business Profile, so that the assistant can publish the business's posts there. Each channel is connected by the merchant's owner through the platform's own sign-in and consent screen, and the owner chooses which Pages and which business locations Paloma may use.

What we receive from Meta: for each Page the owner chose, the Page's name and ID and an access token for that Page, and, where an Instagram professional account is linked to the Page, that account's ID and username. We use them only to publish posts to that Page and that Instagram account, to check how many more posts Instagram allows that day, and to tell the owner in the Inbox that the Page is connected and whether an Instagram account is linked to it. If the owner turns on reposting, we also read the Instagram account’s own new posts — caption and media — to offer each one as a card for the owner’s other channels, and the text and time of the Page’s own recent posts only to check that Meta has not already shared that post to the Page, so it is not published twice; we do not store the Page’s posts. We do not read the Page's or the Instagram account's messages, comments, followers or audience data. When the owner asks the assistant about the business's channels or its Instagram posts — for example, to find a post to carry to another channel — the assistant's language model (Anthropic, section 10) receives the names of the connected Page and Instagram account and the words (up to 160 characters of each) and dates of the account's newest posts.
What we receive from Google: access to the merchant's Google Business Profile through the business.manage permission. We read the business accounts and locations the owner manages — each location's name, title and address, so that the owner can choose the locations to post to — and we publish posts to the locations the owner chose and set their "Order online" link to the business's ordering page. For the locations the owner chose we also read the profile's own details — the business's name, phone numbers, regular and special hours, address or service area, website, categories, description and whether Google shows it as open — when the owner connects the profile and then once a day, so that Paloma can fill in the business's profile. We also read the profile's figures from Google for the locations the owner chose — how many times it was shown in Google Search and in Maps, on a phone and on a computer, and the taps on its call button, its website link and its food menu, the direction requests and the bookings made from it, by day for the last five weeks, and up to 100 search terms people used to find it in the last whole month, each with Google's count (or only "fewer than" a number, when Google gives no more) — once a day, and again whenever the owner or a manager asks the assistant about them, to show them to the owner and managers in the app's assistant and in one line of the morning summary. They are Google's counts, not visitors, calls answered, visits or customers, and Paloma does not turn them into money or orders. They are never shown to the business's staff or its guests, put on its site, ordering page or posts, or sent by email, Telegram or to AI clients a business connects to Paloma. When the name, main phone number, regular opening hours or public address there differs from what Paloma has — except hours that Paloma itself keeps in step on Google, described below — we show Google's version to the owner and managers in the app as a card; nothing from the profile reaches the business's site, ordering page or phone assistant until the owner or a manager approves that card, and we never show an address the profile does not show or work one out from its service area. If the owner or a manager chooses on the card to keep the details on it in step with Google, later changes to them on the profile are applied in Paloma by themselves and the app says so each time, until that detail is changed in Paloma or Google is disconnected. When Google shows a location as closed, we tell the owner in the app and change nothing. Paloma may also set what kind of business it is — a restaurant, a store or another kind — and whether its customers order, book a time or send a request, from the profile's main category, unless the owner or the business's point of sale has already said; the owner can change it at any time, and we keep only that kind, not Google's category. From the profile Paloma may also tell the owner and managers that its description is short, no additional category is listed, it was shown more often while calls did not grow, its newest review is over a year old or there is none, or its hours differ from Paloma's; we keep only that yes-or-no, never Google's text, figures, hours or dates. From the same category Paloma may mark the business as a healthcare practice, whose calls Paloma does not answer (Terms of Service, section 9); we keep only that mark — who set it and when — not the category, and it stays until our team takes it off. When the owner or a manager declines a detail, we keep only a one-way fingerprint of it, so that it is not proposed again, and only while Google still shows it. Each time the owner connects the profile, for each chosen location that names a website, and only for a business that is active in Paloma and has AI balance left, our server also reads that website once: its home page and at most two more pages of the same site that the home page links to, by our reader, which introduces itself as PalomaCEO-menu-reader/1.0 (+https://palomaceo.ai), only asks for public pages and never fills in a form or signs in. It never reads a page of a social network, marketplace, delivery, booking or review service, a link-in-bio page or Google's own pages, and nothing the site's robots.txt closes to any of our readers or to all robots. The pages' words go to our language model provider (Anthropic, section 10) only so that it can draft what the business does and the services or products it sells, with their prices as the site writes them; the words are not kept, and the draft leaves out every email address and phone number, even the business's own. The draft is shown only to the owner and managers, in the app, as one card “From your website”; if the owner or a manager approves it — after removing a service or changing the words, if they wish — we keep the description and the services, with the site's address and the day it was read, as the business's own information, and the assistant in the app uses them to know what the business does. They are not shown on the business's site, its ordering page or its calls. Nothing from the website is used until that approval. When the owner or a manager asks Paloma to compare the profile with what Paloma knows, or the owner approves a card asking Paloma to bring it in line (Terms of Service, section 4), we also read each connected location's website, opening hours and other kinds of hours, menu link, ordering links and reservation links, which of these Google offers for the location's category, and which of them Google itself has changed or is reviewing — those we never change; when the owner approves the card, we write the location's opening hours and, with the same hours, its pickup and delivery hours, its "Order online", "Order pickup", "Order delivery" and menu links to the business's ordering page and, for a location that takes table bookings through Paloma, its "Reserve" link to that location's booking page — each with a tag in the link's address that tells the page's statistics the visit came from Google and through which link — and its website link, when the profile has none, already shows the business's Paloma page, or the owner asked to replace it. If the card the owner approves says that Paloma will keep the hours of the locations it names in step, we then, once a day until the owner stops it or disconnects Google, read those locations' opening, pickup and delivery hours and whether Google has changed or is reviewing them, and, when a location's hours in Paloma have changed, write its new opening, pickup and delivery hours. We never write over hours that the business, its team or Google changed on Google after us: we tell the owner instead. To tell those apart we keep, for each location, only a fingerprint of the hours we ourselves last set there and a one-way fingerprint of the access the owner connected with (connecting again needs a new approval), and, until it is delivered, the in-app note about a change we made — never a copy of what Google shows. Where Google lets a location show a menu and the card the owner approves names it, we also, within minutes of the approval and then once a day until the owner stops it or disconnects Google, write that location's menu — the sections, names, descriptions and prices of the items it sells online, other than alcohol and items for adults only, never allergens, diets, calories or ingredients — in place of the whole menu the profile showed, and, where the card names them, add real photos of those items, at most 10 a day, which Google fetches from the business's Paloma pages: never a picture made by AI or a photo taken from Open Food Facts. We send the menu again only when it has changed in Paloma, and only after reading the menu on the profile: if the business, its team or Google changed it since we last wrote it, we write nothing and tell the owner. For this we keep, for each location, a one-way fingerprint of the menu we last sent and of the menu as Google returned it right after, and, for each photo we sent, our own photo's id with Google's reference to it, also after the owner stops this or disconnects Google, so that a photo is never sent twice — never a copy of the menu or the photos Google shows. The JPEG copy of each photo that Google fetches is kept with the business's other pictures. We never remove a photo from the profile. Only when the owner asks the assistant for it, and then approves a card for that one edit, do we also change a location's description or add to its categories. The assistant's AI model (Anthropic, section 10) drafts the description in that conversation from the business's own details in Paloma; to offer categories, we send Google a few English words the assistant chose for what the business does, with the location's country, and get back Google's names for the categories that match, which are kept like the profile's details shown in a conversation, below. When the owner approves, we read that location's description or categories again, and whether Google has changed or is reviewing them, and write nothing if they changed since the card was made or Google holds its own change to them; otherwise we put the description on the card in place of the one there, or add the categories on the card to those already there, never changing the main category or removing one. Paloma's team cannot approve such a card for the owner, and nothing changes the description or categories on a schedule or by itself. Of each edit we keep the card, with the description or the names of the categories the owner approved (on a card not approved, Google's category names are removed 30 days after it was made), and a one-way fingerprint of what we wrote, until Google is disconnected; never a copy of what the profile showed before. We do not change the profile's name, address, phone number or main category, change its menu and photos only as described above, and do not remove anything from it; what we changed is reported to the owner in the app. We keep a refresh token so that scheduled posts go out, and the hours, menus and photos of dishes the owner lets us keep in step are kept, when the owner is away. We also read the reviews of the locations the owner chose — each review's star rating, its text as Google returns it (a text Google translated stays marked as Google's translation), the reviewer's name as Google displays it and whether the review is anonymous, its dates, and the business's own reply, if any — and each location's average rating and number of reviews, so that the owner can see and search the business's reviews, get a note about a new review with one to three stars, and ask the assistant about them. We do not keep reviewers' profile photos. Paloma does not report or remove reviews. It publishes a reply to a review, in the business's name, only when an owner of the business approves that reply on a card in the app that shows the review and the exact words of the reply, which the owner may change first; only the owner sees these cards — not managers or other staff — Paloma's team cannot approve one, and nothing is replied on a schedule or by itself. Just before publishing, we read that review again and publish nothing if, since the card was made, it was changed or removed or got another reply. A reply is drafted when the owner asks the assistant for one, or — only for a business whose owner turned this on with a card in the app — for each new review by itself: then the review's stars and words and the first word of the reviewer's name as Google displays it go to our language model provider (Anthropic, section 10), with the business's name, kind and its own phone number, and the draft becomes a card in the Inbox. Nothing about the business's guests — their orders, calls, phone numbers or other details — is given to the model for a reply. A card about a review shows the review's stars, words and reviewer's name as Google returned them; 30 days after the card was made, or at once when Google no longer returns that review or Google is disconnected, they are replaced on the card by a short line and a card still waiting expires; of a published reply we keep its words, the review it answers by Google's identifier, and who approved it and when, as the business's own words. A business that Paloma marks as a healthcare practice gets no drafts and no replies through Paloma. If the owner turns it on with a card in the app that shows its exact words, the page of each order a guest placed with the business through Paloma — by phone or on its ordering page — shows, once the order is ready or delivered, a link to write a review of the business on Google. The link is the location's review link from its Google Business Profile, which we keep only while Google still returns it and never for more than 30 days after we last received it, or a link made from Google's identifier of the place. Every such guest sees the same words, whatever they ordered, paid or said; the page sends Google nothing about the guest or the order, not even its own address, and we do not record whether a guest follows the link. Paloma does not text, email or notify guests to ask for a review. We keep a copy of a review only while Google still returns it, and never for more than 30 days after we last received it from Google; a review its author or Google has removed leaves Paloma at our next daily check. We keep the profile's details and figures the same way — a copy only while Google still returns it, and never for more than 30 days after we last received it from Google; our copy of the figures holds them only as Google returned them, never added up, and each daily read replaces the last — except the details the owner or a manager has approved, which then are the business's own profile in Paloma; on a card, 30 days after it was made, only the details it actually saved for the business stay; Google's other details on it, and the assistant's answers to the owner's words on that card, are replaced by a short line — at once, for a card still waiting, when Google is disconnected. A note about a new review shows only its stars, location and date. When the assistant has shown or quoted reviews, the profile as Google returned it, or the profile's figures in a conversation, it sees what Google returned only in that turn and in the user's next two messages in that conversation; after them it sees only a short line in its place. What it was given from Google, and every answer it wrote while that data was open to it, are replaced in the conversation by a short line 30 days after the turn that read it — or, for figures shown from Paloma's earlier read because Google could not be reached at that moment, 30 days after Google returned them; the user's own messages stay. The summary and title of a conversation, which the assistant writes for itself, never carry what came from Google. Our diagnostic traces of the turns after the one that read Google keep none of the words the assistant was given or wrote; the trace of that turn itself is deleted like every diagnostic trace (section 11). The morning summary in the app may show how many new Google reviews came in, their stars and Google's rating, and the profile's figures for the last week Google has counted; 30 days after a summary was written, each of those lines is replaced by a short line and those figures are deleted from it. Reviews, the profile's figures, and the profile's details until they are approved, are available only to the owner and managers in the Paloma app, not to AI clients a business connects to Paloma. A business's reviews, profile details and figures are used only for that business: we never combine them with another business's or count the figures in what Paloma reports it earned for the business, and never match a reviewer to the business's customers, orders or calls.
Through Zernio, until a channel moves to our own app. Until Meta approves our app for Facebook and Instagram, and until Google approves ours for the Business Profile, the owner may connect these channels through Zernio (ZERNIO SOFTWARE SL, Spain), our publishing sub-processor (section 10). The owner then signs in on the consent screen of Zernio's app rather than ours; Zernio holds the platform's access, and we keep only the ids of the owner's profile and account at Zernio. We send Zernio only the approved post — its text, a link to its media, the posting settings and, for Google, the ordering page's address; for an Instagram post the owner approved to carry to a channel that goes through Zernio, that is the post's words as fitted to the channel and its picture or video copied from Instagram — and never guest, order, call or messaging data; we do not use Zernio to read reviews, comments or messages. Reposting from Instagram reads posts only through our own app. Disconnecting the channel in the app removes our connection at Zernio, and Zernio then erases the platform access it held for it. A channel connected through Zernio keeps posting through it after the platform approves our app, until the owner connects that channel again through our app, which the Connectors screen then offers; once the channel is connected through our app, its posts go through our app, we remove its connection at Zernio, and Zernio then erases the platform access it held for it. The same happens when our app is approved for a channel the business has already connected both ways. Nothing is removed from the business's own account on the platform, and the account keeps one monthly price (Terms of Service, section 3).
Nothing is published without the owner. The assistant proposes each post — its text, picture or video, channel and time — as a card in the app (or, when the owner works in ChatGPT, as the same card shown there), and it is published only after the owner or another user with the owner's authority confirms that card. What we send to Meta or Google is the post's text and its picture or video, which the platform fetches from a link that works for a short time. We keep a record of each post — its text, picture, channel, time, status and the platform's reference to the published post — in the merchant's own database.
How the data is protected and shared. Access tokens are stored encrypted and are used only by our servers to act for that merchant. Data received from Meta and Google is not sold and not shared with other merchants or other third parties, except the sub-processors that handle it only to provide Paloma for us (section 10) — Akamai, which hosts it; Anthropic, whose model reads it when the owner asks the assistant about the business's channels, posts, reviews or Google profile and its figures — including a card with details from that profile — or to update that profile, and when Paloma reads the business's own website once to propose what it does and sells; Zernio, for a post that goes through the bridge; and GitHub, whose logs of our engineering work can carry a Page's or account's ID — and the platforms to which the owner confirms a post. It is not used for advertising or to train, fine-tune or evaluate AI models. Paloma's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Disconnecting and deleting this data. The owner can disconnect Facebook and Instagram, or Google Business Profile, on the Connectors screen of the app at any time. Disconnecting deletes the stored access tokens at once; for Google we also revoke the token at Google and delete our copies of the business's reviews and of its profile's details and figures, the details on cards nobody has approved, and the Google figures in its morning summaries, at the same time, and stop keeping details in step with Google; details the owner or a manager approved stay in the business's profile in Paloma, and so does what they approved from the business's website. Scheduled posts for a disconnected channel are not published. The owner can also remove Paloma from the Facebook account's settings (Business integrations) or from the Google Account's third-party access page; the platform then stops our access, and we delete the stored token as soon as the platform reports it no longer works. To have the records of the business's posts deleted as well, the owner can delete the business as described in section 11, or write to privacy@palomaceo.ai from the account's email address, and we delete them within 30 days. Posts already published on Facebook, Instagram or Google belong to the business and stay there until the business removes them on that platform; so do the hours, menu and photos Paloma put on the Google profile.

9. No AI model training

Merchant data, caller data, call recordings, conversations with the assistant and voice input are used only to provide the service — to produce the answer, the order or the notification at the time — and, for an answer a user rated or a request for help, to find and fix what went wrong (section 4), and calls also as described below to improve the service. We do not use them to train or fine-tune machine-learning models, or as material to test models on, except as described in the rest of this paragraph. To keep calls working, at the end of each call our software — not an AI model — looks through the call's transcript for signs that it went wrong, such as an answer said twice, an answer in another language than the call's, or an item called unavailable that the menu sells; the business sees these signs on the call's card, and our team sees which signs appeared, on which call and business and with which voice provider (section 3), and uses their counts to fix Paloma and to choose which provider runs calls. For a call that opens with the statement that it is recorded for quality and starts after the business it was made to agreed to this review under our terms of service (a business that joins Paloma after this was posted agrees when it joins; one that joined earlier, 14 days after we told it in the app or when its owner accepted it, whichever came first) — or to one of Paloma's own businesses — we also use its transcript to build and improve our own service, as the law allows a service provider: after the call, our language model provider (Anthropic, section 10) reads the transcript within that business's data and writes a short finding — the kind of problem, the steps the assistant took and how long they took, and a retelling of the turn that went wrong without names, phone numbers, email or street addresses, card or order numbers. Only such findings, with the business and call they came from, leave that business's data — to our team and the AI tools we build Paloma with — and they are deleted after 90 days. Within 30 days of such a call, a member of our team may read its words, with phone numbers, email addresses, card numbers and street addresses hidden, in our own administration screen, and only when the checks or the review found a problem on it or the business rated it or asked us for help about it; each reading is logged with who read which call and why, the words are not copied out of that business's data or given to any AI tool, and what we learn is used only to change Paloma, never to serve another business with what a caller said. A call whose caller asked not to be recorded, whose statement about AI and recording did not play to its end, or that only left a message after the tone, is not reviewed this way; no one listens to a recording for this review. Our own quality tests run on made-up sample businesses and made-up callers, including a test we add after an answer was rated bad or a call went wrong. Only a test call that our own team placed to one of Paloma's own businesses, from a mobile number a team member confirmed in the app (section 4), may be read back — with long numbers removed — by our team and the AI tools we build Paloma with, and replayed in a test: what our team member said is spoken by a computer voice of Twilio into a made-up sample business on our test system, where a voice provider from section 3 answers it. Through October 18, 2026, a call placed to the customer business that tests its launch week with us, from a mobile number one of its people confirmed in the app (section 4), may also be read back the same way, but is never replayed; calls to that business from any other number are not read back. A test call that a member of our team places, from the mobile number they confirmed in the app, to a customer business they are a member of may also be read back the same way, and its recording checked, at any time, but is never replayed; on such a call only what our team member and the assistant said is read, never the words of anyone the call was passed to. Feedback sent to us (section 4) is read by our team only to decide what to change in Paloma and to reply; its words are never sent to a model provider, except that messages typed to the assistant on this website were sent to Anthropic to answer them before they were sent to the team. Chats with the assistant on this website (section 4) are sent to Anthropic only to write each answer, are read by our team only to see what the website leaves unclear, and are not used to train, fine-tune or evaluate models; our tests of that assistant use made-up questions. To provide the service we reach model and speech providers through their developer APIs, not their consumer apps. Every request we send to Deepgram — for calls and for voice input in the app — carries Deepgram's opt-out from its model improvement program. WhatsApp messages (section 2) go to our language model provider only to draft the reply to that conversation. They are never used to train, fine-tune, evaluate or improve any AI model, ours or a provider's; our tests of WhatsApp drafts use made-up messages only, and a rating of a WhatsApp draft keeps only the rating, never the guest's words. The AI voice providers that may run a call (section 3) do not use it to train their models under their terms with us, and xAI runs our calls with zero data retention.

10. Sub-processors

Sub-processor	Purpose	Location
Akamai (Linode)	Hosting, databases, object storage	United States
Anthropic	Language model (assistant reasoning in the app — including, for a merchant that connects social channels, the names of its connected accounts and, when the owner asks about them, the words and dates of the business's own newest Instagram posts and the business's Google reviews — their stars, words, dates, replies and the reviewers' names as Google displays them — and, for a business whose owner turned on reply drafts, each new review's stars and words and the first word of its reviewer's name, to draft a reply (section 8), and the details and figures of its Google Business Profile, with the search terms people used to find it, and the figures of its site in Google Search, with the searches it was shown for (section 2), and the words of the pages of the business's own website that Paloma reads once after the profile is connected, and, for a business that starts its menu in Paloma, the photo of the menu or the text of the page of its own website that an owner or manager gives the assistant — and the answers of the assistant on this website, for which it receives the visitor's messages, the page they are on and our public website's text; and, on calls not run on an AI voice model (section 3), the words of the call as text and what the assistant looks up during it); and, for a merchant that connects its WhatsApp Business number, the guest's message and the earlier messages of the same conversation, and the business's information the assistant looks up, to draft a reply the business approves (section 2); also the AI agents that help us build and fix Paloma, which get error and problem reports and counts with our internal identifiers of businesses, never the words of requests for help, ratings, feedback or chats with the assistant on this website	United States
OpenAI	Generating illustrative images of menu items and banners the merchant asked for, when that kind of picture is assigned to OpenAI; receives only the item name, its menu description, category and page style (for an option guests choose for an item: the option’s name, its group and the name of one item that offers it), the merchant's own words about how the item should look and up to three pictures the merchant attached, or chose from its own items’ pictures, as a sample of the item or of the style wanted for it, re-encoded without their metadata, or for a banner only the merchant's own words about it — no customer data in these requests; and, for calls run on OpenAI's voice model (section 3), the caller's voice for the length of the call, the assistant's instructions for that business and what it looks up during the call, returning the assistant's voice and a transcript, which OpenAI may keep for up to 30 days only to detect abuse	United States and other countries where OpenAI processes requests
Google (Gemini API)	Generating atmosphere videos without any specific product (one short clip of at most 8 seconds for each video, never cut together from several), and illustrative images of menu items and banners when that kind of picture is assigned to Google, that the merchant asked for; receives only the kind of business and its cuisine or product category, the item's name, menu description and category (for an option: its name, its group and the name of one item that offers it), the page colours, the time of day or season, the merchant's own words about the scene, the banner or how the item should look, and, for an item's picture only, up to three pictures the merchant attached, or chose from its own items’ pictures, as a sample of the item or of the style wanted for it, re-encoded without their metadata — no customer data, and nothing but words for a banner or a video	United States and other countries where Google has facilities
Google Maps Platform	Address suggestions in the delivery form of an ordering page, receiving only the partly typed address, without the customer's name, phone number or order; and the business scanner (section 4): suggestions for the business name a visitor types, the Google listing of the chosen business and of businesses of its kind nearby, and searches such as “georgian restaurant in Aventura” — receives only what is typed, Google's identifier of the place and those searches, from our server, never the visitor's IP address, name or contact details	United States
Google PageSpeed Insights	The business scanner (section 4): how the public website of the scanned business loads on a phone, with a picture of its screen; receives only the address of that website	United States
Google Search Console	So that Google finds the pages we serve for a merchant: verifying each site we serve in Google Search Console under our own Google account, sending Google the address of its list of pages (sitemap), and reading back Google's figures of how the site appears in Google Search and which of its pages Google has in its index (section 2); on a merchant's own domain at its owner's request, making the Google account addresses the owner names owners of the site there and taking them off again, and the owners they add when the owner asks (section 2); receives the public addresses of the site, its pages and that list, and those Google account addresses	United States
Deepgram	Speech recognition for calls not run on an AI voice model (section 3) and for voice input in the app; backup speech synthesis for those calls and for the assistant's fixed sentences on any call, receiving only the text it speaks	United States
Cartesia	Speech synthesis for calls not run on an AI voice model (section 3), and the voice of the assistant's fixed sentences on any call when the voice model's own speech synthesis does not stream speech as it is made, fails, or no AI takes the call — such as its first words, which may include the caller's first name; receives only the text it speaks	United States
xAI (SpaceXAI LLC)	Running calls on xAI's voice model (section 3): receives the caller's voice for the length of the call, the assistant's instructions for that business and what it looks up during the call, and returns the assistant's voice and a transcript; also speaks the assistant's fixed first words; with zero data retention, it keeps nothing once each reply is delivered	United States and other countries where xAI processes requests
LiveKit	Real-time media transport and recording for calls that do not yet come straight from our phone carrier to our own servers	United States
Twilio	Telephony and SMS — including carrying a call's audio between the caller and our own servers, passing a call to the business's phone with the short line its team may hear first, which can carry the caller's first name and up to ten words on why they asked for a person, speaking fixed sentences from their text, and taking a message a caller leaves when nobody answers or the assistant cannot take the call, whose copy at Twilio is deleted once we have stored it (section 3); and Twilio Verify, which creates, sends — by text, or through Meta's WhatsApp for a number outside the United States and Canada — and checks the one-time code that confirms a user's own mobile number (section 4) — it receives that number, the language of the app and the code typed	United States
Telegram (Telegram Messenger Inc.)	For merchants whose owner connects the team's own Telegram group: delivering messages about the business's orders to that group (new orders, and orders that need the team); receives the order's items, total, type and time, where it came from, the guest's first name and note, for a courier still without a driver the delivery company and how long it has been looking, and a link to the order's page for the team — no phone number, surname or address. Separately, Paloma's own operations alerts to a Telegram chat of Paloma's staff: the kind of problem (a server, a backup, a vendor, a business's database, Paloma's own spending with a vendor, or a failed order), the server or vendor concerned, the address name of the business affected, the reference number of a failed order and the short error text our system recorded for it, with email addresses, phone numbers and card-like numbers removed before sending; a weekly count of requests for help and ratings by kind, without the words or the businesses' names; a note that a request for help, a request from this website or feedback is waiting for our team — for feedback, whether it came from this website or the app, its kind, the page or screen and, from the app, the sender's role — without its words, an email address, the business or the person who sent it; for chats with the assistant on this website, only counts by page and part of the page and how many questions went unanswered, never the words; the titles of our own engineering tasks that wait for a person at Paloma; a note that a daily limit for all of Paloma on sign-ups or verification codes has been reached, naming only the limit; and a message about each new business — its name and address name, the email address of the person who added it with everything but its first letter and its domain hidden, which of the two confirmations are done and how it was activated, never a phone number — never sent to a business's group	Telegram's own data centres in several countries
Postmark (ActiveCampaign)	Email to users of a merchant account: password reset, address confirmation, team invitations, whether their business was activated, monthly summary, product news; no customer data	United States
Amazon Web Services (Amazon SES, Amazon SNS)	For merchants whose owner turns on emails to guests: sending the emails section 2 describes to guests who chose the merchant's offers and news, and the one email that asks them to confirm their address, and telling us which were delivered, bounced or marked as spam; receives only the guest's address, the email's subject and text, and our reference for the email; scans emails to block spam and malware, and keeps an address that bounced or was marked as spam on that merchant's suppression list until we remove it	United States
OrderOut	Marketplace orders into the merchant's point of sale, and courier delivery for orders placed with Paloma, including the courier's progress we show to the guest and to the business's staff (section 2); the delivery company that takes a delivery, such as Grubhub, DoorDash, Uber or Relay, gets from OrderOut what its driver needs (section 2)	United States
Cartwheel (GR Dispatch Inc.)	For orders placed with Paloma whose courier we book through Cartwheel: passing the delivery to the delivery company that takes it and returning the delivery's progress — the stage, the delivery company, the driver's name as that company shows it, the driver's position, the expected times and a tracking link (section 2); receives the business's name and the pickup location's address, phone number and pickup instructions, the customer's first name, phone number, delivery address and delivery instructions, whether to leave the order at the door, the order's amount before tax, fees and tip, and the courier tip — never the order's items, the customer's email address or payment details; it passes what is needed to price and carry the delivery to Uber (Uber Direct) or DoorDash (DoorDash Drive), each under its own agreement with Paloma (section 2), and does not sell this information	United States
First Delivery (First Delivery, Inc.)	For orders placed with Paloma whose courier we book through First Delivery: getting delivery prices, passing the delivery to the delivery company in its network that takes it, and returning the delivery's progress — the stage, the delivery company, the driver's name, the kind of vehicle, the driver's latest position, the expected times and a tracking link (section 2); receives, for a price, only the pickup location and the delivery address, and, to book the courier, the business's name and the pickup location's address, phone number and pickup instructions, the customer's first name, phone number, delivery address and delivery instructions, the order's amount before tax, fees and tip, and the courier tip — never the order's items, the customer's email address or payment details; it passes what a driver needs to the delivery company that takes the delivery (such as Uber, DoorDash or Relay), and its own texts to the customer are turned off for our account. Under its Terms of Service with us, First Delivery may use this information to provide, support, secure and improve its service but never to train AI models on it, keeps it confidential, deletes it when we ask, and tells us of a security incident affecting it within 72 hours. First Delivery's own privacy policy also applies to this information, and that policy says First Delivery may sell personal information	United States
Apple, Google, Mozilla, Microsoft (push services)	Delivery of encrypted notifications to the devices of users and guests who turn notifications on, and to a business's order tablets where it allows them; a notification carries only the business name and a fixed line for the kind of event (for a guest's order, at most the courier's estimated arrival time; on an order tablet, the order number and the marketplace it came from) — no customer details, amounts or conversation text	Chosen by the user's device and browser
Stripe	Payment pages for orders (Stripe Checkout) for merchants who use Stripe, payments merchants make to us to add funds to their balance, and the card a merchant saves with us to pay for couriers and the charges to it; receives what section 5 lists — for payments to us, the business name, the owner's email, the amount and, for couriers, the order number	United States
Clover (Fiserv, Inc.)	For merchants who connect Clover: the point-of-sale data in section 2, placing orders and customers in Clover, and Clover Hosted Checkout payment pages	United States
Square (Block, Inc.)	For merchants who connect Square: the point-of-sale data in section 2, placing orders in Square, Square-hosted payment pages, and the business's own Square gift cards (section 2)	United States
PalomaPOS	For merchants who connect PalomaPOS, a point-of-sale system that PalomaFinTech LLC, which operates Paloma, also offers (section 7): reading the point-of-sale data in section 2 with the merchant's consent (section 7); receives from us only the requests to authorize, renew and end Paloma's access and to read the merchant's own data — no guest, staff or order data	Where PalomaPOS keeps the merchant's account; we send it no personal data
Meta Platforms	For merchants who connect Facebook or Instagram: publishing the posts the owner approved to the business's own Page or account; with reposting on, reading the Instagram account's own new posts and the text and time of the Page's own recent posts (section 8)	United States
Meta Platforms (WhatsApp Business Platform)	For merchants who connect their own WhatsApp Business number: receiving the messages guests send to it and the business's replies from the WhatsApp Business app, sending from it only the replies an owner or manager approved, marking messages read, and managing the connection, including filling in Meta's sign-up window with the business's own name, email address (the business's, or the confirmed address of the person who added it), website or ordering page, and the address, phone number and time zone of its location (section 2); the business's WhatsApp account and its messages are held by Meta under the business's own agreement with Meta; and, as Twilio's provider, delivering by WhatsApp the one-time code that confirms the own mobile number of a user whose number is outside the United States and Canada (section 4) — it receives that number and the message with the code	United States and other countries where Meta has facilities
TikTok	For merchants who connect TikTok: publishing the video or photo the owner approved to the business's own account or, when the owner chooses, sending it to that account's TikTok inbox as a draft the owner finishes and publishes in the TikTok app; reading the account's name, nickname and posting options to show them to the owner, without storing them	United States, Singapore
Google (YouTube Data API, Google Business Profile)	For merchants who connect YouTube or their Google Business Profile: uploading the video the owner approved to the business's own channel, and publishing posts and the “Order online” link to the business's own profile, and, when the owner approves it, the profile's opening, pickup and delivery hours — and, if the owner lets Paloma keep them in step, their later changes, once a day — its ordering, reservation and menu links and its website link, and, where the owner approves it, the location's menu — the sections, names, descriptions and prices of the items it sells online — and real photos of those items, with the menu's later changes and new photos once a day	United States
Zernio (ZERNIO SOFTWARE SL, Spain)	Temporary publishing bridge for Google Business Profile, TikTok and YouTube until our own apps are approved, for a merchant's Facebook Page and Instagram professional account until Meta approves our app — and, for an account connected through it before then, until the owner connects that account through our app (section 8) — and for a merchant's LinkedIn company page and Threads account; receives the post text, media (for an Instagram post the owner approved to carry to another channel, its words and its picture or video copied from Instagram), posting settings, the profile id, the chosen Facebook Page and the order page address the owner approved; no guest, order, call or messaging data, and we do not use it to read reviews, comments or messages	European Union
GitHub (Microsoft)	Source code and container hosting; our engineering records — error and problem reports and counts, with our internal identifiers of the businesses affected, never the words of requests for help, ratings, feedback or chats with the assistant on this website; the logs of the commands we run on our servers, whose request lines can carry the ID a platform gives a business's account, such as a Facebook Page or Instagram account ID, and the read-back of a test call that section 6 allows	United States

We publish changes to this list on this page before a new sub-processor starts handling merchant data. Clover, Square and PalomaPOS are the merchant's own point-of-sale providers, and WhatsApp is the merchant's own messaging account at Meta: each holds the merchant's data under the merchant's own agreement with it, and they are listed here because Paloma exchanges data with them for the merchant. PalomaPOS is offered by PalomaFinTech LLC, which also operates Paloma; Paloma exchanges data with it only as section 7 describes. Open Food Facts, which we use to find photos of packaged products, receives only product barcodes and is not a sub-processor.

Paloma uses YouTube API Services to upload videos to a merchant's own channel. By connecting a channel you also agree to the YouTube Terms of Service; Google's Privacy Policy explains how Google handles your data. You can revoke Paloma's access to your YouTube data at any time at Google security settings, and in the app under Connectors → YouTube → Disconnect.

11. How long we keep data

Data	Retention
Call recordings	The retention period of the merchant's account — 30 days, or 7 days where a shorter period is set for the account — then deleted automatically; a recording of a call in which the assistant's statement about AI and recording did not play to its end is never made available and is deleted within two hours of the start of the call; a message a caller leaves when nobody at the business answers or the assistant cannot take the call (section 3) is part of that call's recording, or is that recording, and is kept and deleted with it, and our phone carrier's copy of it is deleted once we have stored it, within a day at most
The assistant's fixed sentences as audio (section 3) — they name the business and the assistant, never a caller	Until the business is deleted; a sentence with a caller's first name is not kept beyond its call
Copies of a call at the AI voice provider that ran it (section 3) — the caller's voice, the assistant's instructions and replies	xAI: none — with zero data retention, deleted once each reply is delivered; OpenAI: kept by OpenAI only to detect abuse of its service, for up to 30 days, then deleted by OpenAI
Conversations with the assistant in the app	Deleted automatically once a thread has had no activity for the period set for the merchant's account — 30 days, or 90 or 365 days where a longer period is set for the account; a user can delete their own thread at any time; what came from Google Business Profile, and the answers written while it was open, are replaced by a short line 30 days after the turn that read it, or sooner (section 8)
WhatsApp conversations — guests' messages, the business's replies from the WhatsApp Business app and through Paloma, and their delivery and read status (section 2)	Deleted automatically once a conversation has had no message for the period set for the merchant's account — 30 days, or 90 or 365 days where a longer period is set for the account — with the words of its reply cards; deleted with the business. A working copy of an incoming message in our job queue: at most a day. Pictures and voice messages: not stored by us
Earlier chats and contacts from the WhatsApp Business app	Not stored: discarded as they arrive (section 2)
The access Meta gives Paloma for a connected WhatsApp number, with the day it ends	Encrypted, until it ends (60 days after the connection), the owner disconnects WhatsApp or connects it again, or the business is deleted (it is kept, unused, while a deletion request can still be cancelled)
Voice input audio	Not stored; the recognized text is kept only if the user sends it, as part of the conversation
Transcripts, call cards, orders, catering requests, knowledge base, assistant notes and the log of assistant actions	While the merchant's account is active
Table bookings — the guest's first name, mobile number and request, the number of guests, the location, the day and time, the language, where it was booked, its status and a one-way hash of the key in its link	While the merchant's account is active, a cancelled booking included (marked as cancelled); deleted with the business
Courier's progress on an order — the driver's name as the delivery company shows it, the kind of vehicle, the driver's positions, and the map points of the restaurant and the delivery address	Only while the courier is on the way: removed from the order when it is delivered or the courier is cancelled or booked again, and in any case within about half an hour after the last reading; the stage of the delivery stays with the order. The driver's phone number is never kept
Copies of a delivery booked through Cartwheel, at Cartwheel (section 10) — the pickup details, the customer's first name, phone number, delivery address and instructions, the amounts sent, the delivery's progress, the driver's name and positions, and any photo or signature the delivery company took at the door	Kept by Cartwheel under its privacy notice and its agreement with us only to provide and improve its services, never sold, for as long as we require it; Cartwheel's terms let it keep a copy after our account with it ends. The delivery company that took the delivery keeps its own copy under its own terms
Copies of a delivery booked through First Delivery, at First Delivery (section 10) — the pickup details, the customer's first name, phone number, delivery address and instructions, the amounts sent, the delivery's progress, the driver's name and positions, and any photo the delivery company took at the door	Kept by First Delivery under its Terms of Service with us and its own privacy policy (section 10): it deletes them when we ask, and we ask it to when our account with it ends; until then, its privacy policy sets how long it keeps them. The delivery company that took the delivery keeps its own copy under its own terms
Ordering page visit statistics	13 months, then deleted automatically
Guest accounts on ordering pages — number, name, language, sign-up and last sign-in	Until the guest deletes the account, and otherwise while the merchant's account is active
Guests' email addresses — with each order, and on the merchant's email list with the guest's name, phone number and each choice to get or stop offers (when, page, location, language, version of the wording, daily keyed code of the IP address, and the business's offer it was made for, if any), the confirmation of the address, and each stop because the mailbox rejected our emails or its owner marked one as spam	While the merchant's account is active; a guest who stops the offers stays on the list only as unsubscribed, so that no offers are sent to them again; an address the merchant deletes at the guest's request is removed from the list; deleted with the business
Record of the emails sent to guests for a merchant (section 2) — the kind, address, location, language, subject, what it was sent for, delivery, bounce or spam report, and when; and on an order, which email it was placed from	While the merchant's account is active; an address the merchant deletes at the guest's request is removed from it; deleted with the business
Addresses on a merchant's suppression list at Amazon SES — after a bounce or a spam report	Until the business is deleted, when we delete them at Amazon SES
Saved delivery addresses of a guest	Until the guest deletes the address or the account; at most 10 per guest, and the one used longest ago is removed when an eleventh is saved; otherwise while the merchant's account is active
Guest sign-in sessions and the `pl_guest` cookie	90 days after last use and no more than 365 days after sign-in, then deleted by a daily cleanup; signing out or deleting the account deletes them at once
Home Screen app keys (iPhone and iPad) — a one-way hash of the key, the guest account and/or the order it points to, and when it was created, expires and was used	The key works once and for 10 minutes; the record is deleted by a daily cleanup once the key has expired, and at once with the guest's account
Guests' notification subscriptions — the push subscription address and encryption keys, the page language, the order or the signed-in guest's account, and when it was created and last reached	For an order without sign-in, until two days after the order (or its scheduled time, if later), then deleted by a daily cleanup; for a signed-in guest, until the guest turns it off on the page, the push service reports it gone or the guest's account is deleted, and no longer than 180 days without a notification reaching it
Guest sign-in codes — a keyed hash of the code, the number and a daily keyed code of the IP address	A code works for 10 minutes; the record is deleted by a daily cleanup once a day has passed since it expired
Counts of codes requested — guests' sign-in codes and the codes that confirm a user's own mobile number — and held back by the limits, and of wrong sign-in codes typed — keyed codes of the number, the IP address and its network, never the number or the address	48 hours, then deleted by a daily cleanup
Guests' replies to our texts — the words of each message, when it came, how many pictures came with it (never the pictures), the last four digits of the number and the whole number, encrypted	While the merchant's account is active; deleted with the business
Opt-out records — the number, when, and whether the guest asked by text or a business recorded the request from the guest's reply	Until the guest replies START
Which business texted a number, so that a guest's reply reaches it — a keyed code of the number, never the number or the words, with the business, the order, the location, the language and when the text was sent	72 hours, then deleted by an hourly cleanup
Call counts behind the call limits — for each call, the business, when it started and ended, and the one-way keyed code of the caller's number, never the number	2 days, then deleted automatically
Daily counts behind the limits against abuse — new businesses added from an IP address and from its network, feedback sent from this website, messages and new chats with its assistant, and business scans started, from an IP address and from its network, business scans each business starts from the app, payment links texted to a number a caller said aloud when the caller's number was hidden, and how much each business uploaded — keyed codes of the address, the network and the number, never the address or the number	Three days after the day counted, then deleted by a daily cleanup
Point-of-sale data from Clover, Square and PalomaPOS	While the merchant's account is active; the history of a disconnected point-of-sale account stays while the business keeps another connection; the history read from PalomaPOS stays after PalomaPOS is disconnected, until the merchant deletes the business
A business's rewards — for each phone number, the balance in points, when it last bought, and each change with the order it came from (section 2)	While the merchant's account is active; a balance goes to zero after the program's period without a purchase (6 months unless the business sets another), and its record stays; deleted at once when the guest leaves the program or deletes their account on the ordering page
Keyed codes of the cards guests paid with at a business's register, each linked to a phone number — never the card's digits, Square's fingerprint or the holder's name	While the merchant's account is active; deleted at once when the guest whose number a card is linked to leaves the program or deletes their account on the ordering page; the card reference itself is never stored
A guest's agreement to a business's rewards terms — the version, the language and when (section 2)	As long as the guest's rewards at that business; deleted with them when the guest leaves the program or deletes their account
A phone number that left a business's rewards, with when it left (section 2)	Until the guest agrees to the terms again, or while the merchant's account is active
Which orders a business's rewards program has looked at, and what it found (earned, no number to earn for, nothing that earns)	While the merchant's account is active
A business's offers — the code, the discount, the minimum, who it is for, whether it asks for the email choice, the number of uses allowed, its dates and its state (section 2)	While the merchant's account is active
Each use of a business's offer — the offer, the order, the discount, and the phone number and email of that order (section 2)	As long as the order it belongs to; the email address is removed when the merchant deletes that guest's address at the guest's request
A business's gift cards — Square's identifier of each card, the last four characters of its code, its value, the buyer's email address, the From and To names, a one-way hash of the key in its page's address, and the card's activity with amounts, balances and orders (section 2)	While the merchant's account is active, as the business's record of its cards, which never expire; deleted with the business. A card's code is never stored
Keyed codes of the cards that paid for a business's gift cards and of the buyers' devices — never the card's digits, Square's reference to it or the device's own identifier	With the gift card it paid for: while the merchant's account is active; deleted with the business
The keyed code of the network a gift card purchase was started on — made from the first part of an IP address, never the address itself	One day: erased at our next hourly check after 24 hours
Wrong gift card codes typed on an ordering page — counted by device and IP address, never the code	Only in our server's memory, for at most a day
A menu kept in Paloma — its items, prices, descriptions, categories, options and the sales tax rate of each location — and the orders and payments recorded on it	Until the merchant deletes the business; an item taken off the menu stays, marked as off the menu, because past orders name it
The business's pictures — item photos, pictures attached in a conversation with the assistant, illustrations made for it, its logo and other brand images	While the merchant's account is active; a picture the business deletes is kept, out of view, for 15 more days so that a photo taken off by mistake can be put back, then erased by a daily cleanup; all of them, those kept 15 days included, are erased with the business
Merchant user accounts, including the identifier of a Google account used to sign in	While the account is active
The mobile number a user confirms in the app (section 4) — encrypted, with a keyed code of it, its last four digits and when it was confirmed	Until the account is deleted, or until another number is confirmed in its place
Codes that confirm that mobile number — we keep none: Twilio Verify creates and checks each code (section 4)	A code works for 10 minutes; Twilio keeps its own record of each verification under its terms with us
Requests for help to the Paloma team and our replies	While the merchant's account is active; deleted with the business. The counts and internal identifiers of requests and ratings in our own records (section 4) are kept until 90 days after the last request or rating of that kind
Ratings of the assistant's answers — the rating, who gave it, which tools the answer used and the user's note	While the merchant's account is active; deleted with the business. The question and the answer kept with a thumb down are deleted with their thread
Details read from Clover to fill in the sign-up when Paloma is opened from the Clover App Market — the business name and one person's name and email address	At most 30 minutes, only in our server's memory; saved only if the person submits the form
A business we have not activated, or declined to activate, and its data	Kept like any other business: until its owner deletes it in the app or removes its last point-of-sale connection, and then deleted as described below; we do not delete such businesses automatically yet, and we will publish any period after which we do here before applying it
The site's figures from Google Search Console and the state of its pages in Google's index (section 2)	The figures: 16 months by the day Google counted them — the period Google itself keeps — then deleted by a daily cleanup, all at once when the site moves to another address, and with the business; the state of a page: while the page is in the site's list of pages and at most 14 days after it leaves it
Google account addresses of the owners of a merchant's own domain in our Search Console property (section 2)	An address the owner named: until Google confirms it is no longer an owner there, then erased; any other: until then or until we give up our verification of the site, whichever is first; for a person who verified the domain at Google themselves, until the domain leaves the business. The record without the address — the site's public address, the business and the dates — is kept for good, so that the property is never opened to or read for another business
Which business held each own domain we verified in Search Console, and when (section 2)	Kept for good, so that one business's figures are never shown to another
One-way codes of the owners Google listed for a merchant's own domain before we first sent an address for that business (section 2)	Until we give up our verification of the site, then deleted
Business scans (section 4) — Google's identifier of the place, our results (which checks passed, the score, the business's place in each Google Maps search, the phone speed result) and when the scan ran	90 days after the scan, then deleted by an hourly cleanup; a scan a business runs from its account in Paloma, a scan it takes as its first one when its owner signs up from that report within 48 hours (section 4), and its weekly re-scans — while the business is with us, and after it is deleted like any other scan
Google's content shown with a scan's report — the business's name, address, phone number, rating and number of reviews, the businesses nearby and which one leads each search — and the picture of the website on a phone	Shown for one hour after the scan finishes, then erased by an hourly cleanup within two hours
Requests sent with this website's form	Until we handle the request and 12 months after, then deleted by a daily cleanup; a request nobody answered is deleted 12 months after it was sent
Feedback sent from this website, with the Feedback button or with “Send to the team” in its assistant — the message, its kind, the language, the page and the part of the page, from the assistant the pages and parts of pages the messages were written from, the version of Paloma and an email address if one was left	12 months after our team handled it, or 12 months after it was sent if nobody did, then deleted by a daily cleanup; the email address is deleted as soon as we have replied or decided not to
Chats with the assistant on this website — your messages, the answers, the language, the page and the part of the page of each message, and how many questions it could not answer	30 days after the chat's last message, then deleted by a daily cleanup; messages sent to the team are kept as feedback (row above). Anthropic deletes what we send it within 30 days of receiving it, unless it has to keep it longer to enforce its usage policy or to comply with the law
Feedback sent with “Send feedback” in the app — the message, its kind, who sent it and their role, the language, the screen, the app's version, and our team's note and reply	While the merchant's account is active; deleted with the business
Order tablets — the device's name, who connected it and when, when it last reached our server, when it was disconnected, one-way hashes of its code and key, and its push subscription if notifications are allowed on it	While the merchant's account is active, a disconnected one included (its key stops working at once); deleted with the business. The push subscription is deleted when the device is disconnected, when the push service reports it gone or refuses five sends in a row. The `paloma_tablet` cookie on the device lasts at most 400 days
Notification subscriptions	Until the user removes the device, the push service reports it gone, or the account is deleted
Account security log — sign-ups (with the email address used and whether with a password or Google) and team members joining (with the email address used), each code texted to confirm a user's own mobile number and each number confirmed (with only its last four digits; a keyed code of the IP address a code was asked from is removed after 48 hours), the activation of a business — by its founder's confirmations, by our staff with the reason for it, or by a Clover App Market install — and our staff's decision not to activate one with the reason for it, a password removed when a Google sign-in takes over an unconfirmed address, point-of-sale and marketplace connections and disconnections, each look at a guest's contacts on an order's page for the team or on an order tablet, orders accepted or marked ready on an order tablet, changes to the limits of a business's account, and requests to delete or restore a business	Two years, then deleted automatically; entries about a business are deleted together with the business, and the email address is removed from entries about a person whose account is deleted
Balance records — funds added, credits, and each charge for AI and paid services with what it was for, when and how much	Seven years, as our accounting and tax records, then deleted automatically; they are kept after the business is deleted, hold the business's internal id rather than its name, and contain no customer data
The card a merchant saved to pay for couriers — Stripe's references, brand, last four digits, expiry, who attached it and when	Until the card is replaced or removed or the business is deleted; the card is then detached from our Stripe account
Courier charges — for each delivery paid with the saved card, the order, the amounts of the charge (the delivery price, the tip and the total), the payment's status and Stripe's reference	Seven years, as our accounting and tax records, then deleted automatically; they are kept after the business is deleted, hold the business's internal id rather than its name, and contain no customer data
What a business does and sells, drafted from its own website and approved by an owner or a manager (section 8) — the description, the services with their prices, the site's address and the day it was read	While the merchant's account is active; deleted with the business. The words of the website's pages are not kept at all
Diagnostic traces of assistant requests	No longer than 30 days
Server logs — the lines our servers write as they run: requests, background jobs, calls to our vendors and errors	Only on our own servers; no longer than 30 days, then deleted automatically
Backups	we can restore any moment of the last 30 days: each backup is kept up to 37 days, and a nightly copy in a second United States region 35 days; a backup file that is removed is erased 14 days later, so anything deleted from our live systems is gone from every backup within 51 days

When a merchant deletes the business, or revokes access for its last point-of-sale connection — for a Clover uninstall, once Clover confirms it to us, or once a Clover connection whose access Clover stopped renewing has not been reconnected in the time section 7 sets (30 days after we first email its owners or 60 days after Clover stopped, whichever comes first, closed at our next daily check after that period) — we stop using its connections immediately and the business is deleted 30 days later: the merchant's own database is dropped, its stored call recordings and pictures are removed from object storage, and its entries in the account security log are deleted, leaving only a record that a deletion took place, without the business name. Within those 30 days the merchant can reconnect or restore the business and keep the data; after them, deletion is permanent, and backups and diagnostic traces age out on the schedule above. A PalomaPOS connection does not count here: disconnecting PalomaPOS, or PalomaPOS ending our access, does not start this deletion, and a business connected to PalomaPOS is not deleted because its last Clover or Square connection ends (section 7). Neither does this deletion start while the business keeps its menu in Paloma (section 2): that menu is the merchant's own, not a connection, and it stays until the merchant deletes the business.

Access withdrawn at the platforms. When the business is deleted, we also withdraw the access it gave Paloma wherever the platform lets us: Paloma's access to any Stripe account it connected is revoked at Stripe, and any card it saved to pay us for couriers is detached from our Stripe account; its authorization at Square is revoked; its grant at PalomaPOS is revoked before its database is dropped; its grants for Google Business Profile, TikTok and YouTube are revoked; its connections at Zernio are removed, and Zernio then erases the platform access it held; its WhatsApp Business number stops sending its messages to our app, and our access to it is deleted; our bot leaves the team's Telegram group; and the phone numbers we got for the business are released. Only Paloma's own access goes — the business's accounts, Pages, profiles, posts and groups stay as they are. Meta and Clover give us no way to withdraw that access ourselves: the Facebook Page access and any Clover token we held are deleted with the business's database, and the owner can remove Paloma in the Facebook account's settings (Business integrations) and uninstall the app or delete the API token in Clover. If object storage or a platform does not respond, we retry automatically, and a step that still fails is flagged to our operator to complete. What only a person can close — such as a marketplace connection at OrderOut, or a phone number that was set up by hand — our operator closes; for that we keep the platform's identifier of it and our internal id of the deleted business, without the business name, for 90 days.

12. Security

Every merchant's data lives in its own isolated database. Access tokens and other credentials are encrypted at rest with per-record keys; all traffic is encrypted in transit. Access follows least privilege. Production credentials are stored encrypted and are decrypted only on our servers, in our deployment pipeline and by our operator, never kept in plain text in source code; changes to production go through audited, allow-listed workflows and our own deploy runner, and the automated agents that help us build and run Paloma operate under those same controls. Every action the assistant takes that writes, pays or contacts someone is recorded in the business's own log of assistant actions. Paloma's support staff may open a business in the app to resolve a request or to set up the service on the merchant's behalf: each such access lasts at most one hour, is opened with a recorded reason, and its start and end and every change made during it are recorded in the business's security log under the staff member's own account, never the merchant's. When we record diagnostic traces of assistant requests to find and fix problems, they stay on servers we operate, and phone numbers, email addresses and card-like numbers are replaced with placeholders before a trace leaves the application.

If something goes wrong. If we learn that personal information we handle for a merchant was accessed or taken without authorisation, we tell that merchant without undue delay, and no later than 10 days after we determine it happened, with what we know, so the merchant can meet its own duties to notify; we then help it notify the people affected. For the accounts of our own users, we notify the people affected and the authorities as the law of their state requires — in Florida and California within 30 days.

Requests from public authorities. If a court, a law-enforcement or a national-security authority asks us for data we hold for a merchant or received from a platform such as Meta or Google, we check that the request is lawful and properly served, challenge it where we believe it is not, disclose only the minimum it lawfully requires, tell the merchant first unless the law forbids it, and keep a record of each request, our answer and its legal reasons.

13. Your rights

Depending on where you live, you may have the right to access, correct, delete or export your personal information, and to appeal a refusal (CCPA/CPRA in California, PIPEDA in Canada, and comparable state laws). In the app, the business owner can download an export of the business's data, including conversations with the assistant, and every user can delete their own conversation threads. A guest who signed in on an ordering page can see their saved addresses and order history there, and delete an address or the whole account at any time. Deleting the account also deletes the guest's rewards at that business, and a guest can leave a business's rewards there without deleting the account; a guest who never made an account can sign in with their number to do the same, or ask the business or write to privacy@palomaceo.ai — no account is needed to ask (section 2). The buyer of a business's gift card can ask the business, or write to privacy@palomaceo.ai, to know what is kept about them; a card's value and activity, with the buyer's email address, are the business's record of a sale, which the business decides about and may keep as the law allows (section 2). A guest who chose to get a merchant's offers by email can stop them at any time on the page of their order, and can ask the merchant to delete their email address. A guest who chose them on an offer's page and has not ordered yet — or who has no account — can ask the business or write to privacy@palomaceo.ai; a discount already received stays theirs. Merchant users can exercise these rights at privacy@palomaceo.ai. Callers and other customers of a business, including guests with an account on its ordering page, should contact that business for anything else: it decides what happens to that data, and we help it respond. We do not discriminate against anyone for exercising these rights.

14. Children

Paloma is a tool for businesses and is not directed to children under 13, and we do not knowingly collect their personal information.

15. International transfers

We store data in the United States. Some providers in section 10 process what they receive in other countries as well; the Location column there says where. Merchants in Canada should be aware that their data is processed in the United States and may be accessible to United States authorities under applicable law. The same holds for merchants and their users in any other country: by using Paloma they have their data processed in the United States and in the countries named in section 10, whose laws may protect it differently from the laws of their own country.

16. Changes and contact

We announce material changes in the app and on this page, and update the date of the last change above. Questions, requests or complaints: privacy@palomaceo.ai, or by post to 2590 Hollywood Blvd, Hollywood, FL 33020, United States. This policy is written in English. If the app or our website says something this policy covers in another language and the two differ, this English text governs.

Clover is a registered trademark of Clover Network, LLC. PalomaFinTech LLC is an independent developer and is not affiliated with Clover Network, LLC or Fiserv, Inc. PalomaPOS is a point-of-sale system offered by PalomaFinTech LLC, which also operates Paloma.

Privacy Policy

1. Who this policy is for

2. What we process on behalf of merchants

3. What we collect from callers

4. What we collect from merchant users

5. Payments — card data never reaches us

6. How we use the data

7. Data obtained through the Clover, Square and PalomaPOS APIs

9. No AI model training

10. Sub-processors

11. How long we keep data

12. Security

13. Your rights

14. Children

15. International transfers

16. Changes and contact

Prefer we set it up with you?

What's on your mind?

Ask Paloma

Privacy Policy

1. Who this policy is for

2. What we process on behalf of merchants

3. What we collect from callers

4. What we collect from merchant users

5. Payments — card data never reaches us

6. How we use the data

7. Data obtained through the Clover, Square and PalomaPOS APIs

8. Facebook, Instagram and Google Business Profile

9. No AI model training

10. Sub-processors

11. How long we keep data

12. Security

13. Your rights

14. Children

15. International transfers

16. Changes and contact

Prefer we set it up with you?