> For the complete documentation index, see [llms.txt](https://developer.parvenu.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.parvenu.io/enrichments/normalize-contact-names/list-lookup.md).

# List Lookup

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

<mark style="color:green;">`POST`</mark> `/normalize_contact_names_list`

{% hint style="info" %}
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.
{% endhint %}

{% hint style="warning" %}
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.
{% endhint %}

**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](/manage-lists/list-saved-views.md).

**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.              |

{% hint style="info" %}
`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.
{% endhint %}

**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**

{% tabs %}
{% tab title="Input" %}

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

{% endtab %}

{% tab title="Output" %}

```json
{
  "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
}
```

{% endtab %}
{% endtabs %}

{% hint style="info" %}
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.
{% endhint %}

**Retrieving results**

* [Check List Status](/get-enrichment-results/check-list-status.md)
* [Download List Data](/get-enrichment-results/download-list-data.md)