TCGdex turns card scans into a translated, queryable dataset

The data is scanned from the physical cards

TCGdex is described as a multilanguage Pokemon trading card game database with card pictures and most of the information contained on the cards. The important detail is the provenance, because it explains the shape of the data. The card text is transcribed from the physical cards rather than from an official feed, which is why the release notes talk about backfilling card market identifiers and why a 30th anniversary set appears in a version title. The repository is the database and the API implementation together, with the `data/` directory holding the card data, `data-asia/` holding the additional Asian releases, `meta/` holding the metadata and the translation files, and `server/` holding the API implementation. The type definitions are at the top level in `interfaces.d.ts`.

Three ways to consume it

The getting started section names three routes. The easiest is to use one of the official SDKs, and the README lists three of them: a JavaScript and TypeScript SDK, a PHP SDK and a Java SDK. The second is to call the endpoints directly at `api.tcgdex.net` and read the documentation for them. The third is to build the API yourself, using the `Dockerfile` and running it on port 3000 with the `docker-compose.yml` file. The full API documentation is at tcgdex.dev, and the project homepage is tcgdex.dev as well. The self-hosting route is the one that matters for anyone who needs their own instance or who does not want a third party in the request path, and it is the reason the server code lives in this repository at all.

Running your own instance is one compose file

The compose file is short, which tells you the server is a self-contained service with one tunable:

services:
  stable:
    image: tcgdex/server:edge # You can choose between using the hub.docker.com one or the github one
    # image: ghcr.io/tcgdex/server:edge
    restart: unless-stopped
    environment:
      # by default the server will start a worker for each threads available
      # You can downgrade the max number of workers by changing this value
      - MAX_WORKERS=2
    ports:
      - 3000:3000 # You can choose any port you want

There is a commented alternative image from the GitHub container registry, and the only configuration is the worker count, which by default starts a worker per available thread and can be lowered. The port mapping is yours to change. The Docker image is a two stage build on the Bun 1 Alpine image, with the build stage compiling the server and then reinstalling the production dependencies, since the comment notes that Bun does not yet support pruning, and the final stage copies only the generated output, the node_modules, the source, the public assets and the package manifest, running as the non-root bun user with `NODE_ENV=production` and port 3000 exposed.

Translation coverage is a per-card and per-language question

The status section is where the project's real constraint lives. The stated goal is to make every card available in every language it was available in, and a status badge is served from the API so the current state is visible. The invitation to help translate explains the data model: each object field on cards that have at least English, French, Spanish, German, Italian or Portuguese can have the others, and there are additional translation files located at `meta/translations`. That is a per-field, per-language structure rather than a per-card one, which is the right shape, since a card's rules text is translated but its attack values and set information are not. The practical consequence for a consumer is that you should not assume a field exists in every language, and the status endpoint is the place to check.

The maintenance scripts are the interesting part of the tooling

The root package manifest is private and holds the maintenance tooling rather than the server, and the scripts describe the work that keeps the data consistent. `check-missing` runs a script that finds missing data, with a help variant that shows the usage, and `link-cardmarket` links cards to their Cardmarket entries, which is the backfilling that appeared in a release title. Then there is a whole family of dex scripts, run with Bun, for fixing the identifiers that map cards to the mainline game dex: an audit with a report mode, a dry-run fix, an apply mode and a lint. The tooling also includes jscodeshift for scripted code transformations, glob for file discovery, and a couple of small utilities for object handling and queueing. The `validate` script is a plain `tsc --noEmit` type check of the whole project, which is the check that a contributor's data change has not broken the shape of the data.

The licence and the disclaimer are both explicit

The licensing section is short and clear on both counts. The database is licensed under the MIT License, with a copy of the licence in the LICENSE file, and the database is not produced, endorsed, supported or affiliated with Nintendo or The Pokemon Company. That second sentence is the one that matters for a project built on scanned card art and transcribed rules: the data is a community effort with no relationship to the rights holder, so a commercial product built on it inherits that separation. There is also a deprecation note, that as of February 2021 the v1 API is no longer supported, so the current v2 endpoints are the only ones to build against. The release history shows the cadence of a data project, with v2.48.0 in September 2026 adding the 30th anniversary sets, v2.47.0 in July 2026 and v2.46.2 in June 2026, and the last push to the master branch was on 2026-10-06.

Editorial conclusion

Adopt the TCGdex API if you are building a card lookup, a collection tracker or a price display, since the data is translated and the endpoints are public with SDKs for three languages. Do not adopt it if you need a guaranteed-fresh or authoritative price feed, since the repository is a community-maintained scan of physical cards and a release note mentions backfilling card market identifiers. Verify first which languages cover the sets you care about, because the coverage is tracked per set and per language, and note that the v1 API is no longer supported.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tcgdex/cards-database on GitHub