apiton blog
Not listed, for sale, on auction, expired: what apiton's statuses mean
apiton.org lists Telegram usernames, anonymous +888 numbers and .ton domains with a status and,
when there is one, a price. This page explains exactly what each status means, where the data comes
from, and how old it can be — so you know when to trust a list and when to check live.
The four statuses
| Status | Usernames and numbers | Domains |
|---|---|---|
| Not listed | the NFT exists and is not offered | registered, not offered, not expired |
| For sale | fixed price: a sale contract or a Fragment listing | fixed price in a sale contract |
| On auction | a Fragment auction is running in the NFT | an auction is running in the DNS item |
| Expired | — | the paid year is over; the name can be claimed |
"Not listed" is deliberately not called "available": the item has an owner, it is just not for sale. An item that does not exist at all — a username never auctioned, a number never minted, a domain never registered — has no page and gets a "not in our catalog" answer with a link to check it in @apitonBot.
The hubs are simply these statuses as lists: usernames for sale, username auctions, numbers for sale, numbers on auction, domains for sale, domain auctions and expired domains.
Where the data comes from
The catalog behind the site is part of the public apiton API (v2.Catalog). It is filled in
three ways:
- An indexer walks the username, number and domain collections to discover items.
- Liteservers — the TON network's own nodes — are used to read each item: owner, expiry, auction state, sale contract. This is the same read the live API does.
- Every lookup through the API adds or refreshes an item: when anyone opens a username,
number or domain in @apitonBot or via
v2.Nft/*, the result goes into the catalog.
Prices come from the NFT's own auction, a sale contract, or the Fragment page — see Where a price comes from. Fragment prices are marked "per fragment.com".
How fresh it is
- Item pages read the item live from the chain when the page is built and merge it with the catalog row. The built page is cached for up to about 10 minutes.
- Hubs come from the catalog and are cached for up to about 5 minutes. The catalog re-reads items in the background under a rate budget, so an item that changed recently may show its previous status on a hub until its turn comes.
- If the live read fails, an item page falls back to the last catalog data and is cached only briefly, so the next visit tries live again.
In short: lists are good for discovery; for a decision, use the live read. The bot card in @apitonBot is always read live.
What the history shows
Item pages show the latest events: listed, delisted, price changed, sold, auction started, new bid, expired, renewed. One caveat: a sold event means the owner changed while the item was listed or right after — the indexer cannot always tell a sale from a plain transfer between wallets.
Known gaps
- The catalog grows as items are discovered. Numbers were seeded from a large existing list; usernames and domains are still being filled in, so a hub is a sample of the market, not all of it.
- A brand-new item may not have a page for a few minutes after it first appears.
- Domain expiry dates are computed from the on-chain
last_fill_up_time(one year of 366 days), exactly as described in How .ton domains expire.
If you build on this data, the same catalog is available through the API — see Using the apiton API.