Skip to main content

Importing Contacts

Hamtrax uses one interactive Import Contacts workflow for files and connected logbooks. Its first screen keeps the decision to three choices: Import from file, Import from connection, or See guides for common loggers.

  • Import any logbook — choose Import from file to upload one past activation, a mixed file, or a whole ADIF or CSV logbook. Hamtrax reviews and routes every contact through the same guarded filing system, skipping duplicates. Choose See guides for common loggers when you need logger-specific export steps first.
  • Import directly from QRZ — connect your QRZ Logbook once, then pull its contacts into that same workflow without downloading a file.
  • Automatic POTA starter import — when you add or change your account callsign, Hamtrax checks your public POTA profile and imports the latest public hunter QSOs POTA exposes for that callsign. This is a capped recent public list, not your full private POTA logbook.

Use Import Contacts for one past activation, a whole logbook, connected QRZ contacts, or a mixed file. One page owns parsing, destination review, duplicate checks, and the cloud-confirmed result.

Equipment stays historical

Imports preserve radio or antenna details that are present in the source. When the source has none, Hamtrax leaves the equipment unknown; it never stamps the radio or antenna you happen to have selected today onto an older imported contact.

Browser imports do not use your native-contact allowance

The free tier's 200-contact native limit counts contacts you log directly in Hamtrax, including Hunt, Activate, manual entry, and the CLI. Contacts imported through Hamtrax in the browser do not count toward that native total. Source-size safeguards and the 200-row loading or preview controls described below still apply; those are not a cap on how many accepted contacts the importer can save.

Import any logbook​

The general importer takes an entire logbook and files each contact where it belongs — activations into activation folders, hunts into monthly Hunting folders, and everything else into a custom folder. You never sort anything by hand.

Getting to the importer​

Open the shared Import Contacts page from any of these shortcuts:

  1. Logbook → Import Contacts — the button above the Contact Folders heading.
  2. Activate → Import a past activation.
  3. Logbook → Parks on the Air → Activations → Import.

All three open the same importer.

Supported files​

Choose Import from file, then drop one file onto the drop zone or click to browse:

  • ADIF (.adi or .adif) — the standard amateur-radio log format, exported by virtually every logger.
  • CSV (.csv) — a spreadsheet-style file. Hamtrax reads its own CSV export back in with full fidelity (a complete round-trip), and recognizes the common column names other logbooks use (CALL, QSO_DATE, TIME_ON, FREQ, BAND, MODE, COUNTRY, DXCC, and so on) automatically. There's no column-mapping step to fill out — recognition is automatic. Hamtrax finds the header row itself: if your spreadsheet export starts with a title line and an export date above the column names, it looks down the first ten rows for the real header, so you do not have to tidy the file first. It also detects the separator, so a tab- or semicolon-separated file still reads correctly even when it was saved with a .csv extension. If no header can be found, the error quotes the first row of your file so you can see what Hamtrax actually read.

Export from another logger​

Choose See guides for common loggers, then select See Steps for the logger whose file you want to move:

LoggerRecommended export
World Radio LeagueGeneral ADIF for a whole logbook, or a filtered QSO Manager export
Ham2K PoLoFull ADIF Export
HAMRSADIF export from Logbook Actions

Each guide explains only how to get the file out of that logger. Return here for the maintained Hamtrax steps.

The separate Import from connection screen also shows LoTW, N1MM Logger+, and HamQTH so you can connect or manage them, but it labels their capabilities accurately: LoTW synchronizes confirmation status, N1MM stores live-logging bridge settings, and HamQTH uploads contacts. None of those three cards imports historical contacts into Hamtrax.

Import directly from QRZ​

Choose Import from connection to see QRZ Logbook. Its action reflects the saved connection:

  1. If the card says Connect, select it to open and expand the QRZ panel in Settings → Preferences → Integrations. Add the API key, then return to Import Contacts.
  2. Select Import. Hamtrax fetches the logbook in pages through its authenticated server gateway; your browser never contacts QRZ directly.
  3. Walk through the same guided Activations → Hunting → Custom → Summary review used for file imports. Empty folder stages are skipped automatically.
  4. Finish the review to save only the new contacts.

