Skip to content
Athanasius edited this page Jul 21, 2021 · 73 revisions

What is EDDN?

The Elite: Dangerous Data Network is a system for willing Commanders to share dynamic data about the galaxy with others. By pooling data in a common format, tools and analyses can be produced that add an even greater depth and vibrancy to the in-game universe.

EDDN is not run by or affiliated with Frontier Developments.

Using EDDN

How you use EDDN depends on who you are:

Trading software users

If you use one of the following trading tools then you're already taking advantage of data supplied by the EDDN network:

Tool Commander
EDDB themroc
EDSM AnthorNet
Elite Trade Net Joe113
Inara Artie
Maddavo's Market Share maddavo
Roguey's Roguey
ED-Intelligent Boardcomputer Extension Duke Jones
edda troydm

Player tools

If you're playing E:D on PC or Mac please consider running one of the following apps to contribute data to EDDN for your own and others' benefit:

Tool Commander
E:D Market Connector Otis B.
ED-Intelligent Boardcomputer Extension Duke Jones
edce-client Andargor
EDDI VerticalBlank, Hoodathunk, T'Kael
EDDiscovery Robby
Elite Log Agent John Kozak
Elite G19s Companion app MagicMau
Elite Virtual Assistant
Trade Dangerous + EDAPI orphu

If your preferred trading tool or app isn't on these lists ask the developer to incorporate support for EDDN!

App developers (data uploaders)

To upload market data to EDDN, you'll need to make a POST request to the URL:

The body of the request should be a JSON-format message corresponding to one of the supported schemas, e.g.:

  "$schemaRef": "",
  "header": {
    "uploaderID": "Bill",
    "softwareName": "My excellent app",
    "softwareVersion": "0.0.1"
  "message": {
    "systemName": "Munfayl",
    "stationName": "Samson",
    "marketId": 128023552,
    "horizons": true,
    "timestamp": "2019-01-08T06:39:43Z",
    "ships": [

There are two readily accessible sources for this data; the Companion API which supplies data that can be used for the commodity, outfitting and shipyard schemas and (from E:D 2.2) the Journal which supplies data that can additionally be used for these plus the journal schema.

When using the Companion API please be aware that the server that supplies this data sometimes lags behind the game - usually by a few seconds, sometimes by minutes. You MUST check in the data from the API that the Cmdr is docked (["commander"]["docked"] is True) and that the station and system (["lastStarport"]["name"] and ["lastSystem"]["name"]) match those reported from the Journal before using the data for the commodity, outfitting and shipyard schemas.

EDDN is intended to transport generic data not specific to any particular Cmdr and to reflect the data that a player would see in-game in station services or the local map. To that end, uploading apps MUST ensure that messages do not contain any Cmdr-specific data (other than "uploaderID" and the "horizons" flag). In practice as of E:D 3.3 this means:

  • commodity: Skip commodities with "categoryname": "NonMarketable" (i.e. Limpets - not purchasable in station market) or "legality": non-empty string (not normally traded at this station market).
  • outfitting: Skip items whose availability depends on the Cmdr's status rather than on the station. Namely:
    • Items that aren't weapons/utilities (Hpt_*), standard/internal modules (Int_*) or armour (*_Armour_*) (i.e. bobbleheads, decals, paintjobs and shipkits).
    • Items that have a non-null "sku" property, unless it's "ELITE_HORIZONS_V_PLANETARY_LANDINGS" (i.e. PowerPlay and tech broker items).
    • The "Int_PlanetApproachSuite" module (for historical reasons).
  • shipyard: Include ships listed in the "unavailable_list" property (i.e. available at this station, but not to this Cmdr).
  • journal: Strip out "..._Localised" properties throughout the data structure.
  • journal/Docked: Strip out "Wanted", "ActiveFine", "CockpitBreach" properties
  • journal/FSDJump: Strip out "Wanted", "BoostUsed", "FuelLevel", "FuelUsed" and "JumpDist" properties.
  • journal/Location: Strip out "Wanted", "Latitude" and "Longitude" properties.
  • journal/Location and journal/FSDJump: strip out "HappiestSystem", "HomeSystem", "MyReputation" and "SquadronFaction" properties within the list of "Factions".

Some of these requirements are also enforced by the schemas, and some of the things the schemas enforce might not be explicitly called out here, so do check what you're sending against the schema when implementing sending new events.

You MUST NOT send information from Beta versions of the game universe using these schemas. You MAY send such information using the .../test versions of these schemas.

Trading tool developers (data consumers)

EDDN provides a continuous stream of information from uploaders. To use this data you'll need to connect to the stream using ZeroMQ (a library is probably available for your language of choice).

Currently available relays:

  • tcp://

You'll need to use your ZeroMQ library to connect to that stream, then zlib-decompress (as simple as zlib.decompress(message) in Python!) the messages as they come over the stream. And that's all - you then have access to all the data being uploaded to the network, almost instantly.

Consumers of data SHOULD examine the $schemaRef property to determine what kind of message has been received, and what if any processing to carry out on the data. You don't need to validate received messages against their schema since the Relay does this before forwarding. You SHOULD ignore (or log) fields and Journal event types that you don't recognise.

Sample applications are available. These simply dump the data to the console - you'll probably want to do something more exciting with it!