FalconPy: the Python SDK for the CrowdStrike Falcon API

What FalconPy is: an OAuth2 wrapper over hundreds of Falcon operations

FalconPy is the CrowdStrike Falcon SDK for Python, and it contains a collection of Python classes that abstract CrowdStrike Falcon OAuth2 API interaction, removing duplicative code and allowing developers to focus on just the logic of their solution requirements.

The scale is what makes the abstraction worth having. There are many CrowdStrike Falcon API service collections collectively containing hundreds of individual operations, and all of which are accessible to your project via FalconPy. Every one of those operations is a request with a path, a method, a body and a set of scope requirements, and the SDK's job is to turn that into a Python call you make once rather than an HTTP request you assemble by hand.

The audience is security engineers and developers who automate against the Falcon platform, which in practice means detection engineering, incident response tooling, asset inventory, and anything else that needs to talk to the platform on a schedule. The repository topics name the domain outright: `devsecops`, `security-automation`, `crowdstrike-apis`, `oauth2` and `sdk`, and the classifier in the package metadata lists `Topic :: Security` and `Topic :: System :: Systems Administration`.

The licence is the Unlicense, which is a public domain dedication, and the package metadata records it as `License :: OSI Approved :: The Unlicense (Unlicense)`. The homepage is the CrowdStrike developer portal page for the Python SDK, at developer.crowdstrike.com/sdks/python.

The last push to the tree was on 2026-10-19, the repository is not archived, and the releases are recent and regular: v1.6.6 on 2026-09-28, v1.6.5 on 2026-08-20 and v1.6.4 on 2026-07-20. The package is published on PyPI as `crowdstrike-falconpy`.

One thing the README does not do is hide its own opinion of itself. It compares the SDK to the One Ring, with a line of verse about one SDK to rule them all. It is a joke, and it is also a reasonable hint about the scope, because an SDK that reaches every service collection in a platform does have a wide surface.

Token management is the part the SDK takes away from you

The claim the documentation leads with is that the SDK completely abstracts token management, and it is worth understanding why that matters, because OAuth2 in a server to server context is where most of the boilerplate lives.

The Falcon APIs are protected by OAuth2, so a client needs a client id and secret, exchanges them for an access token, and refreshes that token when it expires. Doing that correctly means handling expiry, handling a failed refresh, and handling a 401 that happens mid-flight. FalconPy takes all of that, and the developer is left with the operation.

Alongside token handling, the SDK supports interaction with all CrowdStrike regions, which matters because Falcon is a multi-region platform and a hardcoded region or base URL is a classic source of a client that works in one tenant and fails in another. It also supports custom connection and response timeouts, routing requests through a list of proxies, disabling SSL verification, and custom header configuration.

Those last four are the configurable knobs, and each one corresponds to a deployment reality. A corporate network with an egress proxy needs the proxy list. A test harness pointing at a mock endpoint needs the base URL and the timeout control. A site that terminates TLS with an internal certificate authority needs SSL verification disabled, which is a legitimate setting and also the kind of setting that should be confined to a test configuration rather than enabled broadly.

So the abstraction is not only over the API surface. It is also over the transport, and the transport knobs are exposed rather than buried, which is the right call for an SDK that has to work inside other people's networks.

Two ways in: the service classes and the Uber Class

The SDK provides two distinct methods for interacting with CrowdStrike's API, and the documentation puts them side by side in a comparison table with relationship diagrams for each.

The service classes approach gives you one class per API service collection, each providing an interface to the operations available in that collection. This is the shape most people will want, because it mirrors how the API reference is organised, and it means the name of the class tells you which part of the platform you are touching before you read the method name.

The Uber Class approach is a single class that reaches all of the service collections. The trade-off is the usual one. With one entry point you avoid a large import block and you can select a service at runtime, which is convenient when the service is a configuration value or a parameter. You also give up the compile-time and import-time signal about what a given call touches, and a script that reaches for the Uber Class by habit can quietly call into a different part of the platform than the author intended.

Whichever you pick, the operations underneath are the same hundreds of individual operations the API reference documents, so the difference is ergonomics rather than capability.

The samples directory in the repository is organised along the same lines, one directory per service area, and the visible names give a good sense of the platform's breadth: alerts, authentication, containers, correlation rules, CSPM registration, custom IOA, detects, device control policies, discover, discover AWS, exposure management, FalconX sandbox, filevantage, firewall management, flight control, hosts, identity, incidents, installation tokens, intel, IOA exclusions, IOC, and malquery, among others. A `samples/config_sample.json` and a `samples/README.md` sit at the top of that tree.

Supported versions, and the tail of Python 3.8

The SDK was developed for Python 3, and current versions provide support for Python versions 3.8 through 3.14. Every commit to the code base is unit tested for functionality using all versions of the library currently supports, which is a strong statement about the test matrix rather than a claim on a badge.

