Skip to main content
Start with the publisher page and the target it should link to. Hosted checks need an accessible project and check allowance.

​
Choose a one-time check or recurring monitoring

For one check without a hosted watch, use the public browser checker or local CLI check. Continue below only when you want a saved watch with recurring checks. Review its schedule and allowance first. In the app, follow Add link. Use agentlinkops-connect for a supplied placement. Provide the publisher page, your destination and the required target scope. The placement workflow checks the selected website, schedule and allowance before any authorized save, then follows the initial job and returns its dated observation, reason and uncertainty.

​
Create and check the watch

  1. Call list_projects and choose the project.
  2. Call monitor_link with its projectId, your source and target URLs, and the target scope. Save the returned watch identifier. Identical placements are deduplicated.
  3. Read initial_check and check_operation in the response. Creating the watch can already start its first check. If it returned a job identifier, follow that job with get_check_job; do not request a second check. If the initial check was not_queued, read its reason and resolve it before continuing.
  4. Use request_check only when an existing watch needs a deliberate fresh check. Pass subject: "link", subjectId set to the watch identifier, and an idempotency value unique to that intended check. Save its job identifier and read get_check_job until it reaches a terminal state. Respect retry guidance and avoid tight polling.
  5. Read get_history with subject: "link" and the same subjectId for dated observations. Use the observation identifier to locate occurrences or retrieve retained evidence with subject: "link" and observationId.
The reference pages contain exact requests for MCP, CLI and HTTP. Admission to the queue reserves work; it does not prove the link is present. If the network fails after submission, retry the same arguments and idempotency value to recover the same request.

​
Decide what the observation supports

A completed job can yield unknown. Read the observation’s reason separately from the job state. One absent observation describes that fetch; confirmed loss requires two complete absent observations at least thirty minutes apart. Unknown attempts preserve uncertainty. A source link and destination health answer different questions. To check the destination independently, use monitor_target and its check job flow. Keep the watch active for later changes, or pause it with update_link_watch. If raw evidence has expired, keep the dated observation metadata and request a new check when needed. A new check cannot recreate the historical page. See evidence and troubleshooting. If a publisher reported the placement through your sender, use CRM and sender handoff to retain the reply beside the dated link observation.