What we know about you

If you run the inbox yourself

Your customers' messages, bookings and orders stay in your database. We never receive them, so we can't read or recover them. The code is open if you want to check.

Some things leave your inbox, and only for a network it reports to, in Settings → Networks. The setup offers network.surfingdog.ai, switched on; you can switch it, and any other, off again. A network your inbox reports to gets:

• Your inbox's address, once, so it can check your inbox's public profile, and every hour your software version, what it runs on, and how many bookings, orders, quotes and messages arrived in the last 24 hours. Counts only. With your secret key set, this hourly message is signed, and the network answers it with your own standing there.
• Every receipt your inbox signs: when a booking is confirmed or an order accepted or paid, and again when it ends (it happened, the customer did not turn up, either side cancelled, it was delivered). A receipt says which business issued it, your reference for the booking or order, what kind of promise it is, when it was due and when it was made, the amount if there is a price, and how an order was paid when your inbox knows. The customer appears as a code, never a name: an HMAC made with a key only your inbox holds, which the network can't turn back into a person, and the same customer at another business gets a different code. When the customer's assistant presented their pass, the receipt also names that presentation, one per network, so the network that issued the pass counts the outcome on that person's record; every network the receipt goes to sees these references.
• A counter-signature, if the customer's assistant signs a receipt: its signature and its public key. An assistant that keeps its key uses the same one at every business, so the receipts it signed can be linked to each other. It may also name the customer's pass, by a reference that is not the pass itself.
• A new customer's email address, when a customer books or orders with an email and their assistant carries no pass. With it go your reference for that booking or order and the name of their assistant (and a fingerprint of its public key, and its platform, when it signs). The network uses the address to give the customer a key, a secret that lets any business on that network recognise them later. Your inbox asks the network to email the key to the customer itself, as one line in your name: a code for their assistant, with a link to the network's page where they can see and correct their record, and a "Not you?" link. The code and the links carry the network's address; the email uses no other words of the network's. The network keeps the address only until then. A network that leaves that email to your inbox has your inbox send it; turn that line off under Customers you already know. Each network has its own switch for this, "Give first-time customers a key": off when your inbox joins network.surfingdog.ai at setup or on our hosting.
• A pass or a key the customer's assistant carries, only to the network that issued it, with the customer's email address when their request has one, so the network can say how that customer keeps their bookings and whether the address is theirs. An assistant that signs its requests carries a reference instead of the pass, and your inbox passes on its signature: the address, path and query of the request, a hash of what it sent, its content type, its public key and the pass references it signed. Your inbox never passes on a signature that holds a secret, or that covers any other header.

Never sent: message text, names, phone numbers, postal addresses, what was ordered, payment references.

What your inbox keeps of this, in your database: what each network said about a customer (a code for that customer at your business, and their standing) on the booking or order and on the customer; a hash of each pass it saw, to recognise it again; a network's answers for an hour, a day for "already known", filed under hashes. A key a customer's assistant presents is passed on and never stored. A new customer's key is kept sealed with your secret key until it is emailed to them, and their first pass sealed so the assistant that made the booking or order can collect it again; neither longer than seven days, and neither shown to you.

Turn a network off and nothing more is sent to it. What it already holds, it keeps under its own rules. Anyone can run a network, and one we don't run is not covered by this page: add only networks you trust.

If we host it for you

You are the controller of the data your customers send your hosted inbox, and we are your processor, under the processing agreement. For your own account we are the controller: the hosted privacy notice says what we keep and why. Your hosted inbox joins network.surfingdog.ai the day it goes live and sends it what the list above says; switch it off in Settings → Networks.

Google Calendar in your inbox

You can connect your Google Calendar in Settings → Integrations → Calendar. This section is about inboxes we host, and our own, which connect through Surfing Dog Inbox's Google sign-in. An inbox you run yourself uses a Google sign-in you set up.

