Discussion External API Requirements Thread

Thread Closed: Not open for further replies.
Dear Devs, my initial wishlist for an API was fairly basic in that I just wanted commodity price data. But in thinking about the potential for an API I think there would be great value in being able to interact with ED with tools - particularly interfacing devices such as tablets, lights, knobs, switches etc - to create virtual cockpits.

EG: say I want to be able to have a tablet that essentially replaces the NAV panel - a fully functional real nav panel. It could have customisable themes. Different ways to display and interact with the Nav/targeting/mission data. The tablet app would need to access the data it needed to display from ED and then also post commands back to lock targets/destinations.

So, my API feature wishlist is basically twofold:
1. any information available to cmdrs is available via the API and
2. any input from cmdrs can be input via the API

Some specific examples of this would be:

Information to CMDRs:
* Station Services data including:
* What services are available at this station
* News feed - items
* Munitions - modules, ammo levels, costs
* Repairs - modules, health, costs
* Bulletin Board - missions, details
* Outfitting - modules available, details/costs
* Ships - ships available, costs/details, ships parked
* Market - prices/supply/demand, average
* Cartographics - data to be sold
* Nav Panel Data
* location/distance for all nav panel items
* current location
* current destination
* Transactions list and details
* Contacts list and details
* subtarget list and details
* Cargo scanner results
* Sys Panel Data
* Status/Modules/Firegroups/Cargo/Functions - the whole bit
* refinery status
* includes module damage
* Ship status Data
* Hull level, shield status, Power distribution status, mass locked status, landing gear status, cargo scoop status, landing light status
* Alarms
* Ammo levels, fuel level, temperature level
* Sun(star) colour, direction (for virtual cockpit mood lighting)
* clanking sound

Input from CMDRs:
* Station Services transactions
probably don't need any API control here
* Nav panel inputs
* lock target
* lock/unlock destination
* request docking
* cancel docking
* select subtarget
* Sys panel inputs
* module toggle on/off
* functions controls
* refinery controls
* Ship control inputs
* scoop/gear/lights
* deploy chaff/ECM/heatsinks/shieldcell
* probably stick inputs is going too far

So apart from captains log type tools or trading tools to help advise cmdrs on where to go and what to do, we could also have different interfaces to our ships and use the ones we like or are themed to suit our type of ship.

I imagine a virtual cockpit with a Nav panel tablet, a Sys panel tablet (or possibly several for the various tabs in each). A heater in the seat to simulate critical temperatures, various alarm lights/sirens for different alarms, mood lighting depending on the system's star(s) . And a rusty old fan that can be turned on whenever a clanking sound is needed.
Sorry, jumping in at the final hour, but I think the API should basically give as much as possible that a player could record ingame. Important things are:

Player data:
1. Credits
2. Current ship, its outfitting and cargo in hold.

Galaxy/system data:
Anything on the galaxy/system map. Two calls:
1. All systems in the "inhabited zone" (including uninhabited systems within say 50LY of inhabited systems) OR
2. All systems within X light years of a point on the galaxy map.

Shall include: All data on the system maps of such systems, including
a. Any bodies and whether they have been scanned, also mining type/quality
b. Imports/exports, for each station.

Player history
History of player docking, each docking including prices and quantity of commodities on the market.


Obviously there's more ingame data than this, but I suspect the above (along with the jump fuel usage formula) will be enough for most people now.

I'd really like this, because I don't want to record a whole lot of information on paper, but on the other hand I don't want to cheat by getting information online I shouldn't have. The above info based on what I've found myself would be appropriate I think.

I don't think "live in-flight data" should be provided. Also, to keep it simple, there's no need to provide API's for "fastest route". App developers can do this themselves as long as you provide them the data.

Getting the data available should be the focus, leave the creativity of what to do with it to the app developers.
Last edited:
Ok, I'm a bit late to this discussion and there are 30+ pages of backlog, so I haven't read existing suggestions.

One major use case for me is creating something to play with the X52 Pro's MFD. There's lots of data that would be great to have on the MFD, including:

