Alpha build — in active development. Anything here can still change. What this means
EVE Forge

Privacy

Privacy policy

EVE Forge keeps EVE Online records for the pilots you link to it. This page states what that means concretely: what is stored, where it lives, who can see it, how long it stays, how to get it back or have it erased, and what becomes of it if the project stops or CCP stops it. It is written to be checked — every claim below corresponds to something in the source, and docs/PRIVACY.md maps each one to the file that makes it true.

Last reviewed against the code: 2 August 2026

Responsible

Who is responsible

EVE Forge is run in the EU by Latte, one person rather than a company or team. More information about Latte is published at hiddenden.cafe.

To reach a person, write to latte@hiddenden.cafe, or mail the pilot named on the operator page. Email is the one that works if your subscription has lapsed, so it is named here and not only there.

What that address is not: a queue. There is no committed process for a data request and no stated turnaround, and the section on erasure below says plainly what that means. If that is not good enough for you, the honest advice is not to grant the scopes in the first place — which is why it is on this page rather than left to be discovered.

Data

What is stored

Private EVE account data reaches EVE Forge through CCP's ESI API, within the scopes you approved. Older public killmail history is backfilled from zKillboard after ESI's recent window ends; settings or records you enter yourself are the only other addition. A scope you withheld is skipped entirely — that private section stores nothing at all.

Your account

An internal account number, which of your pilots the dashboard opens on, a short ISK transfer code so a donation can be matched to you, a session counter, and the times you created the account and last logged in.

users

Your linked pilots

For each character: its EVE character id and name, CCP's owner hash, the list of scopes you approved, and your ESI access and refresh tokens — encrypted, never in plain text.

characters

The verbatim ESI archive

Every ESI response body we fetch for you, exactly as CCP returned it, one row per character and resource, rewritten only when its content changes. Response bodies only: no tokens, no cookies, no request headers.

esi_payloads

Your records, normalised

Skills, training queue, assets, planetary colonies, current location, killmails (yours and your losses), the page reached by the public killmail backfill, and your mining ledger.

character_skills, character_skill_queue, character_assets, character_planets, character_locations, character_killmails, killmail_sync_states, mining_ledger_entries

Your financial history

Wallet journal, market transactions, market orders, industry jobs, owned blueprints, contracts and their items — kept past the window ESI still serves, which is the point of the tool. Also the per-resource sync state, including the last error.

financial_journal_entries, financial_transactions, financial_market_orders, financial_industry_jobs, owned_blueprints, financial_contracts, financial_contract_items, financial_sync_states, user_orders, industry_jobs

The dashboard read model

A rendered snapshot per character so a page load is a database read rather than a fan-out of calls to CCP.

character_snapshots

What you typed or configured

Your fee and region settings, item cost overrides, private structures you registered, saved appraisals, survey-mining sessions, and ship replacement claims you filed. Two of those are shareable on purpose: a saved appraisal and a survey session are addressed by an unguessable code, and anyone signed in who holds that code can open them — that is what the copy-link button is for. Saving an appraisal is a choice per appraisal, and you can give one an expiry.

finance_profiles, item_cost_overrides, private_structures, appraisals, mining_survey_sessions, srp_claims

Feedback you send, and the conversation on it

What you wrote, the page you sent it from, and your plan and pilot count at that moment. A report sent with an account is a ticket: the operator's answers and your replies to them are stored as messages on it, each with which side wrote it and when the other side opened it — that last part is what the unread count is made of. Also the IP address, browser and referring page the report arrived with — kept to spot abuse of the version that needs no account, and so a bug report does not have to start with which browser you use. Those three are for the operator only: they are not in your own view of your reports, and not in an export of your account, and neither is which of the operator's pilots wrote an answer. A report sent without an account keeps the three origin fields too, has no ticket and no thread, and one whose address and browser match a signed-in account can be recognised as such. If the operator files your report as an issue on their repository, you are shown that issue only when they switch it on for that ticket. A report that reached the operator as an EVE mail carries none of the origin fields — no page, no address, no browser, because it never came through a browser — only the mail's own id, so the same mail is never filed twice. And an answer to one can travel back the same way: one reply, as one EVE mail, to the pilot who wrote first. Where the operator has switched it on, they can also write to a pilot who has not written at all — one mail to one pilot, never a list; that mail is not a report and is not a ticket, so it is stored on the operator's side (who it went to, its subject and text, and whether it arrived) and not against your account.

feedback, feedback_messages

Your EVE mail, if you switch it on for a pilot

