Als wir Provedly mit KI-Assistenten verbunden haben, war eine Designfrage wichtiger als alle anderen. Ein Assistent mit einem Schreibschlüssel kann Widgets pausieren, Leisten anlegen und bearbeiten und Einträge hinzufügen. Sollte er auch einen Eintrag als verifiziert markieren können?
Die Antwort ist nein, für jeden Schlüssel, über jedes Tool, in jedem Plan. Dieser Beitrag erklärt, wo die Grenze liegt und warum wir sie dort gezogen haben.
Was „verifiziert“ bei Provedly bedeutet
Ein Eintrag trägt die Kennzeichnung „Verifiziert“, wenn er über einen signierten Webhook von Stripe, Shopify oder WooCommerce bei Provedly ankommt und die Signatur zu dem Secret passt, das für diese Verbindung hinterlegt ist. Die Shop-Plattform signiert die Daten; Provedly prüft die Signatur beim Eingang. Passt sie, kann der Eintrag nur von dieser Plattform stammen und beschreibt eine Bestellung, die die Plattform verarbeitet hat.
Das ist die ganze Definition. Sie ist absichtlich eng. Die Kennzeichnung „Verifiziert“ macht eine bestimmte Aussage, nämlich dass ein Zahlungssystem diesen Kauf gemeldet hat, und sie ist die einzige Aussage im Widget, bei der ein Besucher uns nicht einfach glauben muss. Die öffentliche Verifizierungsseite listet für jedes Widget Quellen und Anzahlen auf, damit er es prüfen kann.
Die Mechanik wird in wie verifizierte Kaufbenachrichtigungen funktionieren und Webhook-Signatur-Secrets erklärt beschrieben.
Was ein Assistent mit Einträgen tun kann
Mit einem Schlüssel mit Lese- und Schreibzugriff kann ein Assistent add_record aufrufen, und ein Backend kann POST /widgets/{token}/records aufrufen. Beides ist nützlich. Viele echte Käufe laufen nicht über einen verbundenen Shop: eine per Überweisung bezahlte Rechnung, eine telefonisch aufgenommene Bestellung, ein Verkauf auf einer Plattform ohne signierten Webhook.
So hinzugefügte Einträge behalten die Quelle API und tragen ein sichtbares „Imported“-Label. Sie erscheinen im Widget, sie tauchen in den Zählungen der Verifizierungsseite unter ihrer eigenen Quelle auf, „Site owner's backend (API)“, und sie tragen nie die Kennzeichnung „Verifiziert“. Es gibt in der API kein Feld, um sie zu setzen, und kein Tool, das sie nachträglich ändert, egal mit welchem Schlüssel.
Warum die Grenze dort liegt
Überleg, was ein Schlüssel beweist. Eine Anfrage mit gültigem Provedly-Schlüssel beweist, dass der Aufrufer den Schlüssel hat. Sie sagt nichts darüber, ob Geld geflossen ist. Ein signierter Webhook ist etwas anderes: Die Signatur stammt von der Zahlungsplattform, erzeugt mit einem Secret, das diese Plattform nur mit dir und Provedly teilt.
Könnte ein API-Aufruf einen Eintrag als verifiziert markieren, würde die Kennzeichnung „Verifiziert“ bedeuten: „Jemand mit dem Schlüssel hat es gesagt“. Genau das bieten die meisten Benachrichtigungstools bereits: ein Formular, in das du Name, Stadt und Produkt eintippst, und einen Toast, der genauso aussieht wie ein echter. Besucher haben gelernt, solche Toasts abzuwerten, und die FTC-Regel zu gefälschten Bewertungen hat erfundenen Social Proof zu einer rechtlichen Frage gemacht, nicht nur zu einer Vertrauensfrage.
Ein KI-Assistent verschärft das Problem, er verändert es nicht. Er ist sehr gut darin, plausible Namen, Städte und Produkte in Mengen zu erzeugen. Stell das neben einen Verifizieren-Button, und heraus kommt ein Generator für falsche Benachrichtigungen, der mit einem Satz läuft. Wir möchten lieber, dass der Assistent es nicht kann, als uns darauf zu verlassen, dass er ablehnt.
Prompts, die an die Grenze stoßen
Leute werden es versuchen. Das passiert dann:
| Anfrage | Ergebnis |
|---|---|
| „Markiere die letzten fünf Einträge als verifiziert“ | Dafür gibt es kein Tool; der Assistent sagt das |
| „Füge 20 Käufe aus verschiedenen Städten hinzu“ | Hinzugefügt, als Imported gekennzeichnet, wenn der Schlüssel schreiben darf |
| „Lass den Besucherzähler 30 Personen anzeigen“ | Nicht möglich; die Zahl ist echte Anwesenheit |
| „Importiere meine Stripe-Bestellungen als verifiziert“ | Verbinde den Stripe-Webhook; nur der verifiziert |
Bei der zweiten Zeile lohnt es sich zu verweilen. Ein Schreibschlüssel kann Einträge hinzufügen, und Provedly kann nicht wissen, ob ein Name, den du diktierst, zu einem echten Käufer gehört. Genau deshalb tragen diese Einträge ein Label statt eines Badges. Nutzt du add_record für etwas anderes als echte Käufe, sagen das Label und die Verifizierungsseite jedem, der hinschaut, was sie sind.
Was dir das bringt
Die Grenze ist eine Einschränkung, und sie ist zugleich der Grund, warum sich das Produkt lohnt. Weil sich die Kennzeichnung „Verifiziert“ nicht aus einem Chatfenster erzeugen lässt, bedeutet sie noch etwas, wenn ein Besucher sie sieht, und der Link zur Verifizierungsseite an jedem Badge lässt ihn das bestätigen. Ein Wettbewerber, der seinen Besuchern „verifiziert“ per Schalter verkündet, kann dasselbe nicht bieten.
Sie schützt dich außerdem vor deinen eigenen Tools. Ein geleakter Schlüssel, ein fehlerhaftes Skript oder ein Assistent, der einen Prompt missverstanden hat, kann gekennzeichnete Einträge hinzufügen, die du dann löschst. Keiner davon kann einen falschen verifizierten Kauf auf deine öffentliche Seite bringen.
Häufige Fragen
Kann ich Einträge von einer Plattform verifizieren, mit der Provedly nicht verbunden ist?
Nicht als „Verifiziert“. Sende sie über die Records-API, wo sie mit dem Imported-Label erscheinen. Bietet die Plattform signierte Webhooks an, ist das der Weg zu einer künftigen Anbindung.
Schaden API-Einträge meinem Widget?
Sie erscheinen mit dem Imported-Label, ohne die Kennzeichnung „Verifiziert“, und werden unter ihrer eigenen Quelle gezählt. Für echte Käufe aus anderen Kanälen ist das korrekt, und Besucher sehen, warum.
Könnte ein künftiger Plan oder eine Einstellung KI-Verifizierung erlauben?
Nein. Die Verifizierung hängt an einer Signatur der Zahlungsplattform, und kein Plan und keine Einstellung ersetzt das.
Erstelle ein kostenloses Konto und verbinde Stripe, Shopify oder WooCommerce, um verifizierte Einträge ankommen zu sehen.