• What the inbox asks Google for. Which Google account it is (Google's own id for it, and its email address); when you are busy on your main calendar, as start and end times only, never what an event is called, who is in it or where; and permission to see and change events on calendars you own, as Google's screen puts it. The inbox uses that permission only to add, move and remove the events it made, and to read your main calendar's name and time zone, to show you which calendar is connected. Nothing else: not your other events, your contacts or your mail.
• What it does with it. Your inbox never offers customers or their assistants a time you are busy. When you confirm a booking, your inbox adds it to your calendar (the service, the customer's name, the time, and a link to the booking in your inbox), and moves or removes it when the booking changes or is cancelled. It only ever changes events it added itself.
• What it keeps, and where. In your inbox's own database: the account's id and address, the calendar's name, your busy times for about the next three months (replaced each time it reads them), and the id of each event it added. Google's access is kept encrypted with your inbox's own key, never shown to anyone and never sent anywhere but Google. On an inbox we host, this database and its backups are in the European Union.
• Who sees it. You, in Settings, and an AI you connect to your own inbox, which sees what you see there. Your busy times, the account and the events' ids stay in your inbox: none of it goes to our network, and no other company gets it, except the companies that host an inbox for us, as the processing agreement says. Nobody at Surfing Dog reads it, unless you ask us to for help, to keep the service secure, or because the law requires it. We never sell it, use it for advertising, or use it to train AI models. The times your inbox still offers, which leave out when you are busy, are public: anyone, their assistants, and our Search when it carries a booking request can read them, so the gaps show when you are not free during your bookable hours. Search passes them on and keeps none.
• Taking it back. Disconnect in Settings → Integrations: your inbox asks Google to take the access back at once, and deletes the account, the busy times and the events' ids; the bookings it already added stay in your calendar, as your own entries. If Google does not answer just then, the inbox still deletes its copy of the access, but Google may go on listing it: you can remove it there at any time, at your Google Account's permissions. When an inbox we host is closed, it is deleted with the rest of the inbox, as the processing agreement says.

Surfing Dog Inbox'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.

This website

No advertising or tracking pixels, and no cookie banner, because there is nothing to consent to. We count visits to this website with Cloudflare Web Analytics, which sets no cookies and does not follow you across sites: it records the page, the site you came from, your country and your browser, and is never on a business's inbox. Our servers keep technical logs to keep the site up and stop abuse; what they hold, and when an IP address is among it, is under Search below. Cloudflare sits in front of the site and keeps its own logs for the same reason.

On app.surfingdog.ai, the forms for setting up or signing in to a hosted inbox, sending us feedback, and reporting an inbox are protected from bots. Cloudflare Turnstile checks these forms out of sight: it reads signals from your browser and connection, such as your IP address, your browser's name and its TLS fingerprint, to tell people from bots. Cloudflare does this for us, and on its own account uses the same signals to improve the check; its Turnstile Privacy Addendum says what it collects and why.

If you write to us, we keep your message and email address so we can answer, and use them for nothing else. Posts on the requests board are public. The email address you give there is used only to tell you when your request ships.

Search, its MCP server and the checker

Search answers at surfingdog.ai/search, over MCP at surfingdog.ai/mcp, over A2A and through the REST API. It needs no sign-in, sets no cookie, and gives everyone the same answer.

• Searches. The words, filters and place of a search are used to answer it. When an AI agent searches, over MCP, A2A or the REST API, we keep a record of the call, to improve search, with no time limit: its words as the agent typed them, with email addresses, phone numbers, card numbers and bank account numbers (IBANs) taken out, and any other run of eight or more digits in a row too, unless it is the decimals of a number. Street names, house numbers, postcodes, prices, dates and years stay as typed, and so does a name typed into a search. The record also keeps which door it came through (MCP, A2A or the REST API) and which tool it called; the filters it used (a language, a category, the town or country it named, never the coordinates of a point, and what it wanted to do, such as book); how many businesses it found, in which order, and whether on its first page; the kind of assistant or software that sent it (such as Claude or ChatGPT) and its version, and whether it came from an AI platform's published addresses; and how long it took and how it ended. Never your IP address, a session, or anything else that says who sent it: to count how many different callers there are each day, each record keeps a code made from the caller's network (its address with the last part left off) with a secret key drawn at random each day, held only in our server's memory and destroyed when the day ends. Once the day is over, no one, us included, can work a code back to an address or match it with another day's. An agent's other calls to these doors are recorded the same way: which tool, when, how long and how it went, with nothing of what it asked. Of these records, two totals are public, on this website and in the network's API: how many requests agents sent in the last seven days, and how many different callers came on the busiest day. They name no one and no search; what they count is set out on its own page. A search on this website's own pages is not recorded, nor are the reads of a search engine's crawler. The service's log leaves searches out (over the REST API they travel in the query string, which it does not record). The one exception is an error at our front server, under Logs and limits below.
• Checks. When you, or an AI for you, ask to check a website (at /check or with check_business), we keep the website's domain, when and how the check was asked for (the page, MCP or A2A), how many times, and what reading the site found. We do not keep who asked. The record of each new read of a site is deleted after 90 days. The result is public at surfingdog.ai/b/<domain>; a business can hide its own with update_business, with proof that the domain is its own, and can ask us to stop listing or reading its site at surfingdog.ai/bot.
• Doors. We read the doors businesses publish for AI agents (their MCP servers, agent cards, inboxes and the like). Each read itself is kept 90 days. What they found we keep for good, one line per door per day: how many reads we made, how many were answered, failed (and why) or blocked, how quickly, the protocol version the door states, and the first and last day it answered. Beyond the site's own web addresses it holds nothing about a person, no page content and nothing a customer wrote. The days a door was seen answering, and for doors we read every day the share of days every check answered, are public with the business's listing and result. A business that opts out at surfingdog.ai/bot has all of it deleted at once.
• Registering and changing a listing. register_business and update_business keep what a business's AI sends: the listing's facts (name, category, description, address or service area, hours, languages, doors), which are public in the directory; the version of the listing terms it agreed to, and when; the kind of proof it used; and a record of each change (which fields, with which proof, when), which has no time limit today. A phone number or an email address in its text is dropped, never kept. Proof is kept as keyed hashes, never as the secret itself: a challenge until a day after it expires, with a keyed hash of the network address that asked for it, to count a day's challenges; a code sent to an address at the domain until a day after it expires, and that address's hash for 30 days after its code is used; a claim token for its 90 days and 30 days after. For a listing claimed with a code, the address's hash stays with the listing, so a code sent to another address cannot take it over.
• Requests we carry to a business. Surfing Dog never touches the money and never keeps what anyone writes. When a business allows it, we carry an assistant's request to the business's own inbox and keep only a record that it was delivered. A hosted inbox is the business's own: what its customers write is kept there, for that business. When your assistant asks us to send a business your question, a request for a quote or a request for a booking, we pass your words, the details of the request (a service, a time, a quantity, the language you want), your email address and the name you give, if any, to that business's own inbox, and nothing else; we write none of it down. With it go a key made from the request itself, so that a retry is not sent twice, and a code that tells the business's inbox which requests came from the same sender that day, without saying who; it is different for each business and each day. We keep a record that it was delivered: when, to which business, which kind of request and how it went, never who sent it or what it said, for 400 days. The business alone is told how many arrived. To apply the limits we count, in memory, how often one person, one address, one email address (as a keyed hash) and the same words (as a keyed hash, for about an hour) are sent, each forgotten a day after its last use at most. We never carry a phone number. Your request is then the business's, in its inbox, as any customer's is, and it can answer you by email.
• Logs and limits. The service's own log records each request's method, path and how long it took: not your IP address, not a search's words (an agent's searches are recorded as above), and not a tool's arguments. A path can name a business, such as the domain of one listing or check result looked up, but not who looked. How often one address, or one session of an assistant, calls is counted in memory, to apply the published limits, and never written down, except the keyed hash a register challenge keeps (above). The kind of assistant each session named is held in memory too, for a day at most, and which session named it is never written down: each call's record keeps only the kind of assistant, as above. An error at our front server (for example while the service restarts) can be logged with the request's IP address, the address it asked for (a REST search's words included) and its headers. These logs are kept in the server's system log, which is trimmed by size, with no fixed time limit yet.