Since 23 August 2026, and off until you press Connect on a pilot, because the permission it needs is deliberately not part of signing in — asking for it at the login screen would collect a mail permission from every account, including everyone who never opens the page. Connecting stores two things, and your inbox is not one of them. First the permission itself, encrypted at rest with the same key your ESI tokens use, and forgotten the moment you disconnect. Second the mails you send from here: who they went to, the subject, the text, and how the delivery ended — kept because that text has to survive a send that fails or ends ambiguously, so pressing retry re-sends the mail instead of losing what you wrote. Your inbox is never stored. Each time the page loads it is read live from EVE and kept only while it is on your screen: no headers, no bodies, no copy of what other pilots wrote to you. Those people have no account here and agreed to nothing, which is why that is a rule rather than a detail. The operator can read a mailbox you connected — see the operator section below — and cannot send from it.

character_mail_grants, character_mail_sends

How you signed in

One row per successful sign-in: the account, the pilot, the time, the IP address and the browser. It is what makes an unusual sign-in visible at all. Pruned on a schedule, unlike most of what is above.

login_events

Billing

Your subscription, ISK payment intents and their references, your ISK balance ledger, operator-issued access grants, and corporation subscriptions billed to you. There is no card, no bank detail and no invoice address, because nothing here is paid in money.

subscriptions, payments, account_ledger_entries, access_grants, corporation_subscriptions

Market prices, opportunity scans and the station/office tables are also in the database, but they are public game data and belong to nobody: no character id, no account id, no link to you.

Data

Other characters in your records

Some of what CCP hands us about you names somebody else, and we keep it as given: the counterparties in your wallet journal and market transactions, the victim and attackers on your killmails, the sender of an ISK donation, and the pilot who filed a ship replacement claim in a corporation you can read. Where a linked pilot has the in-game role for it, corporation-owned records are stored under that corporation rather than under you. On a corporation's wallet division those counterparty ids are also shown as names, to that corporation's Directors and Accountants — the people whose job it already is to read its books.

None of it is EVE Forge's to publish, and none of it is published — see below.

Data

What is not stored

There is no email address, no password, no real name, no postal address and no payment detail anywhere in the schema. You never give EVE Forge a password: you authenticate at CCP and we receive a scoped token. Everything paid for is paid in in-game ISK, so no card or bank detail exists to store.

Some things about you are nonetheless not EVE data, and it would be wrong to claim otherwise:

  • Your IP address, for rate limiting. Starting a login increments a counter keyed on your IP so the login route cannot be hammered. The counter lives in Redis (or in process memory when Redis is off) and expires with its time window, measured in seconds.
  • Your IP address, in server logs. The web server logs each request with the client address. Those lines are kept in a bounded in-memory ring that a restart empties, and — only where the operator configured a log file — in a rotating file with a hard size ceiling. Secrets are stripped as the line is written, not as it is read: authorisation codes, tokens and client secrets are replaced before they reach either place.
  • Your IP address and browser, when you sign in. Every successful sign-in is recorded with the account, the pilot, the time, the address and the browser, so an unusual sign-in can be seen at all. These rows are pruned on a schedule rather than kept indefinitely.
  • Your IP address and browser, when you send feedback. A report keeps the address, the browser and the page that referred you, whether or not you were signed in. It is there to spot abuse of the version that needs no account and to save asking you which browser you use. It is visible to the operator only, and a report sent without an account can be recognised as coming from the same address and browser as a signed-in one.

Security

Your tokens and your session

  • Refresh tokens are encrypted at rest.They live in two columns on the character row and are Fernet-encrypted with a key held in the deployment's environment, never in the database. Short-lived access tokens are cached in Redis with an expiry.
  • The archive holds no credentials. Only ESI response bodies are archived. Tokens, cookies and request headers are never written to it, which is what makes handing you the complete archive safe.
  • The session cookie carries nothing. It is a signed token holding a character id and a session counter — no personal data, no ESI token.
  • One counter revokes every session.Each account has a session version; a session is only accepted if the version in the cookie still matches the account's. Logging out increments it, so every browser signed in as any of your pilots is signed out at once — and the same lever ends every session immediately if a key ever has to be pulled.
  • A sold character loses its history.If CCP's owner hash for a character changes, the character and the records stored under it are deleted before the new owner can link it. The buyer never inherits the seller's data.

You can withdraw ESI access from CCP's side at any time, without asking us, at CCP's authorised applications page. Revoking there stops every future sync immediately; it does not by itself remove what is already stored, which is what the erasure route below is for.

