Autobahn|Python: WebSocket and WAMP for Twisted and asyncio

What Autobahn|Python is for, and who ends up using it

The library solves one problem twice over: getting real-time messages between Python processes. WebSocket gives you a bidirectional channel over a single TCP connection, and the README describes it as bidirectional real-time messaging on the Web and beyond. WAMP sits on top of that channel and adds two application-level patterns, asynchronous Remote Procedure Calls and Publish and Subscribe, in one protocol.

The distinction matters because WAMP is a routed protocol. The README is explicit that you need a WAMP Router to connect Autobahn|Python based clients, and points at Crossbar.io or the other router implementations listed on wamp-proto.org. That is a deployment decision, not a library decision, and it is the single biggest thing separating this project from a bare WebSocket toolkit.

The people who end up here are usually building one of three things. A backend that has to push state to browsers and to other backends at the same time. A service mesh of Python processes that want RPC without hand-rolling a message envelope. Or a test target: the README notes that the project passes the Autobahn Testsuite strictly for both client and server, which makes it a reference implementation for people checking their own WebSocket code against a known-good peer.

Two runtimes, three APIs, one protocol stack

The package ships parallel module trees. Imports come from autobahn.twisted.websocket or autobahn.asyncio.websocket depending on which event loop you are on, and the README's echo server example shows both import lines side by side with a comment marking the alternative. The WAMP side mirrors this split. This is the design choice that shapes everything else: instead of picking asyncio and leaving Twisted users behind, the project maintains two adapters over shared protocol logic.

On the WebSocket side the README lists message-, frame- and streaming-APIs. Those are three levels of abstraction over the same connection. A message API hands you a complete payload. A frame API exposes the RFC6455 framing. A streaming API lets you consume a large message in pieces rather than buffering it. Which one you pick is a memory and latency trade-off, and the documentation is where you would check the exact semantics; the README only names them.

The protocol coverage is broad by Python standards: RFC6455 plus Draft Hybi-10+, WebSocket compression via the per-message compression draft, TLS, and proxies. The runtime matrix is CPython and PyPy. That combination is why the dependency list in pyproject.toml is short, with txaio as the abstraction layer that lets the same code run under either framework.

Installing Autobahn|Python and running a first echo server

The package is published on PyPI under the name autobahn, and pyproject.toml declares requires-python as >=3.11. The README is blunt about the version floor: earlier release lines supported older interpreters, up to v19.11.2 for Python 2 and 3.4+, up to v20.7.1 for 3.5+, and up to v21.2.1 for 3.6+. If you are pinned to an older interpreter, you are also pinned to an older Autobahn, and no amount of pip upgrading will change that.

Install it with pip:

pip install autobahn

That pulls in txaio, the compatibility layer between Twisted and asyncio. If you intend to use Twisted, install that too, because Autobahn does not choose your event loop for you.

pip install twisted

The README's first example is a WebSocket echo server. The class inherits from WebSocketServerProtocol and overrides lifecycle callbacks, with the import line switching between the Twisted and asyncio variants:

from autobahn.twisted.websocket import WebSocketServerProtocol
# or: from autobahn.asyncio.websocket import WebSocketServerProtocol

class MyServerProtocol(WebSocketServerProtocol):

    def onConnect(self, request):
        print("Client connecting: {}".format(request.peer))

    def onOpen(self):
        print("WebSocket connection open.")

The callbacks you should expect to see fire are onConnect with a request object carrying the peer, then onOpen once the handshake completes. The README's excerpt stops before onMessage, but that is the callback that receives payload and isBinary. The repository keeps a larger set under examples/, split into examples/twisted/ and examples/asyncio/, with examples/run-all-examples.py to drive them and examples/running-the-examples.md describing how. If the README example is not enough, that directory is the next place to look rather than the API reference.

The WAMP router dependency is the real adoption cost

Nothing in this library makes WAMP work on its own. The README states the constraint plainly: WAMP is a routed protocol, so you need a WAMP Router to connect your clients. Crossbar.io is the project's own router, and the README links to a list of other options on wamp-proto.org. That means a WAMP deployment is at minimum two moving parts, and the router is a separate process with its own configuration, its own upgrade cadence and its own failure modes.

This is the case where Autobahn|Python is the wrong tool. If your requirement is a browser talking to one Python process over a socket, adding a router buys you nothing and costs you an operational dependency. Plain WebSocket, or a smaller library that only does WebSocket, will be easier to reason about. The routed model earns its keep when you have many clients and many service providers that should not know about each other, which is exactly the pub/sub and RPC topology WAMP was designed for.

A second limitation is the interpreter floor. Python 3.11+ excludes a large amount of deployed code, and the README's version history shows the project has raised that floor repeatedly over the years. Teams on older interpreters should plan a migration before they plan an Autobahn upgrade.

How Autobahn|Python compares to a plain websockets library

The obvious alternative is the websockets library, which implements WebSocket without WAMP. The difference in approach is architectural rather than cosmetic. websockets gives you a connection object with send and receive, and you build your own message envelope, your own routing and your own request/response correlation on top. Autobahn|Python gives you the same WebSocket layer plus a defined application protocol with registered procedures and topics, and it hands the routing to a separate process.

That trade runs in both directions. With websockets you own the semantics, so there is nothing to learn beyond the socket and no second process to run. With Autobahn you inherit WAMP's model, which means your services register callable procedures and your publishers publish to topics, and the router decides who receives what. If you have ever hand-written a correlation ID table and a subscription registry in a WebSocket service, that is the code WAMP replaces.

The second axis is the event loop. Autobahn|Python runs on both Twisted and asyncio, which matters if you are maintaining a Twisted codebase and do not want to port it. Most modern Python WebSocket libraries assume asyncio only. For a greenfield asyncio project that difference is irrelevant; for an existing Twisted service it is the deciding factor.

Licence, the AI policy change, and what upgrading costs

The README states the project is open source under the MIT license, and pyproject.toml declares license = "MIT". The repository metadata reports the licence as NOASSERTION, which reflects how the host classifies it rather than a different licence; the LICENSE file in the repository root is the authoritative text, and anyone embedding this in a product should read it there rather than rely on a classifier.

The upgrade cost is unusual and worth reading before you pin anything. The README carries an AI policy notice stating that up to and including release v25.6.1 the project contains no code or documentation generated with AI assistance, that v25.6.1 is the final release under the historical contribution policy, and that subsequent releases may contain code or documentation created with AI assistance. The notice asks users to review AI_POLICY.md, which covers contribution rules and warranties and the intellectual property implications, and notes the policy followed an open discussion in GitHub issue #1663. The README then says that if the new policy is incompatible with your development practices or risk tolerance, you should take that into account when deciding whether to upgrade beyond v25.6.1.

That is an explicit invitation to stay on v25.6.1, and it is the kind of thing that should go through whatever review your organisation applies to dependency provenance. The practical cost of staying put is that you stop receiving fixes; the practical cost of moving is that you accept the new policy terms. There is no third option here. Separately, the interpreter floor means any upgrade path also has to clear Python 3.11.

Editorial conclusion

Adopt Autobahn|Python if you need WAMP's routed RPC and pub/sub on top of WebSocket and you are running Python 3.11 or later on Twisted or asyncio; skip it if you only need a WebSocket client, since the protocol layer adds a router dependency you would never use. Before upgrading past v25.6.1, read AI_POLICY.md and decide whether its terms fit your organisation, and pin the version in pyproject.toml until you have.

Frequently asked questions

Official sources

1. crossbario/autobahn-python on GitHub
2. Issues
3. Project website
4. README
5. Releases