Information used for account access and accounting
The service stores email, password hashes, API key hashes and prefixes, credit-usage records, abuse-prevention information including IP information, and payment transaction records. These support account access, authentication, credit accounting, payment verification and abuse prevention. Describing hash storage does not mean individual users’ hashes are published, and it does not promise encryption-at-rest or that no information is retained.
If you save archive responses or coding notes in your own tools, those are separate copies you manage. Do not include passwords or API keys in those files. Consider which contributor details are necessary for the research question and which can be left out of a shared report. The account interface is not a backup or a research-data management service for your local dataset.
Session, invoice recovery and analytics
The website uses a Secure HttpOnly session cookie. The payment widget saves the current user and invoice identifiers in localStorage per hostname for invoice recovery. It does not persist the raw API key, password, transaction hash or invoice amount there. The server authorizes access to invoice status; a saved browser identifier is not permission to view another account’s invoice.
Pages include Statinside analytics counter 43. No particular analytics event fields or cookie-free behavior are asserted here. Account sessions, invoice identifiers and page analytics have different purposes from the historical records returned by the API. Keep those categories separate when documenting how information enters your own research process.
Retention and your own handling decisions
No fixed retention deadline for account, personal or payment information has been established. This does not promise automatic deletion on a schedule. It concerns account-related data, not how long archive records remain available or whether a historical conversation can be recovered in full.
Define access and retention rules for the copies and manual codes stored in your own project. Avoid putting unnecessary personal information in issue reports or shared coding examples. Limit shared extracts to the context needed for the question, while respecting applicable law and third-party rights. The public visibility of an original message does not remove those responsibilities.