Disclosure

Nothing you give us is published

EVE Forge publishes no data that came from a user — not by name, not anonymised, not aggregated across accounts. There are no leaderboards, and no route that hands your records to anybody else. That is a recorded decision rather than an accident of the current release.

It is structural rather than a policy anyone has to remember: no endpoint serves account data without a session, and the handful that answer without one serve public game data only. On the date at the top of this page that was fifteen of 124 endpoints — the health check, the three EVE SSO login routes, the public list of subscription tiers, seven market-preview routes that read prices and regions straight from CCP without touching our database at all, the market-pulse summary described below, a readiness probe that answers only to whoever holds the monitoring secret, and the address your own browser posts to when a page crashes. The third login route only exists when the deployment is local, which the configuration refuses to allow otherwise. Every other endpoint resolves your session cookie against your account row before it answers a word. The count moves as pre-login features are added; the rule above it does not, and re-checking it is a recorded step rather than a matter of trust.

One of those fifteen does read the database, and it is the only one: the market pulse on the front page, which shows the median trading margin per region from the opportunity scanner's last pass. The two tables behind it are built entirely from CCP's public market data on a daily schedule and belong to nobody — there is no character, account or corporation on either of them, and the page shows no item, price or order. It is not an exception to the rule above: there is no user data there to serve.

Data is never sold, never shared for advertising, and never pooled with other pilots' records to build a product.

Third parties

Who else touches it

The backend makes outbound requests to four hosts, and to two more if the operator has connected them. What CCP receives is what your scopes allow and nothing else — the permissions you tick on CCP's screen are the whole of it. zKillboard receives only the public character id used to recover older killmail history:

  • CCP — login.eveonline.com.The EVE SSO: authorising, exchanging and refreshing your tokens, and verifying CCP's signing keys.
  • CCP — esi.evetech.net. The source of private game data. Requests carry your token, because that is what makes them your data. In one direction only it also carries something outward: if you wrote to the operator by EVE mail and they answer, that reply and your character id go to CCP as one mail — the same route it would take from any other client. Where the operator has switched on writing first, a mail they start carries the same one character id outward, one mail at a time.
  • zKillboard — zkillboard.com.One cached public page per sync, addressed only by character id, recovers killmail ids, hashes and ESI-shaped killmail bodies that no longer appear in CCP's recent endpoint. No ESI token, account id or other private data is sent.
  • Fuzzwork — www.fuzzwork.co.uk.A public mirror of CCP's Static Data Export. EVE Forge downloads a handful of static CSV files from it (market groups, industry recipes, planetary schematics) to avoid crawling thousands of ESI endpoints for data that is the same for everyone. These are plain downloads of fixed URLs: no token, no character id, nothing about you is in the request.
  • An AI provider — only if one is connected. EVE Forge has no AI of its own; a provider is connected by the operator or not at all, and on an instance with none, nothing is sent anywhere. The everyday case is a report you send, passed on to be summarised or turned into a development issue. A question asked about how this instance is running can also be answered from stored records, so those can reach the provider too. What never does: your ESI tokens, and the address, browser and referring page a report arrived with.
  • Gitea — a code repository. When a report becomes a development issue, the text of that issue goes with it. No account id and no character id is sent, so an issue does not say who reported it.

There is no analytics, no tracker, no advertising network and no third-party font: the fonts are served from EVE Forge's own origin, and the page's content-security policy allows images from CCP's image server and from nowhere else. Your browser therefore fetches portraits and item icons directly from CCP, and talks to no other outside host.

The application server and its database are hosted in Europe. There are no database backups yet. The scripts and the restore procedure exist and have been rehearsed, but nothing is installed on the server that serves you, so today a disk failure would lose your history rather than delay it. That is stated here because the whole point of this tool is that your history is kept, and a page claiming a backup schedule that is not running would be the worst possible place to be optimistic.

Access

Who can see your data

You can, through the app, for the pilots on your own account. Asking for another account's character returns the same "not found" as a character that does not exist, so the API cannot be used to discover who else is here.

The operator can, for the purposes below. That is worth stating plainly rather than leaving you to assume otherwise: running a service that stores your records means the person running it can reach them, to keep it working, to answer a support question you asked, and to act on a report of abuse. It is not used to browse.

What bounds it is where the permission lives. Operator access is a list of EVE character ids in the deployment's environment, not a flag on an account — so nothing inside the app can grant it, a malformed list locks everybody out rather than letting anybody in, and to anyone not on it those screens answer "not found" rather than "forbidden". Two things it never includes: your tokens, which are stripped from every export before it is written, and any ability to act in game as your character.

