When you open a movie in Loggd and see which studio was behind it, who worked on it, which series it belongs to, or which games might be related: where does this data actually come from?
The obvious answer would be "some movie database." And for a pure movie app, that would be enough. But Loggd isn't a pure movie app. We want to bring movies, TV shows, games, anime, books, and music together in one shared media database, and that's exactly where the simple answer falls apart. Because the one source that does all of that well doesn't exist (yet).
This is exactly the part of Loggd that you don't notice from the outside, but that carries the entire project. Others have already built similar apps before us. What sets us apart lies one level deeper: in the data. In this post, we'll take you into our admin portal, the internal tool we use to assemble this catalog, and explain how and why we do it.
What is the admin portal?
The admin console is our internal control panel. It isn't part of the app you use, but rather the place where we manage content behind the scenes, and above all the catalog data that feeds the application. One part handles posts, finances, the roadmap, contact requests, time tracking, and even project management. The part we're talking about here, though, is what we call Ingest. That's the area responsible for collecting and processing media data.
The core problem: no single source can do it all
There are some really good media databases out there. The problem is that each one is strong in its own area and weaker everywhere else.
- TMDB is our foundation for movies and TV shows. Broad coverage, lots of detail on people, studios, and series, good images in various languages. (API documentation) (last checked: 2026-07)
- TVDB specializes in television, especially at the episode level: seasons, ordering, long-running series. It's strong exactly where general-purpose databases get thin. Another thing that stands out with the images: for individual shows, you don't just get generic actor portraits but actual stills from the show itself. (API documentation) (last checked: 2026-07)
- AniDB is the go-to source for anime. General movie and TV databases often lump anime in with everything else or label it incorrectly. AniDB captures its quirks properly and goes very deep into detail (e.g. voice actors).
- IGDB does the same for games: titles, series, platforms, engines, studios. (API documentation) (last checked: 2026-07)
Let's take TMDB and TVDB as an example, since the difference is easy to see there. TMDB is strong on movies, but things get fuzzier with TV shows. Entries can be edited fairly freely there, episodes get merged or split, and orderings even change after the fact. Specials, like holiday episodes or bonus material, often end up dropped right in the middle of regular seasons. TVDB, on the other hand, is built from the ground up for TV: stable season and episode numbers, and with long-running shows the episode entries stay intact instead of constantly being renumbered. Even anthology series, where each season tells its own story, remain one connected entry instead of falling apart into disconnected pieces.
We could rely on a single source and ignore the rest. That would be the quick path. But then you'd end up with a foundation that's good for movies and falls apart for everything else. Instead, we take each source exactly where it's strongest and painstakingly merge everything together.
Why we don't use provider data directly
We want to model our data so that it carries exactly the features we plan to build, allowing us to add our own information that doesn't exist with any single provider.
No existing provider thinks across media types. TMDB thinks in movies, IGDB thinks in games, each one stays within its own domain. But the interesting connections happen exactly in between. Imagine we later add music to the data and cross-link it: What's the theme song for this movie? What's the most memorable track in this game? Does the same composer show up in both? You won't find this kind of connection in any single database, because none of them were built for it. We can only add it because the catalog belongs to us, not to any particular source.
For that to even be possible, we need our own shape for our data. That's exactly what our technology, which we call Ingest, does. We have our own schema, a structure we defined ourselves, and we treat providers strictly as suppliers. Every record is translated field by field into our structure and manually reviewed before it's saved. On top of this structure, we can build further: add our own fields, link entries to each other, represent things the original provider never intended to support.
The challenge we had to solve
One of the biggest challenges in all of this was simply how differently providers expose their data in the first place. TMDB, for example, has endpoints to load individual movies, plus an endpoint for all changes from the last few days. That means we fetch everything once and then just pull the changes daily after that. IGDB does it differently. There, we download a complete database dump every day.
That's exactly why we built our Ingest interface. All data sources flow into it, it translates each one into a similar schema, and it also keeps track of what's actually in there. That way we know for ourselves when something has changed, even with a source like IGDB, which doesn't reliably tell us that.
Essentially, this is our central receiving dock. Whether a supplier brings a neat little note with the changes every day, or just dumps a whole truckload every morning: at the receiving dock, everything gets sorted, what's new gets noted, and it's carried onward from there.
The real advantage shows up afterward. We can simply say: give me all changes for provider X's data within a certain time range. We don't even need to contact the provider itself at that point, because the current information is already sitting with us. That makes the system faster and less dependent on how well each individual interface happens to be behaving on any given day.
Turning many sources into one coherent catalog
The real trick comes at the end. Each provider brings its own data along. But that creates a problem. An example: a movie comes with a list of involved production companies and actors from its provider, and so does a TV show. If we simply merge TMDB and TVDB naively, companies and people end up duplicated, since they appear independently in both sources.
So that this doesn't sound too tidy: this approach requires an enormous amount of manual work. Mapping and linking entries to each other can rarely be done automatically. That's why we manually go through every entry where there are issues (and unfortunately there are quite a few) and clean up the data ourselves. But we consider this effort worthwhile, because it's the only way we get data that actually lets us build our vision for Loggd.
We're also being upfront about where this is headed long-term: we want to gradually decouple ourselves from the providers and eventually maintain and rebuild the entire catalog ourselves. We simply don't have the capacity for that right now, so we're not promising it either. At the moment, our focus is on improving the existing data, optimizing it, and making sure it can represent what we want it to, so that in the end the experience in the app feels right for you.
In the end, the data foundation is the part of Loggd you don't see, and that's exactly the point. It's supposed to just be there and be right. If you want to see how that feels in the product, check out the current beta at loggd.me. And if you know of a source that's better in its area than what we're using, or you spot errors in the data, feel free to let us know on Discord. Feedback like that is exactly what makes the data better for everyone over time.