---
title: "Run a table's search again"
method: POST
path: "/find-leads/tables/{table_id}/search/run/"
tags: ["find-leads"]
---

# Run a table's search again

`POST /find-leads/tables/{table_id}/search/run/`

## Request

- Base URL: `https://api.getoneprofile.ai` (the document declares no server; this is the origin it was published from)
- URL: `https://api.getoneprofile.ai/find-leads/tables/{table_id}/search/run/`
- Auth: one of:
  - API key in header `X-API-Key`
  - HTTP bearer

Re-run the persisted search into the same table. Existing rows are matched on the provider's identifier and update in place; only genuinely new matches add rows. A search saved under filters this API no longer accepts answers 422 against `query`: open it, fix the filters, and save it again.

## Path parameters

- `table_id` string, uuid, required

## Query parameters

- `max_new_rows` integer, nullable: The most rows this run may add, and so charge for, however many new matches it finds. Leave it out to add every new match within the search's row limit.

## Response `200`

Successful Response

- LeadSearchRunResponseSchema: What one re-run of a table's search changed.
  - `import_status` 'running' | 'success' | 'failed': Where one run of a table's search stands. ``running`` while rows are still being added, then ``success`` or ``failed``.
  - `people_skipped` integer: People the request left out because another of the workspace's tables already has them. A run that continues in the background goes on skipping them.
  - `provider_notices` string[]: What the data source said about the rows the request added, in the words to show beside them; see the create response. A run that continues in the background can add more, and the table's search runs carry every one.
  - `rows_created` integer, required: Rows the request itself added.
  - `rows_not_added` RowsNotAddedSchema: People a search found that did not become rows, and why.
    - `count` integer, required: How many people were found and not added.
    - `reason` 'found_twice' | 'already_in_table', required: Why people an import found are not all rows in the table. ``found_twice``: a new table, where the index held the same person under two records (one profile, two ids), so the second copy found the first. ``already_in_table``: an import into a table that already had rows, where a person found was already one of them (and so was refreshed, not added).
  - `rows_wanted` integer: Rows the import set out to add in all.
  - `run_id` string, uuid, nullable: The run row recording this import, when the search is persisted.
  - `skip_limit_reached` boolean: Whether the search stopped looking after skipping as many people as one search may, so fewer rows may be added than asked for.
  - `total_matched` integer, required

## Other responses

- `401`: Unauthorized
- `402`: Not enough credits to add the rows this would land.
- `403`: Forbidden
- `404`: This table has no lead search.
- `422`: Invalid request made to the API.
- `500`: Internal server error.
- `502`: The lead database refused the query.
- `503`: Service unavailable.

---

[API](https://skmtc.dev/getoneprofile/apis/api-reference-oneprofile.md) · [All operations](https://skmtc.dev/getoneprofile/apis/api-reference-oneprofile/llms.txt) · [OpenAPI document](https://skmtc.dev/getoneprofile/apis/api-reference-oneprofile/revisions/4a6bd71e3f02?raw)