> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentlinkops.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Import and verify backlink candidates

> Import a backlink export, inspect its candidates, verify selected rows and read dated results. Review the separate preview for batch checks and monitoring.

Import a backlink export you already hold, then choose rows worth checking. Imported candidates retain supplier provenance and dates. An import does not establish current presence or recurring monitoring.

## Preserve and inspect the import

Call [import\_backlinks](/reference/commands/import_backlinks) using its supported supplier value and row format. Inspect rejected rows and keep the run identifier. Read [get\_discovery\_run](/reference/commands/get_discovery_run), then page through [list\_discovery\_candidates](/reference/commands/list_discovery_candidates).

For a local CSV with an authorized checkout or supplied toolkit:

```bash theme={null}
agentlinkops import ahrefs.csv \
  --from ahrefs --target example.com
```

Replace the path, file and target with your own values. The [ledger guide](/ledger) explains local candidate files. A local import does not create a hosted discovery run.

## Verify selected candidates

1. Choose a stored candidate and retain its run and candidate identifiers.
2. Call [verify\_discovery\_candidate](/reference/commands/verify_discovery_candidate) with its documented inputs and a stable idempotency value for this check.
3. Save the returned `job_id` and `watch_id`. Read [get\_candidate\_verification](/reference/commands/get_candidate_verification) until the job finishes, following returned retry guidance.
4. Read the observation's state, reason and timestamp. A successful job can return `present`, `absent` or `unknown` evidence. If the job failed without an observation, keep its error and do not invent a result.

Repeat for the selected rows within your available check allowance. After a lost response, preserve the same request and idempotency value. Keep rejected and unknown results for review.

## Start monitoring deliberately

A single-candidate check returns a watch but creates no recurring monitoring. Read its current status: a new watch starts paused, and an existing watch retains its status.

To start recurring checks deliberately, confirm the project, URLs and cadence, then use [update\_link\_watch](/reference/commands/update_link_watch) with `status: "active"`. This can make a check due immediately. Follow [monitoring changes](/guides/monitor-changes); do not resume a watch merely because a verification request was replayed.

## Verify fifty selected candidates

<Note>
  Batch verification and explicit candidate enrollment remain development previews. They need their matching hosted release and database migrations. Use the single-candidate workflow above on the current pilot.
</Note>

In a matching development environment:

1. Select one to fifty stored candidates from the same run, with actual identifiers and optional local references.
2. Call [verify\_discovery\_candidates](/reference/commands/verify_discovery_candidates) with `runId`, `items` and an `idempotencyKey`.
3. Save the batch identifier and per-item outcomes, including budget rejections. Read [get\_candidate\_verification\_batch](/reference/commands/get_candidate_verification_batch) until the jobs finish.
4. For a completed present result, [monitor\_discovery\_candidate](/reference/commands/monitor_discovery_candidate) preserves the candidate's lineage and local reference. Replay does not reactivate a watch someone later paused.

Replay a lost batch response with the same payload and idempotency value. A different selection needs a new value. Read [availability](/capability-status) and [troubleshooting](/guides/troubleshooting) before retrying an unavailable operation.