Two store APIs, eight ZENONIA games, and no publisher key

I wanted to know which ZENONIA games a person can actually buy in 2026. There is no endpoint that answers that question. So I asked two endpoints that answer something next to it, and then spent most of the afternoon working out what their answers do not mean.

Here is the whole method, because it is small enough to fit in a paragraph:

• store.steampowered.com/api/storesearch once per title.
• One GET play.google.com/store/apps/details?id=<package> per Google Play package name.
• HTTP 200 means there is a live listing at that identifier. 404 means there is not.

Eight titles went in on 2026-08-31. ZENONIA 1 came back on Steam as appid 4538960 with a separate demo at 4733680, priced at $8.99. Inotia 4 came back on Steam too, appid 3956320. ZENONIA 4 and 5 came back on Google Play at com.gamevil.zenonia4.global and com.gamevil.zenonia5.global. ZENONIA 2 and 3 returned 404 at the equivalent package names. Six of the eight did not come back from at least one of the two queries.

The part that is easy to get wrong

A 404 from Google Play does not mean the app is gone. It means nothing is published at the string you asked for. Those two statements look similar and are not.

ZENONIA 6 and ZENONIA S were where this bit. I had guessed com.gamevil.zenonia6.global and com.gamevil.zenoniaS.global, got 404 on both, and could have written "delisted" next to each of them. A single guessed package name cannot support that word, because a wrong guess produces the same 404 that a removed app produces.

So the next day I widened it. Starting from the naming pattern that demonstrably works, since ZENONIA 4 and 5 both return 200, I hand-picked 15 variants: both publisher prefixes those two use (Gamevil and Com2uS), the suffix structures that turn up in this naming family, and the case variants of that trailing S. Not a full grid of every prefix crossed with every suffix. A specific list, written down, so anyone can rerun it.

All 15 returned 404. Zero hit 200. The two known-good packages were sent in the same batch as controls and both returned 200, which is the only reason I trust the 404s at all.

That still does not prove either title was never on Google Play. The package-name space is unbounded and I cannot try every string in it. So both stay recorded as Unverified, not as delisted, and the candidate list sits next to the result so that someone who knows a package name that returns 200 can close it in one message.

A 200 is not a green light either

One of the listings that answers 200 also says, in its own store copy, that it is only available up to Android 4.4 KitKat. The page is live. The install button is there. The ceiling is from 2013.

I have not tried to install it on a device, so I record that as the listing's own restriction rather than a prediction about anyone's phone. But it is the reason the table has two separate columns instead of one: "has a live store page" and "you can play this tonight" are different facts, and collapsing them into a single green tick would have been the most useful-looking mistake available.

What I would tell anyone probing a store catalogue

Send known-good controls in the same batch, every time. Two of my requests existed purely to prove the pipeline could still see a 200, and they are the difference between a result and a rumour.

Write down the exact strings you tried. "We searched and found nothing" is unfalsifiable. A list of 15 candidates with 15 status codes is something a stranger can attack.

And date-stamp the row, not the page. Store listings change without telling anyone, so every status I have is a claim about one moment.

Every request behind this, the raw responses and the two controls, is in the full ZENONIA store-status table, with every request logged. If you have a package name that returns 200 for ZENONIA 6 or S, that page is where it belongs.