List Lookup

Repair the contact names on every row of a Parvenu list. Asynchronous, free, writes in place.

POST /normalize_contact_names_list

This is an asynchronous endpoint. It returns a job acknowledgement, not data. Poll /check_list_status until the list reports done, then fetch the rows with /download_list. Free: nothing is charged.

This writes in place, over person_name, first_name and last_name. A cleaned name in a new column would never reach Smartlead, Aimfox or HubSpot, which all map the existing fields, so those are the fields it has to fix.

The original is preserved in person_name_raw, which is also what a re-run reads from. Later improvements to the rules therefore reach rows already processed, and the original is never lost.

Headers

Name	Value
Content-Type	application/json

Body

Name	Type	Description
api_key	string	Your API Key.
listname	string	Name of the existing Parvenu list to repair.
processing_mode	string	Optional. blank_only (default), all, or first_10. See below: it does not mean quite what it means elsewhere.
view	string	Optional. Which rows of the list to process. all (default) processes every contact in the list; verified restricts the run to contacts whose email address is verified.
saved_view	string	Optional. Name of a saved view on this list. Runs only on the contacts in that view. Don't combine with view, filter_stack or search.

Saved views. To run only on the contacts in a saved view, send its name as saved_view. See List Saved Views.

Processing modes

Value	Behaviour
blank_only	Default. Rows never normalized before: the raw backup is still empty. This does not mean "the name column is empty".
all	Re-processes every row, re-reading each from its raw backup, so improvements to the rules reach rows already done.
first_10	The first 10 rows only. Use it to see what the rules do to your data before turning them loose on a whole list.

blank_only is worth reading twice. Because the job writes in place, no name column is ever empty after the first run, so the usual reading of blank_only would make every later run a no-op. It means "not yet normalized", and the raw backup is what answers that.

Rows that are skipped

A row with no LinkedIn profile URL is skipped. Two people share a name far more often than they share a profile URL, and renaming the wrong person is worse than skipping them.

Every row gets a line in its log, including the ones nothing changed on, saying what was done and why.

Example

Input

{
  "api_key": "your_api_key",
  "listname": "my_list",
  "processing_mode": "first_10"
}

Output

{
  "success": true,
  "job_id": "a1b2c3d4e5f6",
  "status": "queued",
  "list_name": "my_list",
  "rows_selected": 50,
  "rows_fetched": 50,
  "message": "Normalize contact names (filtered) started",
  "view": "all",
  "max_rows": 5000,
  "credits_estimated": 0,
  "truncated": false,
  "credits_used": 0
}

Start with "processing_mode": "first_10" and read the results. The failure worth checking for is not a name left broken. It is a name that was already right being changed.

Retrieving results

• Check List Status

• Download List Data