Privacy Policy

This Privacy Policy explains how Symodal LLC ("Mayoo", "we", "us", or "our") collects, uses, and discloses information when you use the mayoo.ai website, API, and desktop application (collectively, the "Service"). By using the Service, you agree to the practices described below.

1. Information We Collect

Account information

When you create an account, we collect your email address, a securely hashed password, and any optional profile information you choose to provide. We may also collect verification codes sent to your email.

Payment information

Payments are processed by Stripe. We do not see or store your full card number. We receive only the metadata Stripe sends back (transaction id, last four digits, card brand, country, success/failure status) for billing reconciliation.

Usage data

For every API call you make through Mayoo, we record the timestamp, the API key used, the model requested, the number of input/output tokens, the cost in USD, and the HTTP response status. On this API path we do not retain the contents of your prompts or the model's responses: they are forwarded to the provider you selected and are never written to our database. The session and sharing features described next do store message content; they are the exception.

One narrow case is worth naming, because it is the only other time anything derived from a request body is stored. We publish a handful of model names that do not exist and are never served — bait, so that a caller enumerating our catalogue on a competitor's behalf identifies itself. A call to one of those names is answered with a plain "unknown model" error and recorded as an abuse event, together with a SHA-256 fingerprint of the message that was sent. The fingerprint is what lets us tell one probe apart from a thousand repeats of the same one; it is not the text, and the text is not kept. No genuine client has any reason to call these names, so nothing you send to a real model reaches this path.

Session data

Mayoo mobile dispatch lets you start a task from your phone and run it on your own desktop. To relay that session between your two devices, our server stores the session record (the title you give it, the model, the working directory, status and timestamps) and every event exchanged between them — this is broader than plain chat text. It includes the assistant's message content, and, whenever a tool is used, the tool call itself: for example, the complete command line of a shell command that was run, or the absolute file path of a file that was read or written, together with that tool's output. How long that is kept is described in section 4.

Shared chats

When you choose to share a conversation, we store a point-in-time copy of the messages you shared, together with the title and model, behind a secret link. That copy is fixed at the moment you create it — later messages never appear on an existing link. Revoking a link stops the page loading for anyone who has it, and the stored copy is then erased 30 days later by a daily job. An unrevoked share stays published until you revoke it. See section 4.

Technical data

We collect IP address, user-agent, and approximate geolocation for security and anti-fraud purposes, and basic browser cookies that are strictly necessary to keep you logged in (session cookies, CSRF token, and language preference). We do not use any analytics or advertising cookies.

2. How We Use Information

• To operate, secure, and improve the Service;
• To bill, process payments, and prevent fraud;
• To respond to support requests;
• To send essential service notifications (security alerts, billing receipts, policy changes);
• To comply with legal obligations, including sanctions screening.

We do not sell your personal information. We do not use your prompts or responses to train any machine-learning model operated by us.

3. How We Share Information

We share information only in these limited cases:

• Upstream model providers. When you make an API request, the prompt and request metadata are forwarded to the upstream model provider you selected. Those providers process the request under their own terms and privacy policies, which we encourage you to review.
• Service providers. We use Stripe (payment processing) and other infrastructure and communication providers strictly as data processors acting under contract, for the purpose of operating the Service.
• Legal compliance. We may disclose information when required by valid legal process, or to protect the rights, property, or safety of users or the public.

4. Data Retention