* Information about the current *navigation* target, regardless of what the current ship target is (so players can cycle through possible Interdiction threats while flying to a station, for instance)
* Comms information, *especially* the ability to select a CMDR and initiate voice or text comms. In fact, extend this to general targeting as well... being able to scroll through a list of targets to find potential bounties would be nice.
* Useful tactical information about allies (once Wings is out), particularly shield and hull health, and distance to ally.
* Number of jumps left and number of light years remaining in currently plotted route! Hell, having this on the HUD would be nice, too.
* Subsystem/power control, cargo management, etc. Basically anything that requires a round-trip to the UI panel could be offloaded to either the MFD or an external app. This would make my second monitor pretty useful.

YES! To this please!
> Player Data
-Owned ships + their location
-Credit Balance
-Ship Loadouts
-Ship information (such as weight, speed, power etc)

>Galaxy Map
- Would be awesome to have a full galaxy map to check out all the systems, and plot routes on

>Market Information
-For the traders, market information for stations that your ship is currently stored in
love to see a way of find out whom has discovered some thing and getting in touch with them, eg: some sort of in email faster than light email system
Having already done some work with the discovery data kindly provided a while back which I transformed into the very popular http://dump.bass-speaker.com/discovery.php site(speed to market was MySQL on this one having written a VBscript exporter from the XLSXM file... not ideal but did the job - and is still getting 300-400 hits a day!!), it’s given me some food for thought about what I would like to see available from the API, and what I also feel would be realistic to be available from the API (data size constraints etc.).

It would be nice if a query that allowed you specify CMDR name and it returned their list of discovered items, however I do feel that this would be unrealistic, since for example, OnePercent had 96831 objects in 8342 systems (and of course this will only have increased I’m sure), even trimming the data response by returning systems list and then object list with FK to system list, it does make it rather a heavy weight query.

Realistically, I do believe a system name query would be okay, as I believe the highest number of objects I saw was 124 (although I’d bet there are systems with more!)

A CMDR stats query (count(stellarobjects), count(systems) etc.) would be nice as well.

And a top 10/100 (or arbitrary number in-between) of CMDR’s would be helpful as well.

Now this may be controversial, but perhaps there could be some "Premium API", given to either trusted/approved/signed NDA or Disclaimer type developers that have an authenticated API that is above and beyond normal user level auth, that perhaps provides more detailed data that can be manipulated (as above for example) , but the query time is restricted/reduced so it's say once a day at 4am or similar when servers are under less load - or even to a dedicated server.
Last edited:

With many great things already suggested, may i propose, that we could have some a bit more active data from the client. I'm talking about in-flight (or in-fight) data:

- current target
- attacker
- ship status
  • modules - online/offline/damaged/cooldown
  • shields/hull status
  • is it being scanned, etc.
- enemy ship status
- ally status
- damage given/recieved, type of damage

Basically something like constant combat log. What i have in mind that let's say there could be an application that would give a player ability to set some additional visual and/or sound cues. A good example of that would be putting that data into a custom text synthesizer which would even further enhance player immersion:

"Alert! Commander Voyak, we're under attack by an Elite Viper. Recieving heavy plasma damage, shields are currently at 21 percent. Shall I deploy hardpoints?"
"Good work commander! You've destroyed him in 1m 32 seconds, that's 17 seconds better than the last fight. You've used two Shield Cell Banks and fired 474 shots from multicannons. Your aiming has improved by 2.5 percent."



Tutorial & Guide Writer
I know it has been said before but I wanted to emphasize the what I feel is very important. I'm hoping that FD is going to implement OAuth, OAuth2, OpenId or some other authentication/authorization method - could be the hashkeys methode used by EVE online. Effectively FD becomes an authorization server. There currently are quite a few systems which allow uploading of data, coordinates, prices, station info etc. Those systems are vulnerable for "poisoning the well" - commanders uploading bogus/false information. Commanders could implement authentication to combat that but every tool author has to reinvent the wheel again. If FD would become an authorization servers things would become much easier for projects like EDDN, EDDB, EDSC etc etc.

Scalability - for coordinates. There are around 19K systems with an economy. Route planners (standalone or part of tools like trading tools) need the coordinates systems in the neighborhood to calculate efficient routes. When the FD api provides coordinates for systems they can be stored and shared in a database. I guess for efficient routes for the 19K systems we perhaps need 150K system coordinates. Totally doable. BUT what if commanders fly into the unknown. Its impossible to store the coordinates of 400 Billion stars. I'm hoping that the FD api gives us the possibility to dump the coordinates of systems in a radius of perhaps 100 LY from where you currently are - locally stored and not being uploaded to a database. The can be processed by route planners to calculate routes.

