pywit: a thin Python SDK for Wit.ai that stopped shipping new features in 2020

The whole surface is one class and three methods

The README lists what `pywit` provides and it fits in a short list: a `message` method for the message API, a `speech` method for the speech API, and an `interactive` method that opens a conversational session against your bot. The constructor takes one meaningful argument, `access_token`, and that is the entire configuration surface.

The minimal example is three lines:

from wit import Wit

client = Wit(access_token)
client.message('set an alarm tomorrow at 7am')

Returning the parsed JSON response is what the `message` call gives you, and the README's own example makes that explicit by stringifying the response and prefixing it with a congratulatory message. Nothing is hidden behind an abstraction layer, which is the main appeal: there is no session object to manage, no async variant, no retry policy to learn, and no generated client to inspect.

That thinness cuts both ways. There is no batching, no streaming response, and no error taxonomy in the documented surface. When Wit.ai returns an error, what you get is whatever the underlying HTTP library surfaces, so error handling is yours to write. For a service you depend on in production, that is a real difference from the official HTTP clients for other platforms that give you typed exceptions.

Audio goes in as an open file handle with explicit content type

The `speech` method takes a file handler already opened in binary mode plus an optional headers dict, which is where you set the content type yourself:

resp = None
with open('test.wav', 'rb') as f:
  resp = client.speech(f, {'Content-Type': 'audio/wav'})
print('Yay, got Wit.ai response: ' + str(resp))

Passing a handle rather than a path or bytes means the SDK does not buffer the audio for you and does not guess at the format. You decide whether that is a feature or an inconvenience. For streaming from a microphone or an upstream service it is the right shape, since you control when and how much to read. For a quick script it is one more thing to get right, and the content type has to match the file or the API will reject it.

The README points at the message and speech endpoints in the versioned docs under 20200513, and the versioning story is worth reading before you build anything. The default API version is `20200513`, and you can target a different one by setting the `WIT_API_VERSION` environment variable:

pip install wit

That default is a fixed date string rather than a moving alias, so a request built against one version will keep hitting that version's contract until you change the variable. Whether that is reassuring or limiting depends on whether you want the platform's newer behaviour or need to match a model you trained earlier.

setup.py still imports a distutils symbol Python removed

The packaging file is the most revealing thing in the repository. It opens with a conditional import of setuptools falling back to distutils, then tries to pull the Python 2 to 3 conversion build command:

try:
    from distutils.command.build_py import build_py_2to3 as build_py
except ImportError:
    from distutils.command.build_py import build_py

That symbol came from the old Python 2 to 3 conversion toolchain, and it is the reason the file has to guess at its build command at all. On a modern interpreter where distutils is absent and setuptools has vendored or removed that path, the fallback chain is what runs. It works often enough that `pip install wit` still succeeds, which is why this has gone unnoticed, but it is a packaging file written for a world that ended years ago.

The dependency list is more surprising. Alongside `requests`, which is pinned at `>= 0.8.8` for Python 3 and below 0.10.1 for anything older, the package declares `prompt_toolkit` as its base requirement. That library is what backs the `interactive` method, and it is a heavy dependency to install for a feature most integrations never call. There is also a conditional append for `simplejson` on Python 2, and a warning branch for Python 2.5 that tells you Python 2.5 is no longer officially supported by Wit.

The version string is where the file and the releases disagree. `setup.py` reports `version="6.0.1"`, while the newest GitHub release is `v6.0.0`, published 2020-05-27 with the note Wit Refresh API update. Both cannot describe the same artifact. The practical reading is that pip installs 6.0.1 from a repository whose released history stops at 6.0.0, so there is no tagged commit matching what you get from the package index.

Licensing has two answers and neither is a license identifier

The repository metadata does not report a license type for this project, and the LICENSE file's contents are not shown anywhere in the README. The README points you at the LICENSE file in the root of the tree and stops there.

