In the CITWIN project, a generic digital twin framework is being developed to analyze changes in active mobility infrastructure in the context of the 15-minute city. To integrate accessibility analyses into this architecture, a standalone REST API was implemented using Python / FastAPI. The API provides the calculation of walking- and cycling-based accessibility to public transport stops as a service and delivers the results as spatial layers for further processing and visualization.

The underlying geo-pipeline is based on a routable network with weighted edges for walkability and bikeability derived from NetAScore. Input data (origins, destinations, OD data) are spatially preprocessed and constrained to the analysis area. Catchment areas are determined using a defined time threshold (e.g., 15 minutes). In addition, a filtered graph is generated that contains only edges above a defined quality threshold (e.g., Bikeability ≥ 0.5). Accessibility is calculated both on the complete network and on the filtered graph. For each destination point (e.g., a transit stop), the analysis determines how many origin points (e.g., households) can reach it within the defined limits in both network variants. Within the filtered graph, only those origin points are considered that can reach the destination within a specified detour tolerance (e.g., 1.5 × shortest-path distance). The number of possible connections is recorded and compared proportionally. Furthermore, aggregated metrics are calculated for the reachable network in each case (network length, average quality). In addition to the full pipeline, a simplified variant with reduced input data requirements is also available. Methodological details of the assessment approach are documented in a separate publication.

The API implements an asynchronous job model to decouple computationally intensive routing processes from the HTTP interface. Analysis jobs are initiated via dedicated endpoints. Once a job has been created, the corresponding metadata are returned. Progress can be monitored either through polling or via a WebSocket connection. After completion, the generated outputs are made available through download endpoints.

Internally, jobs are managed in a simple data structure and processed sequentially. The analysis itself runs in a separate thread, ensuring that the HTTP interface remains responsive during computation. The architecture is designed for project-oriented use under limited load conditions. At the same time, it is structured in a way that allows future extensions, such as the integration of a persistent queue or a worker-based architecture for parallel job execution (e.g., Redis / Celery).

By using FastAPI, the API benefits from the automatic generation of OpenAPI-compliant documentation, enabling immediate and interactive access to the interface specification. All endpoints, parameters, and response formats are available online and can be tested directly. This reduces documentation overhead, ensures consistency between implementation and specification, and facilitates API integration.

To ensure a controlled runtime environment, the NetAScore codebase was integrated directly into the project. This guarantees that both the methodology and implementation state remain versioned and independent of external changes. A deployment script handles the checkout of a defined Git reference, the build of a Docker container, and the configuration of an upstream Nginx server. As a result, the API can be deployed on a server with only a few setup steps.

The geo-pipeline is provided as a standalone service. Analytical methods are implemented as clearly defined interfaces that can operate independently of visualization or data storage, be re-executed, and be integrated into other contexts. In a scientific context, this means that methodological approaches are not only available as publications or code repositories, but also as executable services. This facilitates access to analyses and simplifies integration into external systems or further research projects. The API developed here is prototypical and designed for project-oriented use, but it provides a reproducible and clearly defined service interface for accessibility analyses.