Skip to main content

Importing Contacts

Hamtrax uses one interactive Import Contacts workflow for files and connected logbooks. On a normal launch, its first screen keeps the decision to three choices: Import from file, Import from connection, or Migrate from your logger. Import from QRZ on the connected QRZ page skips those two selections and starts that same workflow with QRZ already selected.

  • 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 Migrate from your logger when you need that logger's 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 custom folders. For contacts that need a custom destination, Hamtrax suggests useful groupings from clues in your import for you to review.

Getting to the importer​

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

  1. Import in the sidebar — its own row at the top, just under the search field, which opens this page in one tap.
  2. Logbook → Import Contacts — the button above the Contact Folders heading.
  3. Activate → Import a past activation.
  4. Logbook → Parks on the Air → Activations → Import.
  5. QRZ connection page → Import from QRZ — opens this importer with QRZ already selected and starts the fetch immediately.

All five open the same importer. The QRZ shortcut begins retrieval immediately; it does not skip Review or Finalize, and nothing is saved automatically.

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.

Local ADIF and CSV files have a 64 MiB safety ceiling. Hamtrax checks the file size before reading it into browser memory, so an unexpectedly huge or hostile file stops with a clear error instead of freezing the tab. Within an accepted file, any individual QSO field over 5,000 characters is skipped with its record so the contact can pass the same storage boundary enforced by the cloud. Leading Ham2K PoLo APP_HAM2K_* operation events are not QSO fields and are ignored before that check.

CSV imports also retain CONTEST_ID, SAT_NAME, SAT_MODE, PROP_MODE, and SUBMODE when present, keeping those details available for review and custom-folder suggestions.

Export from another logger​

Choose Migrate from your logger, 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 Import from connection screen contains the two services backed by production connections: QRZ Logbook imports contacts, while Logbook of The World manages confirmation sync for contacts already in Hamtrax. LoTW does not import historical contacts, and a logger that requires a file stays under Migrate from your logger rather than appearing as a connected service.

When you open either connection page from Import Contacts, its Back button returns here. When you open it from Settings — or load its URL directly — Back returns to Settings → Integrations.

Import directly from QRZ​

Start from either place:

  • From the connected QRZ page, select Import from QRZ. Hamtrax opens Import Contacts and begins retrieval without asking you to choose a method or provider again.
  • From Import Contacts, choose Import from connection to see QRZ Logbook. If its card says Connect, open the dedicated page and add the API key; once connected, you can use either page's import action.

Hamtrax fetches the logbook in pages through its authenticated server gateway; your browser never contacts QRZ directly. Then walk through the same guided Activations → Hunting → Custom → Summary review used for file imports—empty folder stages are skipped automatically—and 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.

Sync confirmations from LoTW​

Choose Import from connection → Logbook of The World to open its dedicated connection page. LoTW credentials are encrypted in a local vault with your passphrase. When you explicitly sync, Hamtrax sends them over an encrypted connection to its authenticated gateway, which requests a read-only LoTW confirmation report and does not retain the credentials server-side.

Hamtrax matches each confirmation to an existing contact by callsign, UTC date and minute, band, mode or submode, and station callsign when LoTW supplies it. A confirmation cannot be reused for a second local row. Any confirmation with no exact local match is kept on that device and retried during later syncs, while the LoTW cursor continues forward. LoTW uploads remain a separate TQSL workflow; see Exporting Contacts.

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 with a transactional per-callsign claim, so two devices cannot import the same profile at once. A successful import is final; if POTA returned no profile or no public rows, Hamtrax may retry after seven days on a later app open instead of treating that temporary empty response as permanent. Accepted contacts appear automatically while Hamtrax is open and connected; you can keep using the app while the import runs.

The three steps​

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

  1. Select. A normal launch starts with Import from file, Import from connection, or Migrate from your logger. Only that choice's controls appear next. The connected QRZ page's Import from QRZ shortcut preselects QRZ and begins this step immediately. 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. Use Next: … to inspect each category, or Review and accept all to keep the current destinations and jump straight to Summary. Optional custom-folder suggestions apply only when you choose Use suggestion. The shortcut does not accept unused suggestions or save anything; contacts are written only after you confirm in Finalize. 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, refused by the cloud, and failed before filing are separate outcomes.

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?​

Every question below compares the record against the copy of your logbook on this device, so Hamtrax proves that copy is complete before the stage runs. A device that has never finished loading your logbook from the cloud — a brand-new browser or phone, or one whose site data was cleared — would answer "no match" to all of them and let a whole file back in as new contacts. So Hamtrax loads your logbook first, and when it still can't confirm it has all of it the import stops before Review: "This device has not finished loading your logbook, so duplicates cannot be checked yet. Check your connection, then retry." Your parsed file is kept, and Retry picks the run back up. The same proof is required again at Finalize, so losing it mid-import gets the same message rather than a second copy of your log. A device that has loaded your logbook before never sees this, online or offline.

③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 the need for custom review 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.

Contextual custom-folder suggestions​