The phone app

Surfing Dog Inbox for Android talks to the inboxes you connect it to, and to Google for notifications. It sends us nothing about how you use it, and no crash reports. What you do in the app (accepting, proposing a time, declining, replies, your notification choices) goes to that inbox, as it would from a computer.

• Your inbox gets the phone's maker and model as its name, the phone's public keys and its push token. You see each phone, and remove it, in Settings → Phone. When a phone is removed, in the app or in Settings → Phone, your inbox also asks the relay to forget it.
• Signing in by email, instead of scanning: the address you type goes to your inbox, which emails you a link. To find your inbox, the app first asks your email's domain for /.well-known/agent-inbox.json, at the domain and at inbox. in front of it.
• The camera reads the code from your inbox inside the app. The picture never leaves the phone.
• Notifications are encrypted by your inbox for your phone alone, then sent through our relay at push.surfingdog.ai to Google's Firebase Cloud Messaging. The relay keeps, for each phone, the inbox it belongs to, its push token (encrypted) and when it last delivered. It cannot read what it carries, keeps no message, and deletes a phone nothing reached for 90 days. Google sees the push token, a Firebase installation ID, when each message arrives and how big it is, under Google's own privacy policy.
• Updates. A copy from Google Play is updated by Google Play and reads nothing from us. A copy from the download page reads surfingdog.ai/phone/latest.json at most twice a day to see whether a new version is out: an ordinary request, logged as any visit to this website is. The app comes from Google Play, under Google's privacy policy, or from GitHub, through this site's download page, under GitHub's privacy statement.
• The demo. "Try the demo" reads made-up examples from our demo shop at demo.surfingdog.ai. It sends nothing about you, and nothing you press in the demo is sent anywhere.
• On the phone, what the app keeps is encrypted with a key in the phone's Android Keystore, and is never backed up. Remove an inbox from the phone in the app's Settings, or uninstall the app, and it is gone.

