Skip to main content
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 using its supported supplier value and row format. Inspect rejected rows and keep the run identifier. Read get_discovery_run, then page through list_discovery_candidates. For a local CSV with an authorized checkout or supplied toolkit:
Replace the path, file and target with your own values. The ledger guide 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 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 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 with status: "active". This can make a check due immediately. Follow monitoring changes; do not resume a watch merely because a verification request was replayed.

​
Verify fifty selected candidates

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.
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 with runId, items and an idempotencyKey.
  3. Save the batch identifier and per-item outcomes, including budget rejections. Read get_candidate_verification_batch until the jobs finish.
  4. For a completed present result, 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 and troubleshooting before retrying an unavailable operation.