What 'the price of a card' means when your users buy in Europe

ggxforce — Wed, 23 Sep 2026 13:28:31 +0000

I built a Pokémon TCG API for the European market, after two years of running a collection app on US-centric data. What I got wrong about prices, currencies, print lines and 'the number'."
tags: api, postgres, go, buildinpublic.

Two years ago I started a card-collection app for the European market. The very first feature request was the obvious one: "what is this card worth?" And the very first thing I learned is that the data I could get my hands on answered a different question than the one my users were asking.

They buy on European marketplaces, in euros, often a French or German printing, and increasingly Japanese cards that never got a Western release. The catalogue data I could find gave me one number per card, in dollars, from one US marketplace, for the English printing, with no date on it. Not wrong. Just an answer to somebody else's question.

So I built the backend the app needed. Then developers started asking for the backend instead of the app, and I opened it as an API. This is what I got wrong along the way, and what the API does differently because of it. It runs in Europe, on one dedicated box, in Go on top of Postgres, and today it holds about 57,800 cards in 651 sets, of which 380 are Japanese and 96 are Simplified Chinese, plus about 2,100 sealed products (numbers as of 23 September 2026, live on the coverage page).

"The price" is five questions

"What is this card worth?" sounds like one question. It is five: on which market, in which currency, in what condition, for which printing, and as of when. A single number silently answers all five for you, and in Europe it usually answers them wrong.

So the API does not return a price. It returns rows, and every row carries its own answers:

{
  "source": "CARDMARKET",
  "variant": "LOW",
  "basis": "ASKING",
  "amount": 412.00,
  "currency": "EUR",
  "locale": "en",
  "condition": null,
  "printing": "HOLOFOIL",
  "grading": null,
  "as_of": "2026-09-22",
  "sample_n": null,
  "provenance": "Cardmarket"
}

source says who observed the figure. basis says what kind of figure it is: ASKING is what a seller wants today, GUIDE is a reference the source computes from its own history, DERIVED is something we computed ourselves. locale is the language of the printing. as_of is the day the figure is for. provenance is a string you can print next to the number.

Next to that row sits a TCGplayer guide figure in USD, for the same card. The two disagree, and they should: one is the cheapest copy a European seller is asking for, the other is a guide computed on the US market. They are two facts about two markets. An API that averaged them would produce a number nobody can find on any website, and the first customer who challenges it would be right.

EUR and USD never get averaged

This was the rule that cost me the most to learn. Early on I had a "price" column. It was in euros for some sources and dollars for others, and a conversion ran in a job somewhere. The number looked fine on a list page, until a collector compared it with the marketplace and asked which of the two was lying.

Now a Cardmarket row is in EUR because Cardmarket trades in EUR, and a TCGplayer row is in USD for the same reason. The API never converts a quote for you. Conversion is a product decision: it depends on the day, the rate you trust, and what you tell your user about it. That belongs to the thing showing the price, not to the thing storing it.

There is one exception, and it is published rather than hidden. Sorting a collection by value needs one comparable figure per card, so we compute a composite index in EUR: take the current rows for one card, one language, one printing; keep only market-level figures from sources we may redistribute; drop series with no observation in thirty days; convert the non-EUR ones with the ECB daily reference rate; take the median, not the mean, because with two or three sources one bad quote moves a mean a long way and a median almost not at all. The result is a row like any other, with source: "PTCG_INDEX", basis: "DERIVED" and sample_n equal to the number of figures behind it. It exists to sort. Show your user the row from their own market.

A French box is not an English box

Sealed product taught me the same lesson from another angle. On a European marketplace an English booster box and a French booster box of the same set are two listings with two prices, often far apart. My first model had one product with one price, and the French collector was looking at the English figure.

Now a sealed product has a kind, the set it belongs to, a pack count, an image, and a price route where locale is the language the box was printed in. Same row shape as a card, minus the fields a box does not have: condition, printing and grading are always null there. Match the row to what the user actually holds.

A region is a catalogue, not a translation

The Japanese line was the second wall. It releases first, it has more sets than the Western line, and a growing share of European collectors buy it. Every dataset I found treated it either as missing or as a translation of the Western set with the same name.

It is neither. A Japanese set has its own code, its own card list and numbering, its own release date, and often cards that never crossed the ocean. So the API keeps three print regions, WEST, JP and CN, as three catalogues. A Japanese card is a card in its own right, with its own id, number, rarity, illustrator and image. Where we know a Western card and a Japanese card are the same printing in two languages, the Western card carries a jp_twin_id; where we do not know, it is null, and null means "unknown", never "was not printed in Japan". I would rather serve a null than a wrong twin, because the twins are exactly the cards whose prices differ most between the two markets.

Two things people confuse, so the API keeps them apart: the region says where a card was printed; lang says which language you want the card's name in. lang=ja on a Western card returns its Japanese name. It does not turn it into a Japanese card.

The engineering choices that came out of this

Rows first, numbers derived. Every price is an observation with a source and a date; every single number the API serves is computed from those rows by a published rule. When a customer challenges a figure, the answer is a query, not an apology.
A dimension that is not in the key silently picks a winner. One marketplace publishes two lowest asking prices per language, one over all sellers and one over sellers shipping within the EU. My series identity did not include that distinction, so whichever row arrived last overwrote the other. A customer reading his rows carefully caught it. The fix put the distinction in the key and exposed it on the row.
A rule applied in two places has to agree with itself in both. Sources carry a 24-hour delay before a figure is served. The cache kept the newest row per series and the delay was enforced only when serving. For a daily source, those two rules together made a whole series disappear: the only cached row was too young, it was discarded, and the servable one from yesterday was gone. Two hundred thousand rows in the cache, zero quotes in responses. Now the delay is applied when choosing what to cache.
Cursor pagination and ETags everywhere, because the first thing every collector app does is download the whole catalogue, and the second thing is do it again tomorrow. A change feed written by database triggers gives a sync position as a single integer, so "what changed since yesterday" is one small call.
Say what is not there. The catalogue has no game text on Japanese and Chinese cards, no sets printed in Korea, and thinner price coverage on older Japanese sets. The coverage page measures all of that live, from the API, and the docs say it in plain words. This turned out to matter more than I expected: about half of our signups now come from answers given by AI assistants, and the pages they cite are the ones that make verifiable claims, gaps included.

What I am still unsure about

Whether a credit model (1 credit for a catalogue call, 2 for prices) reads better than plain request counts. Whether the 24-hour delay is a feature or a reason people leave. And what makes a developer's first call to a new API happen faster: a playground, a copy-paste curl, a Postman collection, or an SDK. Four out of ten signups never make a single call, and I would like to understand why.

If you build for collectors in Europe, or you have run an API where "the number" turned out to be several numbers, I would genuinely like to hear how you handled it. The docs, with a trial key that needs no card, are at https://pokemontcgapi.com/?utm_source=devto&utm_campaign=post_eu-price-api