Drei Wege, auf deinen KI-Sichtbarkeitsdaten aufzubauen

Ja. Die KI-Suchsichtbarkeits-API liefert JSON über einfaches REST, also kann alles, was einen HTTP-Endpoint aufrufen kann, sie lesen: Looker Studio, Power BI, Tableau, Metabase oder ein geplanter Warehouse-Job. Hol dir Sichtbarkeitswerte, Erwähnungsraten, Rankingpositionen und zitierte Quellen pro Marke und Engine, und verknüpfe sie mit deinen eigenen Tabellen. Berechtigte Nur-Lese-Keys (`read:brands`, `read:reports`) sorgen dafür, dass ein BI-Connector nie Schreibzugriff bekommt.

Die vollständige Referenz liegt unter /docs/v1/, generiert aus einer OpenAPI-3.1-Spezifikation. Jeder Endpoint dokumentiert seine Parameter, das Antwortschema und die Fehlercodes, mit lauffähigen curl-, JavaScript- (fetch) und Python-Beispielen (httpx). Da die Spezifikation maschinenlesbar ist, kannst du auch einen typisierten Client in jeder Sprache mit openapi-generator, Stainless, Speakeasy oder Fern erzeugen.

Ja. Eine Anfrage liefert KI-Sichtbarkeitsdaten für alle sechs Engines: ChatGPT, Claude, Gemini, Perplexity, Google AI Mode (AI Overviews) und Grok. Sie sind in einem einzigen Schema normalisiert, sodass du Positionen und Zitate über Engines hinweg vergleichst, ohne Parser pro Plattform zu schreiben oder sechs verschiedene Scraper zu pflegen.

Ja. Wettbewerbsdaten zur KI-Suchsichtbarkeit sind Teil des Berichts-Payloads: Neben deiner eigenen Marke liefern Berichte die konkurrierenden Marken, die jede Engine für denselben Prompt genannt hat, ihre Position in der Antwort und die dafür zitierten Quellen. So verfolgst du deinen Share of Voice über die Zeit und wirst benachrichtigt, wenn ein Wettbewerber dich in einer Kategorie überholt.

Fast. Berichte laufen auf Anfrage oder geplant, und ausgehende Webhooks senden `report.completed`, `report.failed`, `schedule.run.completed` und `schedule.run.failed` an deinen Endpoint, sobald ein Lauf endet, mit HMAC-signierten Payloads. Du musst nicht pollen: Deine Systeme erfahren von neuen KI-Sichtbarkeitsdaten, sobald sie existieren.

Ja. Die Beschränkung auf eine Marke pro Key erlaubt es dir, einen Key auf eine einzelne Marke zu begrenzen, was White-Label- und Enterprise-Dashboards pro Kunde praktikabel macht: Jeder Kunde sieht nur seine eigenen KI-Sichtbarkeitsdaten. Zusammen mit berechtigten Zugriffen, idempotenten Schreibvorgängen und einem stabilen Fehlerformat ist die API gebaut, um individuelle Integrationen in Produktion zu tragen.

Markenverwaltung (anlegen, auflisten, abrufen, aktualisieren, löschen), KI-Sichtbarkeitsberichte über die sechs großen LLM-Plattformen, Zitat- und Quellenverfolgung mit dem Rank Prompt Score, geplante Berichte, ausgehende Webhooks, sowie die Konto-Endpoints (`/v1/me`, `/v1/me/quota`). Du kannst auch einen MCP-Client verbinden. Marken-Audits, KI-optimierte Content-Erstellung, technische SEO-Audits und Outreach stehen auf der öffentlichen Roadmap und erscheinen unter demselben /v1-Vertrag; abonniere den Changelog, um Release-Termine zu verfolgen. Die künftige Oberfläche spiegelt das Dashboard 1:1.

Jeder Tarif enthält Zugriff auf die Entwickler-API, auch der kostenlose, sodass du direkt auf der Entwickler-Seite in deinem Workspace einen Key erzeugen kannst. Willst du ein größeres eigenes Kontingent? Abonniere einen eigenständigen API-Starter- oder API-Pro-Tarif. Jeder Key trägt eingegrenzte Berechtigungen (z. B. `read:brands`, `write:brands`) und optional eine Markenbeschränkung für White-Label-Nutzung. Keys haben das Präfix `rp_live_`, werden nur einmal bei der Erstellung angezeigt und gehasht in der Datenbank gespeichert.

Zugriff auf die Entwickler-API ist in jedem Tarif enthalten, mit einem monatlichen Anfragelimit pro Stufe: 1.000 bei Free, 10.000 bei Starter, 25.000 bei Pro, 50.000 bei Agency und 100.000 bei Agency Plus. Credit-verbrauchende /v1-Endpunkte (die, die ein kostenpflichtiges LLM oder ein Such-Backend von Dritten ansprechen) gehen von deinem Credit-Guthaben ab, du zahlst also nie doppelt; bei Free gibt es keine monatlichen Credits, du lädst also vor abrechenbarer Arbeit auf. Willst du ein größeres eigenes Kontingent? Zwei eigenständige Abos decken das ab: API Starter ($99/Monat, 50.000 Anfrageeinheiten, 500 enthaltene API-Credits) und API Pro ($299/Monat, 200.000 Anfrageeinheiten, 2.000 enthaltene API-Credits). Jeder Tarif wendet ein Limit von 120 Anfragen/Minute pro Key an, und die Kostenübersicht pro Endpunkt steht in der Entwicklerdokumentation.

