Zum Inhalt springen
DEEN

Cord Workbench

Bauen, testen und debuggen Sie Ihre Integration, ohne Cord zu verlassen: jede Anfrage, jeder Fehler, jedes Ereignis und jede Zustellung in einem einzigen Panel.

Was ist das?

Die Workbench ist die Entwicklerkonsole von Cord. Sie sitzt als Schaltfläche Entwickler am unteren Rand der App und öffnet sich zu einem Panel mit acht Tabs: Übersicht, Protokolle, Fehler, Ereignisse, Webhooks, Shell, Schlüssel und Zustand. In der oberen Leiste des Panels befindet sich der Inspektor, der jede ID findet.

API-Schlüssel, Webhooks, Protokolle und Ereignisse leben hier. MCP, Künstliche Intelligenz und Einbettbarer Angebotsrechner bleiben in den Einstellungen, im Bereich Entwickler des Verzeichnisses, weil sie einmalig konfiguriert werden.

Voraussetzungen

  • Berechtigung „Einstellungen“ in Ihrer Rolle. Ohne sie erscheint die Workbench nicht.
  • Aktivierter Entwicklermodus. Das ist eine Präferenz Ihres Kontos, nicht der Organisation.
  • Sie ist in allen Tarifen verfügbar. Der Zustellverlauf der Webhooks, Erneut versuchen und Erneut senden erfordern den Professional-Tarif oder höher.

Aktivieren

  1. Öffnen Sie Einstellungen und scrollen Sie bis ans Ende des Kategorienverzeichnisses.
  2. Aktivieren Sie den Schalter Entwicklermodus.
  3. Die Schaltfläche Entwickler erscheint unten rechts, in der gesamten App. Klicken Sie darauf, ziehen Sie sie nach oben oder drücken Sie W.

Der Entwicklermodus folgt Ihnen auf jeden Computer, an dem Sie sich mit Ihrem Konto anmelden. Sie können ihn auch unter Ihre Präferenzen ändern. Ein Link mit ?wb= oder ?wbi= (siehe Direktlinks) aktiviert ihn ebenfalls.

Das Panel

Die Workbench halb geöffnet über Angebote, im Tab Übersicht der letzten 7 Tage im Live-Modus: 2.523 API-Anfragen mit 1,9 % Fehlerquote, p95-Latenz von 412 ms und 99,5 % erfolgreichen Webhook-Zustellungen; die häufigsten Fehler nach Code, die Herkunft der Anfragen, die letzten Aktivitäten, die Integration ohne Warnungen und 3.412 von 5.000 Anfragen in diesem Monat genutzt.
  • Größe. Ziehen Sie den oberen Griff, um das Panel zu vergrößern oder zu verkleinern; lassen Sie ihn nahe am unteren Rand los, um es zu schließen.
  • Vollbild. Die Schaltfläche neben Schließen erweitert das Panel auf das ganze Fenster. Sie verlassen es mit derselben Schaltfläche, mit ⇧W oder mit Esc.
  • Optionen (⋯). Uhrzeiten in UTC anzeigen ändert sofort alle Datumsangaben im Panel, ohne die Zeitzone Ihres Kontos zu berühren. Das Menü listet außerdem die Tastenkürzel auf und verlinkt auf diese Anleitung und auf die OpenAPI-Spezifikation.
  • Umgebung. Die Workbench zeigt die Umgebung, in der sich die App gerade befindet. In der Testumgebung sehen Sie, was Ihre sk_test_-Schlüssel und die Shell im Modus Test getan haben; im Live-Modus, was Ihre Live-Schlüssel getan haben. Die Übersicht kennzeichnet das mit einem Label Test oder Live.
  • Das Panel merkt sich in diesem Browser, ob es geöffnet war, den Tab, die Höhe, das Vollbild und die UTC-Option.

Tastenkürzel

