Self-Signup für Agenten: Wie ein KI-Agent mit einem Aufruf eine Shager-Sandbox eröffnet – und warum ein Mensch den Veröffentlichen-Knopf behält

Ein KI-Agent kann sich mit einer einzigen Anfrage selbst bei Shager registrieren: POST https://app.shager.ai/api/v1/agent/signup mit einem JSON-Body, der mindestens agent_name enthält. Zurück bekommt er einen API-Schlüssel, eine MCP-URL und einen Claim-Link und kann sofort Workspaces anlegen, Medien importieren und Beiträge entwerfen. Geplant oder veröffentlicht wird nichts, bis ein Mensch den Claim-Link öffnet, sich anmeldet und entscheidet, ob dieser Schlüssel veröffentlichen darf.

Diese Aufteilung ist das ganze Konzept. Der Agent muss nicht auf einen Menschen warten; der Mensch behält die Entscheidung, die echte Zielgruppen erreicht.

Warum sollte sich ein Agent überhaupt selbst registrieren?

Weil die Alternative den Arbeitsfluss des Agenten unterbricht. Ein Agent, der „die Social-Media-Distribution unseres Kunden aufsetzen“ soll, steht beim ersten Schritt vor einer Wand, wenn der einzige Zugang darin besteht, dass ein Mensch ein Formular ausfüllt, eine E-Mail bestätigt und im Dashboard einen Schlüssel anlegt. Bis das passiert ist, ist der Kontext des Agenten weg.

Mit Self-Signup erledigt der Agent die Vorarbeit selbst: Er legt pro Kunde einen Workspace an, holt die Medien herein, schreibt Beitragsentwürfe und übergibt dem Menschen einen einzigen Link, hinter dem alles zur Prüfung bereitliegt. Die Registrierungsanleitung für Agenten steht unter /auth.md, und die Agenten-Seite listet die Discovery-Dateien auf, die ein Agent vorher lesen kann.

Seitlich scrollen für das ganze Diagramm

Wie sieht der Signup-Aufruf aus?

Pflicht ist nur agent_name (2 bis 80 Zeichen). Die anderen Felder helfen dem Menschen zu erkennen, was er übernimmt.

curl -s https://app.shager.ai/api/v1/agent/signup \
  -H "Content-Type: application/json" \
  -d '{
    "agent_name": "Northwind content agent",
    "contact_email": "ops@northwind-agency.example",
    "organization_name": "Northwind Agency",
    "purpose": "Draft weekly posts for 12 restaurant clients"
  }'

Die Antwort packt alles in data:

{
  "data": {
    "api_key": "shgr_live_...",
    "organization_id": "...",
    "sandbox": true,
    "claim_url": "https://app.shager.ai/...",
    "expires_at": "2026-09-19T10:04:11.000Z",
    "mcp_url": "https://app.shager.ai/api/mcp",
    "api_base": "https://app.shager.ai/api/v1",
    "openapi_url": "https://app.shager.ai/api/v1/openapi.json",
    "limits": { "workspaces": 5, "requests_per_minute": 120, "publishing": "after a human claims the sandbox" },
    "next_steps": ["..."]
  }
}

Zwei Felder müssen sofort behandelt werden.

1. api_key wird nur einmal angezeigt. Speichere ihn, bevor du irgendetwas anderes tust – in einem Secret Store oder einer Umgebungsvariablen, niemals in einer Logzeile.
2. claim_url gehört zu einem Menschen. Wenn du contact_email mitgegeben hast, schickt Shager den Claim-Link zusätzlich per E-Mail dorthin, der Agent sollte ihn aber trotzdem in seiner eigenen Antwort nennen.

Pro Adresse sind fünf Registrierungen pro Stunde möglich. So kann ein Agent in einer Schleife nicht Dutzende verwaister Sandboxes erzeugen.

Was kann eine nicht übernommene Sandbox?

Erlaubt vor der Übernahme	Gesperrt, bis ein Mensch übernimmt
Bis zu 5 Workspaces anlegen	Irgendetwas planen oder veröffentlichen
Medien von URLs hochladen	Verbindungslinks für Kunden erstellen
Beitragsentwürfe anlegen	Freigabeanfragen an Kunden senden
Alles auflisten und lesen, was sie angelegt hat

Gesperrte Aufrufe scheitern mit einem klaren Fehler statt stillschweigend nichts zu tun. Ein Planungsversuch liefert HTTP 403 mit "code": "sandbox_unclaimed", ebenso create_connect_link und request_approval. Ein sechster Workspace liefert 403 sandbox_limit. Gute Agenten lesen den code und sagen dem Menschen, was gebraucht wird, statt es erneut zu versuchen.

Verbindungslinks und Freigabeanfragen sind gesperrt, weil beide echte Menschen außerhalb der Agentur erreichen: einen Kunden, der auf einen Link klickt, um seine Facebook-Seite zu verbinden, oder eine prüfende Person, die eine Freigabe-E-Mail bekommt. Das sollte nicht im Namen einer Organisation passieren, die niemand verifiziert hat.

Eine sinnvolle erste Sitzung in der Sandbox

So sieht es aus, wenn sich ein Agent in seinen ersten Minuten gut benimmt, in Python mit requests:

import os, requests

API = "https://app.shager.ai/api/v1"
H = {"Authorization": f"Bearer {os.environ['SHAGER_API_KEY']}"}

