Wrap a WSGI application in an AWS Lambda handler function for running on API Gateway or an ALB.
A quick example:
from apig_wsgi import make_lambda_handler
from myapp.wsgi import app
# Configure this as your entry point in AWS Lambda
lambda_handler = make_lambda_handler(app)Improve your Django and Git skills with my books.
Installation
Use pip:
python -m pip install apig-wsgiPython 3.9 to 3.14 supported.
Usage
Use apig-wsgi in your AWS Lambda Function that you attach to one of:
Both “format version 1” and “format version 2” are supported (documentation). apig-wsgi will automatically detect the version in use. At time of writing, “format version 2” is used for Lambda Function URLs and API Gateway HTTP APIs.
make_lambda_handler(app, binary_support=None, non_binary_content_type_prefixes=None)
app should be a WSGI app, for example from Django’s wsgi.py or Flask’s Flask() object.
binary_support configures whether responses containing binary are supported. The default, None, means to automatically detect this from the format version of the event - on it defaults to True for format version 2, and False for format version 1. Depending on how you’re deploying your lambda function, you may need extra configuration before you can enable binary responses:
ALBs support binary responses by default.
API Gateway HTTP APIs support binary responses by default (and default to event format version 2).
API Gateway REST APIs (the “old” style) require you to add '*/*' in the “binary media types” configuration. You will need to configure this through API Gateway directly, CloudFormation, SAM, or whatever tool your project is using. While this supports a list of binary media types, using '*/*' is the best way to configure it, since it is used to match the request ‘Accept’ header as well, which WSGI applications often ignore. You may need to delete and recreate your stages for this value to be copied over.
Note that binary responses aren’t sent if your response has no ‘content-encoding’ header and a ‘content-type’ header starting ‘text/’, ‘application/json’, or ‘application/vnd.api+json’. This behaviour is to support sending larger text responses, since the base64 encoding would otherwise inflate the content length. To avoid base64 encoding other content types, set non_binary_content_type_prefixes to a list or tuple of content type prefixes of your choice, which replaces the default list.
If the event from API Gateway contains the requestContext key, for example on format version 2 or from custom request authorizers, this will be available in the WSGI environ at the key apig_wsgi.request_context.
If you want to inspect the full event from API Gateway, it’s available in the WSGI environ at the key apig_wsgi.full_event.
If you need the Lambda Context object, it’s available in the WSGI environ at the key apig_wsgi.context.
If you’re using “format version 1”, multiple values for request and response headers and query parameters are supported. They are enabled automatically on API Gateway but need explicit activation on ALBs. If you need to determine from within your application if multiple header values are enabled, you can can check the apgi_wsgi.multi_value_headers key in the WSGI environ, which is True if they are enabled and False otherwise.
Example
An example Django project with Ansible deployment is provided in the example/ directory in the repository. See the README.rst there for guidance.
1 maintainer
Metadata
1 maintainer
Release files for apig-wsgi 2.20.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| apig_wsgi-2.20.0.tar.gz | 17.2 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| apig_wsgi-2.20.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 25.6 kB
Release files / apig_wsgi-2.20.0.tar.gz
| Download URL | apig_wsgi-2.20.0.tar.gz |
|---|---|
| Size | 17.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
9c6aea1e96688b5848efb409ae3c3afb4ed2b162cd71dab683b1466a7387b964
|
|
BLAKE2b-256 checksum How to use checksums |
904a3036a3cd4fdec296b510b366a5e69e4784abce836d57de5f8a3c6ee96691
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 8, 2025.
Transparency logRelease files / apig_wsgi-2.20.0-py3-none-any.whl
| Download URL | apig_wsgi-2.20.0-py3-none-any.whl |
|---|---|
| Size | 8.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5489b3590a748d42b8c040ca11e776ce9eecbb00ae34f509ce82a89f5babfc47
|
|
BLAKE2b-256 checksum How to use checksums |
38d2dfdc29f172c9c8f73b895aeae285717585905a4a9c0d677ed7a1cd7f9812
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 8, 2025.
Transparency log
