vike
API EndpointsOn-chain

/wallets/{address}/ens

Reverse ENS lookup — turn an address into vitalik.eth. Returns null where the address has no ENS name set.

GET https://data.vike.io/v1/onchain/wallets/{address}/ens

Reverse ENS lookup — turn an address into vitalik.eth. Returns null where the address has no ENS name set. Already-resolved names are answered from our own store; an address the store has not resolved is looked up with a few eth_calls over Ethereum JSON-RPC, and the name is forward-verified before it is returned. Those calls go to a pool of public Ethereum RPC endpoints first, then to our own general pool, so the address you ask about is sent to those RPC providers. No vendor API such as Moralis is involved on either path.

cURL
# turn an address into its ENS name, for a label that reads better than a hex string
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045/ens"

# the address case does not matter: the route lower-cases it before the lookup
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/0xd8da6bf26964af9d7eed9e03e53415d37aa96045/ens"

# just the name, with null printed when there is none
curl -s -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045/ens" \
  | jq -r '.ens'

# name a wallet from another route (WALLET is an address from /counterparties or /wallets/discover), keeping source: ens null with source local means no name is set, while null with source rpc may only mean the resolvers were unreachable, so retry before concluding
curl -s -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/$WALLET/ens" \
  | jq '{ens, source}'
addresspathrequired
Wallet address, 0x-prefixed, exactly 42 characters

No response has been captured since the resolver was rewritten

The only capture this page ever had (2026-09-03) was a 400 carrying a Moralis outage message, from when this route sat in front of that vendor. The vendor is gone and so is the message, so that capture was removed rather than left as an example. The card below is the shape the code returns, with placeholders, not a recorded response.

Response shape
{
  "address": "<the address, lower-cased>",
  "ens": "<name>.eth or null",
  "source": "local or rpc"
}

Three things follow from it.

  • source says which path answered. local is our own pre-resolved store; rpc is a fresh lookup over Ethereum JSON-RPC (public endpoints first, then our own pool). A local answer with ens: null is a recorded fact: the address was resolved and has no name set.
  • ens: null with source: rpc is ambiguous. The RPC path treats "every configured Ethereum endpoint failed" as None, which comes back as a 200 with ens: null, the same shape as an address with no name. Retry before concluding an address has none.
  • A real error is a 400. If the lookup raises something unforeseen, the route answers 400 with no local ENS record, and the resolver is unavailable. Provider detail is logged, never sent to the caller. A malformed address is a 400 too (Bad EVM address: …).