How to Scrape Komoot Hiking & Outdoor Routes in 2026

Komoot is the largest outdoor-navigation platform in Europe, with hundreds of millions of routes for hiking, mountain biking, road cycling, trail running and touring. If you’re building a trip planner, a regional trail directory, or a recommendation model for outdoor activities, Komoot is the single richest source of structured route data on the open web. The challenge is coverage: Komoot’s discovery is location-centric, so naively searching one place name barely scratches a region. This guide covers what Komoot exposes per route and how to use tiled grid search to actually cover an area.

What’s worth extracting

Komoot serves its route discovery through an API, so the data comes back already structured — no HTML parsing, no scraping the interactive map. Per route you get:

• Identity — tour ID, name, activity type.
• Distance & duration — total length and Komoot’s estimated time to complete.
• Elevation — total ascent and descent, the metrics that actually determine how hard a route feels.
• Difficulty — Komoot’s difficulty rating (easy / intermediate / expert).
• Start point — start coordinates so you can map or geofence routes.
• Popularity — visitor counts and ratings, the signal for “is this route actually good or just uploaded once.”
• Terrain — surface breakdown (paved, gravel, trail, …) and way-type breakdown, which matter enormously for cyclists and runners choosing a route.
• Highlights — the named points of interest along the route (viewpoints, huts, lakes).
• Media — cover image and map preview image URLs.

That’s a genuinely rich record — far more than a GPX file alone gives you, because it includes the community signals (popularity, ratings) and the terrain composition.

The coverage problem and grid search

Here’s the thing that trips people up. Komoot route discovery is anchored to a location. Search “Lake District” and you get routes near that one centroid — not the whole national park. Search a single coordinate and you get routes near that point. For a one-off “routes near this trailhead” query that’s fine. For “every notable hiking route in Bavaria,” it’s hopeless.

The fix is tiled grid search: cover the target region with a grid of coordinate points, query each cell, and deduplicate the results by tour ID. The scraper handles this automatically — you give it a region or a set of coordinates and it tiles the area, paginates each cell, and merges the results so you get regional coverage instead of one centroid’s worth.

You can also feed it specific tour IDs if you already know the routes you want to refresh, or use place names for quick lookups. Three input modes:

place name      e.g. "Dolomites"           -> tiled search around the place
coordinates     e.g. 46.5,11.8 (grid)      -> tiled grid for full regional coverage
tour IDs        e.g. 1234567, 2345678      -> direct fetch of known routes

Pick activity types to match your use case:

hiking, mountain biking, road cycling,
touring bicycle, trail running, e-MTB, e-touring

▶ Run the Komoot Hiking & Outdoor Routes Scraper — search by place, coordinates or tour ID; tiled grid search for full regional coverage; distance, elevation, difficulty, surfaces, ratings and waypoints as clean JSON. No HTML parsing.

Schema design for downstream use

A clean per-route record for a trail directory or analytics pipeline:

{
  "tour_id": 1839204,
  "name": "Tre Cime di Lavaredo Loop",
  "activity": "hiking",
  "distance_km": 10.1,
  "duration_min": 215,
  "ascent_m": 480,
  "descent_m": 480,
  "difficulty": "intermediate",
  "start_lat": 46.6189,
  "start_lon": 12.3045,
  "visitor_count": 48213,
  "rating": 4.8,
  "surfaces": { "trail": 0.62, "gravel": 0.28, "paved": 0.10 },
  "way_types": { "hiking_path": 0.71, "forest_road": 0.29 },
  "highlights": ["Rifugio Locatelli", "Tre Cime viewpoint"],
  "cover_image_url": "https://photos.komoot.de/...",
  "scraped_at": "2026-05-24T10:00:00Z"
}

A few schema choices worth making early:

• Key on tour_id. Grid search will surface the same popular route from multiple adjacent cells; the ID is your dedup key.
• Keep ascent_m, not just distance. A flat 20 km and a 20 km with 1,500 m of climbing are completely different experiences. Elevation is the difficulty driver — store it prominently.
• Don’t flatten surfaces/way_types. The terrain breakdown is the most valuable filter for cyclists and runners; keep the object so you can query “routes that are >80% paved.”
• Store start coordinates as numbers. You’ll want to do radius and bounding-box queries; keep them numeric, not strings.

Typical use cases

• Travel & tourism apps — aggregate routes into destination guides and trip planners (“best day hikes near Innsbruck”).
• Regional trail directories — build a searchable, filterable directory for a region or country with difficulty and elevation metadata baked in.
• Trip-planning research — pull surface conditions and elevation profiles to plan a route that matches a group’s fitness and gear.
• Recommendation models — collect structured route data as training input for outdoor-activity recommendation engines.
• Popularity analytics — track visitor counts and ratings over time to surface trending or under-the-radar routes.
• Regional comparison — compare difficulty, distance and elevation distributions across regions for tourism or planning research.

The common thread is breadth of coverage. A handful of routes around one trailhead is a demo; a deduplicated, grid-searched set covering an entire region is a directory you can build a product on.

Cost math

The actor is pay-per-event with a tiny run-start fee and free results, and because it talks to the API directly (no browser, no HTML parsing), each route is cheap to fetch. A grid search over a large region returns thousands of routes in one run for cents-to-low-single-digits of compute plus the run-start fee.

The cost lever to watch is grid density: more grid cells means more API calls means more runtime. A coarse grid is cheap but misses sparse routes; a fine grid is thorough but redundant (lots of dedup). Tune the grid to the region’s route density — dense for the Alps, coarser for a remote area.

Common pitfalls

• Single-point search undercounts a region. As covered above, this is the number-one mistake. Use grid search for anything bigger than a single trailhead.
• Duplicate routes across grid cells. Expected — dedup on tour_id and don’t be alarmed that raw cell results overlap.
• Activity type matters for terrain. The same path scored as “hiking” vs “road cycling” surfaces different routes. Set the activity filter deliberately.
• Estimated duration is generic. Komoot’s time estimate assumes an average pace; don’t present it as authoritative for an elite runner or a family with kids.
• Highlights are community-sourced. They’re great signal but uneven — a famous route has dozens, an obscure one has none. Don’t treat absence of highlights as absence of interest.

Wrapping up

Komoot is the deepest structured source for outdoor routes in Europe, and because discovery runs through an API the data comes back clean. The real skill is coverage: tiled grid search plus tour-ID deduplication turns “routes near one point” into “every route in a region.” If you need that breadth on a repeatable basis — for a directory, a planner, or a model — a maintained actor that handles the tiling and dedup is the fast path.

▶ Open the Komoot Routes Scraper on Apify — grid search a whole region, get elevation, difficulty, surfaces and ratings as JSON. Pay-per-event. Start on Apify’s free monthly credit.