• Account data: kept while your account is active, and for up to 24 months after deletion for fraud-prevention and legal-compliance purposes.
• Usage logs (token counts, cost, model, timestamp): kept for up to 24 months.
• Prompt and response content sent through the API: not retained — forwarded to the upstream provider and never written to our database.
• Abuse records for calls to a bait model name (see "Usage data" above): the event — time, API key, IP, country, client identifier, which bait name was called — and a SHA-256 fingerprint of the message, never its text. These are security evidence and carry no automatic expiry; repeat probing over time is the whole point of keeping them.
• Session message content (Mayoo mobile dispatch): erased 30 days after the message is sent. A daily job replaces the stored message body with an empty one; the message's position in the transcript remains so the session still loads.
• Session records (title, model, working directory, status, timestamps): once a session has finished, failed, or been cancelled, it is deleted — together with its whole transcript — 30 days after the last activity on it. A session you never finish or cancel is not deleted on a timer; its message content is still erased on the 30-day schedule above, but the session record itself is kept. You can cancel a session at any time, which starts its 30-day clock. If you delete your account, every session it owns is deleted once the account-deletion grace period has passed, whatever its status or age.
• Shared chat content (conversations you chose to share): a share you have revoked has its stored copy erased 30 days after you revoked it; the empty record of the share is kept so its link can never be reused. A share you have not revoked stays published, with no time limit, until you revoke it — that is what sharing it means. If you delete your account, all of your shares are deleted outright, revoked or not, once the account-deletion grace period has passed. To have a shared copy erased sooner, revoke it and contact us at [email protected].
• Payment records: kept as required by applicable tax and accounting law.

Deletion and every retention period above applies to our live production database. We keep encrypted backups of that database for disaster recovery, and content that has already been deleted can still exist inside an older backup until that backup itself is rotated out — for up to 12 months. Backups are read only for disaster recovery and are not used for any other purpose.

Zero data retention

The 30-day window above is what a session gets by default. Your account settings carry a switch, zero data retention, that changes what is written rather than how long it is kept. A session opened under zero retention leaves no content on our servers at all: its title, its working directory and its message bodies are never written to the database, rather than written and then deleted. That distinction is the point of the setting — anything written once also lands in the backups described above, where deleting a row changes only the live copy.

The switch is off unless you turn it on, it is set for the whole account, and it applies only to sessions opened after you turn it on; it does not reach back. To clear sessions you already have, use the delete-sessions action — the retention periods above continue to govern them.

What the switch does today. Tasks dispatched from your phone cannot use zero retention: our server has to hold the task text long enough for your desktop to collect it. On that path a zero-retention session is refused outright, with an error that says why, rather than being quietly downgraded into a retained one; with the switch on, use the desktop application's incognito mode instead. The server-side sessions this setting is ultimately for are not running yet. So the switch's only observable effect today is that refusal: it is a promise about sessions we do not yet open, and we would rather say so here than leave you to infer a protection you do not have.

Turning it on costs four capabilities, which are listed beside the switch in your account settings. They describe zero retention as it behaves on server-side sessions; you will not experience them today, for the reason just given, but they are what the switch costs once server-side sessions honour it:

• After a dropped connection you can only recover the current turn: the session events we store are the only source your phone has for catching up.
• Picking up the same session on another device is not possible.
• Detached turns have nowhere to put their output, so that capability is effectively off in a zero-retention session.
• Server-side usage in /doctor reads “Unavailable” rather than 0 — data we do not have is never shown as a zero.

What zero retention does not cover:

• Metering and billing records are still written (they contain no message content).
• Sign-in IPs and security events are still written, for abuse prevention.
• Tasks sent from the Dispatch page store their task text separately and are not governed by this switch.
• How the upstream model vendor retains what you send them is outside what this switch can promise.

5. Security

Different credentials get different protection. If you connect your own upstream-provider API key (bring-your-own-key) or complete payout identity verification, that credential is encrypted at rest using AES-256-GCM. Your Mayoo relay API key is not encrypted at rest: authentication checks a one-way hash of it, but we also keep a plaintext copy so the dashboard can display it to you again after creation — treat it like a password, and revoke it immediately if you suspect it has been compromised. Notification credentials you supply yourself (a Telegram bot token, a webhook secret, a WxPusher or Gotify token) are stored as you entered them, without encryption at rest, and are masked before being shown back to you. All traffic to the Service is served over HTTPS, and we follow industry-standard practices for access control. No system is perfectly secure.

6. Bring Your Own Key

