sentinelhub: the official Python client for Sentinel Hub satellite services

The package is a client for a service, and that shapes every decision

sentinelhub is the official Python interface for Sentinel Hub services. That single phrase explains both its value and its limits. It supports most of the services described in the Sentinel Hub documentation and any type of satellite data collection, including Sentinel, Landsat, MODIS, DEM and custom collections produced by users. What it is not is a data source. There is no archive of imagery inside this repository, no downloader that fetches scenes from a public space agency catalogue for free, and no offline mode. Every pixel you get back was processed by Sentinel Hub on their infrastructure, which means the package inherits their pricing, their quotas and their request limits. For a team that already buys Sentinel Hub services, the package is the supported way to reach them from Python. For a team looking for free imagery, it is the wrong tool regardless of how good the interface is.

Six service APIs and the OGC endpoints, all behind one Python surface

The service coverage is broad enough that most users will not need to drop to raw HTTP. There is the Process API for custom processing requests, the Catalog API for searching the catalogue, the Batch Processing API for running jobs over large areas, the BYOC API for bring-your-own-coverage data, the Statistical API for aggregated statistics rather than imagery, and the classic OGC services in the form of WMS, WCS and WFS. Alongside those sits authentication and rate-limit handling, which is where a lot of the practical value of an official client lies. Getting a bearer token, refreshing it, and coping with a service that returns 429 under load are tedious to implement and easy to get subtly wrong. The package also exposes a separate interface for the Geopedia WMS and REST API, which is a slightly different service that some users still have data in.

Geospatial utilities that would be a separate dependency otherwise

Beyond the service wrappers, the package ships basic tools and utilities for working with geospatial and satellite data, and it builds on top of well known packages such as numpy, shapely and pyproj. The utility layer covers an interface for geospatial objects and transformations, large area splitting, data collection objects and IO tools. Large area splitting deserves particular attention, because it is the operation that most often forces a batch of hand-written geometry code. Requesting imagery over a country-sized bounding box in one call is a good way to hit a limit or a bill, so splitting a request into a grid of manageable tiles, each with its own extent and resolution, is a routine requirement rather than an edge case. The dependency list confirms the approach. The package pulls in pyproj and shapely for coordinate work, utm for the conversion to local metric grids, tifffile for raster IO, pillow for image handling, requests with requests-oauthlib and oauthlib for the authenticated calls, dataclasses-json for serialising the request and response objects, click for the command line entry points, and tqdm for progress reporting on long jobs.

Installation is PyPI, conda-forge, or a source clone

The package requires Python 3.8 or later and is available from PyPI:

pip install sentinelhub

There is an extension tag for the extra dependencies needed to interact with Amazon Web Services:

pip install sentinelhub[AWS]

Conda users can install from the conda-forge channel:

conda install -c conda-forge sentinelhub

Or you can clone the repository and install it directly:

pip install .

One platform note: on Windows the README recommends installing the shapely package first from the unofficial Windows wheels repository, because a prebuilt shapely wheel for the platform otherwise is not always available. The package is then configured according to the configuration instructions in the documentation, which is where credentials are set. The build system is hatchling, with the version read from sentinelhub/_version.py, and the package publishes to both PyPI and conda-forge.

Two CDSE-flavored example sets and a large area utility notebook

The examples folder is more informative than the feature list, because it shows what people actually ask the services for. The notebooks are named for the API they exercise: process_request, catalog and data_collections, batch_processing, byoc_request, statistical_request, ogc_request, large_area_utilities, utils and reading_pu_from_headers. The last one is worth noting on its own, since processing unit headers are how a service tells you what it actually did to your request rather than what you asked for. Several examples exist in two flavours, with a _cdse suffix on one set, which reflects the two account and service arrangements the package can talk to, and there are session_sharing and data_search_cdse notebooks alongside. The documentation converts these notebooks into an Examples section, so the same content is available both as runnable notebooks in the repository and as rendered pages on readthedocs. Two webinar videos, one on the Process API in Python and one on the OGC API in Python, cover the same ground in video form.

Configuration is separate from code, and the credentials live there

Once installed, the package is configured according to the configuration instructions in the documentation, and that step is not optional if you want anything to work, since every service call needs an authenticated identity. The general shape of the package is that the configuration layer holds the client identifier and secret and the service endpoint, and the request objects at the top of each API module take that configuration as an argument. This matters for how you deploy. Credentials end up in a configuration file or environment variable rather than in your source, and the example notebooks show the flow of building a request object, passing in the configuration, and then reading a response. The package also exposes the Geopedia interface separately, which has its own credentials, so a project touching both services holds two sets of secrets.

Version 3 is a mature line, and the 2.0 break is still in the blog history

The release history shows a package that has been through a major version change and come out the other side. v3.12.0 was published on 2026-09-16, matching the last push to the repository, with v3.11.5 in March 2026 and v3.11.4 in February 2026. The blog section of the README still links the post on upgrading the sentinelhub Python package and the post on the release of version 2.0, which is useful reading for anyone arriving from an older API. The package classifiers list it as Production/Stable, intended for developers, education and science and research, on MacOS, Windows and Unix, with Python 3.8 through 3.11 listed. The licence is MIT, with the LICENSE file at the repository root, and the authors line names the Sinergise EO research team.

Editorial conclusion

sentinelhub suits a Python team that already has Sentinel Hub credentials and wants the service APIs behind a typed Python surface rather than raw HTTP calls, and the geospatial utilities are a genuine bonus for anything that has to split large areas or work with bounding boxes. It does not suit a pipeline that needs to avoid a vendor dependency, since every data path runs through Sentinel Hub services and their pricing and quotas. Before you build on it, read the configuration instructions for credential handling, confirm that the collections you need are covered by the service rather than the package, and check the CHANGELOG for the version you are pinning against, since the package has been through a 2.0 release and the upgrade notes are the reference.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sentinel-hub/sentinelhub-py on GitHub