Taste Was sie tut
W Öffnet oder schließt die Workbench.
⇧W Vollbild.
/ Setzt den Cursor in den Inspektor.
1 bis 8 Wechselt zum Tab mit dieser Nummer, in der Reihenfolge der Leiste.
J / K Nächste oder vorherige Zeile in Protokolle und Ereignisse.
⌘↵ (Strg+↵ unter Windows) Sendet die Anfrage der Shell.
Esc Schließt, was geöffnet ist: Menü, Dialog, Inspektor, Vollbild und zuletzt das Panel.

Kürzel mit einem Buchstaben oder einer Zahl werden nicht ausgelöst, während Sie in ein Feld schreiben. Auf Bildschirmen unter 880 px gibt es keine Einzeltasten-Kürzel, und das Panel öffnet sich als Blatt über die ganze Breite; auf den schmalsten ist der Inspektor ein Symbol in der oberen Leiste, das sich beim Antippen aufklappt.

Die Tabs

Übersicht

Die Einstiegsansicht, mit einem Zeitraum von 24 Stunden, 7 Tagen oder 30 Tagen:

  • Kennzahlen: API-Anfragen, Fehlerquote, Latenz p95 (mit p50 darunter) und Anteil der erfolgreichen Webhook-Zustellungen.
  • Anfragen im Zeitverlauf: Balken für erfolgreiche und fehlerhafte Anfragen.
  • Häufigste Fehler: die fünf am häufigsten auftretenden Codes. Ein Klick öffnet Protokolle, gefiltert nach diesem Code.
  • Herkunft: die Anfragen nach Quelle. Ein Klick öffnet Protokolle, gefiltert nach dieser Quelle.
  • Letzte Aktivität: die letzten sechs Anfragen.
  • Rechts: die Zustandskarte (sie führt zu Zustand), die API-Nutzung diesen Monat im Vergleich zu dem, was Ihr Tarif enthält, die ersten Schritte, solange es im Zeitraum noch keine Anfragen gibt, und die Ressourcen für Entwickler.

Zur Nutzung des Monats zählen nur Aufrufe mit Live-Schlüsseln: Test-Aufrufe und Aufrufe aus der Workbench verbrauchen Ihr Kontingent nicht.

Die Quelle jeder Anfrage ergibt sich aus dem Client, der sie gestellt hat:

Quelle Wann
Node-SDK, Python-SDK, PHP-SDK, CLI Das SDK oder die CLI von Cord hat sich in der Anfrage zu erkennen gegeben.
cURL Die Anfrage kam von curl.
MCP Ein Aufruf des MCP-Servers.
Cord Elements Ein veröffentlichbarer Schlüssel (pk_), wie ihn Cord Elements verwendet.
Verbundene App Eine über OAuth autorisierte App, etwa Zapier oder Make.
Workbench Die Shell.
HTTP Jeder andere Client.

Protokolle

Jede Anfrage, die /api/v1 und den MCP-Server erreicht hat, in einer Liste mit ihren Details rechts. MCP-Aufrufe zeigen das Tool, zum Beispiel /mcp/tools/call:listar_productos.

Die Workbench in der Testumgebung im Tab Protokolle: die Schnellstart-Anfragen mit cURL und dem Testschlüssel, eine mit dem Fehler invalid_request und eine aus der Shell der Workbench, sowie das Detail von POST /v1/cotizaciones (201, 184 ms) mit Request-ID, Version 2026-10-01, Modus Test und den Schaltflächen Als cURL kopieren und In der Shell öffnen.
  • Suchen Sie nach Route, nach Request-ID (req_…), nach Fehlercode oder nach einem exakten Idempotency-Key. Eine Request-ID wird im gesamten Verlauf gesucht, unabhängig vom Zeitraum.
  • Filtern Sie nach Methode (GET, POST, PATCH, DELETE), nach Statusklasse (2xx, 4xx, 5xx), nach Schlüssel (oder nur denen der Workbench), nach Quelle und nach Zeitraum (1 Stunde, 24 Stunden, 7 Tage oder 30 Tage).
  • Live fügt alle paar Sekunden neue Anfragen oben ein, solange der Tab sichtbar ist. Mehr laden holt die nächsten 50.

