Client libraries

Each library is a single source file you download from this page and drop into your project. Most languages need nothing else - the file uses only the standard library. Rust is the one exception: add the two crates listed in the file header (reqwest + serde_json) to your Cargo.toml and you're done. Every endpoint the Sourdough Tracker HTTP API exposes is wrapped as a typed function named after the data model and operation, so the surface mirrors the REST API one-to-one. Authentication uses the same personal access tokens the rest of the API accepts. The libraries are easy to vendor, audit, and extend directly in your own codebase.

Download

Pick your language and download the single source file. Module name for Sourdough Tracker: sourdough_client. Class name for languages with an explicit wrapper type: SourdoughClient.

Authenticate

Create a personal access token (PAT) from the Integrations menu and pass it to the library at runtime. Every language exposes the same two configuration knobs: an explicit setToken(...) call, or the XCLIENT_TOKEN environment variable for CI / scripted use. Tokens are sent as Authorization: Bearer ... on every request and the library never logs them.

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

Use the library

Save the downloaded file under your project as sourdough_client.py (or the equivalent for your language) and import the operation functions you need. Each function is named <model>_<op> (account_create, deal_list, lead_get, ...) and forwards to the matching HTTP endpoint with retry-on-429, exponential backoff, and Retry-After honoured automatically. List functions accept the standard query parameters (limit, offset, sort, q, plus the type's allowed filters); get/update/delete functions accept the row id as their first argument.

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

# List the first 20 rows
page = log_entry_list(limit=20, sort="-created_at")
print(page["data"], page["meta"]["has_more"])

# Create + read + update + delete
created = log_entry_create({"name": "Example"})
fresh   = log_entry_get(created["id"])
log_entry_update(created["id"], {"name": "Updated"})
log_entry_delete(created["id"])

Available models

Each library exposes one function per operation per model. The list below is the one-to-one mirror of the HTTP endpoints this app exposes.

Environment variables

Analytics + updates

Each call sends one analytics event to the same dashboard as the web UI (operation name, library version, OS - no field values, no request bodies) so the team running this app can see how the integration is used. The data is processed securely; an audit log of every event tied to you can be requested at any time from the company operating the app. Separately, the library checks for a newer version once every 24 hours. In interpreted languages (Python, TypeScript on Node, JavaScript on Node, PHP, Ruby, Elixir) the on-disk file is replaced atomically and the next import picks up the new bytes. In compiled languages (Go, Java, Rust, C#, C++, Kotlin, Swift, Dart, Clojure) the source file is left as-is - users ship pre-compiled artefacts, so the version probe just stamps a timestamp you can surface at build-time. Set XCLIENT_NO_AUTOUPDATE=1 to disable the probe entirely.