One of those bounds is worth spelling out, because a mailbox is the one place this app can write to EVE at all. If you connect a pilot's mail, the operator can readthat mailbox — the same live read you get, using the permission you granted, and each one leaves a line in the operator's log. They cannot send from it. Reading is what connecting authorises and writing under your name is not, so the routes on their side answer reads only. The single exception to "this app does not act in game as you" is a mail you send yourself, from this page, by pressing send.

Retention

How long it is kept

Keeping history is the product: ESI serves a moving window — thirty days of mining ledger, a limited run of recent killmails — and a year-over-year view can only exist if those rows are kept after ESI drops them. So the honest description of today's behaviour is that your records accumulate and are not pruned on a schedule.

What does expire on its own:

  • A shared survey-mining link stops resolving seven days after its last scan update.
  • An appraisal expires if you gave it an expiry when you saved it.
  • Cached access tokens expire in Redis; rate-limit counters expire with their window.
  • Opportunity scans keep only the newest runs; older runs and their rows are pruned.
  • Sign-in records are pruned after a fixed number of days. Feedback is not: a report and what it arrived with stay until the operator deletes them.
  • Server logs are bounded by the in-memory ring and by log-file rotation.

While you are using EVE Forge, everything else stays. That is the point of it: a year-over-year view cannot exist if the rows behind it are pruned, so records accumulate for as long as the account is in use, and no schedule removes them.

If nobody logs in for twelve months, the account and every record under it are removed. Everything: the pilots, the stored history, the verbatim archive from CCP, the billing ledger. Twelve months is deliberately long for this game — skipping an expansion and coming back is ordinary, and the history you left is exactly what you would return for.

Two details worth having, because they change what this promise is worth. The clock reads your logins, not whether data is still arriving — so revoking at CCP does not start it, because withdrawing consent is not the same act as walking away. And the removal is performed by the operator rather than automatically: the sweep is a deliberate action, and the instance reports how many accounts are due so that it is a routine rather than something to remember. In practice that means the twelve months is the point at which removal becomes due, not the minute it happens.

There is no warning before it. EVE Forge holds no email address for you — there is nothing in the schema to send one to — so this paragraph is the notice, which is why it is here rather than in a changelog entry you would have to go looking for.

Dropping from a paid tier to free does not delete anything; it narrows the range the app will show you back to thirty days.

Wind-down

If EVE Forge stops, or is stopped

Third-party EVE tools die, and they mostly die without saying so. Two versions of that apply here, and they are not the same event. EVE Forge is run by one person and could be wound down deliberately. Separately, clause 2.4 of CCP's Developer License Agreement lets CCP disable this application's access to ESI immediately and without notice, and nothing in that clause obliges anyone to warn us first. Since EVE Forge asks for ISK, both endings are written down here before a purchase instead of being explained after one.

If the project is wound down. A planned shutdown is announced, dated, on the changelog and through the contact channel on the operator page, and this section is rewritten with the real dates on the same day. Those are the two channels that exist; there is no mailing list, because there is no email address in the schema to put on one.

There is no committed minimum notice period, and pretending otherwise would be the easy thing to write here. One person runs this, and how much warning you get depends on what ends it: a decision has weeks in it, a CCP cutoff has none by definition. What is committed is the next paragraph — the thirty days of access after the last maintained day — because that is the part that does not depend on knowing in advance.

  • Getting your records out is not self-service.There was a one-click export until August 2026 and there is not one now, so the honest version of this answer is that a copy in a shutdown depends on somebody producing it, the same as a copy on any other day. The tooling exists on the operator's side; the commitment does not. If keeping your own history matters to you, the reliable move is to keep your own copy as you go rather than to rely on this paragraph.
  • Logging in keeps working for a while after the last maintained day. Thirty days from the last day the tool is maintained. Long enough to read what is there and write down what you want to keep. That is worth less than it was when a one-click export existed, and it is what remains rather than what was promised — but it is a date rather than a hope, which is more than the notice period above can offer.
  • Then it is deleted, not left running unattended. An abandoned database holding wallet journals and asset lists is a breach waiting for somebody to find the server, so the live database goes when the thirty days above run out. There are no backups today, so the live database is the only copy and deleting it is the whole of it. If backups are ever installed, the outer bound becomes their rotation rather than these thirty days, and this paragraph has to say so on the same day.
  • One step does not depend on us at all. Revoking EVE Forge at CCP's authorised applications page cuts the tokens from CCP's side whether or not anybody here is still answering. If the project ever goes quiet without an announcement, do that first and ask questions afterwards.

