Draft — for counsel review before launch
Version 0.1 (draft), 3 November 2026. Highlighted text marks facts still to be confirmed.
Privacy policy
This policy explains what personal data Nanner Tech LLC ("Nanner Tech", "we") collects through Rhumb: the website at rhumbdata.com, its sandbox and its API. Nanner Tech LLC is registered in the State of Florida, USA. [To be confirmed by counsel: registered office address] Questions go to support@rhumbdata.com.
1. Who is responsible
- We are the controller of the data about accounts, API keys, usage, billing, the sandbox and the website.
- When an API customer sends prompts and tags to /v1/plan, we process that content on the customer's behalf, as their processor. The customer decides what goes in it, and our data processing addendum governs it. If your data reached us in a customer's prompt, contact that customer first.
- [To be confirmed by counsel: whether an EU representative and a UK representative are required under GDPR and UK GDPR Article 27, or whether our processing is occasional; and if required, their names and contact details]
2. What we collect
- Account: your email address and whether you verified it, your account's plan and status, your email preferences, and when you joined. Sign-in runs on Google's Firebase Authentication: it holds your password (as a hash, never in plain text) or, if you sign in with Google, the profile details Google shares, such as your name and email address.
- API keys: each key's name and optional note, its last four characters, a hash of its secret (never the secret itself), its status, expiry, monthly cap, and when it was created and last used.
- Usage: the number of calls per quota period and per day, by key, endpoint, live or test key, and result class (success, error, rate-limited); and whether we have sent your 80% and 100% quota emails.
- Request records: for each answered API or sandbox request, the time, account and key, endpoint, status, a summary of the need (task or purpose, provider names, and the names of needs and constraints, never values a prompt could carry), the model and provider chosen, why no model qualified if none did, which decision model read the request and whether a fallback was used, the response time and the catalog version. Never the prompt.
- Decision-model spend: per account and day, the number of /v1/plan readings, the input tokens and their estimated cost.
- Billing: your Stripe customer and subscription ids, plan, subscription status, billing period dates, whether the subscription is set to cancel, and any payment grace period. You enter card details on Stripe's own pages; we never receive them.
- Audit log: actions on your account and keys (such as a key created, rotated, disabled or deleted, a plan change or the account's deletion), who took them and when.
- Sign-up checks: daily counts of new free accounts, in total and per email domain. These counts hold no addresses.
- Emails we send you: the address and message, passed to our email provider.
3. The sandbox
The sandbox needs no account. To keep it free and stop abuse:
- Your first sandbox request in a session runs a Cloudflare Turnstile challenge, which sends your IP address and browser signals to Cloudflare. Sign-up and password reset run the same challenge.
- We turn your IP address into a salted hash (an HMAC-SHA-256 with a random salt for each UTC day) and never store the address itself.
- The hash goes into a signed sandbox token valid for 30 minutes, into per-minute and per-day request counters that are deleted after 2 days, and into the sandbox's request records, which are deleted after 90 days.
- Each day's salt is deleted after 2 days. After that, a stored hash can't be recomputed from an IP address, and the same address hashes differently on different days, so hashes can't be linked across days.
- We count failed challenges per day, without any IP data.
- A prompt typed into the sandbox is handled as described in section 4 and is never stored. Sandbox requests are not linked to any account.
4. Prompts sent to /v1/plan and the sandbox
- A prompt is held in memory only while we answer. Its token count sets the context size the answer needs; the first 4,000 tokens, with the tags and the attachment types (type and size only, never files), are sent to OpenAI's decision model to read what kind of task it is. If the request asks for the local decision model, or the sandbox's daily budget is spent, nothing is sent to OpenAI.
- We keep the structured reading (vocabulary values such as a task category, never the prompt or the tags) for 24 hours under a keyed hash of the request, so a repeated request is answered without another reading. Expired readings are purged every 60 minutes.
- Prompts never appear in our request logs, which record the method, path, status and timing of each request, and for /v1/plan which decision model answered, whether a fallback was used and why, and whether the reading came from the cache; nor in our error reports, which exclude request bodies, query strings, cookies and secret headers.
- We don't use prompts to train any model.
- [To be confirmed by counsel: OpenAI's retention of decision-model inputs under our account, including whether zero data retention is approved, and whether EU regional processing is in place for EU traffic]
5. Logs and error reports
Our hosting provider's request logs record technical data such as your IP address, browser user agent and the URL requested, to deliver and protect the service. [To be confirmed by counsel: the retention period configured for these logs in Google Cloud] When the API hits an error, it sends an error report to Sentry with the request path but without its body, query string, cookies, secret headers or user details.
6. Why we use it, and our legal bases
| Purpose | Data | Legal basis |
|---|---|---|
| Run your account and answer your API calls | Account, API keys, prompts, request records | Performing our contract with you |
| Count calls against quotas and rate limits, and show you your usage | Usage, request records | Performing our contract with you |
| Take payments and keep billing records | Billing | Performing our contract; legal obligations for tax and accounting records |
| Send service emails: verification, password reset, quota and billing notices | Email address | Performing our contract with you (quota emails can be turned off in settings) |
| Protect the service: the sandbox challenge, IP hashes, sign-up checks, the audit log, logs and error reports | Sandbox data, sign-up counts, audit log, logs | Our legitimate interest in keeping the service secure and the free sandbox available |
| Improve the catalog and the service from aggregate statistics | Request records, decision-model spend | Our legitimate interest in improving the service |
We don't sell your data, show advertising, or make decisions about you by automated means that have legal or similarly significant effects.
[To be confirmed by counsel: legal bases for the sandbox, which has no contract, and whether any US state privacy law notices apply]
7. Who processes it
We share data only with the subprocessors that run the service, listed with what each receives on the subprocessors page: Google Cloud and Firebase (hosting, database, sign-in), OpenAI (the decision model), Stripe (payments), MailerSend (email), Cloudflare (Turnstile) and Sentry (error reports). We may also disclose data where the law requires it.
8. International transfers
We are based in the United States, and the service's API and database run in Google Cloud's us-central1 region in the United States. Where data from the EU, EEA, UK or Switzerland is transferred, we rely on standard contractual clauses or an equivalent safeguard. [To be confirmed by counsel: whether Nanner Tech self-certifies under the EU-US Data Privacy Framework, and the UK and Swiss transfer mechanisms]
9. How long we keep it
| Data | Kept |
|---|---|
| Prompts and tags | Not kept: in memory only while we answer |
| Structured readings of /v1/plan requests | 24 hours |
| Request records (including sandbox IP hashes) | 90 days |
| Sandbox rate-limit counters | 2 days |
| Daily IP-hash salts | 2 days |
| Sandbox tokens | Valid for 30 minutes |
| Daily totals of request records, for our dashboard | Indefinitely; daily counts only (some per account id), with no prompt, IP hash or key |
| Account, API keys and settings | Until you delete your account (section 10). A deleted account's former sign-in id, and its revoked keys' names, notes and last four characters, are not deleted. [To be confirmed by counsel: a retention period for these records, which have no automatic deletion today] |
| Usage counts, decision-model spend and the audit log | Linked to your account id; not deleted with the account, but they no longer lead to you once it is deleted. [To be confirmed by counsel: a retention period for these records, which have no automatic deletion today] |
| Billing records | Our subscription records stay, without your Stripe customer id once the account is deleted; Stripe keeps invoices as the law requires |
10. Deleting your account
You can delete your account from your account settings; you may be asked to sign in again first. When you do, at once:
- any subscription is cancelled and your Stripe customer record is deleted (Stripe keeps its invoices);
- every API key is revoked and its secret hash erased;
- your email address and settings are erased from our database, and your sign-in account is deleted from Firebase Authentication; we keep its former sign-in id only to refuse sessions issued before the deletion;
- the names and notes you gave your keys, and each key's last four characters, stay with the revoked keys;
- the deletion is recorded in the audit log.
Records kept by account id, such as usage counts and request records, stay until their normal expiry (90 days for request records) but no longer lead to you.
11. Cookies and browser storage
We don't use analytics or advertising cookies, and the site sets no cookies of its own. It serves its own fonts, so loading a page sends nothing to a font provider. In your browser's storage, the site keeps only what it needs to work:
- your light or dark theme choice;
- your signed-in session, kept by the Firebase Authentication library.
Cloudflare Turnstile (sandbox, sign-up and password reset), Google sign-in and Stripe's checkout and billing pages may use strictly necessary cookies of their own under their own policies. [To be confirmed by counsel: whether these third-party cookies need a notice or consent banner in any market]
12. Your rights
Depending on where you live, you can ask us to access, correct, delete or export your data, to restrict or object to how we use it, and to withdraw any consent you gave. You can see your keys and usage in your account, export your usage as CSV and delete your account yourself; for anything else, email support@rhumbdata.com and we'll reply within 30 days. If you're in the EU, EEA or UK, you can also complain to your local data protection authority.
Because we store sandbox data only as daily-salted IP hashes, we usually can't find a person's sandbox records, and don't need to keep extra data to do so.
13. Children
The service is meant for developers and businesses and is not directed at children.
14. Changes
The version and date at the top of this page show when this policy last changed. We will email account holders before a material change takes effect.