Writing to businesses

Now and then we write to a business by email about Surfing Dog Inbox: one email, written for that business, and at most one more if it does not answer. We write only to companies, at an address they publish for their business on their own website, never to consumers, and we never buy or rent lists. Each email says where we found the address and how to stop us writing.

• What we keep. The business's name and website, the address we wrote to, what its own site says that the email speaks of, when we wrote and what we sent, and any reply, so that we answer and never write twice. Basis: our legitimate interest in telling a business about a service that fits what its own website already does.
• Stopping it. Reply "stop", or write to privacy@surfingdog.ai, and we never write again. We then keep only the address and the website on our list of those we must not write to, so that we do not write by mistake. You can also object, and use the rights below, at any time.

Your rights

Under the GDPR you can ask for a copy of what we hold about you, ask us to correct or delete it, object to what we do with it, and complain to a supervisory authority. For the network, deleting means we remove what links a record to you (your email's code, your keys and passes); the coded records of past bookings stay, because businesses' records are made of them. In Portugal that is the CNPD. Write to privacy@surfingdog.ai and we will answer within a month.

Where we rely on legitimate interest rather than your consent, it is to keep the service running and prevent abuse, and you can object to that too.

Our network, and the customers of businesses on it

We run the network at network.surfingdog.ai. Businesses whose inbox reports to it are listed in its directory, and it keeps a record of how reliably businesses and their customers keep bookings and orders. It uses only real transactions, and it never refuses or blocks anyone: it orders its directory by rules it publishes, and each business's own rules decide what a customer's record earns them, rules that may only speed things up or bring in a person, never refuse.

What it keeps, and for how long.

• The hourly messages, with the internet address they came from, for 90 days. A business's listing (its public profile, version, whether it is answering, its counts and its standing), and snapshots of it, for good.
• The words of the searches AI agents send it, as typed, with email addresses, phone numbers and card and bank numbers taken out, with no time limit, to improve search: never who sent them, and no IP address.
• Every receipt, counter-signature, and record of which business was shown which customer's standing, for good. A record that could quietly disappear would be worth nothing, so none does.
• For a customer: a record with no name, keyed by an HMAC of their email address, and an HMAC of its domain (never the address itself); the hashes of their key and passes (never the secrets, except a new customer's key and pass, kept encrypted for seven days so a retry never loses them, and a pass made from a key, kept encrypted for a day); the name, public key and platform of the assistants that carried them; and the outcomes of their bookings and orders, from receipts that name them by a code.
• Sign-in sessions for 24 hours, and emailed codes for ten minutes. A code is sent to the address as typed, and the address is not stored.

Who sees what.

• A business's standing (its score and tier, and how many promises it kept and broke) is public, in the directory. Nothing about any customer is ever in it.
• A customer's standing is seen by a business only when the customer's assistant presents their pass there. There is no way to look a person up. The business sees their tier, their score, how many promises they kept and broke and at how many businesses, since when the network has known them, whether they proved their email address, and whether their pass was used unusually. It never sees their email address or which other businesses they used, and each business gets a different code for the same person.

If you are a customer.

You never sign up. If you book or order with an email at a business on the network, you may get an email with your key. You can give it to any assistant, or ignore it. With a code sent to your address you can sign in at the network to see your record, every business that was shown it, and the passes your assistants hold; revoke a pass; replace a lost key (your record carries over); and contest an outcome you think is wrong. Or write to us.

The network's rules, in plain words and as numbers, are on the network page and at network.surfingdog.ai/v1/ranking, with every change announced fifteen days before it applies.

Changes

The date at the top shows the last change. The site is an open repository, so every edit to this page is a public commit. We will announce material changes on the blog.