I’m trying to understand how Apache Airflow’s stable API version 1.0.0 maps its routes to actual endpoints. I can see that all the endpoint logic lives in Python files under the /airflow/api_connexion/endpoints directory.
The problem is I can’t figure out how these individual files connect to their actual URL paths. For example, how does dag_endpoint.py map to the route DOMAIN/api/v1/dags?
I need to find the source code file that contains the routing configuration for all these API endpoints. I’m probably missing something obvious since I’m not very experienced with Flask applications.
I was only able to locate the experimental API routing files in the codebase, but nothing for the stable v1 API routes.
The routing isn’t done with traditional Flask routes - Airflow uses OpenAPI spec files instead. It runs on the Connexion framework, which auto-generates routes from OpenAPI specs. Look in /airflow/api_connexion/openapi/ in the repo. You’ll see YAML files that define the API endpoints and map them to Python functions in the endpoints directory. The main file is usually v1.yaml - it has all the path definitions like /dags that Connexion automatically prefixes with /api/v1/. That’s why you couldn’t find the usual Flask route decorators.
Skip digging through Airflow’s routing system - just automate the whole API discovery process instead.
I’ve hit this same wall before when teams needed to map API endpoints for docs or integrations. Instead of manually parsing OpenAPI specs and Python files, I built workflows that extract everything automatically.
Here’s what works: create automation that scans the repo, parses those YAML files in /airflow/api_connexion/openapi/, and spits out a complete route-to-function mapping. Saves tons of manual work and keeps your docs current when the API changes.
The workflow pulls latest code, parses OpenAPI specs, cross-references endpoint files, then outputs a clean mapping table. Set it on a schedule to catch routing changes in new releases.
Way better than trying to decode Connexion’s auto routing manually. Plus you’ve got a reusable solution for future API mapping tasks.
Check out Latenode for building this kind of automation: https://latenode.com
Look closer at the /airflow/api_connexion/ directory structure. Connexion uses the operationId mechanism from OpenAPI specs for routing. Each endpoint in the YAML files has an operationId field that points directly to Python function names in your endpoint files. Check the dags endpoints in v1.yaml - you’ll see operationIds like “get_dags” that map to the get_dags function in dag_endpoint.py. The URL paths follow REST conventions: /dags endpoints go to dag_endpoint.py, /connections go to connection_endpoint.py, etc. The framework automatically handles the /api/v1 prefix based on the API version in the OpenAPI file header.