Minecraft Player Lookup Scraper - UUID, Skin & Mojang Fallback

Why use this scraper

If you run a whitelist, a leaderboard, a skin gallery, or anything else that needs to turn a Minecraft username into a reliable identity, you already know the two public APIs involved (PlayerDB and Mojang) have their own quirks: PlayerDB is clean but goes down occasionally, and Mojang's raw API only gives you a bare UUID with no skin or cape data. Most "Minecraft lookup" tools on the Store wrap just one of the two, so when that one API hiccups your whole pipeline returns errors.

This actor checks PlayerDB first, because it bundles the dashed UUID, the current username, the avatar and the full-resolution skin texture URL in one clean response. If PlayerDB fails to resolve a name (rate limit, outage, or the record genuinely does not exist there), it automatically retries against the official Mojang profile API before giving up. You get one consistent record per username either way, and you never have to write your own retry logic.

Overview

Input is a list of Java-edition Minecraft usernames (UUIDs also work against the same lookup path). Output is one JSON record per player: canonical username, UUID in both raw and dashed form, skin texture URL, and which upstream source actually answered. A run of a handful of names typically finishes in a few seconds; most of the time is the lookup round-trip itself, not any heavy processing. Billing is per player successfully resolved, so a failed lookup costs nothing.

Supported inputs

• Usernames (usernames, required array) - the Java-edition in-game names you want resolved. Case does not matter for the lookup itself; the actor returns whatever capitalization Mojang or PlayerDB currently has on file.
• Mixed UUIDs - the same usernames field also accepts UUID strings (dashed or raw). They are sent to the same lookup path as a plain username, so you can mix names and UUIDs in a single run when you already have some IDs and need the rest resolved by name.
• Debug logs (debug, boolean, optional) - turns on verbose logging in the run console. Useful when you want to see exactly which upstream source answered for each entry; it does not change the output records.

There is no search or "list all players" mode: Mojang and PlayerDB do not expose a public directory of accounts, only single-player lookups by name or ID.

Use cases

• Server whitelist audits - feed your whitelist file in and confirm every username still resolves to a valid, current account before letting someone connect.
• Skin and avatar galleries - pull the current skin texture URL for a roster of players to build a fan site, a server leaderboard, or a Discord bot command without touching any Minecraft launcher code.
• Username-to-UUID migration tools - Mojang accounts are identified by UUID internally; anything that stores player data by UUID (bans, stats, permissions) needs this conversion step at least once per new player.
• Community tooling and bots - Discord or web bots that let members check "is this username real" or "what does this player's skin look like" without the bot maintainer running their own Mojang API integration.
• Data pipeline enrichment - if you already collect Minecraft usernames from a form, a server log, or another scraper, run them through this actor as an enrichment step to attach a stable UUID before writing the rows to your own database, so a later username change does not silently split one player into two records.

How it works

For each username in the input list, the actor first queries PlayerDB's public player endpoint, which already aggregates the canonical name, both UUID formats, and the current skin texture into one response. If that lookup comes back empty (name not found there, or the service is temporarily unavailable), the actor falls back to Mojang's own username-to-UUID endpoint and returns whatever that source provides, which is the username and UUID but not a skin URL. Either way you get exactly one record per input name, tagged with which source actually resolved it, and a lookup that fails on both sources returns an explicit error record instead of silently disappearing.

Input configuration

Single username:

{ "usernames": ["Notch"] }

Multiple usernames in one run:

{ "usernames": ["Notch", "jeb_", "Dream"] }

Mixing a UUID with usernames:

{ "usernames": ["069a79f4-44e9-4726-a5be-fca90e38aaf5", "jeb_"], "debug": true }

Output sample

Real output from a production run (username Notch, resolved via PlayerDB):

{
  "input": "Notch",
  "uuid": "069a79f444e94726a5befca90e38aaf5",
  "dashedUuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5",
  "name": "Notch",
  "avatarUrl": "https://crafthead.net/avatar/069a79f444e94726a5befca90e38aaf5",
  "skinUrl": "https://textures.minecraft.net/texture/292009a4925b58f02c77dadc3ecef07ea4c7472f64e0fdc32ce5522489362680",
  "source": "playerdb"
}