Die Details einer Anfrage zeigen den Status, den Fehlercode mit seiner Meldung und einen Link So beheben Sie das zu Fehler, die Request-ID, das Datum, die Latenz, den Schlüssel, die Quelle, die API-Version, den Modus, die IP-Adresse und den Idempotency-Key. Hat Cord die gespeicherte Antwort einer wiederholten Anfrage zurückgegeben, wird das als Wiederholte Antwort markiert, und darunter stehen die anderen Anfragen mit demselben Idempotency-Key.

  • Als cURL kopieren kopiert die Anfrage, bereit zum Einfügen in Ihr Terminal: Der Header Authorization liest Ihren Schlüssel aus der Umgebungsvariablen $CORD_SECRET_KEY. Der Body ist nicht enthalten, weil er nicht gespeichert wird.
  • In der Shell öffnen lädt sie mit ihren Parametern in die Shell. Im Live-Modus erscheint das nur bei GET-Anfragen.
  • Ressource prüfen öffnet die ID aus der Route im Inspektor.

Cord speichert den Body von API-Anfragen und -Antworten nicht, nur deren Metadaten. Sie zu speichern hieße, bei jedem Aufruf Daten Ihrer Kunden (Steuernummern, E-Mail-Adressen, Beträge) aufzubewahren. Um eine vollständige Antwort zu sehen, wiederholen Sie die Operation in der Shell oder prüfen Sie das Log Ihres eigenen Servers.

Jede Anfrage wird 30 Tage aufbewahrt. Ein täglicher Prozess löscht ältere Einträge, daher ist der längste Zeitraum in Protokolle, Fehler und Übersicht 30 Tage. Das Löschen übernimmt eine Datenbankfunktion, die nur Einträge entfernt, die älter als 30 Tage sind; nicht einmal Cord kann damit etwas Neueres löschen.

Fehler

Fehlgeschlagene Anfragen, gruppiert nach Code, Methode und Route, wobei die IDs in der Route durch {id} ersetzt sind – so sehen Sie die Ursache statt jeder einzelnen Zeile. Zeitraum von 1 Stunde, 24 Stunden, 7 Tagen oder 30 Tagen. Eine Anfrage ohne eigenen Code erscheint als http_ mit ihrem Status.

Jede Gruppe zeigt, wie oft der Fehler aufgetreten ist und wann zuletzt. Beim Öffnen sehen Sie die letzte Fehlermeldung, den Pfad, das erste und letzte Auftreten, wie viele Schlüssel ihn verursacht haben, und drei Aktionen: Anfragen ansehen (Protokolle, gefiltert nach diesem Code), Beispiel ansehen (die neueste Anfrage im Inspektor) und So beheben Sie das.

Ereignisse

Der Ereignisverlauf Ihres Unternehmens: derselbe, den GET /api/v1/events zurückgibt, auch wenn Sie keinen einzigen Webhook haben.

  • Filtern Sie nach Ereignistyp, nach Zustellstatus (Fehlgeschlagen, Ausstehend, Zugestellt) und nach der ID des Objekts. Live und Mehr laden funktionieren wie in Protokolle.
  • Jede Zeile zeigt den Status ihrer Zustellungen, den Typ, das Objekt, wer das Ereignis ausgelöst hat (API, MCP, Dashboard, Workflow, Workbench, Integration oder System) und das Datum.
  • Die Details zeigen die Ereignis-ID, das Datum, das Objekt (ein Klick öffnet es im Inspektor), wer es ausgelöst hat, mit dem Namen des Schlüssels oder der Person, die Ereignisdaten und eine Zustellung pro abonniertem Endpoint: URL, Status, Versuche, nächster Versuch, das evt_…, das dieser Endpoint erhalten hat, und den letzten Fehler.
  • Erneut senden sendet eine Zustellung noch einmal mit demselben Payload und demselben evt_…, damit Ihr Server sie deduplizieren kann. Bei mehr als einer fehlgeschlagenen Zustellung erscheint Fehlgeschlagene erneut senden. Beides erfordert den Professional-Tarif oder höher.
  • Der Status des Ereignisses ergibt sich aus der letzten Zustellung an jeden Endpoint: Ein erfolgreiches erneutes Senden ersetzt den Fehlschlag. Eine Zustellung, die Cord abgebrochen hat, weil der Endpoint deaktiviert wurde, erscheint als Abgebrochen, nicht als zugestellt.