You can have requests to a model provider run on an API key you hold with that provider instead of on our accounts. The provider then bills you directly for the model usage. The request otherwise travels the same path as any other API request: it is forwarded to the provider you selected, and the record described under "Usage data" in section 1 is written as usual, marked as having used your own key. There are two ways to supply the key. They differ in what we hold, so they are described separately.

A key you store with us

When you save a provider key in your account settings, it is encrypted at rest as described in section 5. From then on, requests from your account to that provider run on it. The settings screen shows only the key's last four characters, and there is no way to have the full key shown back to you: you already hold it at its source, and handing secrets back out would only widen the ways it could leak. The key is decrypted in memory only while a request to that provider is being handled, and is not kept between requests. Deleting the key removes it from our live database outright; the backup note in section 4 applies to it as it does to everything else there.

Server-side sessions run with a stored key — once server-side sessions run at all, see "What the switch does today" in section 4 — keep their session records and message content under the retention periods in section 4 and honour the zero-data-retention switch exactly as described there. This section adds no promise on top of that one and takes nothing away from it.

A key sent with each request

Our API also accepts the key in a request header, sent with each request. We use it for that one request and nothing else: the header is removed from the request before anything downstream can forward or log it, and the key is never written to our database or to any log. Because the whole request is assembled on your side, there is no server-side session to keep: the prompt and the response follow the "Usage data" rule in section 1 and are not retained.

The desktop application does not use this path yet. A device-only mode that keeps the key in your operating system's keychain and supplies it this way is planned. Once it exists, a device-only session will run entirely on your machine, and will carry the first three of the four limits listed for zero data retention in section 4: after a dropped connection only the current turn can be recovered, the session cannot be picked up on another device, and detached turns have nowhere to put their output.

Requests made with your own key are not billed at our model prices. They carry a flat routing fee instead: charged once per request that we actually served (a request the provider rejected, or that failed, is not charged) and unrelated to how many tokens the request used. The current rate is published on the pricing page rather than here, so that this policy does not go stale when it changes.

Today the retention default for a server-side session is the one stated in section 4, whichever key it runs on: retained under the periods listed there, with the zero-data-retention switch off unless you turn it on. We intend to set that default by account tier; when account tiers are introduced, the tiers and their defaults will be stated on the pricing page. Whatever the default, the switch in section 4 remains yours to set.

Should we offer encryption of stored session content under a key that you control (a customer-managed key), it would mean two things and only two: the content is encrypted at rest under your key, and you can revoke that key, after which we can no longer open what was stored under it. It would not put the content beyond our reach while a session is running: to build a request, the service has to decrypt the history in memory, and for detached turns and scheduled loops it has to keep that ability for as long as they run. This is not offered today.

Whichever way you supply it, the key is yours, and so is the relationship with the provider. What the provider keeps of the prompts and responses sent under your key is governed by your agreement with them, not by this policy; the last exclusion under zero data retention in section 4 applies with extra force here. What this section promises is confined to our own servers.

7. Your Rights

Depending on where you live, you may have rights to access, correct, port, or delete the personal information we hold about you, and to object to or restrict certain processing. To exercise these rights, contact [email protected]. We will respond within 30 days.

8. International Transfers

Our production infrastructure is located in Japan (Tokyo). When you use the Service, your API requests are forwarded to the upstream model provider you selected, which may process your data in a different country depending on that provider's own infrastructure. By using the Service, you consent to these transfers for the purposes described in this policy.

9. Children

The Service is not directed to children under 13, and we do not knowingly collect personal information from children under 13. If we learn that we have, we will delete it promptly. Note that the Service also requires users to be at least 18 years old under our Terms of Service.

10. Cookies

We use only technically necessary cookies: a session cookie to keep you logged in, a CSRF token cookie to protect form submissions, and a language-preference cookie. We do not use analytics, tracking, or advertising cookies, so no cookie-consent banner is required.

11. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be communicated by email or by a prominent notice in the Service at least 14 days before they take effect. The "Last updated" date at the top indicates when this policy was most recently revised.

12. Contact

Questions about this Privacy Policy: [email protected].

Symodal LLC · operator of mayoo.ai