Discussion External API Requirements Thread

Thread Closed: Not open for further replies.
With the requested Api and the ideas I have read through, I guess I will see add on that should have been there as automations in the game in the first place. The Docking Computer was the best thing of Elite(1984). Think about it. I see game mechanics that are not needed even for game play considering the level of the technology and robotics of the Real world. Training videos when the game should have been intuitive to some extent like the original Elite was. Considering i bought the original game on a whim because the graphics looked cool and got through the painful docking to the docking computer. The game became a repetitive as hell after that with the equipment becoming maxed out and the ability to take out Anacondas and Fer-da-lances at will with the cobra Mk III. Joysticks were a lot simpler too with a analog stick and two buttons.

Before thinking of an Api, Your development team should focus on getting the memory leaks under control. There is a pretty big one on the Loader program and I have not been able to track it down completely. The one on Chrome seems to be found and fixed now. I have a 16gb box and nothing goes to the swap file until I start that loader of Elite. I did not think it was that complex of a program. The guild wars 2 loader does not do that.

Just my two bits again.
Quick list-

- Access to the games chat system... assuming it starts working soon.

Would require being able to log in, see which friends are online, and send and receive messages.

- Access to the galaxy map and system maps as it is in game.

I don't want access to all the price data, that has been hidden for a reason. What I would love to do is be able to do is browse a web version of the map away from the game. While we're at it, can we get info for systems we've visited saved locally: Blackmarkets, import, export, banned, system explored with adv scanner, etc.
Would require star names and locations, and all the info from the system view.

- Ability to play with livery options offline.

Once there are more options available, it would be great have a model and texture viewer to experiment with livery options, both for the ships you have and the ships you want.
Would require ship model and texture data.
Game State

I was planning to make a App that would show the various toggles and states of the ship on tablet and or logitech keyboards.

That would require access to in game data like shields, hull integrity, silent running on/off, landing gear on/off.
Total Cargo space / free cargo space. lights current contacts, ect

And a question for the dev team: would Frontier consider making an app that could funtion as the pilot side screens ? I would love to use my tablet to select destinations, check contacts ect ...
I would like to see an actual Universal Cartographics app for tablet/iPad.

This way, I can more conveniently examine the systems and galaxy outside of time on my PC. I would like to read about various systems while I'm commuting (in the real world). I would like to use the app to hunt for trade routes, or look for areas to explore, or plot travel routes. Of course, if such an app could be tied directly to my account, even better.

I imagine, for example, plotting a route on my iPad while on my way home from (real) work, saving it, and then retrieving the route when I log on into the game at night.


Tutorial & Guide Writer
For starters, I'm very happy that the (web)API is being worked on and we can express our thoughts and give input. That said when I look at the timeline of the whole procedure. Thread closing 16ht of February, private working group, testing API it looks to me we won't see a (web)-API before end Q1, beginning of Q2. Still a few months in the future. In the mean while a LOT of effort is going into getting data out of the game in a legal way and make it usable for the current tools. Stuff like OCR-ing, crowd sourcing the get coordinates of systems.A LOT of effort which could be put to better use to create end user tools.

In the end data has to be distributed to tools which collect info and make it available to others. Distributing info: EDDN to distribute dynamic info. TGC (The great collector) aka edsc API, the upcoming eddb (Elite data database) for static data (like coordinates systems).

It has been said before by others. It would be great that while the web(API) is being worked upon that same basic information is stored (locally) on the ED computer. Things which are needed most badly are.
1) JSON/XMP dump of prices when opening the commodities market.
2) JSON /XML dump of 3D coordinates of a star system.
3) JSON/XML dump of current situation (freespace, docked etc) with coordinates. Location is now read from the netlogs but there are no coordinates.

1) is for trading tools.
2) Is for routeplanners (often built into trading tools)
3) Is captains log applications.

As a lot of the needed data is either send to the client or procedurally generated inside the ED client it could be very easily dumped into a JSON/XML file. It would enable the current existing tools to mature and flourish. It also means that OCR-ing for priced data would not be longer needed and that the crowd sourcing effort for getting coordinates would have much much easier task. It would mean that things like EDDN, TGC and eddb could REALLY start to take off. Collecting data which can then be used by end user tools. When the (web)API is ready that data would be send to EDDN/TGC/EDDB also.

