Eine API zu haben heißt nicht, dass ein Agent handeln kann
Viele Netlinking-Plattformen veröffentlichen heute eine Seite, die für ein Sprachmodell zum Lesen gedacht ist, oder eine reine Lese-API für einen Katalog. Wenige gehen weiter: einen Agenten eine Seite suchen, eine Bestellung aufgeben und deren Veröffentlichung verfolgen lassen, ohne dass ein Mensch bei jedem Schritt ein Formular ausfüllt. Diese Seite zieht diese Grenze, Frage für Frage, ohne eine bestimmte Plattform zu nennen.
Eine für einen Agenten lesbare Seite, ohne Maschinenzugriff
Die Plattform beschreibt ihr Angebot klar, in vollständigen Sätzen statt Marketing-Jargon. Ein Agent kann sie lesen und einem Nutzer zusammenfassen. Bestellen kann er nichts: der weitere Ablauf bleibt ein Kontaktformular oder ein Angebot per E-Mail.
Ein Katalog mit reinem Lesezugriff
Ein Export oder eine API liefert die Seiten, manchmal die Preise. Ein Agent kann suchen und vergleichen. Die Bestellung wird wieder menschlich: Formular, E-Mail, oder Vertriebsanruf.
Voller Zugriff, lesend und schreibend
Der Agent kann eine Seite suchen, eine Bestellung aufgeben, ihren Fortschritt verfolgen und genau wissen, was nach jedem Aufruf passiert. Zu dieser Kategorie gehört die unten beschriebene Nautilinks-API, und das nennt diese Seite eine wirklich steuerbare Plattform.
Sechs Punkte, die auf jeder Plattform zu prüfen sind
Ein Katalog, der als JSON verfügbar ist, nicht nur als HTML
Eine für einen Browser gebaute Seite zwingt einen Agenten dazu, ihre Struktur durch Parsen zu erraten. Ein Katalog mit stabilem Schema, benannten Feldern, Paginierung und dokumentierten Filtern beseitigt diese Unschärfe und die Fehler, die daraus entstehen.
Ein im Voraus schriftlich festgelegter Vertrag darüber, was nach jedem Aufruf passiert
Eine Bestellung anzulegen kann drei sehr unterschiedliche Dinge bedeuten: einen festen Kauf, ein zu bestätigendes Angebot, oder einen an einen Vertriebsmitarbeiter weitergereichten Lead. Ein Agent kann nur dann selbst entscheiden, was als Nächstes zu tun ist, wenn dieser Vertrag vor dem Aufruf dokumentiert ist, nicht erst danach entdeckt wird.
Schlüssel mit getrennten Scopes
Ein Schlüssel, der nur den Katalog lesen kann, und ein Schlüssel, der auch bestellen kann, sollten niemals dasselbe sein. Die Trennung begrenzt den Schaden eines falsch konfigurierten Agenten oder eines durchgesickerten Schlüssels.
Ein Sandbox-Modus zum Testen ohne Ausgaben
Bevor ein Agent echtes Geld anfassen darf, muss sich der vollständige Ablauf, Suche, dann Bestellung, dann Nachverfolgung, simulieren lassen, ohne dass irgendetwas belastet wird oder eine echte Verpflichtung bei einem Publisher entsteht.
Eine klare Grenze, wer bezahlt und wie
Manche Plattformen lassen den Agenten allein eine bereits von einem Menschen aufgeladene Zahlung abschließen. Andere verlangen, dass ein Mensch bei jeder Bestellung einen Link öffnet. Beide Ansätze sind vertretbar; nicht vertretbar ist es, keinen von beiden zu dokumentieren.
Nachverfolgung ohne wiederholtes Abfragen eines Dashboards
Ein signierter, vom Empfänger überprüfbarer Webhook ist besser als ein Agent, der alle fünf Minuten erneut eine Seite abfragt in der Hoffnung auf eine Statusänderung.
Vier Arten, auf die Frage mit „ja" zu antworten
Eine Seite, die sich gut liest
Das Angebot ist klar genug erklärt, damit ein Agent es versteht und einem Nutzer zusammenfasst. Kein Maschinenzugriff dahinter: die Bestellung läuft weiter über ein Formular oder eine E-Mail.
Ein Katalog mit reinem Lesezugriff
Eine API oder ein Export liefert die Seiten, manchmal die Preise. Ein Agent kann suchen und vergleichen. Die Bestellung wird wieder menschlich: Formular, E-Mail, oder Vertriebsanruf.
Schreibzugriff vorhanden, Vertrag unklar
Der Agent kann eine Bestellung aufgeben, aber was danach passiert (echte Belastung, Angebot, Lead) ist nicht im Voraus dokumentiert. Von Fall zu Fall zu prüfen, bevor man vertraut.
Schreibzugriff mit explizitem Vertrag
Suche, Bestellung, Nachverfolgung, mit einer Antwort, die ohne Zweideutigkeit sagt, was gerade passiert ist: bezahlt, wartet auf einen Menschen, oder abgelehnt.
Was die Nautilinks-API konkret tut
Nautilinks verkauft Backlinks auf einem Katalog von Seiten, die wir selbst betreiben, aufgeteilt auf drei Regale zu Festpreisen (Plancton 5 €, Corail 15 €, Nautilus 30 €). Dieser Katalog ist über eine REST-API (/api/v1/agent/*) und einen entfernten MCP-Server erreichbar, elf Tools, kein zu installierendes Paket.
- API-Schlüssel tragen getrennte Scopes (Lesen, Bestellen), bis zu fünf aktive Schlüssel pro Konto.
- Ein Sandbox-Schlüssel simuliert Suche, Bestellung und Nachverfolgung, ohne jemals das Konto zu belasten oder eine echte Verpflichtung bei einem Publisher zu erzeugen.
- Eine Bestellung wird sofort beglichen, wenn das Guthaben des Kontos sie deckt. Andernfalls wird ein Stripe-Zahlungslink zurückgegeben, den ein Mensch öffnen muss, bevor irgendetwas verbindlich wird. Beide Ausgänge sind in der Antwort dokumentiert, nicht zu erraten.
- Pro Schlüssel gilt ein tägliches Missbrauchslimit.
- Die Bestellverfolgung läuft per direktem Aufruf oder per signiertem Webhook, statt ein Dashboard erneut abzufragen.
Dieser Vertrag trägt eine bewusste Grenze: ein Agent kann niemals allein eine Kartenzahlung abschließen. Das ist eine Entscheidung, keine Lücke. Die Obergrenze dessen, was ein Agent ausgeben kann, bleibt das Guthaben, das ein Mensch zuvor aufgeladen hat, oder das tägliche Limit des Schlüssels.
Die vollständige Umsetzung, Authentifizierung, Endpunkte, Anfragebeispiele, Anbindung des MCP-Servers, ist in der API-Referenz dokumentiert.
Geschrieben von Benoit Demonchaux, der das Nautilinks-Netzwerk betreibt.
Häufige Fragen
Macht eine für einen KI-Agenten gut geschriebene Seite eine Plattform steuerbar?
Nein. Ein Agent kann eine Seite lesen und zusammenfassen, ohne auf ihr handeln zu können. Steuerbar zu sein setzt Maschinenzugriff voraus, mindestens Lesezugriff, idealerweise Schreibzugriff mit einem dokumentierten Vertrag darüber, was jeder Aufruf tut.
Kann ein Agent auf jeder ernsthaften Plattform allein bezahlen?
Das hängt von der Wahl der jeweiligen Plattform ab, beide Ansätze existieren. Manche lassen den Agenten ein bereits von einem Menschen aufgeladenes Guthaben belasten. Andere verlangen, dass ein Mensch bei jeder Bestellung einen Zahlungslink öffnet. Bei Nautilinks ist es der erste Weg, wenn das Guthaben die Summe deckt, sonst der zweite: in beiden Fällen wird nie eine Karte belastet, ohne dass eine Person die Zahlung freigegeben hat.
Ändert MCP etwas gegenüber einer klassischen REST-API?
Der Datenvertrag ist identisch. MCP fügt eine Discovery-Schicht für Clients hinzu, die es nativ sprechen (Claude Code, claude.ai, Cursor), ohne dass ein Entwickler Integrationscode schreibt. Eine klassische REST-API bleibt der direkteste Weg, darauf aufzubauen.
Wie testet man eine Integration ohne finanzielles Risiko?
Indem man nach einem Schlüssel oder einem Sandbox-Modus sucht, der den vollständigen Ablauf simuliert, Suche, dann Bestellung, dann Nachverfolgung, ohne echtes Guthaben zu belasten oder eine Verpflichtung bei einem Publisher zu erzeugen. Nautilinks bietet diesen Modus nativ an, mit einem Schlüsselpräfix, das sich vom Produktionspräfix unterscheidet.
Schränkt ein tägliches Limit den Nutzen eines Agenten ein?
Es begrenzt das Risiko im Fehlerfall, nicht die normale Nutzung. Ein Limit in der Größenordnung von rund zwanzig Bestellungen pro Tag deckt eine vernünftige Nutzung bequem ab; darüber hinaus antwortet die API mit einem expliziten Fehler, statt die Ausgaben unkontrolliert laufen zu lassen.
Wo findet man die vollständige technische Dokumentation der Nautilinks-API?
In der API-Referenz, mit Endpunkten, Authentifizierung, Idempotenz, dem täglichen Limit und vollständigen Anfragebeispielen.