Lath is a backend you run your product on, so it holds two different kinds of data: yours, and your customers’. You are the controller of the second and Lath is the processor. The distinction runs through everything below.
An email address, a name if you give one, your workspace and projects, and a record of every operation you performed. API keys are stored as a SHA-256 hash and a short prefix — the value itself is shown once and never stored, so nobody at Lath can recover it. Card details are held by the payment processor; Lath stores an identifier and the amounts.
Lath offers sign-in through these providers for the end users of your product. What is requested from each is listed exactly, because it is the whole of what is received.
Requested: openid, email, profile. What is kept: the stable subject identifier Google issues, the email address, and whether Google reports it as verified. The profile scope is requested because the email claim alone omits the verified flag, and an unverified address cannot be used to link an account. No name, no picture and no other profile field is stored.
Requested: read:user, user:email. What is kept: the account identifier, and the primary verified email address. The email scope is necessary because GitHub’s public profile address is a display field a user may set to an address they do not control.
Requested: openid, profile. What is kept: the subject identifier only. The email claim is deliberately not requested — Microsoft does not guarantee it is verified and a directory administrator can set it, so it is not evidence of ownership and Lath will not treat it as such.
The access token is used once, immediately, to read the identity above, and is then discarded. It is not stored, not refreshed in the background, and never used to read anything else in your account. Lath requests no calendar, drive, contacts, repository or mail permission from any provider, and asks for no scope that would allow it to.
Whatever your product provisions through Lath: customer identifiers, plans, entitlements, subscriptions and usage counters. It is used to run the service you asked for and for nothing else.
A sign-in link or code is sent to the address given. Lath records that the message was sent, to which address, when, and whether the provider accepted it — the body is not retained. Volume is counted so that limits can be enforced.
A session records the browser’s user agent and the IP address it was created from, so that a person can see where their account is signed in and end a session they do not recognise. Operations records may carry the IP address a change was made from. These exist to answer “who did this, and from where” after the fact, and are not used for advertising, profiling or tracking across sites.
Your data is not sold, not shared with advertisers, and not used to train models. There is no analytics pixel on this website and no third-party script on any page you are reading.
Lath runs on infrastructure it does not own: managed Postgres, edge compute, an email relay and a payment processor. The current list is provided to customers on request and before any change that would move your data to a new one. Sign-in providers are not subprocessors — you or your users choose them, and data flows from them to Lath rather than the other way.
Operational records are append-only and kept while the account exists, because an audit log that can be edited is not one. Sessions expire on their own. Sign-in links and codes are single-use and short-lived. Write to support@trylath.com to export or delete an account and it will be done within thirty days, including the identities above.
Access, correction, export and deletion, exercised by mailing the address above. Lath is pre-launch and small enough that this is a person reading a message rather than a workflow.
Material changes will be noted here with a new date below. Questions about this policy go to support@trylath.com.