Diese Seite wurde aus dem Englischen übersetzt.
Entwickler-Tools
Ein Tool für API-Tests und Debugging bauen
Kliv ist ein KI-App-Builder. Beschreiben Sie das API-Test- und Debugging-Tool, das Ihr Team braucht — gespeicherte Requests, geplante Probes, Response-Diffs, Incidents und Partner-Zugriffsgrenzen — und Kliv baut es.
Geben Sie Ihre Idee einfach in das Textfeld ein, und AI baut sie für Sie
Was ist Kliv?
Kliv ist kein Desktop-API-Client und kein gemeinsamer Sammlungsdienst – Kliv ist eine KI, die Software für Sie baut.
Sie beschreiben die App, die Sie brauchen, in einfachen Worten, und Kliv baut die Datenbank, die Logik, die Oberflächen, geplante Jobs und Zugriffsregeln. Das Ergebnis gehört Ihnen, und Sie können es später durch weitere Anweisungen ändern lassen. Es ist kein Template-Arbeitsbereich.
Auf dieser Seite ist diese App eine Arbeitsumgebung für API-Tests und Debugging. Kliv baut alle Arten von Web-Apps; diese hilft einem Team, Requests zu merken, Probes auszuführen, Responses zu vergleichen und Incidents mit Belegen zu verknüpfen.
Warum gemeinsame Request-Sammlungen an ihre Grenzen stoßen
Ein API-Client auf jedem Laptop funktioniert für eine Integration und zwei Engineers. Er stößt an seine Grenzen, sobald viele Partner-APIs im Spiel sind, Teammitglieder in unterschiedlichen Zeitzonen arbeiten und Kunden wissen wollen, ob der Ausfall an Ihrem Code oder an einer Partneränderung lag.
Kliv baut die Arbeitsumgebung als verlässliches System of Record. Jeder Endpoint, jeder gespeicherte Request, jedes Probe-Ergebnis, jeder Response-Diff und jeder Incident ist eine Zeile in einer gemeinsamen Datenbank – mit Berechtigungen und einer Historie, die den Laptop einer einzelnen Person überdauern.
Die Bausteine eines Requests
Fünf Datensätze machen aus einem gespeicherten Request einen Debugging-Workflow.
Endpoint-Datensätze
Basis-URLs pro Umgebung, Auth-Verfahren, Partnerkontakt und das Changelog, das Sie pflegen. Requests und Incidents hängen an diesem Datensatz.
Gespeicherte Requests
Headers, Body und Assertions wie erwarteter Status, erwartete Struktur und Latenzgrenze. Ein Request wird zum Test, sobald er Assertions hat.
Probe-Zeitpläne
Serverseitige Funktionen spielen gespeicherte Requests nach einem Zeitplan ab, etwa alle 15 Minuten gegen Staging und stündlich gegen Produktion. Eine fehlgeschlagene Assertion eröffnet einen Incident.
Incidents
Ein Incident hält den Response-Diff, die Timeline, betroffene Händler und fest, wer wann informiert wurde.
Partner-Zugriffsgrenzen
Engineers sehen nur die ihnen zugewiesenen Partner. Eine Kunden-Statusansicht zeigt ausschließlich die eigenen Integrationen und nichts darüber hinaus.
Ein Beispiel: Mareikes Team für Versandintegrationen
So könnte ein Team eine mit Kliv gebaute API-Testumgebung nutzen. Das ist nur ein Beispiel – Sie würden Ihre eigenen Partner, Requests, Umgebungen, Assertions und Incident-Regeln beschreiben.
Ein Partner ändert eine Response ohne Vorwarnung
Ein Frachtführer deployt auf Staging, und der Versions-Header wechselt von 2.13 auf 2.14. Es gibt weder eine E-Mail noch einen Changelog-Eintrag vom Partner.
Die geplante Probe erkennt die Strukturänderung
Mareikes Probe stellt fest, dass das Tracking-Payload ein Feld gewonnen und ein anderes verloren hat. Der Endpoint liefert weiterhin 200, aber die Struktur-Assertion schlägt fehl.
Der Incident wird mit dem Diff eröffnet
Die betroffenen Händler werden direkt aus den Daten benannt, denn nur zwei wickeln Fracht über diesen Frachtführer ab. Die Schwere hängt nicht von Vermutungen ab.
Das Team spielt Staging und Produktion nebeneinander ab
Am Montag läuft der gespeicherte Request in einer Ansicht gegen beide Umgebungen. Die Änderung ist eingegrenzt, die Lösung ist ein Mapping-Update, und die Untersuchung bleibt auf einem Bildschirm.
Der Kunde sieht eine eingegrenzte Timeline
Der Händler sieht seine eigene Incident-Seite: was sich geändert hat, wann das Team es wusste und was unternommen wurde. Integrationen anderer Händler sind nicht sichtbar.
Beschreiben Sie die API-Arbeitsumgebung, die Sie möchten
Kliv baut nach Ihrer Beschreibung, geben Sie also Partner, Umgebungen, Zeitpläne, Assertions, Incident-Regeln und Sichtbarkeiten an. Je mehr Details Sie liefern, desto näher kommt die erste Version an Ihr Ziel.
Frachtführer-API-Arbeitsumgebung
Gespeicherte Requests, Probes und Incidents für Versandpartner.
“Baue eine API-Testumgebung für unsere Versandintegrationen. Speichere Requests pro Frachtführer, hinterlege Staging- und Produktions-Basis-URLs, führe Staging-Probes alle 15 Minuten aus, führe produktionssichere Probes stündlich aus, prüfe Status 200, Pflichtfelder im Tracking und eine Latenz unter 800 ms, und eröffne Incidents mit vollständigen Response-Diffs und betroffenen Händlern.”
Zahlungs-Sandbox-Monitor
Einen Zahlungspartner vor dem Release im Blick behalten.
“Baue einen API-Monitor für Zahlungen, der unsere gespeicherten Requests für Autorisierung, Capture, Refund und Webhook-Verifizierung stündlich gegen die Sandbox abspielt. Prüfe Response-Struktur, Status und eine Latenz unter 500 ms, und eröffne bei jedem fehlgeschlagenen Check einen Incident mit dem Diff.”
Kunden-Statusportal
Jedem Händler seine eigene Integrationshistorie geben.
“Baue ein Kunden-Statusportal, in dem sich jeder Händler anmeldet und Uptime, Incidents und Probe-Historie ausschließlich für seine eigenen Integrationen sieht. Sende E-Mail-Updates, wenn ein Incident eröffnet wird, den Status wechselt oder gelöst wird.”
Unter der Haube der Konsole
Probes sind geplante Jobs. Jede Probe ist eine serverseitige Funktion auf einem Cron. Sie spielt den gespeicherten Request ab, wertet die Assertions aus und schreibt das Ergebnis als Zeile.
Partner-Keys bleiben serverseitig. Sandbox- und Produktions-Keys werden von der Plattform gespeichert und zur Laufzeit eingefügt. Sie liegen nicht in exportierten Sammlungen, auf Laptops oder in Wikis. Eine Staging-Probe kann nicht mit Produktions-Keys laufen, wenn Sie die Umgebungen getrennt kennzeichnen.
Zugriffsgrenzen sind Datenregeln. Ein Engineer mit Zugriff auf zwei Frachtführer bekommt aus denselben Tabellen auch nur diese zwei zurück. Ein Kunde sieht seine eigene Statusansicht. Die Datenschutzregel greift, bevor Zeilen ausgeliefert werden.
Weil es sich um eine App handelt, kann sie um Oberflächen wachsen, die ein Kunde nutzen kann: Händler-Statusseiten, wöchentliche Probe-Digests und einen Agenten, der aus Ihrer eigenen Incident-Historie die Frage „Wann hat sich die Tarif-API zuletzt geändert?“ beantwortet.
Kliv schreibt beim Bauen außerdem Tests und kann die Veröffentlichung zurückhalten, bis sie bestehen. Die Testing-Seite erklärt diese Vorgehensweise.
Häufige Fragen
Was genau ist Kliv?
Kliv ist ein KI-App-Builder. Sie beschreiben den API-Test-Workflow, den Sie brauchen, und Kliv baut eine echte App mit gespeicherten Requests, Probe-Zeitplänen, Incidents, Diffs und eingegrenzten Ansichten.
Bekomme ich eine echte App oder eine Vorlage?
Eine echte App. Ihre Endpoints, Assertions, Zeitpläne, Umgebungen, Incidents und Zugriffsregeln werden in einer Datenbank gespeichert, die für Ihren Workflow gebaut wurde.
Kann ich sie nach dem Bau noch ändern?
Ja. Sie können Partner, Assertions, Zeitpläne, Incident-Felder, Kundenansichten oder neue Umgebungen hinzufügen, indem Sie die Änderung einfach in Worten beschreiben.
Können Probes gegen Produktion laufen, ohne Schaden anzurichten?
Ja. Sie kennzeichnen, welche gespeicherten Requests produktionssicher sind. Schreibende Requests können fest auf Staging beschränkt bleiben, und jede Umgebung hat ihre eigenen Keys.
Können Kunden die Arbeitsumgebung einsehen?
Sie sehen eine eingegrenzte Ansicht: ihre eigenen Integrationen, Incidents, Uptime und Probe-Historie. Engineers behalten die vollständige Konsole.
Was passiert, wenn eine Assertion um 3 Uhr nachts fehlschlägt?
Es wird eine Incident-Zeile mit angehängtem Response-Diff angelegt. E-Mail oder Slack können den diensthabenden Engineer benachrichtigen, und die Probe läuft weiter, sodass die Wiederherstellung erfasst wird.
Können wir bestehende Request-Sammlungen importieren?
Ja. Gespeicherte Requests sind Daten. Beim Import erhalten sie Zeitpläne, Assertions, Incidents und Zugriffsregeln, statt als Dateien auf einem Laptop liegen zu bleiben.
Kann sie Secrets sicher speichern?
API-Keys bleiben serverseitig und werden beim Ausführen einer Probe eingefügt. Sie müssen nicht zusammen mit den Request-Definitionen exportiert werden.
Kann ich meine eigene Domain nutzen?
Ja. Interne Konsolen und Kunden-Statusansichten können auf Ihrer eigenen Domain laufen.
Kann ich später von Kliv weg wechseln?
Ja. Der Code der App synchronisiert sich mit Ihrem eigenen Git-Repository, ein Wechsel ist also ein Git-Pull statt ein Neubau.
Brauche ich ein separates Incident-Tool?
Nein, nicht für den hier beschriebenen Workflow. Incidents können in derselben App leben wie die Probes, Diffs und für Kunden sichtbaren Timelines.
Mehr in dieser Kategorie
Von Kreativen gebaut
Entdecken Sie, was möglich ist
Sehen Sie echte Apps, die Entwickler und Kreative weltweit mit Kliv gebaut haben
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Erkennen Sie die Versionsänderung, bevor Kunden es tun
Beschreiben Sie, wie Ihr Team APIs testet – Partner, Requests, Probes, Assertions und Zugriffsgrenzen. Kliv baut die Arbeitsumgebung, die sich daran erinnert.
