Reverse-engineering Fortnite's backend during the biggest game in the world

It was 2018 and Fortnite was everywhere. I was playing constantly with friends, and like everyone else, we were obsessed with our stats — who had the best K/D, whose win rate was actually climbing, who was improving versus who just talked a big game. The problem was Epic Games didn't offer a public API for any of this. There was no official way to pull player stats. The data existed somewhere on Epic's servers, but they hadn't given anyone a door to walk through.

So I found my own door.

I fired up a packet sniffer and started capturing the network traffic between the Fortnite client and Epic's backend services. Request by request, I mapped out how the client authenticated with Epic's servers, which endpoints it hit to fetch player data, and how the payloads were structured. Once I understood the auth flow — how tokens were generated, how sessions were maintained, how platform-specific queries were routed — I could replicate it all server-side. I'd effectively reverse-engineered Epic Games' private API.

With that foundation, I built MasterFortnite.com. You could search for any Fortnite player across PC, PlayStation, or Xbox and see their full breakdown — K/D ratio, win rate, total kills, matches played, split across Solo, Duo, and Squad modes. But I wanted it to be more than a basic lookup tool.

I built ranked leaderboards across dozens of stat categories. I created a custom skill rating system I called FSR — Fortnite Skill Rating — that computed where you sat in the overall percentile distribution and assigned letter grades from S+ down to F. The percentile engine ran as a background job, periodically crunching the entire player database to generate fresh breakpoints so every grade stayed current as the population shifted.

The feature I was most proud of technically was session tracking. Epic's data only gave you cumulative lifetime totals — total kills, total wins, total matches. There was no match-by-match history anywhere. So I built a diffing system: every time the app refreshed a player's stats, it compared the new totals against the cached version. If your match count jumped by three, the system calculated what happened in those three matches by looking at the deltas in kills, wins, and other stats. It synthesized a play-by-play match history from nothing but shifting aggregate numbers.

The timing couldn't have been better. Fortnite in 2018 was the biggest game on the planet — everyone from middle schoolers to Drake was playing. People were hungry for anything that let them track and compare their performance, and the site grew to over 100,000 monthly users without me doing much marketing at all. The demand was just there.

Under the hood I was dealing with real production challenges for the first time. I designed a caching layer in MongoDB so the traffic wouldn't hammer Epic's endpoints, implemented rate limiting to avoid getting blocked, and ran background jobs to keep Twitch streamer integrations and percentile data fresh on rolling intervals. I built a companion Discord bot so people could look up stats without ever leaving their server. The whole stack was Node and Express with server-rendered pages, which looking back is charming, but it handled the load.

The best part was playing Fortnite with friends and pulling up MasterFortnite on a second monitor to check stats mid-session. There's something satisfying about casually saying "oh yeah, I built this" while your squad is arguing about who choked in the last game.

I'd originally built it all independently. But a friend named Yang Liu who was one of the most successful developers on iogames.space, and ran a network of huge gaming stat sites, the Master Network, invited me to bring MasterFortnite under that umbrella. Yang and his team were a huge inspiration to me and I enthusiastically wired up my platform to their domain.

Eventually the project wound down. Competitors like FortniteTracker had bigger teams shipping features faster, and MasterFortnite wasn't my primary focus. The gap kept widening, so I let it go. But it was one of the projects that taught me what production engineering actually feels like — not the clean version from a textbook, but the messy reality of caching strategies, rate limits, database performance under real load, and keeping a system alive when a hundred thousand people are relying on it every month. Those lessons stuck with me long after the site went dark.