Note: Of course, every single piece of extra info like things bought/sold with their profit/loss, I kill someone or get killed could be put to good use in the existing tools.

I really think dumping that info is pretty straight forward and relative easy to implement. It would be great if that bit of work could be done in parallel to working on a full fledged (web)api. Just my 2 eurocent.
Last edited:
I agree with Wolverine. The web API will be very nice to have. But i would be very glad to have some improved logging in the meantime.

Elite now stores systemname in netlog if verbose logging is on.
It would help my captains log collection and other if it was always on or logged to another file.

I would also appreciate if Elite stores information about docking into a station in the logfile too.

I dont realy care in which way tou stire information. I can always adapt my program.

Dumping that info in a logfile would be easy to implemnt and like wolverine says be done in parallel with a more complete API in the future.

Looking forward to get more information via an api but in the meantime i am very happy about the limited information i can get from the netlog file.
For a start, then:

42. Feed cookies and chocolate and bacon sandwiches, or a bacon-chocolate-cookie-sandwich to the guy who will own this API.

This is to solve the problem of suffering, missery and everything, and from there:


Access patterns/considerations:

1. Long-half-life data:

Much of your data (System names, Item Names, etc) is likely to have a long half time. I'd like to see this data provisioned as static content in more than one format (but that's because I've done this before for an MMO).

Some folks will want XML and some will want JSON and some will want JS and some will want CSV. For the static portion of the content, you can refresh this periodically - probably at patch time, and by serving it as static content you can encourage API consumers to use HEAD requests. And if you cap this off with an index, then you can facilitate a single

HEAD /api/content.csv

If it hasn't changed, you don't have to fetch any of the static content.

I personally would prefer the data to be in either terse json format or csv. I'm sure some people will want XML because they hate bandwidth, but those are also the guys most likely to do things like HEAD requests and actually try to avoid downloading everything every time in the first place.

2. Maintaining the spirit of discovery:

I'm about to ask you to expose a lot of your data, but that doesn't mean you have to put on an apron and answer to "Garcon".

There are a number of crowd-sourcing projects going on now to try and gather data from the ED universe. The main problem with these is a lack of authority for the data.

Perhaps in the future, when X% of the data has been discovered, you can expose more data, but I think to start with the most helpful thing would be an API which connects with the game by requiring you to - at the very least - discover systems.

To achieve this, some form of "EDGUID" (Elite Dangerous Globally Unique ID) which you can only retrieve from in-game. Provide an SLA that for a given star, any name or position changes will not result in a change of EDGUID and you establish the all-important COA.

Your API would then require users to refer to a System by it's EDGUID and it's name stripped of any punctuation or spaces:


You've got two factor authentication to prohibit crawling sufficiently long for you to catch anyone trying to do it, and player's - and thus third party tools - can only obtain this data as their users actually play the game.

Beyond that, for now, I think the main things I would love to have available for my trade database/profit optimizer:

a- List of Item Categories (perhaps by language):
[ identifier, name ]
b- List of Standard Tradeables (excluding rares, is fine):
[ identifier, category, name ]
c- List of Player Ships
[ identifier, name, cost, blurb ]
d- List of "Public" System EDGUIDs and Names
[ "AAX-192-KYW-929-A08", "Luyten's Star" ]
e- System information:
[ proper name, "blurb", galactic coordinates, permit (y/n) ]
f- Station information:
/api/station/<EDGUID of System>/<stripped station name>
[ proper name, faction ]

I suspect at some point the star data will need to be compartmentalized into quadrants (40x40x40ly) to discourage people from writing apps that start with requests.get("/api/all-dem-stars.2gb.xml")...

So - here I am, the author of a trading tool, and ... I'm not asking you for all kinds of data.

