Club Log performs log matching against QSOs where both callsigns are Club Log users. This procedure is similar to an LoTW match (with a tolerance of +/- 15 minutes) and is suitable for validating that a QSO occurred. To query for log matches programmatically, you may use getmatches.php.
getmatches.php takes a number of HTTP GET parameters and returns a JSON array of matches.
- api = Your API key
- email = The user's Club Log account email address (ideally, please ask the user to provide an Application Password from Club Log)
- password = The user's Club Log password
- callsign = A valid callsign belonging to the user (it must be owned by the account)
- startyear = Starting year for matches (the date of the match, not the QSO), eg 2013 - OPTIONAL
- startmonth = Starting month for new matches, eg 1, 01, 12 = December - OPTIONAL
- startday = Starting day of the month for new matches, eg 3, 03, 13, 31 - OPTIONAL
Note: You should use HTTPS, as one of these parameters is the user's Club Log password.
As matches occur gradually in Club Log, it is anticipated and hoped that you will want to filter the report to only fetch new matches each time you call getmatches.php. There is no reason to ask Club Log for matches already retrieved, but you might want to have a 1-day overlap each time, to be sure you don't miss something matched later in the same day as your penultimate lookup. To specify a starting date, you must provide a valid value for startyear, startmonth and startday (that is to say, all three are required). The date is when the match was completed by Club Log (not the QSO date). If no date is supplied, all matches are returned without a date filter.
Here is an example query to retrieve new QSO matches made on or after 2013-12-17 00:00:00 for G7VJR:
Here is an example query to retrieve all matches for G7VJR:
It would be greatly appreciated if you could avoid the second query being used unnecessarily. Try to use the start date filters, as this is much more efficient and will give you smaller, faster results.
All results are returned as JSON in an array. For example, you may get this result:
[["G0LGJ\/M","223","2005-07-16 08:00:00","20","CW"],["CO2IZ","70","2005-08-15 20:27:38","20","SSB"]]
(notice that slashes are escaped in JSON). The fields are unlabelled for compactness. Reading left to right they are:
- Matched callsign
- Matched callsign's DXCC ID (ie. ADIF entity number)
- QSO date (as logged by the owner of the lookup; the DX station is within +/-15m but you won't get to know the exact time)
- Band ID (eg. 20 = 20M, 70 = 70CM)
- ModeID = a string representation of the mode (eg. CW, SSB, RTTY and so on - this will say "false" if the mode is unknown.