EDMarketConnector pipes Elite Dangerous trade data into the tools that price it

The market tools need data that only the PC client writes down

Third party trading and market tools for Elite Dangerous need commodity prices, station listings and ship information, and the game itself does not hand that out in a shareable form. EDMarketConnector, shortened to EDMC, exists to close that gap. It is a Python application that a PC player runs locally, and it works from two directions at once: it reads the Journal files that the game writes on the player's own machine, and it queries the API that Frontier Developments supplies, so the result can be fed to whichever third party sites the player already uses. The scope is narrow by design, and the README is clear about the boundary: this application is only of use to PC players of Elite Dangerous and its expansions, and it will not work with PS4 or Xbox accounts. If your trading habit is console based, there is no path through this project, and no configuration change will change that.

Journal files and the Companion API are the two inputs

The mechanism is a local watcher plus a web client. The Journal side reads files the game leaves on disk, which is why the project ships a filesystem watcher dependency and a module named journal_lock.py, and why journal_lock.py sits next to monitor.py in the top level listing. The API side is the Companion web API, which Frontier originally supplied for the Elite Dangerous iOS app and now supports for third party apps. The disclaimer in the README states the risk plainly: if that API ceases to function in the future then much of the application's functionality will be curtailed, although it could still utilise Journal files. That sentence is the most useful architectural fact here. Market and station discovery leans on the API, while local game state leans on the Journal, so an API outage does not kill the app but it does degrade it into something narrower.

Plugin architecture, not a fixed set of sites

EDMC is not a hardcoded list of destinations. Plugins extend the behaviour of the app, and the repository carries a plugins/ directory, a plugin_browser.py, and a modules.json file, with PLUGINS.md as the starting point for anyone writing one. A separate debug_webserver.py and dashboard.py suggest that the app exposes local endpoints rather than pushing data only outward, which is what allows a plugin or a local tool to consume the same parsed stream. The tree also shows a heavy localisation surface: an L10n/ directory, an l10n.py module, and EUROCAPS.TTF for rendering. That combination, plugin hooks plus a local web surface plus translations, is what separates a trading utility from a script, and it is also what makes upgrades a matter of plugin compatibility rather than just app compatibility.

Installation and first run live in the wiki, not the README

The README does not carry a setup recipe of its own. Installation and uninstall are delegated to the Installation & Setup wiki page, running from source is delegated to a separate wiki page, and there is a dedicated Troubleshooting page plus a docs/Releasing.md page for distribution packaging. So the honest first-run path is: pick a release or a source checkout, follow the wiki, and only then configure destinations. The dependency set is pinned in requirements.txt, and it is short enough to read as a description of what the app does: an HTTP client, image handling, a filesystem watcher, a Windows system tray library, a Windows permissions library, process inspection, a semantic version parser, and a TOML writer. Platform markers in that file show that the tray and permission features are Windows only.

requests==2.33.0
pillow==12.3.0
watchdog==6.0.0
simplesystray==0.1.0; sys_platform == 'win32'
semantic-version==2.10.0
pywin32==311; sys_platform == 'win32'
psutil==7.2.1
tomli-w==1.2.0

text

What to look at after a source install is whether the process starts, whether it detects the Journal folder, and whether the destinations you enabled receive data. The Troubleshooting wiki page and the log files it points to are the intended place to answer those questions.

Running from source means a checked-in test harness

For a source install, the repository already carries the tooling expectations. pyproject.toml configures pytest with testpaths pointed at the tests directory and enables coverage reporting across the main package and the plugins package. The coverage rules in that same file are platform aware in a way that reveals the project's shape: separate rules exist for win32, darwin, linux and an unknown platform, and each rule excludes the branch that does not apply to the running system. There is a .flake8 configuration, a .mypy.ini, a .pre-commit-config.yaml, and a .python-version file, so linting, type checking and a pinned interpreter are part of the expected contributor workflow rather than optional extras. For a user this matters less than it sounds, but it does tell you that a source checkout expects a specific Python version and a fairly conventional dev toolchain.

Windows first, with Linux and macOS carried along

The repository layout shows a Windows centric history. There are three .bat launchers in the top level, including one that resets the UI and one that runs a local server authentication flow, along with a Windows desktop file, an icon, and an installer.py plus a build.py. Alongside that sit Python platform rules for darwin and linux, and a Debian style desktop entry, so the app is not Windows only, but the affordances are uneven. The coverage configuration makes the same point in a different way, since each platform gets its own exclusion rule. If you are on macOS or Linux, the pieces you may miss are the batch reset switches and the system tray integration.

A stable line with a parallel beta track, and an upstream in the background

The published history shows a stable track and a pre-release track running side by side. The most recent stable tag is 6.1.2, dated 2026-01-29, and it was preceded by 6.1.2-beta1 two days earlier, on 2026-01-27. The newest tag overall is 6.1.3-beta3, a pre-release from 2026-05-30. The last push to the repository was on 2026-10-01. So work is still landing, but the newest artefact is a beta rather than a stable release, which matters for anyone who installs by tag. A second signal is the Companion API risk described earlier: the upstream dependency is the piece most likely to change under you, and the README answers that by pointing to Journal files as the remaining fallback. Licence terms sit underneath all of this. The code is under the GNU Public License version 2 or later, with copyright attributed to Jonathan Harris for 2015 to 2019 and EDCD for 2020 to 2024, and the acknowledgements page carries the third party credits.

Editorial conclusion

Adopt it if you play Elite Dangerous on PC, use third party market trackers or trade tools, and want local commodity and station data parsed automatically instead of by hand. Do not expect it to work for PS4 or Xbox accounts, and do not treat it as a system of record when the Companion API degrades. Before trusting it with a live market, confirm the version you run matches a current release, read the Installation & Setup wiki page rather than a third party guide, and check the log files that the Troubleshooting page points to, because a silent Journal parsing failure looks like an empty market.

Frequently asked questions

Official sources

1. EDCD/EDMarketConnector on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases