Club Log has a complete set of DXCC slot data pre-calculated and available efficiently for each callsign registered. This data is used to provide the DXCC matrix on the "DXCC Charts" page. This page shows which entities the user has worked on each band, and includes the QSL status of each of the slots, as well as various filters.


In order to help you integrate this data into other applications, you can retrieve the data in the matrix in JSON. For example, if you are writing a tool which could be personalised for a user (perhaps only showing DX spots they need, or highlighting missing QSLs in their log) then you may wish to retrieve Club Log's DXCC matrix for a callsign owned by that user, and use this to modify the way slots are displayed in your application. You are welcome to use the data however you wish.

 

The JSON output is provided using the json_dxccchart.php end point:


https://clublog.org/json_dxccchart.php


The GET variables used are as follows:


  • call = The callsign, which must be owned by the email address
  • api = Your application API key
  • email = The email address of the Club Log account that owns the callsign
  • password = The password of the Club Log account (ideally, please ask the user to provide an Application Password from Club Log)
  • mode = 0 for all modes, 1 for CW, 2 for Phone and 3 for Data. This is optional. If not set, all modes is assumed.

Example:

https://clublog.org/json_dxccchart.php?call=G7VJR&api=APIKEY&email=michael@g7vjr.org&password=SecretPassword&mode=0


The response from this call is either a plain text error, or (if everything parses correctly) it will be a JSON array. Each element in the array is itself an associative array of the ADIF DXCC IDs the user has worked, containing each band mapped to its QSL status via an enumeration.


For example, ADIF number 1 (Canada) might look like this:


{"1":{"6":1,"10":2,"12":3,"15":1,"17":3,"20":1,"40":1,"60":2,"80":1,"160":2}....}


The QSL enumerations are:


  • 1 = confirmed
  • 2 = worked
  • 3 = verified


Referring to the example output, this means that Canada has been worked (1) on 6m, confirmed (2) on 10m, verified on 12m (and so on). You can also see that 30m is missing, which means that slot has not been worked.


The full JSON output will be copious as it will continue with each ADIF entity!


Notes:

  • All lookups are cached for 60 minutes for performance reasons, so you should probably avoid making repeated requests in a shorter interval than this, as doing so will not yield fresh data (unless the user uploads a new ADIF)
  • If any DXCC is missing, or any band is not listed, this implies that that slot has not been worked.
  • There is no use of zero (0) for "not worked". Instead, "not worked" is implied by the absence of a value. This is done for compactness.
  • If the callsign provided has other callsigns linked to it in the user's account, then the response will be for all linked callsigns combined.