Direct QRZ imports are capped at 100,000 contacts or 64 MiB per run. This keeps an unexpectedly large or malformed remote response from overwhelming the browser; no contacts are saved unless the complete fetch fits within both limits.

If a QRZ contact already exists locally, Hamtrax skips the duplicate and attaches its QRZ log ID to the matching local contact. That remote identity is what lets auto-push recognise the contact as already present in QRZ. A duplicate-only QRZ review can still be finished so those IDs are attached even when there is nothing new to save. Importing never deletes a contact from QRZ. Imported contacts are never auto-pushed either, and deleting an imported contact in Hamtrax always leaves the QRZ original alone.

Prefer a file, or need to connect first? See Import from QRZ for both supported paths.

Automatic POTA starter import​

When your Hamtrax account gets a callsign for the first time, or when you change it later in Settings → Account, Hamtrax fetches the public POTA profile for that callsign and imports the latest public hunter QSOs POTA exposes. This is a starter import only: POTA currently exposes a capped recent public list, not your full private POTA logbook.

These contacts follow the same rules as file imports: Hamtrax skips duplicates, files hunted parks into monthly Hunting folders, fills map coordinates from POTA park data when available, and runs the same folder guardrails before anything is saved. The import runs in the background and only ever happens once per callsign — even if you're signed in on two devices — and the contacts appear in your logbook on the next refresh, usually a minute or two after your callsign is saved.

The three steps​

A progress bar walks you through Select → Review → Finalize:

  1. Select. Start with Import from file, Import from connection, or See guides for common loggers. Only that choice's controls appear next. A file or connected QRZ Logbook then enters the same parser, which works out where every contact will go.
  2. Review. Hamtrax shows one non-empty folder category at a time: Activations, then Hunting, then Custom, followed by a count-only Summary. Protected activation and Hunting destinations are read-only. Only the Custom stage offers organization choices; excluding a contact never reroutes it.
  3. Finalize. Hamtrax creates any folders it needs, writes the contacts, and then waits — briefly — for your logbook in the cloud to say what it accepted. The summary reports that answer rather than the local save: filed, still filing, and refused are separate numbers.

Throughout the Review step each destination names itself in full: an activation card shows the park's real name above its folder name, and every contact row carries the reference that sent it there, because that reference is the reason for the destination. Where one activation is split across two cards because it ran through 0000Z, the second card says so in place — activations are scored per UTC day, so a session from 23:40Z to 00:19Z is filed as one folder per day by design, not by accident.

Every decision, end to end​

Every contact you import walks the same path. Nothing below is a judgment call Hamtrax makes differently from one run to the next — these four stages are the rule set, in order. Stage ③ is drawn in two halves so each diagram stays readable: ③a picks the kind of destination, ③b resolves the activation folder.

Stages ① and ② have already run by the time the Review step opens, which is why the summary can tell you how many records were unreadable or duplicated before you confirm anything.

① Parse — is the record readable?​

② Duplicates — have I seen this contact already?​

③a Route — which side of the contact decides?​

Hamtrax reads the contact's own activity tags in a fixed priority order — your side first, their side second, plain entity evidence last. This half picks the kind of destination; only the activation route needs the extra question in ③b.

Two rules ride along with the first question. A MY_SIG that names no reference identifies nothing, so it is dropped before the tree runs and the contact routes on its THEIR side as the hunt it is. And an activity code Hamtrax doesn't have installed — or can't tell apart — is never re-stamped as POTA; it stays custom and unchanged.

③b Route — which activation folder?​

Only contacts that took the Activation route above reach this half. A hunting month and a custom folder are already decided; an activation still has to name itself and find out whether one of your existing sessions owns it.

④ Guardrails and your review​

The first three checks all run on this device, and they all judge a folder this device just worked out for itself. Only the fourth judges the folder your logbook actually holds — which is why the summary at the end of an import waits for it, and reports filed, still filing, and refused separately instead of calling a local save an import.

How contacts are sorted​

