Architecture
How the Znuny Python SDK is structured and how it talks to GenericInterface.
Architecture — Znuny Python SDK
The znuny PyPI package is a Znuny-branded layer over a shared GenericInterface client implementation.
flowchart LR
App[Your Python app] --> Znuny[znuny package]
Znuny --> GI[otrs_gi_core]
GI --> REST[Znuny GenericInterface REST]
CLI[znuny-cli] --> GI
What you import
from znuny import ZnunyClient, ClientConfig, TicketCreate, ZnunyError
ZnunyClient is the async HTTP client. Domain models (TicketCreate, TicketSearch, …) are Pydantic v2 types validated before each request.
Request flow
- You call
client.login(BasicAuth(...)). - Each method builds a JSON payload (credentials + ticket data).
- The client POSTs/PUTs to
{base_url}/Webservice/{name}/{operation}. - Responses are parsed into
Ticketmodels or raiseZnunyError.
Znuny-specific defaults
| Area | Znuny behavior |
|---|---|
| CLI | znuny-cli uses Znuny console paths (otrs.Console.pl) |
| Setup wizard | Detects Znuny installations for webservice import |
| Public API | ZnunyClient, ZnunyError, setup_znuny_system |
The HTTP protocol and ticket models match what Znuny exposes through GenericInterface — the same OTRS-family API Znuny inherited.
CLI vs library
| Component | Purpose |
|---|---|
ZnunyClient | Runtime ticket CRUD from your application |
znuny-cli setup-system | One-time webservice and user provisioning on the Znuny server |
