What connects to AgentLinkOps, and how.

Five different things

Hosted access behind every class is invitation-only. Reading this page, the backlink tools by workflow or the agent brief creates no account and starts no monitoring.

1. File imports

An import reads rows from a file you already own. Eight presets know the column names that Ahrefs, Semrush, Majestic, Moz, DataForSEO, Linkody and Search Console write, and the eighth is a generic CSV with no assumed columns. A preset only supplies defaults; every import can be driven by an explicit column map, so a renamed column is fixed with one flag rather than a release. When detection fails, the tool prints the header row it saw and the exact map that would fix it.

Three rules hold for every preset. A preview writes nothing and reports each rejected row with its file line and reason. Coverage of an import is always partial, because nothing in an export says whether it is the whole result or page one of forty, and the import never claims otherwise. Columns the map does not claim, such as a supplier’s rating, travel with the row as supplier metrics and are never scored by the tool.

One layout is refused rather than imported. Search Console’s headline exports count links per site or per page of yours; they are not lists of linking pages. Reading one as rows would mean inventing a source URL for every line, and an invented URL is a link the checker would then fail to find and report as lost. The refusal names the export it saw and the one to use instead. The Search Console import reference shows the accepted layouts.

The same rows can be stored in the hosted service with import_backlinks, which needs the discovery:write scope, names the supplier in provenance, keeps supplier dates separate from any check, returns rejected rows by position, and answers a repeat of the same rows with the same run instead of duplicate candidates. Imported rows are candidates, not verified links, and are not enrolled in monitoring. What happens next is shown in the walkthrough, and the import formats index holds the eight references.

2. Agent clients over MCP

An MCP client connects to https://app.agentlinkops.com/mcp over streamable HTTP and approves the workspace connection in your browser. The connection carries the same authenticated command catalog as the HTTP API and the CLI; a client that connects sees the same tools with the same scopes. The agent setup guide has the exact commands, the copyable setup prompt and the recovery steps, and the docs site keeps the MCP connection guide in step with the deployed version.

Some combinations are not supported, and the guide says so rather than letting an agent guess: an MCP OAuth token used as a REST credential, a local stdio server, the anonymous free check through an authenticated connection, the repo-local context tools through any cloud endpoint, and any client that cannot reach the public internet. A separate local MCP host serves the repository context tools over stdio; it is a checkout feature, not a hosted connector.

3. The HTTP API and the CLI

If your tool is not an MCP client, the same service answers REST under https://app.agentlinkops.com/v1/ with a scoped API credential sent as a bearer header. GET /v1/commands returns the connected command catalog with input schemas and required scopes, and POST /v1/commands/<name> runs one command with its argument object as the body. The docs site publishes the OpenAPI document for those routes beside the HTTP connection guide.

The CLI is the third door to the same catalog: agentlinkops tools prints the command schemas and scopes, and agentlinkops call <name> runs one. The CLI also works with no account at all for local checks and the repository ledger; the CLI guide covers both modes and the compatibility aliases that still answer to the working name during the pilot.

As recorded for the production version deployed on September 15, 2026, the three doors share 73 authenticated commands, plus one anonymous free check on its own endpoint. The count comes from the registry the tool catalog is generated from, and it is stated here with its date because it changes with releases. Every command is checked against the credential’s scopes on every request:

A credential carries only scopes its owner holds, a member’s project grant is the ceiling on every credential they hold, and narrowing the member narrows their credentials at once. The ceilings, retention windows and deletion rules are on the access and data page.

4. Your CRM and sender, through the portable handoff

AgentLinkOps has no place to hold your prospects, your outreach history or your combined CRM, and it never connects to a mailbox. Relationships stay in your CRM; delivery, replies and suppression stay in your sender. Your agent prepares the campaign and writes into those tools with its own access. What AgentLinkOps supplies to that work is dated backlink evidence: published contact routes extracted from a saved page, with deliverability marked not_checked on every one, and observations of the placements you monitor.

The bridge between the two is a portable handoff: a document your agent composes locally and applies to the destination you choose. It is deliberately a document rather than a connector, because a CSV export, a vendor connection your agent already has and a hosted AgentLinkOps command have different capabilities, and a page that blurred them would be lying about one of them. No CRM or sender connection has been tested for the handoff, and AgentLinkOps sends nothing on its own. The CRM and sender handoff guide is the operating procedure; this section describes the artifact.

The handoff artifact, as exercised by the fixture in the next section, carries:

