Client-Bibliotheken

Jede Bibliothek ist eine einzelne Quelldatei, die du auf dieser Seite herunterlädst und in dein Projekt legst. Die meisten Sprachen kommen ohne weitere Abhängigkeiten aus - die Datei nutzt nur die Standardbibliothek. Rust ist die einzige Ausnahme: Füge die beiden im Datei-Header genannten Crates (reqwest + serde_json) deiner Cargo.toml hinzu, fertig. Jeder von der HTTP-API von Sourdough Tracker bereitgestellte Endpunkt ist als typisierte Funktion gekapselt, benannt nach dem Datenmodell und der Operation - die Oberfläche spiegelt damit eins zu eins die REST-API. Die Authentifizierung läuft über dieselben persönlichen Zugriffstoken wie der Rest der API. Die Bibliotheken lassen sich direkt im eigenen Code-Repo übernehmen, prüfen und erweitern.

Download

Wähle deine Sprache und lade die einzelne Quelldatei herunter. Modulname für Sourdough Tracker: sourdough_client. Klassenname für sprachen mit explizitem Wrapper-Typ: SourdoughClient.

Authentifizieren

Erstelle ein persönliches Zugriffstoken (PAT) im Integrationen-Menü und übergib es der Bibliothek zur Laufzeit. Jede Sprache bietet dieselben zwei Wege: ein explizites setToken(...), oder die Umgebungsvariable XCLIENT_TOKEN für CI / Skripte. Tokens werden als Authorization: Bearer ... mit jeder Anfrage gesendet und niemals geloggt.

from sourdough_client import set_token
set_token("pat_…")
# or, equivalently:
# export XCLIENT_TOKEN=pat_…

Bibliothek einsetzen

Lege die heruntergeladene Datei in deinem Projekt als sourdough_client.py (bzw. die Entsprechung deiner Sprache) ab und importiere die benötigten Funktionen. Jede Funktion heisst <model>_<op> (account_create, deal_list, lead_get, ...) und ruft den passenden HTTP-Endpunkt auf, inklusive Retry bei 429, exponentiellem Backoff und automatischem Beachten des Retry-After-Headers. Listen-Funktionen akzeptieren die üblichen Query-Parameter (limit, offset, sort, q sowie die für den Typ erlaubten Filter); get/update/delete-Funktionen erwarten die Datensatz-ID als erstes Argument.

from sourdough_client import log_entry_list, log_entry_get, log_entry_create, log_entry_update, log_entry_delete

# Erste 20 Datensätze
page = log_entry_list(limit=20, sort="-created_at")
print(page["data"], page["meta"]["has_more"])

# Anlegen + Lesen + Ändern + Löschen
created = log_entry_create({"name": "Example"})
fresh   = log_entry_get(created["id"])
log_entry_update(created["id"], {"name": "Updated"})
log_entry_delete(created["id"])

Verfügbare Modelle

Jede Bibliothek liefert eine Funktion pro Operation und Modell. Die Liste unten ist die Eins-zu-eins-Spiegelung der HTTP-Endpunkte für diese App.

Umgebungsvariablen

Analyse + Updates

Jeder Aufruf sendet ein Analyse-Event ans gleiche Dashboard wie die Web-UI (Operations-Name, Bibliotheksversion, OS - keine Feldwerte, keine Request-Bodies), damit das Team, das diese App betreibt, die Nutzung der Integration sieht. Die Daten werden sicher verarbeitet; ein Audit-Log aller dich betreffenden Events kann jederzeit beim Anbieter dieser App angefragt werden. Zusätzlich prüft die Bibliothek höchstens alle 24 Stunden auf eine neuere Version. In interpretierten Sprachen (Python, TypeScript unter Node, JavaScript unter Node, PHP, Ruby, Elixir) wird die Datei auf der Platte atomar ersetzt; der nächste Import lädt die neuen Bytes. In kompilierten Sprachen (Go, Java, Rust, C#, C++, Kotlin, Swift, Dart, Clojure) bleibt die Quelldatei unverändert - dort werden vorkompilierte Artefakte ausgeliefert, also stempelt der Versions-Probe nur einen Zeitstempel, den du beim Build sichtbar machen kannst. Mit XCLIENT_NO_AUTOUPDATE=1 lässt sich die Prüfung komplett abschalten.