The data I am asking for would allow my users to have a solid foundation for the data they are gathering, sharing, co-operating on, with plenty of motivation to continue exploring and playing. That core, things like item names etc, is just the static data that doesn't detract from the game by being exposed. The availability of coordinates and names for Systems means that where users choose to collaborate, they don't have to get bent out of shape because I, for example, am a baked-in C64 Monty Mole fan and I can't type "Ron Hubbard" for the life of me (apologies to everyone being misdirected to Rob Hubbard Port).

The co-ordinates are used in my tool for finding nearby stars, calculating jump routes, or finding "stars within X jumps of system X at a maximum of Yly per jump".

  import tradedb
  tdb = tradedb.TradeDB()

  # Lookup "The Ascending Phoenix" in Chi Eridani
  start = tdb.lookupPlace("chi/ascendingph")

  # Find the route to lave with a 16.11ly jump limit
  lave = tdb.lookupPlace("lave")
  route = tdb.getRoute(start, lave, 16.11)

  # Get a list of stations within 5 x 19.5 jumps
  # only include stations paying for something
  # sold here, where paying > buying
  # and don't go to lave, that place sucks.
  trading = tdb.getDestinations(
  		maxJumps=5, maxLyPer=19.5,
  		maxPadSize='ML',  # medium or large pads only

Right now, all of the data is user-supplied (system names, coordinates; station names, coordinates, black market, pad size, ls from star; trade prices). A chunk of my users are running their own, private, stand-alone database; many others are using 3rd-party crowd sourcing projects (maddavo's site, EDDN).

So, yeah, a part of me would love to say "can I have a way to get price data from X hours ago as 'backfill' material" or "it would be great if you could tell us the max pad size of stations" but I think it's better for the game that we don't have that for now. I think having the foundation of system and star data, gated by discovery, is far better for the game.

I'm pretty sure some TradeDangerous users won't thank me for this, but I value the game first and foremost over the tool I've written for it :)

[I should point out: TD has a number of commands dealing with finding missing/old/ambiguous data and a lot of my users thus use the crowd-source project as a way to supplement the mission system and add value to the game for themselves]

Perhaps you might consider exposing some additional data as seeing material, the way you initially exposed a number of systems names/coordinates, you might have a small number of systems for which you expose additional data, in which case the values I'd most want access to are:

. System:
- Permits required,
- Number of stations,
. Station:
- Orbit (I'm not interested in 2 hour flights),
- Type,
- Max Pad Size (so I know if I can land there),
- Has black market,
. Trades:
- Items sold by station,
- Items bought by station,

You might even consider something like a 12hr average price for the listed items for those stations.

This is only some of the data I'm already gathering (we also record the units and level), and it allows me to figure out where I can buy or sell items for missions, allowing for things like how big my ship is, whether the goods I have are illegal.

It lets me figure out what's likely to be a good haul between two systems, even if there are a number of jumps required between them, although I should point out that it is absolutely not guaranteed to do so because even if I had "live" data it cannot preempt the actual travel time of getting cargo from A to B.

Hope this is in line with what you were looking for in terms of feedback.
Last edited:
Rather than list, things I would just say that an API should provide all information that is already surfaced to the individual player in some way with some key exceptions such as relative positioning of other ships as seen on the scanner (otherwise someone could use it to code an "aim bot").
Last edited:
As noted earlier, it seems to me that most of these ideas could be achieved in game with further development of the galaxy map, UI etc by Frontier.
Of course, but pragmatically speaking, Frontier don't have the time or resource to be able to implement everything that we'd like to see. If they give us an API and let us develop apps or websites to complement what's in the game, it's a decent compromise.
+1 for Game State

It's simple enough to build a custom USB keypad/controller to send commands but it would be so cool to get a dump of ship state including current states of :

Current target
Silent running
cargo scoop
Current selected HUD panel and sub-menu/ option

Basically anything that is selectable/toggle-able by the pilot through the in-game HUDS

A shared memory map file would be fine (read only) so that folks could write client apps to turn this into whatever protocol they need to talk back to their custom device.
Wow! Just wow!

I don't have time (work) to go into too much detail but this thread caught my eye. And I love the idea of an API to help build some community spirit :)

First I think we need trading to be in-game. We need a CMDr log that populates your trading data when you visit a station. That data should be valid for 24hrs or so. But not in the form of an API. I hope this is an in-game feature. No more spreadsheets and a Notes feature in there too.

The API should be for telemetry and way point saves and maybe grouping data. I want to meet up with Dave. Computer take me to Dave. Dave's system data is logged and off you go ;) That kind of thing. Sending out distress beakons or meeting points can all be implemented. Oh how the mind now boggles.

Friend can all share some data together. But the best thing will be custom dashboards! We have this in iracing and it's real community building stuff. Oh wow, I just had a flash of a new dash in my haed. Oh stop it I have to work!

I think there needs to be some lines drawn though. We don't want too much (or any) automation in the machanics. We need to still go from a to b and visit stations and work for our data. I hope any API will not take that away.

Voice activation!!!! Needs some big love and an API would work so well there too.

Oh I have so many ideas but no time to think!

Big thanks Michael and will watch this closely! Happy Days People ;)
Last edited:
The API could allow access to a RGB value of the current ambient light in the cockpit - we can then hook this value to RGB LED lamps in the room (or simpit) so for example, the whole room will flash when laser-fire zings overhead; a low-cost way to extend the game beyond the screen and make the environment seem to fill your peripheral vision.

When you fly with a huge orange sun overhead in your canopy, you and your cockpit (the room) really are flooded in the orange light, you barrel-roll and the room darkens as the sun goes under the wing, etc.

The cockpit RGB value offers a cheap-hardware way to increase immersion, basically. Using peripheral vision can make experiences significantly more "real".
Was this in reply to me? Because I asked for this on the last page :)

Besides the system information (Planet, Star, Station, Asteroid belts) it would be great to get access to the minor systems faction influence data. Based on that it would be great to implement a kind of stock market app to allow for making credits (or loosing as in RL :) during the day when not actually playing Elite.

Would be cool to have some "little" Elite playing going whilst being at work.
I just wish there was some sort of a trader capability that allowed you to to save prices of the commodities market at a given station. I find myself using notepad or screen shots to keep track of pricing....
Ideally the data needs to be provided in an format that is easily consumed by the maximum number of client apps. XML would seem to be the most logical choice though if support could also be included for JSON this might be useful also.
XML response documents should contain 1 root tag <RESPONSE> and a fixed number of 2 child tags. The first child should always be a versioning tag, telling the consumer which version of the API they are talking to (possibly with major, minor, revision subtags to allow a more fine grained use of the response).
The second tag should describe the type of response the is being delivered, such as TRADE, SHIP, CHARACTER etc.

The API might benefit from being implimented seperately on the server and the client.

Server API should provide information that is global available to players in the game, by splitting the two API's you reduce the chance for abuse by requesting privildged information on a client from an attacking party. To prevent abuse the API server should require a token to access. The replies should be rate limited per token, and the replies should be cached to minimise the change of flooding attacks. Such information should include:

Response Type				Use Case
-------------------------------------	---------------------------------------------
Map co-ordinates for a named system	Route planning
Ship stats				Ship load-out planning

Client API, needs to provide information that is visible only to the client itself. Such information should include:

Response Type				Use Case
-------------------------------------	---------------------------------------------
Current location			        Route planning, exploration mapping
Current system information  		Exploration database creation
 - Everything visible from system
 - Pad types for platforms
Current market information		Trade planning, market graphing
Current statistics (from sys panel)	Progression tracking

Some information may be considered highly priviliged, and may require a validate privilidge token for use only by trusted partners - such as peripheral developers.

Response Type				Use Case
-------------------------------------	---------------------------------------------
Sensor information                      	External scanner peripheral
Sys,Engine,Weapons pips              External power management peripheral
Module power status			External module peripheral
Ship status information			External warning system
 (hull strength, sheild stats)

A potential feed-in system might also be useful to allow very small amounts of automation from external apps.

Request Type				Use Case
-------------------------------------	---------------------------------------------
Comms messaging			Message macros
Thread Closed: Not open for further replies.
Top Bottom