Accessing the USAPL Lifter Database Without Losing Your Mind
The USAPL publishes meet results publicly, but the raw data isn't packaged for easy analysis. Most people try to scrape individual meet pages and end up with a mess of HTML tables that break every time the site layout changes. That approach wastes more time than it saves. What actually works is pulling from the open dataset that USAPL makes available through their results archive, then running it through a local SQLite database. I started doing this around 2021 when I was trying to track age-group progression for a list of lifters I coached. My first attempt was downloading CSVs by meet date and manually concatenating them. It took three weekends and the result was full of duplicate entries and mismatched weight classes because the formatting shifted between years. The proper method starts by fetching the full results from usapl.org/results using a scripted approach. You grab the JSON endpoints directly rather than parsing HTML. The structure gives you meet ID, lifter name, bodyweight, total, and individual lift values in a consistent format. Once you have that, you dump everything into a single SQLite file with tables for lifters, meets, and attempts. A simple import script takes about forty minutes to process a year of data if you've never done it before. After that, it runs in under five minutes.
Here's the part most people miss: USAPL lists multiple divisions within the same meet record. A lifter might compete in both a raw and equipped division on the same day, and both entries appear in the database with separate totals. If you don't deduplicate by division type, your top performer lists will be inflated and misranked. I caught this after noticing a single lifter appearing three times in my weighted-point calculator with identical bodyweights but different totals. Flagging rows by division and keeping only the highest total per lifter per meet fixed it. Another counter-intuitive detail is the Gears scoring system. USAPL switched from Wilks to Gears in recent years, and some meet records still use Wilks depending on when the data was entered. Your ranking queries need to check which point system applies to each meet, or your top performers list will mix apples and oranges. I wrote a quick lookup table mapping meet IDs to their scoring system and joined it during the ranking query. This took maybe ten extra lines of code and prevented about a year's worth of inaccurate results from being published.
What the Data Actually Shows
Once your database is clean, you can run queries that the public-facing site doesn't let you run. Filtering by age group, weight class, and division side by side reveals patterns that aren't obvious from a leaderboard. The top raw lifters in the database cluster heavily in the 83kg and 93kg men's classes and the 72kg women's class. That's not surprising on its own, but when you look at the depth — the number of lifters within ten percent of the leader in each class — you get a much clearer picture of where competition is actually densest. I ran a query once pulling all squat and deadlift totals for female raw lifters in the 84+ bodyweight class over three years. The distribution was tighter than I expected. The gap between the top fifty and the median was smaller than the gap between the median and the bottom twenty-five percent. That tells you the upper tier is deep, not just dominated by a handful of athletes. If you're doing recruiting or scouting, focusing on the middle pack can be more productive than chasing the names at the very top.
Get the Full Details
Practical Query Examples
A basic query to find the top five lifters by total in a given weight class looks like this: SELECT lifter_name, bodyweight_kg, total_kg, gears_points, division FROM results WHERE weight_class = '83kg' AND division = 'raw' AND year = 2024 ORDER BY gears_points DESC LIMIT 5; You'll want to add a DISTINCT clause on lifter identifiers if your import step didn't already handle deduplication. Hashing the combination of name plus bodyweight plus meet date gets you close, but it's not perfect. Two different lifters can share a name and weight. A secondary sort by total or by meet ID helps you spot duplicates visually when you're reviewing the output.
For age-group analysis, you need to join the lifter table with the birthdate field if it exists in your schema. USAPL meet data sometimes includes age at time of competition, which is easier to work with than calculating from a birthdate. If your download is missing age fields, you can approximate using the meet date minus the reported age, but that introduces a small error margin of roughly plus or minus one year depending on meeting month.
Limitations You Should Know About
This approach only covers USAPL sanctioned meets. It won't capture IPF, UAP, or raw-friendly federations that share the same pool of athletes. If your goal is to find the absolute best lifters across all federations in the US, USAPL data alone will undercount. I found this out when a lifter I had ranked third in my database showed up as a national champion in another federation's meet the following year. Adding supplemental datasets from other sources requires normalizing weight class labels and point systems, which is its own project. The database also has gaps in older results. Pre-2018 data is spottier, and equipment division records before 2020 are incomplete in many cases. Don't draw conclusions about historical trends using those years without verifying the coverage manually. Cross-checking a random sample of ten meets from each year against the published results page takes about fifteen minutes and will tell you whether your dataset is reliable for your time range. If you're not comfortable writing SQL or Python scripts, there are third-party tools that wrap some of this functionality, but they charge subscription fees and often lag behind the raw data by weeks. Running your own import script is faster in the long run and gives you control over the deduplication logic and the queries you're running. The initial setup is the expensive part, not the ongoing maintenance.
