Tableau Web Data Connector SDK: a deprecated toolkit for pulling web data into Tableau

A deprecation notice that comes before the feature description

The first substantive thing in this README is a warning, and it changes how every other line should be read. The repository will be removed with the Tableau 26.3 release, the Web Data Connector 2.X framework is deprecated, and it will not receive further updates. The recommended path is the REST API Connector on Tableau Exchange, which the README describes as built by Tableau, supporting JSON and CSV over HTTP GET, with Basic, Bearer and OAuth authentication, and running on Tableau 2023.3 and later. Two constraints on that replacement are called out, and they are the kind of detail that decides whether a migration is painless: the REST API Connector is extract-only, and it requires a JDBC driver installation. So the value of this repository today is not the SDK but the migration context it gives you.

What the WDC actually did for a Tableau user

The purpose, stated plainly, is to use the Tableau Web Data Connector to connect to web data sources from Tableau, and this repository is the SDK for it, including developer samples and a simulator to help you create connectors. The problem it solved was that Tableau's built-in connectors cover databases and files, and a lot of useful data lives behind a web API with a JSON payload. A connector written with this SDK let Tableau treat that API as a data source, so that a workbook could be built against it in the normal way. The audience was therefore two groups: developers writing a connector for an API that mattered to their organisation, and the analysts who wanted that data inside Tableau without a nightly extract pipeline. The project description in the repository metadata is short in the same spirit, bring the data you care about into Tableau, and the homepage is the project website with its documentation.

The simulator, the samples and the reference documentation

The repository layout shows how the pieces fit together, and it is worth reading because it maps to the workflow a connector author followed. There is a Simulator directory, which the README describes as helping you create your connectors, and the scripts in the package metadata show that the simulator is a small local web application rather than a test harness. Alongside it sit the Examples directory, with subdirectories for HTML, JavaScript, JSON and an OAuth proxy example, and a reference directory for the connector reference documentation. There is also a docs directory, a community directory, a news directory, a _posts directory with the site content, and the _includes, _layouts, assets and index.html files that make up the project website, plus a webpack.config.js and a .babelrc for the build. The Examples/OAuthProxyExample entry is the one that explains the OAuthProxyExample directory, and the presence of an HTML example alongside the JavaScript and JSON ones shows that connectors could be written in more than one form.

Running the simulator locally, and the port numbers it expects

The npm scripts in the package metadata describe the local development loop, and they are concrete enough to be useful even now for reading how the simulator worked. The corsproxy script exports CORSPROXY_PORT=8889 and runs the proxy, the http-server script exports SERVER_PORT=8888 and runs the server with no-cache enabled, and the start script runs both in parallel through npm-run-all. A start:bundle variant adds the webpack bundle step:

    "start": "node node_modules/npm-run-all/bin/npm-run-all --parallel corsproxy http-server",

The CORS proxy is the piece to understand. A connector fetches data from a third-party API, and the browser applies same-origin rules to that request, so a local proxy sat in front of it during development. The ports are hard-coded in the scripts, which is a small thing that matters if you are running anything else on 8888 or 8889 locally.

Lint, unit tests and an end-to-end suite run in the browser

The test setup is where the SDK's age shows, and it also explains what a connector was expected to do. Linting covers the Simulator directory with eslint over js and jsx files, with a separate fix variant and a cache. The unit tests run mocha recursively over Simulator/tests/unit with babel-core/register, and the end-to-end tests run over Simulator/tests/end-to-end, which is the significant one, since a WDC has to behave like a real Tableau connector when Tableau drives it. Coverage is enforced through nyc with thresholds of 70 for lines, functions and branches, and there is a coveralls reporter plus a travis variant of the test script. The preinstall script is unusual and worth noting for anyone trying to build this today: it runs npm install --package-lock-only with audit and scripts disabled and then npx npm-force-resolutions, which is a workaround for dependency resolution in a project whose dependency tree predates current npm.

Release tags from 2016 and a repository still receiving commits

The release history is old and the commit history is not, which is the combination you get with a project that is kept alive for maintenance but not developed. The tagged releases are Simulator v2.0.0 and v2.0.1 on 2016-07-12, and Simulator v2.1.0 on 2016-11-03, so the last named artefact is a decade old. The last push to the repository, however, was on 2026-10-19, two days before this writing, and the repository is not archived. That combination is consistent with a codebase that is still receiving small fixes while the framework around it is being retired. The licence is MIT in both the repository metadata and the README, and the package itself is published as webdataconnector at version 2.0.0. The top-level entries also include a CODEOWNERS file, an .eslintrc, a .npmrc, a .travis.yml and a _config.yml for the project site.

What the REST API Connector changes about the same job

The alternative named in the deprecation notice is the point of comparison, and the difference is architectural rather than cosmetic. The Web Data Connector SDK put a JavaScript connector on the Tableau client side, which is why the SDK is a client-side framework, why the simulator exists to emulate that behaviour locally, and why the whole thing now has a browser-shaped dependency tree with babel and webpack. The REST API Connector moves the work to the server side. The README states that it supports JSON and CSV over HTTP GET, which is a narrower data shape than a general connector, and that it handles Basic, Bearer and OAuth authentication rather than leaving the credential handling to a custom script. The trade is that the replacement is extract-only, so a workflow that expected live refresh through a connector is not equivalent, and the JDBC driver installation is new operational work for whoever runs the server. For a connector that only ever pulled a table for a periodic extract, the migration is closer to a configuration change than a rewrite.

Editorial conclusion

The Tableau Web Data Connector SDK is worth understanding only if you maintain a connector that already exists, because the 2.X framework is deprecated and will be removed with the Tableau 26.3 release. It does not fit a new connector project, since the README points those to the REST API Connector on Tableau Exchange, and it does not fit a team that needs live or bidirectional data, since the replacement is described as extract-only. Before investing more time in this repository, read the deprecation notice at the top of the README, and if you have an existing connector, plan the migration and confirm whether the extract-only and JDBC driver requirements of the replacement change your deployment model.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tableau/webdataconnector on GitHub