Nein. Der Zugriff auf die Entwickler-API ist in deinem Tarif enthalten, mit einem monatlichen Anfragelimit, das pro Stufe skaliert (1.000 bei Free, dann 10.000 / 25.000 / 50.000 / 100.000). Credit-verbrauchende /v1-Endpunkte nutzen dieselben monatlichen Credits, die du bereits bezahlst, es gibt also nichts extra zu kaufen. Einen eigenständigen API-Starter- oder API-Pro-Tarif würdest du nur ergänzen, wenn du ein größeres eigenes Anfragekontingent mit eigenen enthaltenen API-Credits willst.

Ein Burst-Limit von 120 Anfragen pro rollierender Minute gilt für jeden API-Key, unabhängig vom Tarif. Zusätzlich gewährt dein Tarif ein monatliches Kontingent an Anfrageeinheiten. Das Kontingent gehört dem Konto: Jeder darin erstellte Key, deiner und die deines Teams, zieht aus demselben Pool, und der Kontoinhaber sieht jeden davon und kann ihn widerrufen. Jede gemessene Antwort enthält `X-RP-Quota-Limit`, `X-RP-Quota-Used`, `X-RP-Quota-Remaining` und `X-RP-Quota-Reset`, damit du dein Tempo ohne Polling bestimmen kannst. Gedrosselte Aufrufe liefern einen 429 mit `Retry-After`.

Noch nicht. Die API kommt mit einer OpenAPI-3.1-Spezifikation, sodass du idiomatische Clients in jeder Sprache mit openapi-generator, oazapfts, hey-api, Stainless, Speakeasy oder Fern erzeugen kannst. Die Doku enthält curl-, JavaScript- (fetch) und Python-Beispiele (httpx) für jeden Endpoint. Eigene TypeScript- und Python-SDKs stehen auf der Roadmap.

Die Endpoints `GET /v1/me` und `GET /v1/me/quota` kosten 0 Anfrageeinheiten und zählen nie gegen dein Kontingent, sodass du Keys, Scopes und Anfragesignierung testen kannst, ohne Budget zu verbrauchen. Für vollständige End-to-End-Tests erstelle einen separaten Key mit eingeschränkten Scopes und nutze ihn gegen eine Testmarke.

Der /v1-Vertrag ist additiv. Wir fügen nur Felder und Endpoints hinzu; wir entfernen oder benennen sie nie still um. Wenn ein Breaking Change unvermeidbar ist, liefern wir /v2 parallel zu /v1 mit einer langen Übergangsfrist aus und kündigen die Abschaltung jedes Endpoints rechtzeitig über den Standard-HTTP-Header `Sunset` an.

Ja. Binde einen Key bei der Erstellung optional an eine einzelne Marke (`allowed_brand_id`). Die API lehnt jede Anfrage ab, deren Zielmarke nicht passt, selbst wenn der aufrufende Key `write:all` trägt. So können Agenturen und Plattformen markengebundene Keys an Kunden ausgeben, ohne einen neuen Rank-Prompt-Workspace anzulegen.

Ja, Webhooks sind live. Registriere einen Endpoint pro Marke mit `POST /v1/brands/{brand_id}/webhooks` und abonniere `report.completed`, `report.failed`, `schedule.run.completed` und `schedule.run.failed`. Payloads sind HMAC-signiert, das Signing-Secret rotiert (das alte Secret bleibt 24 Stunden gültig), und ein Endpoint deaktiviert sich nach wiederholten Fehlern automatisch. Du musst den Berichtsstatus nicht mehr von einem Worker aus pollen.

Ja. Der Rank-Prompt-MCP-Server erlaubt Claude Code, Cursor, Claude Desktop oder jedem MCP-Client, deine Berichte, Marken und Zitate zu lesen und in deinem Namen Berichte auszuführen. Du verbindest dich per OAuth im Browser, es gibt also keinen Key zum Einfügen. Sieh dir die MCP-Server-Seite auf rankprompt.com/mcp für die 30-Sekunden-Einrichtung an.

Bearer-Token-Authentifizierung über TLS, berechtigt pro Ressource. Browser-CORS-Aufrufe werden am Edge blockiert: Die API ist ausschließlich Server-zu-Server. Keys werden gehasht gespeichert, und wir melden das `rp_live_`-Präfix beim GitHub-Secret-Scanning an, sodass geleakte Keys automatisch erkannt werden. Die API läuft auf derselben gehärteten Infrastruktur wie der Rest der Rank-Prompt-Plattform, mit EU/US-Datenresidenz-Optionen.