An API existing doesn't mean an agent can act
Plenty of link-building platforms now publish a page written for a language model to read, or a read-only API to browse a catalog. Few go further: letting an agent search for a site, place an order, and track its publication without a human filling in a form at every step. This page draws that line, question by question, without naming any specific platform.
A page an agent can read, with no machine access
The platform writes its offer plainly, in full sentences rather than marketing jargon. An agent can read it and summarize it to a user. It cannot order anything: the rest of the journey stays a contact form or an email quote.
A read-only catalog
An export or an API returns the sites, sometimes the prices. An agent can search and compare. Ordering, though, falls back to a human: a form, an email, a sales call.
Full access, read and write
The agent can search for a site, place an order, track its progress, and know precisely what happens after each call. This is the category the Nautilinks API described below belongs to, and what this page calls a genuinely pilotable platform.
Six things to check on any platform
A catalog exposed as JSON, not just HTML
A page built for a browser forces an agent to guess its structure by parsing it. A catalog exposed with a stable schema, named fields, pagination, and documented filters removes that ambiguity, and the errors that come with it.
A contract, written in advance, for what happens after each call
Creating an order can mean three very different things: a firm purchase, a quote to approve, or a lead handed to a salesperson. An agent can only decide what to do next if that contract is documented before the call, not discovered after.
Keys with separate scopes
A key that can only read the catalog and a key that can also place orders should never be the same thing. Separating the two limits the damage of a misconfigured agent or a leaked key.
A sandbox mode to test without spending
Before letting an agent touch real money, you need to be able to simulate the full call, search then order then track, without it debiting anything or creating a real commitment with a publisher.
A clear line on who pays, and how
Some platforms let the agent settle a payment alone from a balance a human already funded. Others require a human to open a link on every order. Both approaches are defensible; what isn't is documenting neither.
Tracking that doesn't require re-polling a dashboard
A signed webhook, verifiable by the recipient, beats an agent re-querying a page every five minutes hoping for a status change.
Four ways to answer "yes" to the question
A page that reads well
The offer is explained plainly enough for an agent to understand and summarize it to a user. No machine access behind it: the order still runs through a form or an email.
A read-only catalog
An API or export returns the sites, sometimes the prices. An agent can search and compare. Ordering, though, falls back to a human: a form, an email, a sales call.
Writes are possible, the contract is vague
The agent can place an order, but what happens next (a real charge, a quote, a lead) isn't documented in advance. Worth checking case by case before trusting it.
Writes with an explicit contract
Search, order, tracking, with a response that states without ambiguity what just happened: paid, waiting on a human, or declined.
What the Nautilinks API actually does
Nautilinks sells backlinks on a catalog of sites we edit ourselves, split across three fixed-price shelves (Plancton 5 €, Corail 15 €, Nautilus 30 €). This catalog is reachable through a REST API (/api/v1/agent/*) and a remote MCP server, eleven tools, no package to install.
- API keys carry separate scopes (read, order), up to five active keys per account.
- A sandbox key simulates search, ordering, and tracking without ever debiting the account or creating a real commitment with a publisher.
- An order is settled immediately if the account's prepaid balance covers it. Otherwise, a Stripe payment link is returned, for a human to open before anything is committed. Both outcomes are documented in the response, not left to guess.
- A daily anti-abuse cap applies per key.
- Order tracking works either by direct call or by signed webhook, rather than re-polling a dashboard.
This contract carries a deliberate limit: an agent can never, on its own, complete a card payment. That's a choice, not a gap. The upper bound of what an agent can spend stays whatever balance a human funded beforehand, or the key's daily cap.
The full implementation, authentication, endpoints, request examples, connecting the MCP server, is documented on the API reference.
Written by Benoit Demonchaux, who runs the Nautilinks network.
Frequently asked questions
Does a page written well for an AI agent make a platform pilotable?
No. An agent can read and summarize a page without being able to act on it. Being pilotable requires machine access, at minimum read access, and ideally write access with a documented contract for what each call does.
Can an agent pay on its own, on any serious platform?
It depends on the platform's own choice, both approaches exist. Some let the agent debit a balance a human already funded. Others require a human to open a payment link on every order. On Nautilinks, it's the first path if the prepaid balance covers the total, otherwise the second: either way, no card is ever charged without a person approving the payment.
Does MCP change anything compared to a plain REST API?
The data contract is identical. MCP adds a discovery layer for clients that speak it natively (Claude Code, claude.ai, Cursor), without a developer writing integration code. A plain REST API remains the most direct path to build on.
How do you test an integration without financial risk?
By looking for a key or a sandbox mode that simulates the full call, search then order then tracking, without debiting a real balance or creating a commitment with a publisher. Nautilinks offers this mode natively, with a key prefix distinct from the production one.
Does a daily cap limit what an agent can actually do?
It limits exposure in case of error, not normal use. A cap on the order of a couple dozen orders a day comfortably covers reasonable use; past it, the API returns an explicit error rather than letting spend run unchecked.
Where is the full technical documentation for the Nautilinks API?
On the API reference, with endpoints, authentication, idempotence, the daily cap, and complete request examples.