Scalability - for system info. The info for systems is quite a lot of info. To much to store in a database - for a very large numbers of systems. It would be nice if there would be a fd_systems_id which can be stored in a database. A tool retrieves that info, feeds that to ED and receives the PG info back. Ideally there would be an separate offline GM which gives you info about a system (not wasting at the FD servers). If that could be run on the windows server on a hosting service it would allow tool authors to give info about all systems - it would costs them bandwidth ofc.

For me the most important feature is an FD authorization server.

Edit: I'm really hoping that the FD api at least provide all the information which is currently shown in the misc screens, market, GM, systems map etc. If NOT the OCR-ing (and its problems with it) will continue. Not to mention that their is the risk that authors will restart scraping data from the game - when the FD api is out and its nerfed to much to be really usefull. So far most (if not all commanders have played ball).....

Edit 2. In the above examples/suggestion I'm taken the assumption that FD doesn't want to spill BW and that most data will be provided locally - as retrieved from Ed rather then from the servers. The P2P was done to preserve BW so I can imagine they don't want to spill BW for the FD-api either.
Last edited:
I'd like to do an x52 MFD app, to display some read-only data

1. Basic ship status (for both player ship & current target): Current shield %, current hull %, module health
2. Session status:
a) Session playtime
b) Liquid credits at start of session
c) Credits earned / spent since session begin, broken down:
-> Profit from missions (and # of successful / failed missions)
-> Profit from combat bonds / bounty (and # of each)
-> Profit or loss from trading / smuggling (and # of sales)
-> Loss from insurance (and # of deaths)
-> Money spent/gained by ship or module purchases/sales
3) Basic combat stats for the session (and for the player's entire career if you will share it): wanted targets killed, warzone targets killed, clean targets killed, deaths
4) Net reputation gain/loss for the current system's factions this session
Last edited:
When is this going to start being implemented? Can us beta testers get access to a beta version of the API for testing?

well its been awhile since my last post, but I wanted to post my thoughts. I been trying a trade-helper, which currently relies on manual submission at the moment (single or CSV). What id like to do is to query the server about a location, say;


This would then return a file (either JSON or XML), the contents of a system with information on each station such as ware-prices.

<system id='sol' name='Sol' x='0.0' y='0.0' z='0.0'>
  <object type='planet' name='Earth' x='' y='' z=''/>
  <object type='station' name='Abraham Lincoln' x='' y='' z=''>
        <offer id='1' ware_id='hydrogen-fuel' demand_price='0' supply_price='113' demand_level='0' supply_level='2'>
        <offer id='1' eq_id='burst-laser' price='4400' class='1' rating='f' type='fixed'>
        <offer id='1' ship_id='cobra-mk3' price='379718' allegiance='none' allegiance_rank='0'>

After-which I could process the file into my own database, so it can be used to compare prices, find ships for sale, equipment etc.If a whole system is too much, what about querying just single station for stock and prices.

Over the past week or so had a lot of problems with performance, but finally got it sorted now. The API however would make the whole process much quicker and easier. If there is any testing, id be willing to help.

Id also like a way to query the server for a certain commander, so maybe a leader-board? or offer suggestions etc. not sure, but I could think of things.
Last edited:

Michael Brookes

Game Director
Thanks to everyone for their input on this topic. I was supposed to close this thread on Monday, but as I was out of the office that has been delayed. I shall close the thread tomorrow and begin the process of putting it together for internal review.


Thanks to everyone for their input on this topic. I was supposed to close this thread on Monday, but as I was out of the office that has been delayed. I shall close the thread tomorrow and begin the process of putting it together for internal review.



Shiny! And thanks to you for patiently listening :D

Michael Brookes

Game Director
Thread closed so I can begin the internal process reviewing the input on this thread. Thanks to everyone who has participated. We obviously have a lot of work going on so I anticipate it being a few weeks before the next update on this. I'll post when we have something.


Thread Closed: Not open for further replies.
Top Bottom