Hamtrax resolves each activity through the installed program packages and routes it automatically. This core filing policy also drives the Logbook's global Add Contact preview and save, so one contact reaches the same program destination whether it came from a file or the manual form. Three programs are installed today — Parks on the Air, DX Chasing, and Repeaters — and the same seam is ready for later programs without changing the importer:

  • You activated under a supported program (a "my reference" in MY_SIG_INFO; currently POTA only — DX Chasing and Repeaters are hunt-only, because a country can't be activated and a repeater is something you work rather than put on the air) → that program's activation folder, named in POTA's current CALLSIGN@PARK-YYYYMMDD format. Hamtrax checks each contact against same-program activations already in your logbook: if one recorded a session covering that contact's UTC day, the contact joins it, so a session that ran through 0000 UTC stays whole. Otherwise Hamtrax creates a folder keyed to the contact's UTC day.
  • You hunted under a supported program with no MY activity identity (a "their reference" in SIG_INFO — a POTA park reference, SIG reading DX with the ADIF DXCC entity number in SIG_INFO, like 269 for Poland, or SIG reading REPEATER with the repeater's callsign and output frequency in SIG_INFO, like W0ERH 442.100) → that program's UTC-month hunting folder, created automatically if needed. Program-scoped monthly folders require the same Hunt program, a reference valid for that program, no MY_SIG / MY_SIG_INFO, and the same month — a DX month never takes a POTA hunt, a POTA month never takes a DX contact, and neither takes a repeater contact. A contact whose MY side names a reference is activation/P2P-owned and cannot enter a month; when that MY program is unsupported, the import keeps the original fields and offers the contact in the custom-folder review instead of stripping them. Released POTA YYYY-MM folders preserve month-only compatibility for blank-program legacy contacts, while an explicit other program is still blocked.
    • A MY_SIG with no MY_SIG_INFO beside it is dropped, because it names nothing. A program code on its own selects no folder, earns no program credit, and isn't a meaningful ADIF pair to keep. Some loggers stamp the log type's program code onto every record of a session-typed log whether or not you recorded a location — HAMRS writes MY_SIG=POTA across a whole POTA-typed logbook — so reading that bare code as an activation would keep an ordinary hunt out of its month for no gain. Hamtrax removes it and files the contact on its hunted side exactly as it would any other hunt. The test is the reference, not the program, so it applies the same way whatever the code says. A MY side that does name a reference is never touched — including an unsupported program like SOTA with a real summit reference, which still keeps its fields and goes to a custom folder — and a reference a supported program refuses is still reported as a rejection rather than quietly erased.
    • When contacts reach the custom step and you already have custom folders, the review asks where should these go? and offers New folder or Existing folder as a visible choice, with your existing custom folders listed to pick from. Choosing an existing one files into that folder instead of minting another; the destination card's New folder / Existing folder badge always tells you which is about to happen.
    • Repeater contacts route on that explicit SIG tag only. Nothing is inferred from a frequency, a mode, or a callsign, and no logbook before Hamtrax wrote SIG=REPEATER — so the tag is effectively Hamtrax's own export coming home, and a contact through a repeater that arrives untagged simply files like any other untagged contact.
  • The contact carries no activity tag at all, but names a DXCC entity → the DX Chasing UTC-month folder for that entity. No logger other than Hamtrax writes SIG/SIG_INFO for DX — that ADIF pair names a special-interest activity like POTA or SOTA, and country chasing has no such tag — so a DX contact exported from another logbook or pulled from QRZ arrives carrying only the standard DXCC entity number, or a COUNTRY name. Hamtrax reads either one and files the contact, using the very same rule that decides whether a country counts as worked on your DX Chasing tab. Country names are matched against the official ADIF entity list, plus a small hand-checked set of everyday short names — so Germany finds the entity the list calls Federal Republic of Germany. Names that genuinely cover more than one entity are never guessed: Korea, Russia, Congo, United States and United Kingdom each span two or more DXCC entities, so a contact carrying only one of those words waits for you in the custom-folder step rather than being credited to the wrong country. Three things stop it from over-reaching: another program's tag on either side always wins (a SOTA contact stays SOTA, and your own activation stays an activation), the entity must be a real current one from the official ADIF list, and contacts in your own country are left alone — most loggers stamp DXCC on every contact including domestic ones, so filing those would bury the real DX in your own folders.
  • The activity is unsupported or ambiguous, or neither side has an activity → a custom folder. The original fields stay unchanged; Hamtrax never guesses a program or re-tags SOTA or WWFF as POTA. In Review, you decide whether these go into one existing or newly named custom folder, or get split by month, year, band, or mode. If a known supported program is explicit but its reference is invalid, the row is rejected instead of falling through to a less-protected folder.

Only stages containing contacts appear. Activation folders are fixed by your park and the session Hamtrax matched the contact to; Hunting folders are fixed by the installed program, worked park or entity, and UTC month. Those destinations cannot be changed in Review, which keeps the same folder-hygiene rules as normal logging. Custom folders have no protected placement rule, so that is the one stage where Hamtrax asks how you want the contacts organized. Review is locked, but not final: if an import files an activation under a park reference that was wrong in the file itself, the finished folder has an Edit button beside Activation.

Why one folder, and not one per UTC day

Because that is what POTA asks for. Their log-submission guidance is explicit:

"It is recommended to combine logs from a single activation into a single ADIF file where applicable (same park and same station callsign), although not required."

"A single ADIF file may contain multiple UTC days."

— POTA — Submitting Logs

An activation folder is what Hamtrax exports as one log file, so cutting a session in half at midnight would hand POTA two files where they want one. Splitting also never affected your credit either way — POTA scores from the timestamps in the log, not from how your folders are arranged.

Folders still merge the way POTA counts activations:

"Multiple activities at the same park in the same state/province/entity and the same UTC day count as a single activation, provided that the ten or more QSOs combined were made."

— POTA Rules

One case still splits at midnight

If a file's contacts run through 0000 UTC and there is no matching activation already in your logbook, they land in one folder per UTC day. There is no recorded session for them to rejoin, and Hamtrax won't guess where one session ended and the next began. POTA permits either shape, so Hamtrax takes the honest one rather than inventing a session boundary.

When an imported contact is missing coordinates, Hamtrax fills them from known park and callsign data where it can. POTA park coordinates always win over callsign coordinates for both the operator side and the contacted-station side, so maps use the actual park location for POTA contacts.

Duplicates are skipped for you​

Hamtrax won't add the same contact twice. It skips:

  • Duplicates within the selected source — repeated rows collapse to one.

  • Contacts already in your logbook — matched on callsign, date, time, band, mode, and both program-qualified references.

  • Repeat hunts within the same program — a hunted contact is kept just once per activator, per program-normalized reference, per UTC day. On the day-level programs the QSO time is ignored entirely: logs from different apps often disagree on the exact time, so this catches the same hunt logged twice a few hours apart. The contact's resolved program is part of the identity, so an explicit record under another program remains separate even when its reference text matches. Contacts from your own activations (park-to-park) are never collapsed this way.

    How far that goes is each program's own rule, because the programs score differently. POTA counts one contact per park per UTC day no matter the band or mode, so a second one is a duplicate. DXCC credit is counted per band and per mode, so working the same country on 20m and again on 40m is two separate achievements — Hamtrax keeps both, and only collapses a DX contact when the activator, entity, UTC day, band, and mode all match. Repeaters go one step further and count every QSO: chatting through the same repeater three times in an afternoon is three real contacts, so only an identical re-log — same station, same repeater, same day, band, mode, and time — is treated as a duplicate. In practice that means re-importing a file is still safe, while nothing you genuinely worked twice is thrown away.

Because of this, re-importing the same file or QRZ Logbook is safe — nothing gets added a second time. Import a growing source as often as you like; only the genuinely new contacts come in.

Every record is accounted for​

Nothing is dropped silently. The final Summary accounts for each record in the selected source:

  • Unreadable — stopped during parsing because a required value is missing or structurally invalid. The source summary shows N unreadable with a Show unreadable records disclosure and the reason for each. Only records that produced no contact are counted: a record Hamtrax recovered and imported anyway is listed there as a note, but never counted as unreadable. The count beside the heading is always the true total.
  • To import — ready to be filed into its reviewed folder when you confirm.
  • Duplicate — skipped as a repeat (in the selected source or already in your log).
  • Rejected — parsed successfully but can't be routed or saved without breaking a logbook guardrail. This is decided before anything is written, which is why you see it in the review rather than after.
  • Excluded — anything you removed yourself (below).

Skipped contacts that share the same reason are listed together on one line, naming the first few callsigns with and N more standing in for the rest, so a file with two hundred duplicates is a handful of readable lines rather than two hundred copies of one sentence. The count beside the reason is always the true total. Reasons only group when they are genuinely identical — "already hunted at US-0001" never merges with the same sentence about a different park.

Once you confirm, the finish screen splits what you sent into what your logbook has actually answered for:

  • Filed — accepted by your logbook. It's there on every device you sign in on.
  • Still filing — written on this device and queued, with the answer still on its way. Filing carries on in the background; you can leave the page, and anything that turns out to be refused shows up under Needs Filing.
  • Refused — sent, and your logbook wouldn't take it where it was headed. The finish screen uses the same contact identity, plain explanation, and outcome as Needs Filing. It is a read-only summary; actionable rows direct you to the Logbook's one recovery flow. If the destination folder was the thing that was refused, the contact says so by name instead of quoting a rule about a folder that doesn't exist.

The counts reflect what your logbook accepted, not the raw number of rows returned by the source — and not the number Hamtrax managed to write on this device, which is a different and much easier question. A contact only counts as filed once the cloud has said so.

Only the counts that have something to say are shown. A number at zero is left off the finish screen, so a clean import reads as a single filed tile instead of one real number beside four zeros. Filed always appears, even at zero, because it is the question the screen exists to answer — and a count above zero is never hidden, which is the same rule the Review header follows. Records the file was unable to yield at all stay visible here as unreadable, so a ten-row file that filed six still tells you what happened to the other four.

Excluding contacts before you confirm​

While reviewing a destination, click the ✕ on any contact to leave it out of this import. Changed your mind? Restore it — nothing is committed until you confirm on the Finalize step. This is an include/exclude choice only; it never moves a contact to a different folder. Long folder lists load 200 contacts at a time when expanded, with a Show 200 more contacts control until every row is available.

info

Saving new contacts requires a callsign on your account (imported contacts carry your callsign for folder naming and export). If yours isn't set, Hamtrax asks for it as soon as your file is read, over the Review screen — and takes it right there. Your file already names its operator on every record, so the prompt usually arrives with that callsign filled in and reads "Is this your callsign?"; confirm it and you carry on with your file, your routing, and your review choices intact. It runs the same callbook check as Settings, so only a confirmed callsign saves, and saving one re-routes the plan — activation folders are named from your account callsign. Add it in Settings instead is still there if the callbook genuinely can't find you. A duplicate-only QRZ finish only reconciles remote IDs, so it does not need a callsign.

The folder guardrails always decide

Every protected placement is checked while Hamtrax builds the plan, checked again against the real folder before execution, checked a third time by the batch-write door that protects normal logging, and checked a fourth time by your logbook in the cloud — the only one of the four that judges the folder your account actually holds rather than the one this device worked out. A contact that fails any of the first three appears under Can't be imported; one the cloud turns away appears under Refused by the cloud on the finish screen and under Needs Filing in your Logbook. Neither is ever rerouted into a less-protected folder just to make the import succeed.

[SCREENSHOT: General import Review step showing one folder category, its destination cards, and the Back / next-stage controls; companion screenshot of the final Summary with its tiles — only the non-zero ones appear, plus filed — the Refused by the cloud section, the duplicates explainer line, and the grouped skip reasons, where contacts skipped for the identical reason share one line naming the first few callsigns plus "and N more" (exact re-import vs. a program-voiced hunt duplicate — POTA naming the park reference and UTC day, DX naming the band, mode, and UTC day; an identical repeater re-log is already an exact re-import, so it shows the neutral "same UTC day, time, band, mode & references" reason rather than a Repeaters-voiced one)]

Importing a single past activation​

There is no separate activation importer. Tap Import a past activation on Activate, or Import beneath Logbook → Parks on the Air → Activations; both shortcuts open Import Contacts.

Choose Import from file, upload the ADIF or CSV, and review the destinations Hamtrax derives from the file. For POTA contacts to land in an activation folder, the source must carry valid operator-side POTA activity identity, including the park reference. Hamtrax does not ask you to invent or overwrite a missing park during import: missing, invalid, or ambiguous identity stays visible in Review and is never silently re-tagged.

An imported activation arrives finished, not live. When a matching recorded activation already exists, its span can keep a session together through 0000 UTC. Without one, contacts are organized into activation folders by UTC day.

Re-importing is safe: the same guarded duplicate checks used for every other import skip contacts already in your logbook.

Validation and warnings​

The importer is conservative — bad records are dropped or normalized at parse time so they don't pollute your log. Failures appear as unreadable records with a reason. For a CSV you get the physical line number — Row 12 is line 12 of the file, the row your spreadsheet shows — which stays correct even when the header is not on the first line. ADIF records are not line-bound, so those are numbered one-based as Record 1, Record 2, and so on.

What gets dropped or normalized:

  • Missing required fields — every record needs CALL, QSO_DATE, and TIME_ON.
  • Invalid date — the QSO_DATE must be a real YYYYMMDD between 1900-01-01 and one year from today. Feb 30, 99999999, year 1776, etc. are marked unreadable before routing.
  • Invalid time — TIME_ON / TIME_OFF must have hours < 24, minutes < 60, seconds < 60. A typo like 250000 is marked unreadable instead of becoming "25:00".
  • Garbled callsign — the instant structural check requires 3–15 characters, only letters, digits, and /, at least one letter and one digit, no empty or repeated-slash segments, no more than four slash-delimited segments, and at least one segment that mixes letters and digits (the base call). This is a fast shape check, not a live callsign-directory lookup.
  • Oversized field or cloud command — an ADIF field that declares a length larger than 64 KB makes the parser skip that whole record, not just the field, because a bogus length prefix means the record's boundaries can no longer be trusted. Parsing resumes at the next <EOR>, so every remaining record in the file is still imported normally. Cloud acceptance then applies the authoritative contact-command bounds: the normalized command must fit within 64 KiB, preserved unknown ADIF data may contain at most 256 fields, field names may be at most 64 characters, and each preserved value may be at most 8,192 characters. These are separate checks: parser acceptance does not promise that an arbitrarily large record can be stored.
  • Frequency out of range — anything ≤ 0 or ≥ 300,000 MHz is normalized to 0 (the BAND field, if present, is still used).

Offline imports​

ADIF and CSV imports work without an internet connection. QRZ import requires a connection while the remote contacts are fetched. Once a plan is confirmed, contacts are saved to your local database and accepted folder assignments sync to the cloud when you reconnect.

Offline there is nothing for your logbook to answer yet, so the finish screen counts every contact as still filing rather than claiming an import that hasn't happened. The same is true of a very large import that is still draining when the summary appears: what's written is written, and the number simply tells you the truth about how far the cloud has got.

If the cloud permanently rejects an imported contact after reconnecting, Hamtrax shows a warning notification (once for the batch, not once per row) and keeps the original command plus saved reason category on that browser or device under Logbook → Needs Filing. The shared review row turns that category into plain language and never displays an internal contact id or raw server message. Only a new contact classified as a folder-hygiene rejection offers Choose folder and an explicit destination in the Logbook; any other permanent imported-create rejection remains review-only. A filing attempt leaves the original marked Saving corrected contact until the cloud accepts the replacement, and the item is not cloud-backed or available on another device before then.

An oversized command is never silently counted as cloud-saved: it remains accounted for on the originating device with its rejection, but it is not available on another device unless a valid replacement is accepted.

Large files (10,000+ QSOs) parse in a few seconds. Destination cards render contacts in user-requested chunks of 200; the full valid set is still queued. Because browser imports, CLI logging, and automatic imports share the account's cloud work budget, an unusually large import may pause at a UTC reset and continue afterward. The exact idempotent rows stay on the originating device and resume without being duplicated.

Getting-started checklist

A user-initiated import completes Import contacts when at least one new contact is added. A duplicate-only import does not complete it, and the automatic public POTA starter import that may run after signup does not count as this hands-on setup step.