In the Custom stage, Hamtrax looks for explicit clues and shared patterns in the contacts that no installed program claimed. Each suggestion shows a proposed folder name, the number of matching contacts, and the reason for the proposed grouping. Edit the proposed name if needed, then choose Use suggestion. Choose Undo to change an accepted name or restore the usual custom-folder choices for its contacts. An unused suggestion never changes a contact's destination.

Clues include a recorded contest ID grouped by year, a satellite name, an activity program Hamtrax does not run itself, or a propagation mode. A program such as SOTA, WWFF, or IOTA becomes one suggestion for the summits or references you chased (THEIR SOTA) and another for the ones you activated (MY SOTA), each gathering the contacts tagged for it, so a lifetime of one-off references is not split into folders too small to offer. When every contact for a program names the same reference, that reference stays in the folder name — MY WWFF · KFF-0001. A reference recorded with no program code is still offered on its own. Weaker patterns need contacts with at least three distinct callsigns: a shared named net in the notes, the same portable station and operator location on one UTC day, or a shared band and mode. Explicit clues take priority over these broader patterns.

Hamtrax shows up to eight suggestions, computed locally from the current import without extra service lookups. Native activation and Hunting routes, duplicates, and rejected contacts stay outside this step. A contact appears in at most one suggestion, so accepting multiple suggestions cannot file it twice. If the suggested name matches an existing custom folder, the review tells you that those contacts will be added to it.

Contacts outside the suggestions you accept keep the usual organization choices. When you already have custom folders, choose New folder or Existing folder and pick the destination. You can also split the remaining contacts by month, year, band, or mode. The destination cards show New folder or Existing folder before you finalize.

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.
    • 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. A DXCC value must be a complete integer that names a current ADIF entity: partial values such as 9A, scientific notation, zero, and unknown entity numbers are ignored rather than half-read into the wrong country. 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 → custom-folder review. The original fields stay unchanged; Hamtrax never guesses a program or re-tags SOTA or WWFF as POTA. Review offers contextual suggestions when the import contains useful clues. You choose which suggestions to use and how to file the remaining contacts: one existing or newly named custom folder, or a 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. Protected destinations are fixed during Review: 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 data already on your device — the POTA park catalog first, then the callsign data Hamtrax keeps locally. 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. A contact that already carries a grid square is left as it is, because a grid square is enough on its own — maps, shared maps, and QSL cards turn it into a point when they draw, and an export carries it through as a grid square.

Nothing in this step goes out to the internet to look a callsign up, so filling in locations never holds up a large file. The trade is worth knowing: a station the local callsign data doesn't list — most stations outside the US, and very new licensees — is stored without coordinates of its own unless its record carried a grid square. Nothing else about the contact changes. It files into the same folder and exports exactly the same, and your own side of the QSO is still placed from the park you activated, the folder it landed in, or your profile location; the contact simply has no pin of its own on the map until something can say where it was.

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.

All of that reads the copy of your logbook on this device. On a device that has never finished loading it, Hamtrax stops the import and asks you to connect and retry rather than reading an empty copy as an empty logbook — see ② Duplicates.

Every record is accounted for​

Nothing is dropped silently. The final Summary accounts for each QSO record in the selected source. PoLo operation and timeline events are metadata rather than contacts, so they are intentionally excluded from contact totals:

  • To import — ready to be filed into its reviewed folder when you confirm.
  • Unreadable — stopped during parsing because a required value is missing or structurally invalid. The source summary shows N unreadable with a Show parse notes 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.
  • 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 keep logging contacts by hand while it does, 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. A folder that merely hasn't answered yet doesn't refuse anything: its contacts stay still filing until it does.
  • Failed before filing — the local save or its durable sync command failed, so the contact was not sent to the cloud. Hamtrax rolls back a local row whose command could not be queued and lists the exact contact separately; it never calls that a cloud refusal.

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, and Review and accept all 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 or malformed field — an ADIF or CSV field inside a QSO over 5,000 characters makes the parser skip that whole record, matching the cloud's scalar-string boundary before the contact reaches the save queue. Leading PoLo APP_HAM2K_* operation events are ignored as non-QSO metadata before this limit, so even a large event cannot contaminate or swallow the contact after it. For other ADIF fields, parsing resumes at the next <EOR> because a bogus length prefix makes the current record's boundaries untrustworthy. For CSV, a closed oversized field is skipped without losing later rows; an unclosed quoted field is reported as unreadable instead of being silently folded into a contact. Cloud acceptance separately caps the full normalized command at 64 KiB and preserved unknown ADIF data at 256 fields with 64-character names. Parser acceptance still 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 on a device that has already loaded your logbook at least once — skipping duplicates means comparing your file against that local copy, so Hamtrax needs a complete one before it can plan. On a device that has never finished loading it, an offline import stops before Review and asks you to connect and Retry; see ② Duplicates. 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. Filing sends both folders and contacts to your logbook in groups rather than one at a time, which makes a large import file many times faster, and it hands the logbook back between groups so a contact you add by hand never waits for the import to end. A file spanning years of activating and hunting can need well over a hundred folders; those are created on your device in one pass and then sent up together, so Creating folders passes in seconds instead of a round trip apiece. The Logbook's folder tree takes those new folders in one pass as well and then holds still while contacts file into them, instead of redrawing itself over and over behind the finish screen. 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.