What it does in the flow
This is another door into step 1, lead in — parallel to the API, not a lesser version of it. Upload a file in the dashboard's Import section, map your file's headers to lead2inbound's canonical fields (phone, name, state, consent evidence, custom fields), and every row runs through the exact same normalization, dedupe, and consent/DNC checks as a lead posted via the API. The result is a per-row report: imported and eligible, imported but ineligible (with a reason), or held back as a duplicate.
How it works
- Export your leads to CSV from wherever they live today (spreadsheet, CRM, ping-post platform).
- In app.lead2inbound.com → Import, upload the file. The dashboard reads your header row and proposes a mapping.
- Confirm which column is
phone(required), and map whatever else you have — name, state, zip, consent timestamp/version/source URL, custom fields. - Run the import. You get a row-level report: how many landed as new eligible leads, how many were marked
ineligible(most commonlymissing_consent), and how many matched an existing lead from the last 30 days and were skipped as duplicates.
ineligible — the same rule the public API enforces on a single POST. The report tells you exactly which rows to go fix at the source.FAQ
What columns does the importer expect?
Only a phone column is required. Everything else — name, state, zip, consent fields, custom fields — is optional and mapped visually; nothing has to match our field names exactly.
Will re-importing the same file create duplicates?
No. The same 30-day phone-based dedupe that guards the API guards CSV import, so re-uploading a file (or importing overlapping exports from two vendors) won't double-queue the same lead.
Can I import leads without consent evidence to review them first?
Yes — they're still stored and visible in the dashboard, just flagged ineligible and excluded from dialing until you either add consent evidence or accept they can't be called.