What Harakumo keeps about your app's users

The people who use your app have no Harakumo account. What Harakumo holds about them is what your app sends through each service, plus the few records a service keeps to work: a sign-in pool keeps each user's email address and password hash, the mail log keeps each email's recipient and subject, a payment keeps the buyer's email and country. This page lists all of it, from the code, so you can fill in the stores' forms and write your privacy policy from what is true.

To your users, Harakumo is a service provider acting for you: it keeps this data to run the service, bills you by counts and never by who your users are, does not sell it, and does not train AI models on it. Who at Harakumo can see what, and how long each kind of record is kept, is on harakumo.com/security; what Harakumo keeps about you, the account holder, is on harakumo.com/privacy.

Before you fill in a form

Both stores count data a service provider stores for you as data your app collects, so what the table below lists counts as collected by your app, with you responsible for it. The forms also ask whether the data is linked to a person (a sign-in pool's records are, by email address), whether it is used for tracking (Harakumo uses none of it for advertising or tracking, and puts no identifier, analytics code or cookie in your app), and who else receives it, which the table says per service.

Only what your app sends is held: an app that never asks for a name stores no names. Add whatever your app itself collects and whatever other services it uses, such as crash reporting, an analytics kit, or a push service other than Harakumo's.

Read each store's current form before answering. The categories change, and the words below are Harakumo's, not the stores'.

Service by service

Service	What Harakumo keeps	For how long	Who else receives it
Sign-in (auth pools)	Each user's email address, the name your app sends (if any), a hash of their password (never the password; none for an account made with Apple or Google), when they signed up and last signed in, whether and when their email was verified, and a count of recent wrong passwords, with a 15-minute lock after too many. A code emailed to verify an address, reset a password, confirm a new address or delete the account is stored hashed and expires after 15 minutes; a new address waits beside its code until it is confirmed. The token the app holds is not stored: it lasts 7 days unless the pool sets a shorter lifetime, and a deleted user's tokens stop verifying at once.	Until the user deletes their own account (in the app, or on the deletion page), your app deletes the user (`DELETE /api/auth-pools/:id/users/:userId`), or you delete the pool or the project.	The email delivery provider, which carries the code emails.
Signed-in devices (refresh tokens)	For an app that asks for refresh tokens: one record per signed-in device, with the label the app gives it (such as "Sam's iPhone"), when it signed in and was last used, and hashes of its current refresh token and the one before it, never the tokens. At most 20 per user.	A session ends after 60 days without a refresh, a year after sign-in, at sign-out, or when the password or email address changes; an ended session's record is removed the next time that user signs in on a device asking for a refresh token, and every record goes with the user.	No one.
Sign in with Apple and Google	Which Apple or Google account signs in as which user: the provider, the account's id for your app, the email address it gave, and when it was first and last used. The ID token the app sends is checked and not kept.	Until the user is deleted, or you delete the pool or the project.	No one. Harakumo checks the token against Apple's and Google's published keys and sends them nothing; the person signed in with that company on their own device.
Push notifications	For an app that registers devices for push: each device's push token, its platform (iOS or Android), which push service delivers to it and, for Apple, whether it is a development build, with when it was registered and last seen. At most 20 per user. The notifications you send are not kept, only how many went out.	Until the app unregisters the device, the user registers more than 20 (the oldest goes), or the user is deleted. A device the push service reports gone is switched off and kept until then.	Apple's push service and Firebase Cloud Messaging, which carry each notification, its title, text and data, to the device.
Events to your server	When a user is deleted and the pool has a webhook: a `user.deleted` event with their id and email address, kept to deliver it to your server.	The address leaves the stored event once it is delivered or given up on (eight tries over about two days; a retry goes out only while your app is in use, so it can wait longer). The event without it stays until you delete the pool or the project.	Your own server, at the webhook address you set.
Sign-in abuse counters	The address a sign-up, sign-in, code or reset request came from, as a counter per pool: at most 10 sign-ups an hour and 30 sign-in attempts in 10 minutes from one address, for example. A counter is a number next to an address; no address is kept with a user.	A counter is deleted two days after it starts.	No one.
The bot check on sign-up (when it is on)	Nothing: the one-time token a visitor's browser earns is confirmed once and dropped.	—	The company that runs the check: the visitor's browser talks to it while passing the check, and Harakumo sends it the token, and the visitor's address when known, to confirm it.
Your function (the app's API)	Nothing. Requests to a function's own address do not pass through Harakumo, which neither logs them nor counts them, apart from how many requests Shield's rules refused, and nothing a function prints is kept. The guard in front of the function reads a caller's country, address and user agent only to apply your Shield rules, and keeps none of them. What your function stores, it stores in the services below.	—	Whoever your function sends data to, which only your code decides.
Databases	Whatever rows your app writes. Harakumo's own tools show a database's size and row counts, never its rows.	Until your app deletes the rows, or you delete the database or the project. Copies kept to recover from failures remain until those copies are deleted; that period is not set yet.	No one.
File storage	The files your app uploads, under the names it chooses, each with its size and time. Harakumo keeps no record of who uploads or downloads a file: the bytes pass between the person's device and storage, and a link is checked, not logged. An upload link lasts at most 15 minutes; a download link lasts at most 15 minutes from a read-only key and up to 7 days from a full one.	Until your app deletes the file (`POST /api/storage/:id { "key", "method": "delete" }`), or you delete the bucket or the project.	No one.
Vector DB	The texts and metadata your app adds, and their vectors.	Until your app deletes them by id (`POST /api/vectors/:id { "action": "delete", "ids" }`), or you delete the collection or the project.	No one. Text sent to be embedded is embedded on the infrastructure provider's inference and reaches no model company.
Memory	The keys, values and chat messages your app stores under the scope it names (a user id or a session), and the embeddings of what it stores for recall by meaning. A conversation keeps its last 1,000 messages per scope; an item with an expiry goes when it passes.	Until expiry, until your app deletes a key (`DELETE /api/memory/:id/keys/:key`) or a scope's transcript (`DELETE /api/memory/:id/messages?scope=`), or you delete the store or the project.	No one. Embeddings are made on the infrastructure provider's inference.
AI	A request log: the model asked for and the one that answered, token counts, cost, timing and whether it failed. Never the prompt or the answer.	30 days.	The company that makes the model: your prompt and its answer go there. `GET /api/ai/chat` lists every model with its maker (`provider`). With `harakumo-1`, that is the first available model in its order, and another company's model when one fails; name a model to know which company. `llama-3.3-70b` and `kimi-k2.6` run on the infrastructure provider's edge inference, as embeddings do, and reach no model company.
Agents	Each run's input, output and every tool call with its arguments and results, so you can review them: what a tool read from your database, memory or repo is in the run.	Finished runs are deleted with their steps by a daily clean-up once they are more than 90 days old; a run still going is kept until it ends. Deleting the agent deletes its runs at once.	The company that makes the agent's model, as for AI.
Mail	For each email: the recipient's address, the sender, the subject, when it was sent and whether it was delivered or failed. Never the body. An address that bounced, complained or unsubscribed goes on the workspace's suppression list, so it is not mailed again.	The log and the list stay for as long as the workspace exists.	The email delivery provider, which carries the message.
Payments	Card numbers never reach Harakumo or your app: the buyer pays on the processor's hosted page. Harakumo keeps the amount, currency and description, the buyer's email and country with each payment, and the email your app gave when it made the checkout link.	Payment records are kept after the project is deleted, as the law requires.	The payment processor, which has the card and whatever the buyer typed on its page.
Media	The videos your app uploads and the live streams it sends, with each asset's name, size, duration and a view count. No record of who watched.	Until you delete the asset or the project.	The infrastructure provider, which stores and plays them.
The companion website (a static site)	The site's files. Harakumo keeps no visitor log: the program that serves a site reads a visitor's country, address and user agent only to apply your Shield rules, keeps none of them, and counts only how many requests each rule refused.	—	No one.
Server apps	The last 200 lines your app prints, as the deployment's runtime log in the dashboard. If your app prints a visitor's address or email, that is in the log.	Until the deployment is deleted.	No one.
Usage and billing	Counts per workspace and project: database calls, emails sent, AI tokens, agent runs, storage size. Never anything about one person.	Kept as the workspace's usage history.	No one.

Name the companies

The forms and your policy ask who else receives the data. For what Harakumo handles, that is Harakumo, as your service provider, and the companies behind it: a hosting, storage and inference provider (sites, functions, databases, files, edge models and embeddings), an email delivery provider, a payment processor, the AI model companies whose models your app uses, Apple's and Google's push services when your app sends notifications, and the bot-check provider when the bot check is on. Their names are not published on harakumo.com/security yet; until they are, name the kinds, and name each model company from GET /api/ai/chat.

The stores expect an app that sends what people type to an AI model to say so in its policy and to name who receives it. With a named model that is one company; with harakumo-1 it is any company in the router's order, so an app that must name exactly one names a model.

Deleting one person's data

Deleting the user from the sign-in pool removes everything the pool holds about them in one step. What your app stored about them in a database, storage or memory is for your app to remove, which the user.deleted event tells it to do.

Delete the user from the sign-in pool: they can do it themselves (delete-account in the app, or the deletion page), or your server calls DELETE /api/auth-pools/:id/users/:userId. Their tokens stop verifying at once, and their signed-in devices, push devices, Apple or Google links and emailed codes go with them. Your webhook hears user.deleted.
Delete their rows from your database with your own SQL, and their files from storage, key by key (POST /api/storage/:id { "key", "method": "delete" }).
Forget their memory: their transcript (DELETE /api/memory/:id/messages?scope=<userId>) and their keys, and their vectors by id.
What stays: their address and the subject lines in the mail log, their email and country on any payment (as the law requires), the abuse counters, which hold only an address for two days, and their address in the user.deleted event until it is delivered or given up on.

What Harakumo does not do with your users' data

No advertising and no analytics about your users: no advertising identifier, no analytics code and no cookie of Harakumo's in your app. Harakumo's only cookies keep you signed in and remember your active workspace on harakumo.com; neither is set in your app.
No selling, and no training of AI models on your users' data, your content or your prompts.
No reading by staff: Harakumo's admin tools show resource names, counts, sizes and status, never your database rows, stored files, your app's user list, the emails you send or your AI prompts. What they do show, and when a look is written to your audit log, is on harakumo.com/security.
Nothing crosses a workspace: a resource id from another workspace answers 404 before any of its data is read (see Security & data isolation).