So there are two facts and you need both. There is a LICENSE file, and there is no machine-readable license designation attached to the repository. For a package published to PyPI that is worth pausing on, because package metadata consumers and automated license scanners will see the same absence you do. Anyone building on this needs to open that file and read it rather than infer from the fact that a LICENSE exists.

Two other legal pointers in the README are more specific. Terms of use and privacy policy both resolve to opensource.facebook.com legal pages, which is where the SDK's origins show: the file header in `setup.py` carries a Facebook copyright line, and the project lives under the wit-ai organisation now. The distinction that matters is between the SDK's own terms and the terms of the Wit.ai service it calls. They are separate documents, and a permissive SDK licence does not grant you anything about the service.

The last release, v6.0.0, is titled Wit Refresh API update, which dates the most recent feature work to May 2020.

Four example scripts and two zipped bot bundles

The README does not carry a tutorial. It says to see the examples folder, and the tree holds four Python scripts plus two archives: `examples/basic.py`, `examples/celebrities.py`, `examples/joke.py`, `examples/messenger.py`, alongside `examples/wit-example-celebrities.zip` and `examples/wit-example-joke-bot.zip`.

The naming suggests the scope. A joke bot and a celebrities example are the two classic Wit.ai demos, and a messenger example points at the platform's history as a Facebook product, which matches the copyright header and the terms pages. The two zip files being archives rather than plain scripts suggests they bundle more than one file, most likely intent and entity definitions that the Wit.ai console otherwise expects you to create by hand.

The `interactive` method has no runnable example in the README beyond the bare call, which is a gap if you plan to use it, since it is the one method that opens a session rather than returning a value. `prompt_toolkit` being a hard dependency explains the absence: it is a terminal UI library, so that method is a REPL, and the README does not describe the commands it accepts or how to exit it. If the REPL is not your use case, the dependency is still installed either way.

For a library this small, the examples folder is the real documentation. Worth noting that none of them are referenced individually in the README, so which one to start with is a judgement call.

An interactive REPL and a configurable logger are the customization points

The `interactive` call starts a conversation with your bot and blocks:

client.interactive()

This is the feature that justifies the prompt_toolkit dependency and the reason the SDK is more than an HTTP wrapper. For exploring a Wit.ai bot by hand, typing into a terminal is faster than writing a script per utterance. For anything automated it is the wrong tool, and mixing it into a service is a mistake, since it owns the terminal.

Logging is the other documented customization point, and the defaults are worth knowing. Logging goes to STDOUT at INFO level, which means an SDK call in a service will write to your process's standard output whether or not you asked for it. You can change the level on the client's own logger:

from wit import Wit
import logging
client = Wit(token)
client.logger.setLevel(logging.WARNING)

Or pass a whole logger object into the constructor, which is the cleaner option if your application already configures logging through the standard `logging.config` module the README links to. That constructor argument is the intended integration point for people embedding the SDK in something larger.

The maintenance picture is narrow but honest. Three releases exist, at 3.5 in May 2016, 4.0.0 in June 2016 and v6.0.0 in May 2020. The repository is not archived and the last push was on 2026-08-28, so someone is still committing to it. The gap between those two facts is the whole story of this library: the file gets maintained, the feature set has not moved since 2020.

Editorial conclusion

pywit is a good example of an SDK whose value has been overtaken by the service around it. If you are integrating Wit.ai from Python today, this gets you a correct token handshake, a message call and a speech call in a handful of lines, and the code is short enough to read in full. If you are starting a new voice or NLU project, the more important question is how much the Wit.ai platform itself is still the right dependency, and the repository does not answer that. The version mismatch is the first thing to check: setup.py carries 6.0.1 while the newest GitHub release is v6.0.0 from 2020, so a `pip install wit` gives you code that was never tagged as a release. Read that setup.py build section before pinning, because it imports a distutils symbol that recent Python versions have removed. The repository is not archived and the last push was on 2026-08-28, so the file is maintained, but no feature has shipped since May 2020.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. wit-ai/pywit on GitHub