Interne Ereignisse wie quote.expiring oder invoice.due_soon tragen das Label Intern: Workflows nutzen sie, und sie werden nicht per Webhook gesendet. Testzustellungen (die Schaltfläche Testen eines Endpoints oder der Simulator ohne objeto_id) sind keine Ereignisse Ihres Unternehmens: Sie erscheinen nicht hier, sondern nur in den Zustellungen des Endpoints.

Webhooks

Ihre Endpoints, mit dem Kontingent Ihres Tarifs. Endpoint hinzufügen öffnet einen Assistenten im Vollbild:

  1. Ereignisse auswählen. Die 41 Ereignisse des Katalogs, nach Familien gruppiert, mit Suche und einem Kontrollkästchen, um eine ganze Familie auszuwählen. Alle Ereignisse umfasst auch die, die Cord später hinzufügt; wählen Sie keines aus, erhalten Sie alle.
  2. Ziel konfigurieren. Eine öffentliche URL mit https://.
  3. Secret speichern. Das Signatur-Secret (whsec_…) wird nur einmal angezeigt. Von dort aus können Sie auch Testereignis senden.
Der Tab Webhooks der Workbench im Vollbild: der ERP-Endpoint mit 93,1 % erfolgreichen Zustellungen in 7 Tagen, aufgeklappt mit seinen Zustellungen; die neueste, quote.approved im zweiten Versuch, ist mit 500 fehlgeschlagen und zeigt den genauen Payload, den Cord gesendet hat, die Antwort des Servers sowie die Schaltflächen Erneut versuchen und Ereignis ansehen.

Jeder Endpoint zeigt sein maskiertes Secret, wie viele Ereignisse er empfängt, seine letzte Zustellung und die letzten 7 Tage: Zustellungen pro Tag, Erfolgsquote und Latenz p95. Seine Aktionen:

  • Testen sendet ping oder eines seiner abonnierten Ereignisse mit Beispieldaten, in der API-Version, auf die der Endpoint festgelegt ist. Der Payload trägt "test": true auf der obersten Ebene, damit Ihr Server einen Test von einem echten Ereignis unterscheiden kann.
  • Bearbeiten, Secret rotieren (mit einem Fenster von 1, 24 oder 72 Stunden, in dem beide Secrets gültig bleiben), aktivieren oder pausieren und Löschen.
  • Reaktivieren oder Reaktivieren und wiederholen, wenn Cord den Endpoint nach einer Serie von Fehlschlägen deaktiviert hat. Die zweite Option reiht erneut ein, was in den letzten 24 Stunden fehlgeschlagen ist.
  • Wenn Sie die Zeile aufklappen, sehen Sie die letzten 50 Zustellungen. Jede zeigt Was Cord gesendet hat (den exakten Payload) und Was Ihr Server geantwortet hat (bis zu 2.000 Zeichen), mit Erneut versuchen und, wenn sie aus einem Ereignis stammt, Ereignis ansehen.

Die vollständige Anleitung (Payload, Signaturen, Katalog und Wiederholungen) finden Sie unter Webhooks.

Shell