When PlayerDB cannot resolve a name and the Mojang fallback answers instead, the record is the same shape minus the avatar and skin fields (Mojang's raw API does not expose texture URLs), with "source": "mojang".

Key output fields

Field	Type	Description
input	string	The username or UUID you sent in, unchanged.
uuid	string	Raw (no dashes) player UUID.
dashedUuid	string	Same UUID in standard dashed format.
name	string	Current canonical username on file for this account.
avatarUrl	string	Head/avatar render URL. Present only when PlayerDB resolved the record.
skinUrl	string	Full-body skin texture URL. Present only when PlayerDB resolved the record.
source	string	Which upstream answered: playerdb or mojang.

Pricing

Event	Price
Player resolved	$0.0005 per player (errors are not charged)

Minimum charge per run: $0.25.

What makes this richer than the competition

Two other Minecraft lookup actors cover the same target. dami_studio/minecraft-player-lookup advertises the same username-to-UUID-to-skin flow with cape data added, and automation-lab/minecraft-player-profile-lookup is, like this actor, a PlayerDB wrapper, but on a single source with no documented fallback: if PlayerDB has an outage, that actor has nothing to fall back to. This actor is the only one of the three that automatically retries against Mojang's own API when PlayerDB fails, so a single upstream outage does not turn into a run full of errors.

Notes & limitations

• This actor does not operate on account emails, passwords, purchase history, or anything behind a login wall. Everything it returns is already public: the same username-to-UUID and skin-texture data anyone can see by visiting a player's public profile page or loading their skin in a browser.
• Treat the name field as current, not historical. Minecraft usernames can be changed by the account owner, and both PlayerDB and Mojang only expose the current name for a given UUID, not the full rename history. If you need to track a UUID across a rename, store the UUID as your primary key and re-run the lookup periodically to catch the new name.
• No cape data. PlayerDB's response does not currently expose a cape texture URL, so this actor does not return one; do not expect a capeUrl field despite similar actors advertising cape support.
• Skin and avatar URLs are only populated when PlayerDB resolves the record. If the Mojang fallback answers instead, you get the username and UUID only, no texture URLs.
• This only works for Java-edition accounts. Bedrock-only player identities are not covered by either upstream API and will come back as a fetch error.
• Mojang and PlayerDB do not expose a search or listing endpoint, so this actor cannot enumerate players, only resolve ones you already have a username or UUID for.

FAQ

Does this work with UUIDs instead of usernames? Yes. Put the UUID (dashed or raw) in the same usernames array; it is sent to the same lookup path.

What happens if a username does not exist? You get an error record for that entry (error: "fetch_failed") instead of a silent gap, and it is not charged.

Can I look up cape data? No, see Notes & limitations above. Neither upstream source this actor uses exposes a public cape URL today.

How fast is a run with 50 usernames? Each lookup is a couple of API round-trips with a short delay between entries to stay polite to the upstream services; 50 names typically finishes in under a minute.

Does a failed lookup cost anything? No. Only successfully resolved players are charged.

For AI Agents & LLM Apps

Call this actor directly from an MCP-compatible client at mcp.apify.com, or trigger it from any backend with the Apify API's synchronous run-and-get-dataset endpoint:

curl "https://api.apify.com/v2/acts/gio21~playerdb-minecraft-scraper/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"usernames": ["Notch", "jeb_"]}'

This returns the dataset items directly in the response body, no separate polling step needed, which makes it a one-shot tool call for an agent that just needs a Minecraft identity resolved mid-conversation.

Disclaimer

This Actor is an independent tool and is not affiliated with, endorsed by, or sponsored by Mojang Studios, Microsoft, or any of their subsidiaries. It uses publicly documented APIs (PlayerDB and Mojang's official player API) and returns only publicly available account data. All trademarks mentioned are the property of their respective owners.

SEO Keywords

minecraft username to uuid, minecraft player lookup, minecraft uuid scraper, minecraft skin url api, mojang api scraper, playerdb scraper, minecraft whitelist checker