Mar 31, 2026 · Steve Berry, N1EZ
I want to tell you about something that is less a feature and more a statement of intent. DxQSO now has an open API — a front door for other logbook and app developers to build on top of the same connected system that powers everything we make. If you have ever wondered why we are so insistent that DxQSO is not a logbook, this is the clearest answer yet.
From the very beginning, our philosophy has been to empower the apps you already use rather than compete with them. There are excellent logging programs out there, and the world does not need us to build another one. What the world has lacked is a modern, common place for ham radio data to live and flow — and a way for developers to plug into it. The API is that idea turned into infrastructure.
It gives developers a clean, supported way to send logbook activity into DxQSO and to read what an operator is doing — their contacts, their QSL achievements, what they are working on right now — always with the operator’s permission. Think about what that unlocks. A POTA app that writes activations straight into your living record. A contest tool that reads your standings. A club platform, an award tracker, a band-conditions service, a kind of ham application nobody has built yet — all able to connect to the same real-time record and the same alerts.
Mechanically, the API does two things, and both are gated by the operator’s consent. It lets an application write logbook activity into a user’s living record — a POTA app posting an activation, a logger streaming contacts as they happen. And it lets an application read what an operator is doing — their consolidated contacts, their confirmed QSL achievements, what they are working right now — so a tool can act on real, current data instead of a stale export. Nothing moves without the operator allowing it. The point is not to open your logbook to the world; it is to let the tools you choose work together on your behalf.
The interesting part is not the endpoints; it is what people build on top of them. An award tracker that reads your live standings and tells you the moment you are one confirmation away. A band-conditions service that knows what you still need and points you at an opening. A club platform that shows members’ real activity. A contest tool that writes its log straight into your record with no export step. A category of ham application nobody has built yet, because until now there was no common, real-time place for the data to live. Every one of those becomes a weekend project instead of a from-scratch infrastructure build, because the plumbing already exists.
Our data has been stranded for decades — locked inside desktop programs, exported as ADIF files, re-imported, duplicated, and lost. Every developer who wanted to do something interesting had to reinvent the plumbing first. An open, well-documented API means they can stop reinventing plumbing and start building the actual idea. That is good for them, and it is far better for us, the operators who get to use what they build.
This is also exactly why we keep insisting DxQSO is a system, not an app. The repository that holds your logbooks is the foundation. The connectivity, the real-time alerts, the collaboration, and now the open interface that lets the whole ecosystem plug in — that is the product. We want to be the connective layer the next generation of ham radio software is built on.
If you build ham radio software, this is an open invitation: come build on DxQSO, and let us carry the data-plumbing and real-time-delivery burden so you do not have to. Reach out and let us talk about what you want to make.
And if you do not write a line of code, this still matters to you. It means the tools you use tomorrow can all speak to the same record — that the hobby’s software is finally starting to behave like one connected ecosystem instead of a drawer full of programs that cannot talk to each other. That is the future we are building toward, and the API is how we open the door to it.
