Skip to main content
POST
Run a table's search again

Authorizations

X-API-Key
string
header
required

Path Parameters

table_id
string<uuid>
required

Query Parameters

max_new_rows
integer | null

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.

Required range: x >= 1

Response

Successful Response

What one re-run of a table's search changed.

rows_created
integer
required

Rows the request itself added.

total_matched
integer
required
import_status
enum<string>
default:success

running when the request added a first batch and the rest is still being added in the background, so poll the table's search runs for progress; success when every row is in.

Available options:
running,
success,
failed
people_skipped
integer
default:0

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_not_added
RowsNotAddedSchema · object | null

The people the search found that are not rows, and why, once every row is in: found_twice when the people search holds one person under two records, so a new table took them once; already_in_table when a person found was already a row of the table. Null when every person found was added, or while rows are still being added.

rows_wanted
integer
default:0

Rows the import set out to add in all.

run_id
string<uuid> | null

The run row recording this import, when the search is persisted.

skip_limit_reached
boolean
default:false

Whether the search stopped looking after skipping as many people as one search may, so fewer rows may be added than asked for.