• An explicit mapping. Which handoff field lands in which destination field, named in the payload. Nothing is matched by guessing a column.
• Stable identifiers on every row. A local id, the destination’s own record id, the sender’s id where one exists, and the revision the row expects to find. A row whose revision has moved is not overwritten.
• Scope. The project and campaign the rows belong to, and a schema version.
• Receipts. Every apply is an operation with an id derived from the payload’s fingerprint. The receipt says unknown until the destination has committed, then names the ids it changed, the ids it left alone, whether effects are complete, and messages_sent: 0.
• Readback checkpoints. After a write, the destination is read back in pages under a cursor and a snapshot hash; the checkpoint records how many rows were accepted and whether the read completed.
• Restart safety. A process that exits before commit leaves the receipt at unknown; one that exits after commit resolves on the next receipt read; replaying the same payload returns the original receipt rather than a second write.

Two other doors into your own records already exist in the CLI and the service. agentlinkops adopt reads an existing SQLite CRM into ledger entries, read-only, previewing first and naming every status it treated as active. export_link_watches pages through every monitored placement for local CRM recovery, over MCP with the export scope or the REST export route, so nothing you monitored is held in a format only the workspace can read.

The research side of the same lane is owned by the campaign qualification work: candidates are qualified against templates with verdicts and no score, public contact routes are attached with their evidence, and the handoff record is checked at the boundary by a guard that refuses any field that would claim a message exists. It caught its own author’s subject line on its first run. The link building hub and the agent workflows hub describe that work in the reader’s terms.

A round trip, on a fixture

The outputs below are pasted from the recorded replay of the portable handoff fixture, run on September 14, 2026: 18 fresh processes, three of them killed on purpose, against a synthetic SQLite destination on reserved example hostnames. It is a fixture. No vendor was involved, no network request was made and no message was sent, and the replay record says all three.

The destination started with three records. One already carried a reply and a suppression flag, which belong to the sender and must survive. The prepared payload mapped three fields and carried four input rows, one of them a duplicate:

$ prepare
{"input_rows": 4, "duplicate_rows": 1,
 "operation_id": "fixture-import-2510b51f7f7b80c1014b9ebc1b7ede070fec3234a581771dfa58ced4310290a5",
 "payload": {
   "schema_version": 1, "synthetic": true,
   "scope": {"project": "synthetic-project", "campaign": "synthetic-campaign"},
   "mapping": {"source": "source_url", "target": "target_url", "evidence": "observation"},
   "rows": [
     {"local_id": "local-1", "crm_id": "crm-1", "sender_id": "sender-1", "expected_revision": 1,
      "fields": {"source_url": "https://publisher.example/resource",
                 "target_url": "https://target.example/guide", "observation": "unknown"}},
     {"local_id": "local-2", "crm_id": "crm-2", "sender_id": "sender-2", "expected_revision": 1, "fields": {…}},
     {"local_id": "local-3", "crm_id": "crm-3", "sender_id": null,       "expected_revision": 1, "fields": {…}}
   ]}}

Then the writes, with the interruptions the replay injected. Exit code 75 marks a process the replay killed:

$ receipt                      → {"status": "unknown", "terminal": null}
$ apply    (killed mid-transaction, exit 75)
$ receipt                      → {"status": "unknown", "terminal": null}
$ apply    (killed after commit, exit 75)
$ receipt                      → {"status": "completed", "terminal": true, "effects_complete": true,
                                  "changed_ids": ["crm-1", "crm-3"], "unchanged_ids": ["crm-2"],
                                  "messages_sent": 0}
$ apply    (same payload again) → the same receipt, byte for byte; no second write

Read the two unknowns. A write that died before commit did nothing, and the receipt still says unknown rather than failed, because an empty lookup is not proof that nothing was saved. A write that died after commit is resolved by reading the operation back. Writing again is never the answer. The record that already matched, crm-2, is named as unchanged, so a zero-change receipt is distinguishable from a lost one.

Readback was interrupted once and then resumed under its cursor:

$ readback (killed during readback, exit 75)
$ readback → {"checkpoint": {"accepted_rows": 1, "complete": false, "next_cursor": "eyJvZmZzZXQiOjEs…",
              "snapshot": "e54a4a21…fe206a"}, "records": [{"crm_id": "crm-1", "revision": 2,
              "reply": "replied", "suppression": 1, "target_url": "https://target.example/guide", …}]}
$ readback → {"checkpoint": {"accepted_rows": 2, "complete": false, "next_cursor": "eyJvZmZzZXQiOjIs…"}, …}
$ readback → {"checkpoint": {"accepted_rows": 3, "complete": true,  "next_cursor": null}, …}
$ readback → the completed checkpoint again; nothing re-read

