Every activity here belongs to a named person. That single fact decides the whole project, and it is why the honest answer starts with the API and consent.
ScrapeIt builds and runs the pipeline as a managed service. For athlete data we integrate the official OAuth API, handle the consent flow, keep the scope to what your use case needs and index rows by the consent that covers them. For public data we collect the segment and leaderboard surfaces the site leaves open, at a civil rate.
We will not build an athlete profile database from public pages, and we will say so at the scoping call rather than after taking the work. It is against the site's published rules and against data protection law, and a dataset built that way cannot survive a review.
Activity data is personal data and heart rate data is health data. Your lawful basis, your retention period and your deletion path are decisions for you and your counsel; we build the pipeline to whatever they decide and make the consent boundary visible in the data. Bring the use case to counsel before the project starts, not after.
Through the official API with athlete consent: activity identifier, type, start time, elapsed and moving time, distance, elevation gain, average and maximum speed, and the device where reported. Heart rate and power series are available where the athlete records them and the consent covers them, and they are treated as health data throughout.
From the public segment surfaces: segment identifier, name, sport type, distance, average and maximum grade, elevation, the geographic area it sits in, and the leaderboard entries the page publishes.
Athlete identity is handled deliberately rather than by default. For research and product analytics we deliver pseudonymised identifiers so activity can be linked across time without naming a person. Named athlete data is delivered only where the athlete consented to that specific use through the API scope, and we record which consent covers which rows.
Route geometry is a separate decision again. A GPS track is location data about an individual, frequently starting at their home, and we deliver it only under explicit consent and usually truncated at both ends by default.
Every row carries its source - API with consent, or public page - because six months later somebody will need to know which, and the answer has to be in the data rather than in somebody's memory.
Segment and leaderboard data is the part of this source that carries no consent burden, because a segment is a shared route rather than a person. Popularity over time, seasonal patterns and comparative difficulty across routes are all answerable from it, and it is the natural starting point for planning and research work.
Aggregate research is where most non commercial demand sits: which routes cyclists actually use, how usage shifts after infrastructure changes, where demand concentrates. Those questions need counts and geometry, not identities, and we scope them that way by default.
Deletion has to be designed in rather than bolted on. When an athlete withdraws consent, their rows have to leave the dataset and any derivative of it, which means the pipeline needs to know which rows came from which consent before that day arrives, not after. We build that index from the start.
Retention is agreed at the start too. Consented data with no stated retention period is a liability that grows quietly, and the conversation is much easier before the data exists.
Strava is a training platform where athletes record activities and compare them on shared routes. The data is unusually rich and unusually personal: a single activity carries a route, a time, a heart rate series and an identifiable person at the end of it.
The site is explicit about automated access, and reading its crawl rules is the first step in any project here rather than the last. Several paths are closed outright, including the interface path and activity analysis views, and the rules name a set of AI crawlers and disallow them from the site entirely. Segment pages remain open and respond normally.
Alongside that, Strava runs an official developer programme with an OAuth API. That is the correct route for anything involving athlete data: the athlete authorises access, the scope is explicit, and consent can be withdrawn. It is also the only route that produces a dataset a company can defend.
So the shape of a legitimate project here is narrow and worth stating plainly: consented athlete data through the API, plus the public segment and leaderboard surfaces the site leaves open. Anything wider is either against the published rules or against data protection law, and usually both.
Get a Quote
Developers
Customers worldwide
Pages extracted
Hours saved for our clients
€199 / one-time
setup fee - included
€169 / mo
setup fee €499
€229 / mo
setup fee €499
€349 / mo
setup fee €499
€549 / mo
setup fee €799
Most sources in this section are published for the public. This one is published by individuals about themselves, and that changes everything downstream: the lawful basis, the retention, the deletion path and what a company may build.
Activity data is personal data in every jurisdiction that matters, and heart rate data is health data, which carries a higher bar again. A route that starts at the same address every morning identifies a home. None of that is hypothetical, and none of it is solved by the data having been visible on a web page.
So the honest answer is the boring one. Use the official API, take consent from the athlete, keep the scope narrow, record which consent covers which rows, and honour withdrawal by deleting rather than by flagging. We will build exactly that, and we will decline a brief that asks us to assemble athlete profiles from public pages instead.
Within those limits the source is genuinely valuable. Segment and leaderboard data supports route popularity analysis, infrastructure and urban planning research and product benchmarking without naming anyone. Consented athlete data supports training products, coaching tools and research with the participant's agreement, which is how that work is supposed to be done.
The site also names AI crawlers in its rules and disallows them from the whole site. If your intended use is training a model on this data, that rule is directed at you, and the conversation to have is a licensing one with Strava rather than a technical one with us.
Learn how to use web scraping to solve data problems for your organization
Leveraging advances in technology, the AI-powered web scraper has skyrocketed in demand and is helping to expand capabilities by automating tedious daily tasks and speeding up data collection from thousands of websites several times over.
Web scraping is a method of obtaining web data by extracting it from pages of web resources with the help of a program, that is, in automatic mode. It is used to syntactically convert web pages into more usable forms.
If you specialize in machine learning, you need to feed large amounts of data to the algorithms. Web scraping is the easiest and the most efficient method of collecting the data from all over the Internet.
ScrapeIt is a managed extraction company, not a tool you have to learn. Our team builds the API integration and the consent indexing, watches it as scopes and interfaces change, and repairs it before your product goes quiet.
You see a sample first, in your format, within the scope you actually need, with the consent source visible on every row so your counsel can review the shape before any real data is collected.
No. Activity data is personal data about an identifiable person, heart rate is health data, and a route that starts at the same address every morning identifies a home. The site also closes several activity paths in its crawl rules. For athlete data the route is the official API with the athlete's consent, and that is the only version we build.
The public segment and leaderboard surfaces the site leaves open: segment identifier, name, sport, distance, grade, elevation and the entries the page publishes. A segment is a shared route rather than a person, which is why it carries no consent burden and why it is the natural starting point for planning and research work.
Then read the site's crawl rules first: they name AI crawlers explicitly and disallow them from the whole site. That rule is directed at exactly this use, and the conversation to have is a licensing one with Strava rather than a technical one with us. We will not route around it.
By deleting, not by flagging, and it has to be designed in from the start. The pipeline indexes rows by the consent that covers them before the withdrawal arrives, so when it does the rows and their derivatives can actually leave. Retrofitting that after the data exists is the part nobody budgets for.
Only where their consent covers that specific use. By default we deliver pseudonymised identifiers, which lets activity be linked across time without naming anyone, and that is sufficient for most product analytics and all aggregate research. Route geometry is a separate decision again and is usually truncated at both ends.
Step 1 - Make a Request
You share your needs, expectations, and desired timeframe. We’ll suggest the best solution based on your request and budget.
Step 2 - Configuring Custom Web Crawlers
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Step 3 - Collect and Deliver
Once you approve the sample, we launch the project and start full data collection. We gather, filter, and structure the data for easy use, delivering it on time in your preferred format.
Step 4 - Maintain and Support
Our team manages ongoing processes, monitors website changes, and supports all data extraction cycles. We can also help integrate data into your systems or create dashboards to simplify analysis.
Scrapeit Sp. z o.o.
10/208 Legionowa str., 15-099, Bialystok, Poland
NIP: 5423457175
REGON: 523384582
