The retention position the roadmap requires, stated per category rather than as a single sentence, because the answers genuinely differ.

Images

Nothing is kept. An image arrives base64-encoded in a request body, is held in memory, is forwarded to the model provider, and ceases to exist when the request ends. It is never written to disk, never written to the database, and never appears in a log line.

This is the strongest claim on this page and the one most worth being able to prove. It is enforceable by reading app/api/ai/describe/route.ts: the buffer is a local, and nothing persists it.

What the model provider keeps is their retention policy, not ours — which is why the sub-processor list matters and why the OpenRouter fallback is an open question rather than a detail.

Descriptions

Returned to the plugin and stored in the customer's own WordPress database, in their vergeml_ai_index table. We keep no copy. Deleting them is the customer's own operation on their own site.

The one exception is batch jobs: ai_job_items holds a returned description until the plugin collects it, because a batch is asynchronous and the result must survive until it is fetched.

Purged 30 days after the job finishes. The nightly /api/cron/reconcile clears alt, caption, tags and error on every item whose job has ended, failed or been cancelled and finished more than thirty days ago.

Two deliberate choices in that:

• Thirty days from the job finishing, not from collection. A site can be offline for a fortnight, and a customer returning to find the descriptions they paid for already deleted is a worse failure than holding them a little longer.
• A job that has not finished is never touched, however old. Its items are work already paid for and not yet collected; emptying them would take away the thing that was bought.

The job row itself survives with its image_count and credits_spent. That is our accounting, not the customer's content — the promise is that we stop holding what the model wrote about their pictures, not that we forget a job happened.

Usage and metering

credit_entries holds one row per credit movement: a licence id, an amount, a reason, a timestamp. No filename, no image, no description. It is the financial record, it is what the rate limiter counts, and it is retained for as long as the licence exists plus the statutory invoicing period.

Accounts and licences

Email, hashed password, licence keys (hashed), activated site URLs. Retained while the account exists. On deletion, removed within 30 days.

Invoices and tax records

Retained six years: Art. 30 of the Spanish Código de Comercio requires accounting records to be kept that long, and the tax limitation period is four. This is not negotiable and overrides a deletion request for those specific records. The exact figure is the accountant's to confirm; six is the conservative reading and the one stated here.

Logs

Vercel request logs hold IP addresses and request metadata for whatever their platform retains on the current plan; that figure is Vercel's to state and is not something this repository can assert, so it is quoted from the dashboard rather than guessed at here. Application logs record token counts and error codes, never image bytes and never the licence key itself.

Sessions

sessions rows carry last_seen_at, ip and user_agent, added in migration 004 so a user can recognise their own sessions. Retained until sign-out or expiry, and expiry is two limits rather than one (lib/auth.ts):

These are read from the constants, not chosen for this page, so the page cannot drift from the code without the constants moving first.

Who this is

Boetiek House S.L., CIF B75865022, Calle Fernando Fuentes 2, 38300 Santa Cruz de Tenerife, Spain.