$ prepare  (a payload with nothing new)   → operation_id "fixture-import-b11d1989…"
$ apply                                    → {"changed_ids": [], "unchanged_ids": ["crm-1", "crm-2", "crm-3"],
                                              "effects_complete": true, "messages_sent": 0}

The first record came back at revision 2 with its target filled in and its reply and suppression untouched. The suite behind this replay passed 37 of 37 tests on September 14, 2026. The replay record lists its own limits: it is a self-authored deterministic replay, not a clean-client or native-vendor run; a killed process is not a power loss; a completed checkpoint is a dated snapshot, not continuous monitoring; and the fixture is not distributed. Those limits are why this page calls the handoff a document and not a connector.

Webhooks and digests: the outbound side

Changes leave the service two ways. Your agent reads the change feeds by cursor with list_link_events and list_target_events, applying a full page before saving its cursor. Or an HTTPS receiver you run subscribes with create_webhook to single events or to a daily or weekly digest, and signed deliveries arrive on their own ten-minute schedule.

Every delivery is signed with HMAC-SHA-256 over the timestamp, a dot and the raw body. The signing secret is shown once and can be rotated with two secrets active during the overlap. Delivery is at-least-once, so receivers deduplicate by delivery id; a 410 from the receiver disables the endpoint immediately and loses nothing, because undelivered events stay in the feed. Delivery diagnostics are readable and never resend.

Both header sets are sent with identical values during the pilot. The alias set is removed in a separate dated release after pilot customers are notified, and never silently. A receiver written against the working name keeps working until then.

The transports for events and digests exist and are tested; hosted delivery to a customer receiver is gated by environment configuration in the current build, so saving an endpoint proves no delivery. The CLI can verify a delivery’s signature locally with agentlinkops receive and then pull the feed under its own credential, which is how a signed notification becomes a ledger update without trusting the payload. The methodology page covers why delivery is designed this way, and the webhook guide shows the receiver setup.

5. Planned connectors

A customer Google Search Console connection is planned and not released. The plan is a read-only property connection with page and query performance context for choosing target pages. It has no date. In the current source there are no Google OAuth scopes, no Search Analytics client and no property-binding flow; the authorization and acceptance of a live connection is an open task that needs a human login. Three things that sound like this connector are not it: the Search Console file import above, which reads an export you download yourself; the local, read-only Search Console context tools, which run in a repository checkout and not on the hosted endpoint; and the verification of AgentLinkOps’s own domain, which is site ownership and not customer permission. Google’s API has no links-report endpoint either way, so no connector can promise complete backlink discovery.

An optional external sender adapter is specified as a candidate and not built. It would be a local, read-only reconciler of sent-and-reply state using the message ids your sender already assigns. Its demand gate is at zero, because the toolkit collects no telemetry and nobody has declared the need. Deduplication, reply stops and suppression stay customer-owned invariants whether or not it is ever built, and no native sending service is authorized.

Live supplier discovery and new competitor inventories are not on this list because they are not connectors: they are lanes that exist in code and are disabled in this build, and the walkthrough shows the refusal they answer with.

What this page does not claim

• No vendor CRM or sender connector. The handoff is a document your agent applies with its own access; no destination has been tested.
• No sending. AgentLinkOps never connects to a mailbox and never sends outreach, invitations or notifications by email.
• No customer Google connection. Planned, not built, no date.
• No equivalence between the five classes. A tested command form, a documented snippet without a test, a REST route and a plan are labeled differently here because they are different.
• No production delivery claim. Webhook transports are tested; hosted delivery to a receiver is gated by configuration.
• No public signup and no price. Hosted access is invitation-only, and no number on this site can be charged.

How this page was checked

Written September 15, 2026 against the repository at commit 8a8e808. Each statement quotes a row of the DP-0023 claims ledger: A-01 to A-03, A-05, A-10, A-11, M-04, M-06, P-02, P-04, P-07, P-08, W-01 to W-04, W-08, W-09, and the rows I-01 to I-13 added for this page with the file and line each one reads. The preset table renders from the same data file as the import references, so it cannot list a preset the CLI does not have. The client table restates the tests recorded on the agent setup guide, dated September 12, 2026, without adding a test that was not run. The round-trip outputs are pasted from the September 14, 2026 replay record and trimmed only where marked; the fixture’s test suite passed 37 of 37 that day. The webhook header names are read from the delivery module on that commit, and the command count is the one recorded for the production version deployed on September 15, 2026.

A changed source file voids a claim until it is rechecked. If a connection here no longer matches the tool, the ledger is where the correction starts.