SDK¶

There is no hand-written client library to install. Instead the API publishes its OpenAPI document, and you generate a client for your language from it.

That is deliberate: the document is produced from the running service, so a client generated from it matches what is deployed rather than whatever a hand-maintained library was last updated to.

<<INSERT API URL>>/openapi.json

A CLI is coming

A command-line client is in development — see CLI. Until it lands, generating a client or calling the API directly covers the same ground.

Generating a client¶

Any OpenAPI 3.1 generator will work. Two common ones:

openapi-generatoropenapi-python-client

openapi-generator generate \
  -i <<INSERT API URL>>/openapi.json \
  -g python \
  -o ./taiga-client

Swap -g for typescript-axios, go, java or any other supported generator.

openapi-python-client generate \
  --url <<INSERT API URL>>/openapi.json

Authenticating a generated client¶

Generators produce an authentication hook from the document's security schemes, but they cannot run the device code flow for you. Obtain a token first, then hand it to the client as a bearer credential.

The token response needs unpacking

The token endpoint returns each credential as an object, so the value to pass is access_token.token rather than access_token. Generated helpers that expect the flat OAuth shape will need a few lines of adaptation — see Device code flow.

What the document covers¶

/openapi.json describes the public and authentication-required endpoints — the same surface shown in /reference. Endpoints your role cannot reach are still described; they will answer 403 or 404 at call time rather than being absent from the client.

Regenerating¶

Additive changes ship within a major version, so a client generated today keeps working — it simply will not know about anything added since. Regenerate when you want new endpoints or fields, and on any new major version.