Führt jede Operation der öffentlichen API mit Ihrer Sitzung aus, ohne einen Schlüssel zu erstellen.

  • Test läuft in Ihrer Testumgebung: Sie können Daten anlegen und ändern, ohne echte Daten zu berühren, und die Test-Simulatoren verwenden.
  • Live · nur Lesen liest Ihre echten Daten: Es lassen sich nur GET-Operationen senden.
  • Nicht in der Shell laufen Operationen, die an einen Schlüssel gebunden sind (Webhook-Endpoints über die API und Sitzungen von cord listen), sowie solche, die per Streaming antworten oder Dateien hochladen.

Wählen Sie eine Operation aus der Liste (mit Suche), füllen Sie ihre Parameter und ihren JSON-Body aus, der ein Beispiel enthält, und senden Sie sie mit Senden oder ⌘↵. Unter Optionale Header wählen Sie die API-Version (Cord-Version). Die Antwort zeigt Status, Latenz und Request-ID und hat drei Ansichten: Antwort (bis zu 200 KB), Header und Code, mit derselben Anfrage in cURL, Node-SDK, JavaScript (fetch) und Python, wobei Ihr Schlüssel als $CORD_SECRET_KEY verwendet wird. Zuletzt verwendet speichert Ihre letzten 15 Aufrufe dieser Organisation in diesem Browser.

Jeder Aufruf aus der Shell erscheint in Protokolle mit der Quelle Workbench und verbraucht nicht das API-Kontingent Ihres Tarifs. Ein Klick auf die Request-ID öffnet sie im Inspektor. Haben Sie den Aufruf in einer anderen Umgebung als der der App ausgeführt (zum Beispiel in Test, während die App live ist), wird die Request-ID nur kopiert: Wechseln Sie den Testmodus der App, um sie in Protokolle zu sehen.

Schlüssel

Der Tab Schlüssel der Workbench im Vollbild: oben 3.412 von 5.000 API-Anfragen in diesem Monat genutzt und die Version 2026-10-01; darunter geheime, eingeschränkte und öffentliche Schlüssel im Live- und Testmodus, jeweils mit maskiertem Token und den letzten 4 Zeichen, Berechtigungen, letzter Nutzung, Erstellung und Ablauf, dazu eine OAuth-Verbindung und ein widerrufener Schlüssel.
  • API-Nutzung diesen Monat im Vergleich zu dem, was Ihr Tarif enthält, und die aktuelle API-Version. Jeder Schlüssel und jeder Webhook wird auf die Version des Tages festgelegt, an dem er erstellt wird; der Header Cord-Version ändert sie pro Anfrage. Siehe Versionen.
  • API-Schlüssel: Erstellen, bearbeiten, rotieren und widerrufen Sie geheime (sk_), eingeschränkte (rk_) und veröffentlichbare (pk_) Schlüssel, im Test- oder Live-Modus. Jeder Schlüssel hat eine Schaltfläche Protokolle, die seine Anfragen der letzten 7 Tage öffnet. Über OAuth autorisierte Apps erscheinen als Autorisierte Verbindung. Siehe API-Schlüssel.
  • API-Referenz: alle Operationen, gruppiert, mit einem Beispiel mit curl, einer Schaltfläche Testen bei denen, die sich in der Shell ausführen lassen, und der Schaltfläche, die einen Integrations-Prompt für ChatGPT oder Cursor erzeugt.

Zustand

Eine Liste aktiver Warnungen, jede mit einem Link zu dem Tab, in dem sie sich beheben lässt:

  • ein deaktivierter Endpoint oder einer mit 3 oder mehr Fehlschlägen in Folge;
  • Ereignisse ohne verbleibende Versuche und überfällige Versuche in der Warteschlange;
  • eine Fehlerquote von 5 % oder mehr bei mindestens 20 Anfragen in 24 Stunden;
  • 5xx-Fehler in den letzten 24 Stunden;
  • ein Schlüssel, der abläuft, oder ein rotierter Schlüssel, der nicht mehr funktioniert, in den nächsten 7 Tagen.

