aiocoap – The Python CoAP library

The aiocoap package is a Python implementation of CoAP, the Constrained Application Protocol (RFC 7252, more info at

It uses the Python 3’s asynchronous I/O to facilitate concurrent operations while maintaining a simple to use interface and not depending on anything outside the standard library.

aiocoap is originally based on txThings. If you want to use CoAP in your existing twisted application, or can not migrate to Python 3 yet, that is probably more useful to you than aiocoap.


For how to use the aiocoap library, have a look at the Guided Tour through aiocoap, or at the Usage Examples and CoAP tools provided. All the details are in the aiocoap module documentation.

All examples can be run directly from a source code copy. If you prefer to install it, the usual Python mechanisms apply (see Installing aiocoap).

Features / Standards

This library supports the following standards in full or partially:

  • RFC7252 (CoAP): missing are a caching and cross proxy implementation, proper multicast (support is incomplete); DTLS support is client-side only so far, and lacking some security properties.
  • RFC7641 (Observe): Reordering, re-registration, and active cancellation are missing.
  • RFC7959 (Blockwise): Multicast exceptions missing.
  • RFC7967 (No-Response): Basic support, but not automated in library
  • RFC8132 (PATCH/FETCH): Types and codes known, FETCH observation supported
  • draft-ietf-core-resource-directory: A standalone resource directory server is provided along with a library function to register at one. They lack support for groups, PATCHes to endpoint locations and security considerations, and are generally rather simplistic.
  • draft-ietf-core-object-security-06 (OSCORE, formerly OSCOAP): Infrastructure for supporting it is in place (lacking observe and inner-blockwise support), but no simple way exists yet for launching protected servers or requests yet.

If something described by one of the standards but not implemented, it is considered a bug; please file at the github issue tracker. (If it’s not on the list or in the excluded items, file a wishlist item at the same location).


Basic aiocoap works out of the box on Python 3.5 or greater. Full functionality is currently available only on Linux and possibly some BSDs (see platform issues). For Windows, macOS and uvloop, limited transports for server and client operation are available and automatically enabled, but see their respective caveats.

Some components (eg. servers that should auto-generate .well-known/core resources, OSCORE, DTLS) require additional packages to be present; they are automatically installed when following the Installing aiocoap instructions. For slimmer systems, see for the definition of the “extras”.

Developers of projects building on aiocoap should specify the required extras in their own dependency statements. For example, an application that provides a server with a .well-known/core file and OSCORE will want to depend on aiocoap[linkheader,oscore] >= 0.4a1.


aiocoap tries to stay close to PEP8 recommendations and general best practice, and should thus be easy to contribute to.

Documentation is built using sphinx with ./ build_sphinx; hacks used there are described in ./doc/README.doc.

Bugs (ranging from “design goal” and “wishlist” to typos) are currently tracked in the github issue tracker.

Unit tests are implemented in the ./tests/ directory and easiest run using ./ test; complete test coverage is aimed for, but not yet complete (and might never be, as the error handling for pathological network partners is hard to trigger with a library designed not to misbehave). The tests are regularly run at the CI suite at gitlab, from where coverage reports are available.

Relevant URLs