The repository topics list the same range as separate tags, `python38` through `python314`, and the package metadata requires Python 3.8 or newer, with a classifier for each minor version from 3.8 to 3.14.

There is one compatibility note worth carrying forward, because it is the kind of thing that silently breaks a build. Developers working with Python version 3.6 will need FalconPy versions less than 1.4.0, and developers working with Python version 3.7 will need versions less than 1.6.0. So if you are on an end of life interpreter, the SDK is still usable, but only on an older release line, which means you are also not getting the current operations.

Operating system support is broader than the unit test matrix. The SDK is unit tested on macOS, Ubuntu and Windows, and will also run on Amazon Linux, CentOS, Fedora, RedHat, Arch, Debian, Kali, Pop! OS, SUSE and openSUSE. That list is a statement about where the maintainers expect people to deploy it, and Kali's presence says something about the audience.

The details of supported operating systems and Python versions, along with project security and testing procedures, are collected in the repository's `SECURITY.md`.

The dependency list is two packages, and the dev list says what they check

The runtime dependency list in the package metadata is short enough to read in one breath.

requires-python = ">=3.8"
dependencies = [
    "requests",
    "urllib3",
]

That is requests and urllib3 and nothing else. There is no date parsing library, no config framework, no logging facade, no retry library of their own, and no CLI parser in the runtime requirements. For an SDK that abstracts hundreds of operations, that is a strong statement about the discipline behind it, and it also means the transitive dependency tree you inherit is small enough to reason about.

The development dependencies tell you what the project checks itself with.

[project.optional-dependencies]
dev = [
    "bandit",
    "coverage",
    "flake8",
    "pydocstyle",
    "pylint",
    "pytest",
    "pytest-cov"
]

Bandit is a static security linter, which is a reasonable inclusion for a security SDK. Flake8 and pylint cover style and lint, pydocstyle checks docstring conventions, pytest and pytest-cov run the suite and measure it. The repository carries a `.flake8` file and a `.pylintrc` at the root, so both tools are configured rather than run with defaults.

The build backend is hatchling, pinned below 1.30.0, and the `requirements.txt` in the repository is autogenerated by pip-compile from a `requirements.in`, with the header comment explaining how to update it. The `requirements-dev.txt` file sits alongside it.

The rest of the repository is the standard shape for a project of this kind: `src/` for the package, `tests/` for the suite, `docs/` for the documentation, `util/` for tooling, `samples/` for the example scripts, plus AUTHORS.md, CHANGELOG.md, CITATION.cff, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, SUPPORT.md, an OSSMETADATA file, and a pyproject.toml driven by hatchling.

Where FalconPy is the wrong choice, and what the alternatives are

The first limitation is the obvious one and it is not a criticism of the code. This SDK only talks to CrowdStrike Falcon, and it only helps if you have a Falcon tenant to talk to. If your security data lives somewhere else, this is not the abstraction you want, and the operations vocabulary in the samples directory will not map onto your platform.

The second is scope of the platform behind the SDK. Every operation requires the corresponding OAuth2 scope in your API client, and the SDK makes the request easy; it does not make the authorisation available. The SDK makes the request easy; it does not make the authorisation available. Anyone planning a deployment needs to know which service collections their tenant actually exposes, and the repository cannot answer that.

The third is the abstraction cost itself. The Uber Class and the service classes both hide the HTTP underneath, which is the point, but it also means a custom request, an unusual header or a newly released operation may not be reachable until the SDK catches up. A raw HTTP client against the documented API reference will never lag behind the platform, at the cost of handling OAuth2 and response shapes yourself. The difference in approach is direct: FalconPy is a library over a specific vendor's API, and the raw API is the vendor's own contract.

A generated client is a third path some teams take, and the API reference at developer.crowdstrike.com is the authoritative source for operations, but the SDK release cadence here is frequent enough that tracking it is rarely the bottleneck.

For a team that lives in the Falcon platform and wants the ergonomics, FalconPy is the sensible choice. For a team with a single, unusual operation to call, the raw API is probably less work.

Editorial conclusion

Adopt FalconPy if you automate against a CrowdStrike Falcon tenant and want the OAuth2 token lifecycle handled for you, the service collections exposed as classes, and a runtime dependency list of only requests and urllib3. Do not adopt it if your security data lives in another platform, or if you only need one unusual operation that a raw client against the API reference would reach without waiting for an SDK release. Before you build, confirm which service collections your tenant actually exposes, since your API client needs the matching OAuth2 scope, and check the `samples/` directory for the service area you care about, because the sample scripts show the request shapes the SDK produces.

Frequently asked questions

Official sources

1. CrowdStrike/falconpy on GitHub
2. License: Unlicense
3. Project website
4. README
5. Releases