Please let us read the database you already have

Pre-script: This article turned out way longer than I was initially intending. For those of you with limited patience with verbose and marginally humorous word vomit, I encourage you to go to the tl;dr, which I'm hoping is a reasonable summary. It might not be. Or maybe it is. You'll only know if you read the whole thing.

There is a moment familiar to anyone who has played Star Citizen for longer than a week, in which you are sitting inside a ship after refining a quantity of quantanium, and you do not know what that quantity is. Or the quality.

You did know. You knew about ninety seconds ago, when the number was on a screen in front of your face at the refinery. Then you closed the screen, because someone in your org needed help with a Cutlass that had become wedged into a landing pad at an unsatisfying angle, and the number now lives exclusively in the part of your brain that handles phone numbers and the names of people you have met four times.

The game, meanwhile, knows. The game knows to several decimal places. At this exact moment there is a server in a rack in a datacenter somewhere holding that number with perfect fidelity, humming to itself, entirely uninterested in sharing. Ok, let's be honest, maybe it's imperfect fidelity, given what we've come to expect from persistence between patches.

So you alt-tab. You open a spreadsheet, or a Discord message to yourself, or a phone. And you type the number in. By hand. A number that a computer already has, into a computer, using your fingers, in the year 2026. Or in my org, we open Hangarworks. Yep, that's a plug.

I want to be precise about what I am asking for here, because "the game developer should build a thing that I want" is the least useful sentence in online writing and I have no interest in adding to the pile. I am not asking for a feature. I am not asking for UI. I am not asking anyone to design anything. I am asking for a doorknob on a room that already exists.

The thing about doorknobs

An API, for anyone who has wisely avoided finding out, is a way for one program to ask another program a question and get a boring, machine-readable answer back. Not a web page. Not a screenshot. A little parcel of structured facts: this player has 42 SCU of Titanium, at quality 0.31, in the player's storage at Everus Harbor.

That is it. That is the whole technology. It has existed since roughly the invention of the second computer.

The reason this matters is that the data is not the hard part. CIG has already done the hard part. They have modelled crafting, mining yields, resource quality, cargo, hangars, org membership, and a market, and all of that lives in a database because there is nowhere else for it to live. Every fact I want is a fact the game already tracks in order to function. Nobody has to invent it, balance it, or art-pass it. It just needs a way out.

And here is the part that should be persuasive rather than merely correct: the community will build the tools. For free. Enthusiastically. At a pace CIG could not match if it hired a hundred people, because there are more than a hundred of us and we are not on the roadmap.

We know this will happen, because it has already happened four times, in four games, and it went well every time.

Exhibit A: Destiny 2, and the app Bungie did not have to write

Bungie ships a public API for Destiny 2 that exposes essentially everything about a player's account: their characters, their gear, their stats, their vault, and the exact contents of every inventory slot. Crucially, it also allows writes. An authorised third-party application can move an item from a character to the vault, or from the vault to another character, on the player's behalf.

What the community did with this was build Destiny Item Manager, which is universally known as DIM and which is, by a distance, the best inventory interface Destiny has ever had. It is a browser tab. You drag things around in it. It has search syntax that lets you type things like "show me every hand cannon I own that I have never used and could safely delete", and it answers instantly, and then it deletes them.

The important detail is not that DIM is good. The important detail is who did not build it. Bungie's in-game vault management was, for years, a system in which you walked to a physical vault, opened a grid, and moved items one at a time while a loading spinner considered its options. Improving that would have meant a UI team, a design pass, a QA cycle, and console certification, all competing against actual content for the same finite pool of developer months.

Instead Bungie exposed the data, and some volunteers built a better vault than the vault, and Bungie got to keep shipping raids. The API turned a UI problem into somebody else's hobby. That is not a compromise. That is an outrageously good trade.

Exhibit B: Guild Wars 2, and the answer to "but security"