Darunter drei Karten: der Status jedes Endpoints (aktiv mit Erfolgsquote und p95, pausiert, deaktiviert oder mit Fehlschlägen in Folge), die Ereigniswarteschlange (ausstehend, überfällige Versuche, endgültig fehlgeschlagen und Zustellung p95) und API in den letzten 24 Stunden (Anfragen, Fehlerquote, 4xx, 5xx und Latenz p95).

Inspektor

Fügen Sie eine ID in das Suchfeld in der oberen Leiste des Panels ein oder drücken Sie /:

  • eine Request-ID (req_…) öffnet diese Anfrage;
  • eine Ereignis-ID (evt_…) öffnet das Ereignis, aus dem sie stammt, oder sagt Ihnen, dass es eine Testzustellung war;
  • die ID eines Angebots, einer Rechnung, eines Kunden, eines Produkts, eines Schlüssels, eines Webhook-Endpoints oder eines Ereignisses.

Bei einem Objekt sehen Sie seinen Typ, seinen Namen oder seine Nummer, die Ereignisse, die es erwähnen, und die Anfragen der letzten 30 Tage, die es betroffen haben (oder die dieser Schlüssel gestellt hat). In Cord öffnen führt zu seiner Seite, wenn es eine hat, und bei einem Angebot, einer Rechnung oder einem Kunden öffnet Als API-Antwort ansehen es in der Shell. Zurück oder Esc bringen Sie zum Tab zurück.

  • /app?wb=registros öffnet die Workbench in diesem Tab. Die Namen sind resumen (Übersicht), registros (Protokolle), errores (Fehler), eventos (Ereignisse), webhooks, shell, api (Schlüssel) und salud (Zustand).
  • /app?wbi=<id> öffnet den Inspektor mit dieser ID.

Beide aktivieren den Entwicklermodus, falls er ausgeschaltet war.

Häufige Fragen

Warum sehe ich eine Anfrage nicht, die ich mit einem Testschlüssel gestellt habe? Die Workbench zeigt die Umgebung, in der sich die App befindet. Wechseln Sie in die Testumgebung, um zu sehen, was Ihre sk_test_-Schlüssel getan haben.

Zählt die Workbench gegen mein API-Kontingent? Nein. Das Navigieren im Panel ruft Ihre API nicht auf, und Aufrufe aus der Shell zählen ebenfalls nicht. Es zählen nur Anfragen mit Live-Schlüsseln.

Warum zeigt Ereignisse Ereignisse an, obwohl ich keine Webhooks habe? Weil der Tab den Ereignisverlauf Ihres Unternehmens liest, nicht die Zustellungen. Ohne Endpoints erscheint jedes Ereignis als Keine Endpoints.

Warum kann ich die Zustellungen eines Endpoints nicht sehen? Der Zustellverlauf, Erneut versuchen und Erneut senden erfordern den Professional-Tarif oder höher. Endpoints erstellen, Ereignisse empfangen, Testen, Secret rotieren und Reaktivieren sind in allen Tarifen verfügbar.

Wie lange werden die Protokolle aufbewahrt? 30 Tage ab jeder Anfrage. Wenn Sie einen längeren Verlauf brauchen, speichern Sie die Request-ID (Cord-Request-Id) und die Antwort in Ihrem eigenen System.

Sieht mein Team dasselbe wie ich? Ja. Jedes Mitglied mit der Berechtigung „Einstellungen“ sieht die Daten der Organisation. Persönlich sind der Entwicklermodus, der an Ihr Konto gebunden ist, sowie in jedem Browser die Größe des Panels und die UTC-Option. Die zuletzt verwendeten Aufrufe der Shell werden in jedem Browser pro Organisation gespeichert.