If CCP withdraws ESI access. This is the ending EVE Forge cannot prevent, argue with or plan around, so here is exactly what it does:

  • Syncing stops in the same minute. One client talks to ESI and there is no second route to your game data; a refused token is the end of it. Nothing is deleted by that and nothing is corrupted — the records simply stop gaining newer rows.
  • What is already stored stays readable. The app renders from its own database rather than calling CCP on page load, so your history, your reports and the export still work with the tokens dead. What visibly breaks is anything that reads CCP live: market prices freeze at their last refresh, and the public market preview stops answering.
  • A cutoff that turns out to be permanent is a shutdown. A tool that can no longer read EVE is finished, whatever the intention was, and the notice, export and deletion terms above then apply in full.

What that costs you in ISK. A paid tier is a thirty-day period charged against an ISK balance held on your account. Two things about it are properties of the code rather than promises: automatic rebilling is off unless you switch it on, and switching it off on your account page stops every future charge at once, because the renewal pass only ever looks at subscriptions that have it enabled. So a cutoff cannot quietly keep billing you.

A period that is cut short is not refunded, and that is said here rather than discovered later. A refund could only ever be a manual in-game transfer, for the reason set out below, and a manual promise is one that depends on somebody being available and willing. Rather than make one, this page says no.

What makes that a small answer rather than a bad one is the bound around it, and the bound is a property of the code rather than a promise: automatic rebilling is off unless you switch it on. So the most a cutoff can cost you is the remainder of one thirty-day period you chose to buy. If that is a risk you would rather not take, the free tier takes none of it, and that is a better reason to stay on it than any sentence here.

Why that is a property rather than a policy: no route in EVE Forge sends ISK out of it and no route removes balance from the ledger. The balance is an append-only list of credits and debits, credited only by a real ISK transfer arriving in the receiving wallet. So there is no refund button to switch on, and the answer above is not a policy choice dressed up as a limitation — the limitation is real and the choice was whether to promise around it by hand.

An unplanned stop, by definition, announces nothing. That is why the dated changelog carries the commitment that something new appears there every month: a gap in those dates is the earliest honest signal you will get, and it is a signal you can check for yourself without asking anyone.

Rights

Your rights

  • Access — a copy of everything. There is no download button.A self-service export existed and was removed in August 2026; the tooling that produces the file still exists on the operator's side, so a copy can be made, but this page is not going to describe a process nobody has committed to running.
  • Rectification — correcting something wrong. Almost everything here is a copy of what CCP served, so a wrong number is usually wrong at the source and a corrected value would be overwritten by the next sync within fifteen minutes. What you entered yourself — fee settings, cost overrides, structures, appraisals, claims — you can change in the app. That part is unaffected by anything else on this page: it is your own input, in your own account, editable where you entered it.
  • Erasure — deleting it. There is no delete button either, and the same is true of it: the code that erases an account is still here, and no route reaches it. Set out in full below, including what revoking at CCP does and does not achieve.
  • Withdrawing consent. Revoke EVE Forge at CCP. Every future sync stops immediately, because a refused token is the only key we have.

None of the four is on a clock. There is no committed turnaround for a message and this page does not invent one — but the twelve-month rule above is a date rather than a promise, and it is the one route by which records go away without anybody having to act on a request at all.

Erasure

What you can and cannot have removed

There is no delete button, and this page is not going to pretend there is one. EVE Forge has no route that erases an account and no route that unlinks a character. Both existed for two weeks in August 2026 and were removed. Saying otherwise would be the easiest sentence on this page to write and the only one a reader could catch us on.

What you can do, entirely without us:

  1. 1 · Revoke EVE Forge at CCP's authorised applications page. This works immediately and does not depend on us at all: the refused token is the only key we have, so every future sync stops.
  2. 2 · Be clear about what that does not do. Revoking stops new data arriving. It does not remove what is already stored, and nothing on this page promises that it will. Those two are different things and the difference is the whole point of this section.

You can ask, at the address above. What this page will not do is put a deadline on the answer or describe a procedure, because neither exists — and a policy that invents one is worth less than a policy that admits it has none.

One thing that follows from all of it, and is worth reading before you decide: the only reliable way to keep records out of EVE Forge is not to grant the scopes. A scope you withhold is skipped entirely rather than half-filled, so you can grant the minimum and add more later — and the minimum is the one decision on this page that is fully yours and fully reversible.