def call(method, path, **body):
    r = requests.request(method, f"{API}{path}", headers=H, json=body or None, timeout=60)
    payload = r.json()
    if not r.ok:
        err = payload["error"]
        raise RuntimeError(f"{r.status_code} {err['code']}: {err['message']}")
    return payload["data"]

me = call("GET", "/me")
print(me)  # organization, scopes, sandbox status

ws = call("POST", "/workspaces", name="Harbor Tacos", timezone="America/Chicago")

media = call("POST", f"/workspaces/{ws['id']}/media",
             url="https://harbortacos.example/press/fall-menu.jpg",
             file_name="fall-menu.jpg")

print("Workspace", ws["id"], "media", media["id"], media["kind"])

Gib timezone beim Anlegen eines Workspace ausdrücklich an. Das ist ein IANA-Zonenname, und spätere Planungen werden in dieser Zone interpretiert – ein Restaurant in Chicago sollte also nicht die Standardeinstellung von jemand anderem erben.

Zu diesem Zeitpunkt gibt es noch keine verbundenen Social-Media-Konten, denn dafür braucht es einen Verbindungslink, und der setzt die Übernahme voraus. Der Agent bereitet Inhalte und Struktur vor, der Mensch öffnet die Tür zum Rest.

Seitlich scrollen für das ganze Diagramm

Was passiert, wenn der Mensch übernimmt?

Der Mensch öffnet claim_url, meldet sich bei Shager an (oder legt ein Konto an) und übernimmt die Sandbox samt den Workspaces, Medien und Entwürfen, die der Agent vorbereitet hat. Bei der Übernahme entscheidet er, ob der Schlüssel des Agenten auch planen und veröffentlichen darf – das fügt die Berechtigung publish hinzu.

Diese Entscheidung verdient einen Moment Nachdenken. publish wegzulassen, ist auch langfristig ein völlig solides Setup: Der Agent entwirft, der Mensch oder der Kunde gibt frei und plant. Viele Agenturen fangen so an und legen später unter https://app.shager.ai/dashboard/agents einen separaten Schlüssel zum Veröffentlichen an; dort lässt sich jeder Schlüssel widerrufen, und jeder Aufruf eines Agenten erscheint im Audit-Log. Die Vor- und Nachteile dieser Setups beschreibt die wöchentliche Distributionsroutine.

Nach der Übernahme sind die nächsten Schritte, die die API selbst vorschlägt, naheliegend: create_connect_link aufrufen, damit der Kontoinhaber seine Social-Media-Konten (Facebook, Instagram, YouTube, X, LinkedIn oder TikTok) ohne Shager-Login verbindet, dann create_post und, wenn der Schlüssel publish hat, schedule_post.

Was, wenn niemand übernimmt?

Nicht übernommene Sandboxes laufen nach sieben Tagen ab, zu dem in expires_at angegebenen Zeitpunkt. Die Entwürfe und Workspaces verschwinden mit ihnen. Ein Agent, der an einem längeren Projekt arbeitet, sollte den Menschen vor diesem Datum daran erinnern – und auf den Ablauf nicht reagieren, indem er sich immer wieder neu registriert. Eine neue Sandbox übernimmt die alten Entwürfe nicht.

Wie sollte ein Agent die Übergabe formulieren?

Klar, mit dem Link und den Konsequenzen. Etwa so:

I set up a Shager sandbox for Northwind with 3 client workspaces and
9 draft posts. To connect the clients' accounts and publish, open this
link and sign in: <claim_url>
When you claim it you can choose whether I'm allowed to schedule posts
myself. If you don't claim it by Sep 19, the sandbox and drafts are deleted.

Diese Nachricht sagt ehrlich, was erledigt ist, was wartet und was der Mensch in der Hand hat. Und genau auf solche Nachrichten wird am ehesten geklickt.

FAQ

Kostet Self-Signup etwas?

Nein. Die Sandbox ist kostenlos, und während der Startphase ist Shager auch nach der Übernahme kostenlos, ohne Kreditkarte; bevor wir Geld verlangen, sagen wir dir rechtzeitig Bescheid. API- und MCP-Zugang sind in jedem Tarif enthalten. Die Grenzen der Tarife stehen auf der Preisseite.

Kann der Agent nach der Registrierung MCP statt REST nutzen?

Ja. Die Antwort enthält mcp_url, und derselbe Schlüssel funktioniert als Authorization: Bearer shgr_live_... auf dem MCP-Server. Die Tools entsprechen eins zu eins den REST-Operationen aus dem OpenAPI-Dokument.

Kann ein übernommener Schlüssel jemals veröffentlichen, ohne dass ein Mensch den Beitrag sieht?

Nur wenn der Mensch bei der Übernahme publish erteilt hat und der Workspace keine Kundenfreigabe verlangt. Beides entscheidet der Mensch, und beides lässt sich später ändern: Schlüssel können im Dashboard widerrufen werden, und Freigaben lassen sich pro Workspace verpflichtend machen.

Nächster Schritt

Sobald die Sandbox übernommen ist und die Konten verbunden sind, geht es vom Ausprobieren zum vollen Durchlauf. Die durchgängige Content-Pipeline für Agenten setzt genau hier an, vom Briefing bis zu veröffentlichten Beiträgen und Klicks pro Konto.