Tableau Server Client: the Python wrapper around the Tableau REST API

The gap between the REST API and a scriptable client

The Tableau Server REST API covers a large surface: publishing, permissions, users, groups, projects, sites, jobs, extracts, webhooks, schedules and subscriptions. The Tableau Server Client exists to put a Python object model in front of that surface. The README states the aim as increasing your productivity as you interact with the Tableau Server REST API, and says that with the library you can do almost everything you can do with the REST API, listing publish workbooks and data sources, create users and groups, and query projects, sites and more. The word almost carries the weight, and the README is careful about where the boundary is. If you want sample code that talks to the REST API directly, in Java, Python or Postman, it points you at a separate rest-api-samples repository. TSC is the object-oriented layer; the raw samples are the other option.

A small, deliberate dependency set

The pyproject.toml is where the design decisions are visible, and they are conservative. The runtime dependencies are defusedxml, packaging, requests, urllib3 and typing_extensions, with requests pinned at 2.32 or newer and urllib3 constrained to the 2.6.3 to 3 range. There is no XML parsing library of your own choosing here, because defusedxml is doing that work, and the name says what it is for. The project itself is named tableauserverclient, described as a Python module for working with the Tableau Server REST API, with the authors listed as Tableau, and the licence is MIT with the licence file declared in the build metadata. The build backend is setuptools, and the version is dynamic, taken from versioneer, which is why setup.py exists in a project that otherwise configures everything in pyproject.toml.

import versioneer
from setuptools import setup

setup(
    # This line is required to set the version number when building the wheel
    # not yet sure how to move this to pyproject.toml - it may require work in versioneer
    cmdclass=versioneer.get_cmdclass()
)

That split is a small maintenance wrinkle worth naming. Version information is derived from the git tags at build time, and setup.py exists only to wire the versioneer command classes into the build.

Python version floor and the classifier list

The README is explicit that as of October 2026 support for Python 3.9 has been dropped, and that support for older Python versions aims to match the versions listed on devguide.python.org. The pyproject.toml matches that with requires-python set to 3.10 or newer, and classifiers for 3.10, 3.11, 3.12, 3.13 and 3.14. So a team on 3.9 has to move before upgrading the library, and the library will not quietly install on an unsupported interpreter. The black configuration in the same file sets line-length = 120 and target-version for py310 through py314, and it excludes the tableauserverclient/bin/ directory from formatting, which suggests a shipped binary payload inside the package that a formatter should not touch.

The samples directory is the real API documentation

The samples/ directory is the most useful part of the repository for someone learning the library, and its file names are a map of the API. There are scripts for create_group, create_user, create_project, create_schedules, create_extract_task, add_default_permission, manage_subscriptions and kill_all_jobs, and exploration scripts for explore_datasource, explore_favorites, explore_site, explore_webhooks and explore_workbook. There are also list_jobs, export, extracts, filter_sort_groups, filter_sort_projects, inspect_connection_details, metadata_paginated_query, initialize_server, login and a getting_started folder. Two of those names hint at behaviour that is easy to get wrong by hand. filter_sort_projects and filter_sort_groups cover server side filtering and sorting, and metadata_paginated_query covers the pagination that REST APIs tend to hide. The shared file samples/_shared.py holds whatever the other samples need in common, so the samples are meant to be read together.

Testing splits into unit tests and end to end tests

The repository separates test/ from test_e2e/, and the optional test dependency group in pyproject.toml shows what each side needs. The group pins black at 26.10.1 and mypy at 2.3.1, and pulls in pytest, pytest-cov, pytest-subtests, pytest-xdist and requests-mock, with type stubs for requests. requests-mock is the give-away for the unit side: it intercepts HTTP calls so the library's request construction can be asserted without a server. The end to end side is what test_e2e/ is for, and it is not covered by that mocked approach. The mypy configuration is not a blanket strictness switch, since check_untyped_defs is set to false and a couple of error codes are disabled, which is a common choice for a library that accepts loose input from REST payloads while still typing its own surface.

Release cadence, branches and the licence badge

The release history is regular. v0.42 was published on 2026-10-15, v0.41 on 2026-06-25 and v0.40 on 2026-02-03, so the library ships roughly every four months and is still on the 0.x series, which by Python convention means the API is not yet promised to be stable. The default branch is development rather than main, so the branch you clone is the active one. The repository is not archived and the last push was on 2026-10-20, five days after the v0.42 tag. The README carries a Tableau Supported badge, which is a statement about vendor support for the tool rather than about the API surface it wraps, and a FOSSA badge that reflects automated licence scanning. The MIT licence text is in LICENSE, with a separate LICENSE.versioneer file for the vendored versioning tool.

Where the library is the wrong choice

The clearest case is when you need the endpoint itself rather than the abstraction. The library models Tableau resources as objects, which is exactly what you want for routine administration and exactly what gets in the way when a new REST endpoint appears before the library wraps it, or when you need an HTTP call the library does not expose. For that, the raw REST API samples in the other repository are the documented route. A second case is language fit. This is a Python library, so a team whose automation lives in Java, .NET or shell scripts will either run Python alongside it or use the REST API directly, and the README already points at Java and Postman samples for that reason. A third case is the environment floor: Python 3.10 or newer, with no 3.9 support left. And a practical note on the dependency set, since urllib3 is constrained below version 3, an organisation that has pinned its own HTTP stack more aggressively may find the install step a conflict to resolve rather than a one liner.

Editorial conclusion

Adopt the Tableau Server Client if your team automates a Tableau Server or Tableau Cloud from Python and you want the REST API surface wrapped in typed objects rather than hand written request code, since the sample directory documents each area of the API for you. Do not adopt it if you need the raw endpoint behaviour, because the README points you to the separate rest-api-samples repository for code that talks to the REST API directly, in Java, Python or Postman. Before you upgrade, read CHANGELOG.md and confirm your Python version is 3.10 or newer, since support for 3.9 was dropped in October 2026, and pin the urllib3 range when you install.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tableau/server-client-python on GitHub