Effective date: 14 September 2026 · Last changed: 10 October 2026 (a Gating Check is kept while it is unfinished, so a restart does not end it; how long Keepa's market data is kept is now listed; 9 October: your ungated list is kept until you clear it, and closing an account is described as it works)
Article 5(1)(e) of the UK GDPR requires personal data to be kept no longer than necessary. This schedule says how long each kind of data lives and what ends it.
| Data | Kept for | How it ends |
|---|---|---|
| Email address | Life of the account | Deleted immediately when you close the account |
| Password hash | Life of the account | Deleted with the account |
| Previous password hashes | Life of the account | Deleted with the account |
| Two-factor secret and recovery codes | Until 2FA is turned off, or the account closes | Deleted immediately when 2FA is disabled |
| Account created / last sign-in / last password change | Life of the account | Deleted with the account |
| Password change date and expiry (passwords expire after 365 days) | Life of the account | Deleted with the account |
| Email verification status | Life of the account | Deleted with the account |
Previous password hashes are kept for one reason: to stop a password being re-used when it is changed. They cannot be reversed to recover a password.
| Data | Kept for | How it ends |
|---|---|---|
| Sign-in session | 7 days maximum, or 12 hours idle | Expires automatically; deleted on sign-out; every session for an account is destroyed when its password changes |
| Password reset link | 1 hour | Expires, or is consumed on use |
| Email verification link | 24 hours | Expires, or is consumed on use |
| Failed sign-in counter | Until a successful sign-in | Reset on success |
Reset and verification links are stored as SHA-256 hashes, never as the link itself. Someone reading the file could not reconstruct a working link from it. Each is single-use: using it destroys it.
| Data | Kept for | How it ends |
|---|---|---|
| Encrypted Amazon refresh token | Until you disconnect, or the account closes | Deleted immediately on disconnect |
| Selling Partner ID, store name, marketplaces | Until you disconnect | Deleted on disconnect |
Disconnecting is immediate and needs no request to us. We recommend also revoking the authorisation in Amazon Seller Central, which is the belt-and-braces version and is entirely within your control.
| Data | Kept for | How it ends |
|---|---|---|
| Buy Box history | Rolling 7 days | Samples older than 7 days are discarded automatically |
| The cost you last typed for a product on the dashboard, and the day you typed it (added 19 October 2026) | Until you type a new one, or close your account — your newest 10,000 products | Replaced when you type a new cost; the oldest goes once there are more than 10,000; erased with the account |
| Products you found ungated, and what they were worth at the time | Until you clear the list, or close your account | "Clear list" on the Ungated List removes all of them at once, on every device; closing the account removes them too. Changed 9 October 2026 — they were kept for 30 days |
| Daily counts of how much you checked and how much was usable | Up to 400 days | Aggregate totals only — no product is named, so nothing here is Amazon Information |
| A Gating Check that has not finished: the list you pasted and the result for each product checked so far | Until it finishes or you discard it; a week if it is left untouched | Kept on the server while it is unfinished so that a restart of NASST does not end your check. Removed the moment it finishes, is discarded, or is replaced by a new one |
| Saved deal feeds (the filters you asked us to watch) | Until you delete the feed, or close the account | Deleted with the account |
| Deals found by the hourly sweep | 24 hours | Replaced by the next sweep; expired entries are dropped on read |
| Your SerpApi key, if you add one | Until you remove it, or the account closes | Encrypted at rest; deleted immediately on removal |
| SerpApi results from your own searches | 24 hours | Cached under your account only, then expires |
| A competing seller's shop name, looked up from their merchant ID | 90 days | Expires automatically; the name alone is kept, nothing else about them |
| A competing seller's full record (Buy Box share, brands, categories), when you ask for one | 24 hours | Expires automatically |
| A product's price, sales and Buy Box history (market data from Keepa; nothing in it comes from any customer's account) | Price and sales history 6 hours; who held the Buy Box and the sales figures shown in deal lists 3 days | Expires automatically. The page says when Keepa was asked, and "Refresh" asks again |
| Cached Amazon catalogue and pricing data | Short-lived, for performance | Expires automatically |
| Record of API calls made, for rate-limit accounting | 7 days | Older days are deleted automatically |
The 7-day Buy Box window is not arbitrary. Those samples record which other sellers held the Buy Box, and that is not something to hold for longer than the figure needs. Seven days still gives roughly 336 half-hourly samples per product — enough for a percentage that means something rather than a guess.
Why your ungated list is kept. (Changed 9 October 2026.) The products Amazon has said your account can list are the list you work from, found by your own searches on your own account. Until this date a product was dropped 30 days after it was last found, which left a list that emptied itself. It now stays until you clear it — "Clear list" on the Ungated List removes all of it — or close your account. Each entry shows the day it was last checked, because Amazon can change a restriction at any time: the list is a record of what it said then, not a promise about now.
What is in it is product information and Amazon's answer about your own account. Nothing in it is about a buyer. Amazon's Data Protection Policy puts a fixed limit of 30 days on buyers' personal information, of which NASST holds none, and requires everything else obtained through its API to be kept only for as long as it is needed to provide the service. A working list that you keep, and can clear whenever you choose, is kept on that basis.
| Data | Kept for | How it ends |
|---|---|---|
| Error and diagnostic logs | 12 months | Files older than the retention period are deleted automatically |
| Retailer pages you send with the page saver | 24 hours | Deleted automatically; the stored HTML goes with the record |
| Products extracted from those pages | 24 hours | Deleted with the page they came from |
| A security finding naming an address that scanned or was repeatedly refused | While open, then 30 days after it is resolved | Pruned automatically once resolved |
Logs record failures, not activity. They hold the endpoint of a failed request, a timestamp and an error message. Credentials are pattern-matched and stripped before anything is written to disk.
No IP address is written to them. The compliance pack drafted in September described an address as something that "may appear in a log line"; the request logger writes the method, the normalised path, the status and the duration, and no caller passes an address to it. The counts behind rate limiting live in memory for fifteen minutes and are then discarded. The one place an address is written down is a security finding — the row above — raised when a single address scans for known-vulnerable paths or is refused repeatedly, which is a record of an attack rather than a record of a customer.
Product identifiers are stripped too. A request path carries the item being looked at, so /api/keepa/B01LYFHY7S is written as /api/keepa/:asin. That keeps what a security log is for — which endpoint, what status, how slow — while making sure twelve months of logs cannot become a twelve-month record of which products a seller researched.
> Decided and implemented, 2026-08-28. Logs were kept for 14 days, which was > correct when the tool was single-user and local and wrong from the day NASST > was split off. Amazon's own two pages disagree — the Security and Compliance > Overview says a minimum of 90 days, the Key Security Control Guidance says at > least 12 months — so retention is set to 12 months, which satisfies both. > RETENTION_DAYS in server/log.js, pinned by the regression suite.
This changed on 28 August 2026. Closing an account used to be a request by email. It is now something you do yourself, and it happens immediately.
Go to Account → Close your account, enter your password and type DELETE. That single action removes, in order:
There is no queue and no 30-day tail. The moment you confirm, you are signed out on every device and your Amazon connection and its token are deleted. The rest is erased straight away, a piece at a time so that a large account does not hold up anybody else: a second or two for most accounts, longer for one that holds a great deal. The page waits, and tells you when it is done. The account itself goes last, when everything behind it has gone.
If a step fails, the account is kept — signed out, and with whatever had already been erased still erased — so that you can sign in and close it again. We would rather leave an account to be closed a second time than strand records behind one that no longer exists. (Reworded 9 October 2026: this used to say that nothing is deleted if a step fails, which was never how it worked.)
The password is asked for again even though you are already signed in. This is the only irreversible action in NASST, and an unattended logged-in browser should not be enough to trigger it.
One thing must be done first. If you have a live paid subscription, cancel it in Billing before closing the account. We cannot cancel it for you — that happens in the payment provider's own portal — and deleting our records while they carried on charging your card would be worse than asking. A free trial does not block closure; nothing has been charged.
If you cannot sign in, email info@nasst.co.uk and we will do it for you, after confirming the request came from you.
Deletion is deletion. We do not keep a shadow copy for analytics or marketing.
First exception: where we are legally required to keep a record — for example an invoice for HMRC — we keep the minimum for the period the law requires, and nothing else. We will tell you if this applies to you.
Second exception: which Amazon accounts have had a free trial. We keep a one-way hash of the Amazon seller id that used a trial, and the date it started. Nothing else: not your email address, your name, your store name, your token or anything you did with the service.
This one survives closure on purpose, and it is the only record that does. Without it, closing the account and signing up again with a different email address would grant another fourteen-day trial on the same Amazon account, and another after that, indefinitely. A trial costs us real money in third-party API calls, so an unlimited supply is not something we can absorb. The lawful basis is our legitimate interest in preventing repeated fraudulent use of a free trial, under Article 6(1)(f) of the UK GDPR.
We store a hash rather than the seller id itself because it is the least we can keep and still recognise a repeat. We should be plain about what that does and does not achieve: hashing here is pseudonymisation, not anonymisation. Somebody who already holds a particular seller id can check whether it appears in the list. What they cannot do is read the list and learn who is in it.
It is kept indefinitely, because a record that expires is a trial that can be taken again the day after it does.
Backups run nightly at 03:30 UTC. They contain only the data that cannot be rebuilt: accounts, your encrypted Amazon token, subscription state, buy-box history and server configuration. Caches and logs are deliberately excluded.
Each backup is encrypted with AES-256 before it leaves the server, and the decryption passphrase is not stored on the server it protects. Copies are kept for 30 days and then deleted, both on the server and at the backup site.
The backup site is a separate facility in Falkenstein, Germany — a different country to the Helsinki server, so that losing one site does not lose both copies. Both are within the EEA, so no international transfer arises.
Where deleted data persists briefly in a backup, it is not restored to live use and is overwritten within the backup cycle.
We review this schedule annually, and whenever a feature changes what we hold.