Bring the leads from your previous CRM or tracker across as a CSV — which columns are needed, what happens to the rest, and why imported leads are never sent to an advertiser.
Settings → Import takes a CSV export from whatever you ran before d0pe and writes those leads in as history. They are searchable, they appear in the dashboard and reports, and they carry a flag that keeps “the approve rate we inherited” separable from “our approve rate”.
Imported leads are never delivered. The importer does not touch the routing engine at all, so a file of 40,000 old leads cannot become 40,000 API calls to an advertiser. This is how the code is built, not a switch you have to remember to set.
A phone or an email. One of the two, per row. Without either there is nothing to identify the lead by and nothing to match it against on a re-run, so the row is rejected. Everything else is optional.
That means a minimal file works: email, phone, first name, last name, country, type. No dates, no partner ids, no status column.
Any column d0pe does not recognise is kept on the lead as a free parameter rather than dropped. Sub ids and tracker params are often the only link back to the campaign that produced a lead, so nothing is thrown away.
CSV or TSV, first row naming the columns. The separator is detected from the file — comma, semicolon, tab or pipe all work, so an Excel export from a European locale needs no editing. UTF-8, Windows-1251 and Latin-1 are all read, and the byte-order mark Excel writes is stripped.
03/04/2026 is the 3rd of April or the 4th of March depending on who exported it, and no amount of cleverness can tell which. So the importer asks: day first, month first, or ISO. Pick wrong and the dry run will show dates that look off — check before you commit.
ISO timestamps are read as ISO whatever you picked, since they are unambiguous. A timestamp carrying a UTC offset is converted to your instance's timezone.
If a row is marked as a depositor but has no deposit date, the deposit is dated to the lead's registration date. That keeps the conversion in the same period as the lead, so cohort and per-month reports stay coherent — rather than piling every historical conversion onto the day you ran the import.
Rows are matched against what the CRM already holds — partner lead id first, then phone, then email. A row that matches is skipped and counted as a duplicate. So if an import fails halfway, or you are not sure whether a file went in, upload it again: only what is missing gets written.
Before anything is written you see exactly what will happen: how many leads will be created, how many are already here, how many rows were rejected and why — with line numbers — and the date range the file covers. Those numbers come from the same code that does the writing, so they are not an estimate.
If your instance deletes leads older than a set number of days (Settings → retention), the dry run tells you how many imported rows fall outside that window. They would be removed by the next cleanup, within the hour. Raise or switch off retention first if you want to keep that history — the importer will not quietly exempt rows from a rule you set on purpose.