Guild Wars 2 has what is probably the most quietly admired API in the genre. It exposes account progression, unlocks, wallet balances (all of them, in all of the game's approximately nine hundred currencies), trading post listings and prices, character equipment, map and node data, and a great deal more. GW2Efficiency is built on it, and does the sort of accounting that would otherwise require a second monitor and a mild personality disorder.

But the part of GW2's API worth lifting outright is not the data. It is the permissions model.

A player logs into the official account page and mints an API key. While minting it, they tick boxes: this key can see my inventory, but not my wallet. This key can see my characters, but not my trading post history. They paste the key into whatever tool they fancy. If they stop trusting the tool, or get bored of it, or read something unflattering about its author, they revoke the key, and the tool instantly becomes an inert rectangle.

This is the answer to the objection that always arrives within nine seconds of anyone proposing an API, which is "what about security". The player grants specific access, to a specific tool, and can withdraw it at any time without changing their password or contacting support. It is not a novel or risky idea. It is the same OAuth flow you use to let a calendar app see your calendar. Guild Wars 2 has run it for over a decade without the sky falling.

Exhibit C: World of Warcraft, and the argument from scale

Blizzard's Battle.net API serves character profiles, achievements, item data, mounts, professions, and, most consequentially, auction house data across every realm.

This produced Wowhead and it produced the Undermine Exchange, and it produced the entirely expected situation in which a meaningful fraction of the game's economic activity is planned on websites rather than in the game. Someone deciding what to craft this week is looking at price history graphs, on a phone, on a train. They are engaged with World of Warcraft while nowhere near World of Warcraft.

The lesson here is about scale and time. WoW is a twenty-year-old game with an enormous item database and an economy nobody could hold in their head, and Blizzard's answer was not to build the definitive auction house analysis tool. It was to publish the data and let a thousand people build a thousand tools, of which about six became load-bearing.

Star Citizen currently has 1,607 crafting blueprints. I know this because I count them every patch, in a way I will describe shortly and which will not reflect well on anybody. That number is going up. The complexity curve CIG is climbing is the same curve Blizzard climbed, and it is worth noticing that Blizzard did not climb it alone.

Exhibit D: EVE Online, which is the actual comparison

If Star Citizen has a spiritual predecessor in this specific argument, it is EVE, and the EVE Swagger Interface is the most sophisticated player-facing API in gaming.

ESI is described by an OpenAPI schema, which means tooling can generate a working client automatically rather than a human reading documentation and typing it out badly. It uses OAuth2 with granular scopes. It exposes character skills and skill queues, corporation structures and their fuel levels, industry jobs and their completion times, market orders and full price history, asset locations, contracts, and fleet composition.

And the EVE tool ecosystem that grew out of this is not a nice-to-have. It is infrastructure. Industrial planning, market arbitrage analysis, fleet doctrine management, corporate logistics: all of it happens in third-party applications, because a spaceship cockpit is a spectacularly bad place to do accounting for four hundred people.

The reason this is the relevant comparison is that CCP arrived at a conclusion Star Citizen is currently sprinting towards without seeming to notice: once your game contains a real economy, a significant amount of engagement with it will happen outside the game, and your only choice is whether that engagement is well-supported or miserable. EVE players plan manufacturing runs at work. That is not a failure of the client. That is thousands of people thinking about your game during hours they are not paying you for, and every one of those hours makes them more likely to log in that evening.

Star Citizen wants to be that game. Star Citizen is building crafting, refining, cargo, salvage, org logistics and player-driven markets, which is to say: Star Citizen is building homework. Homework needs somewhere to be done.

The objections, briefly, because they are all answerable

"People will cheat with it." Read-only endpoints do not let you do anything you could not do by looking at your own screen, only faster and without transcription errors. Ironically, the current situation is worse: because there is no sanctioned way to get data out, the enterprising have already resorted to reading game files and memory, which is precisely the category of thing you would rather people did not get comfortable with. An API is not a new attack surface. It is a sanctioned alternative to an existing one.

"It's an alpha, everything changes." Yes, and versioned endpoints are how every one of the four games above handles exactly that. Also, and I say this gently: the community is already tracking every schema change you make, patch by patch, without being told, using tools built by people who do not work for you. We noticed. We always notice. Letting us notice in a supported way costs you less than the current arrangement, which involves us reverse-engineering your data model and occasionally getting it wrong in public.

"We're busy." This is not a counterargument. This is the argument. You are busy, which is exactly why you should not be the ones building the inventory manager, the mining route planner, the org logistics dashboard, or the crafting cost calculator. We will build those. We are, in fact, already building those, badly, out of scraped files and hand-typed numbers, which brings me to the confession portion of this post.

Where Hangarworks actually gets its data

Hangarworks is a crafting and org logistics tool. It tracks who in your org knows which blueprints, what raw materials everyone is holding, what finished components are in the org's stock pool, who has reserved what, and what you would need to mine to build a given list of things.

Here is where every single one of those facts comes from.

The blueprint catalogue comes from scmdb.net, a community site that extracts crafting data from the game files. It is excellent work and I am grateful for it daily. It is also load-bearing in a way that makes me slightly ill, because scmdb serves only current builds. When a build goes away, its catalogue goes away with it. Hangarworks therefore snapshots every catalogue it fetches into a folder in the repository, roughly 700 KB per build, permanently committed, because that snapshot is the only remaining evidence that a version of the game ever contained a particular recipe. Skip a patch and that comparison point is gone forever. I have written a script whose entire job is this. Getting data from scmdb was shorthand, and if we don't end up with some kind of API, I'll probably end up unpacking the game files too, because it gives me the ick to do this. But I'm just one guy with a 80% completed CSCI degree from 1998. We were programming in Pascal and COBOL back then. I left because my university thought all of us should be preparing to find jobs in the lucrative industry of "fix Y2K bugs in permanent crunch at Microsoft and Boeing for the next 2 years". That seemed soul crushing. Fast forward and I ended up working in the games industry for 24 years, which was also soul crushing. Just a slightly different kind.

That catalogue also includes a field in our data model called cigDataError, which is a boolean flagging blueprints where the extracted data is internally contradictory. We have a schema field for the game being wrong about itself, because there is no authoritative source to check against.

Which blueprints a player has learned arrives by the player going to a third-party website, exporting a JSON file of their profile, and importing that file into Hangarworks, at which point we filter to the entries marked completed. This works. It is also, if you say it out loud slowly, an absolutely deranged way to find out what recipes a player has unlocked.

Where a resource can be mined is a hand-curated JSON file. A player like me wrote down which moons and belts and points of interest yield which materials, across Stanton, Pyro and Nyx, and maintains it by hand as the game changes.

Where blueprints come from is also hand-curated: mission reward, reputation reward, boss drop, vendor, event. Typed in from player reports.

Everything about what you personally own is typed in by you. All of it. Every gram.

What one read-only endpoint would change, per feature

This is the part where I stop complaining and get specific, because "give us an API" is only slightly more useful than "build a thing" unless I explain why.

Exact blueprint data

We would stop diffing scrapes. Right now, working out what changed for crafting in a patch means fetching two extracted catalogues and comparing 1,607 entries mechanically, which I do, and which produces good results, and which is still fundamentally archaeology. A /crafting/blueprints endpoint with a version parameter would turn a fragile pipeline into a fetch, and it would end the class of bug where the community's understanding of a recipe is wrong for a fortnight because an extraction missed a field.

It would also let us tell you something we currently cannot: whether the recipe changed since you last looked at it. Blueprints have ingredient slots, each with a minimum quality and a set of modifiers that scale a component's final stats from a start quality to an end quality. Those numbers move between patches. At present, a crafter's mental model of a recipe silently goes stale and nothing anywhere tells them.

Inventory location

The single most valuable endpoint, and it is not close.

Hangarworks currently has a field on each of your resource holdings called a location note. It is free text. It is capped at 120 characters, a limit I chose because it is long enough for "CRU-L1" and short enough that nobody can use a roster row as a billboard. A human types it. A human keeps it up to date, which is to say a human does not, because nobody in the history of software has ever kept a free-text location field up to date.

An endpoint returning where a player's cargo actually is would replace the entire feature with something true. "You are holding 42 SCU of Titanium and it is in storage at Port Tressler" is a fact the game possesses and I am asking it to say out loud.

The org-scale version is better still. Our stock pool lets members list finished components for others to claim, each with a location for pickup, and the honest description of that system is that it runs on trust and good intentions. Real location data turns an org's shared inventory from a shared belief into a shared fact, which is the difference between a logistics tool and a group chat with a database attached.

Resource quality and quantity

This is the example I keep coming back to, because it is where the current arrangement is not just inconvenient but actively lossy.

Hangarworks stores your holdings as a resource name, then a quality value, then an amount in SCU. Quality is not decoration. Blueprint ingredient slots carry a minimum quality, so material below the threshold is not merely worse, it is ineligible. And the modifiers on a slot scale a crafted component's final stats between a start quality and an end quality, which means the difference between quality 0.31 and quality 0.48 Titanium is the difference between two different components at the end of the process.

So: the game computes a precise quality figure. The crafting system gates on that figure and interpolates from it. And the way a player currently gets it into a planning tool is by reading it off a screen and retyping it into a phone, with all the fidelity you would expect from a person doing arithmetic in a spaceship.

Every planning feature we have is downstream of numbers a human transcribed. That is the cost, and it is not the typing. It is that nobody trusts the totals, so nobody plans against them, so a tool that could tell an org exactly what it can build today instead tells it what it could build if everyone's data entry were current, which it never is.

The mining planner, which deserves better inputs

Give a plan to Hangarworks and it works out the fewest mining stops that cover every resource you need. Not approximately: it prunes dominated locations, takes a greedy solution as a bound, then branch-and-bounds to an exact minimum, verified against brute force on 600 generated cases. I did this properly because greedy was about 16% worse and would routinely send you to three locations when two would do, and a tool that wastes an hour of someone's evening is not a tool.

It is a good algorithm sitting on top of a hand-maintained list of which rocks contain what, subtracting inventory numbers that were typed in by hand. The algorithm is the easy part. It always is.

Craft timers, which are free retention

Blueprints carry a craft time in seconds. We know how long a thing takes. What we cannot know is whether your crafting job is done, because that is a fact about your session, not about the catalogue.

A read-only endpoint listing a player's in-progress crafting jobs and their completion times would let Hangarworks send a push notification when the bench finishes. I want to be clear about who benefits from that, because it is not primarily me: a notification that says "your component is ready" is a notification that puts someone back in the game. EVE has run on exactly this loop for twenty years. Skill queue finishes, mail arrives, player logs in. It is the cheapest engagement mechanic in the genre and it is currently sitting unused because the data cannot leave the building.

Market prices

Our points economy values everything by stamping an aUEC figure on the inputs at the moment a request is created, using a valuation module that is, in the end, an educated guess with good manners. Real market data would make an org's internal economy reflect the actual one, and would let every org running a contribution system stop arguing about whether a run of Quantanium was worth what someone said it was worth.

What I am actually asking for

Not write access. Not day one, and honestly not ever, as far as Hangarworks is concerned. I do not want to move your cargo. I want to know about your cargo, with your permission, which you can withdraw.

A first version that would change the entire community tooling landscape is roughly five read-only endpoints behind an OAuth flow with scoped tokens, in the Guild Wars 2 style:

1. Character and account basics. Handle, org membership, that sort of thing.
2. Inventory. What you are holding, how much, what quality, and where it physically is.
3. Crafting. The blueprint catalogue for a given build, and which recipes this player knows.
4. Jobs. In-progress crafting and refining, with completion times.
5. Market. Listings and price history, at whatever granularity is comfortable.

Rate limited. Versioned. Documented with an OpenAPI schema so clients generate themselves. Scoped so a player can hand a tool their inventory without handing it their org.

That is not a moonshot. That is a few weeks of work for a small team who already know where the data lives, and it would be repaid immediately by an ecosystem of tools that CIG does not have to design, build, support, localize, or put on a roadmap.

We are going to build these tools anyway. We are building them right now, out of extracted game files, hand-curated JSON, third-party exports, and an enormous amount of human typing. The only question on the table is whether the inputs are any good.

You can even call it StarAPItecht. We already know that's the kind of wordplay we'd be signed up for. I'd promise not to even groan. Pinkie promise.

---

TL;DR

• The data already exists. Every fact a crafting or logistics tool wants is a fact the game must already track to function. This is a request for access, not for a feature.
• Four games have already run this experiment. Destiny 2 (Bungie API, which produced DIM, a better vault than the vault), Guild Wars 2 (a superb REST API with scoped, revocable player-minted keys), World of Warcraft (Battle.net data behind Wowhead and the Undermine Exchange), and EVE Online (ESI, an OpenAPI-described, OAuth2-scoped monster that runs an entire industrial economy out of game).
• Guild Wars 2 already solved the security objection. Player mints a key, ticks exactly which scopes it gets, revokes it whenever. It is the calendar-app permission flow, and it has worked for over a decade.
• EVE is the big comparison. Once a game contains a genuine economy, a lot of engagement moves outside the client whether you support it or not. Star Citizen is building crafting, salvage, cargo, org logistics and markets, which is to say it is building homework, and homework needs somewhere to be done.
• Hangarworks currently runs on: a community site that extracts data from game files and only serves current builds (so we permanently snapshot every catalogue or lose it forever), a schema field for when the game's own data contradicts itself, blueprint knowledge imported via a third-party JSON export, hand-curated files for where materials are mined and where recipes drop, and hand-typed numbers for absolutely everything a player owns.
• The biggest single win is inventory location. We have a 120-character free-text field where a human types "Mole, Daymar OM-3, orange container", and no human has ever kept such a field current.
• The most lossy is quality. Recipes gate on a minimum quality and interpolate component stats between a start and end quality, so quality is not flavour, it is eligibility and outcome. It currently reaches planning tools by being read off a screen and retyped.
• Craft timers are free retention. A push notification saying "your component is ready" puts a player back in the game. EVE has run on that loop for twenty years. The data is right there.
• The ask is five read-only endpoints, OAuth-scoped, rate limited, versioned, OpenAPI documented. No write access required.
• The tools get built either way. The only decision is whether they are built on good data or on archaeology.