The slug rename broke my database, so I built the thing we should've had all along: permanent card IDs for Sorcery
A few weeks ago, EC changed the set numbering used in its API slugs and image files. Suddenly, every spreadsheet, bot and database keyed on strings like 004-witch-b-s quietly caught fire.
Those slugs look like identifiers, but they’re assembled from mutable data: set number, card name, product and finish. Any of those can change, and now that I’m deeper into building my own tools, I don’t want to go through this again.
Yu-Gi-Oh has Konami passcodes. Magic has Scryfall IDs. So today I bring you:
Sorcery Registry
https://github.com/sadkinglabs/sorcery-registry
Every gameplay card receives a permanent codex_id, shared across all its reprints, our equivalent of an oracle ID. Every physical printing receives its own permanent printing_id.
The IDs never move or get reused. The database refuses attempts to change or delete them, and CI checks every update against the previous registry. Slugs, names and set numbers become what they should always have been: mutable attributes, not identities.
From now on, when a slug changes, if it ever does, its old value remains resolvable through slug_history. Ambiguous upstream changes are held for human review rather than guessed at.
The whole published registry is one deterministic JSON file on GitHub:
- No hosted service to disappear
- No prices or marketplace dependencies
- Official public API data, plus a small, transparent corrections file
- A documented schema and SHA-256 checksum
- A local MCP server so Claude, Cursor and other compatible tools can query it
The registry has little purpose sitting alone in its repository. Its value comes from people building on the IDs.
Use it. If you maintain a tool, bot, spreadsheet, collection manager or pricing tracker, key your records on these IDs. The next slug rename should become an ordinary metadata update, not a migration emergency.
Challenge it. Look through the data, query it and try to find mistakes or dangerous assumptions. If something is missing for your use case, open an issue and tell me.
Help maintain it. Corrections are accepted through pull requests, with the evidence and reason retained publicly. New-set syncs also land as reviewable PRs. More eyes on those changes means more confidence in the registry.
I made this for the community, but I can’t credibly maintain a community identity standard forever by myself. If you think the idea is worth pursuing, please get involved, even if that just means trying it, opening an issue, reviewing a sync or starring the repository to show there is interest.
And if, over time, trusted community members want to help maintain it directly, I would genuinely love for this to become shared infrastructure rather than one person’s project.