Back to Blog

Minecraft Heads API JSON Response: Guide to Endpoints

Introduction

The Minecraft Heads API JSON response is the structured data returned by the Minecraft Heads API when you request head data from MCHeads. It tells you which Minecraft head matched your request, its head ID, which categories and tags it belongs to, and how to use it in a website, plugin, bot, or other Minecraft-related app.

This guide covers the API v2.0 response schema, how to fetch a single head by ID, how to search heads with query parameters, and how to handle errors, empty results, pagination, filtering, and rate limiting.

What Is the Minecraft Heads API?

The Minecraft Heads API is a REST API for discovering and retrieving Minecraft head metadata from MCHeads. It returns JSON so developers can browse heads without scraping pages or guessing asset URLs.

A typical response includes a head’s ID, name, category, tags, and image or texture fields. That makes the API useful for search pages, category listings, and in-game catalogs.

Because the API is versioned, the exact response schema can change between releases. Always check the current API documentation before relying on field names in production.

Base URL, Authentication, and First Request

The base URL should come from the API documentation for the current version. If the docs specify API v2.0, use that versioned base path exactly in your request URL.

Most read-only endpoints do not require authentication, so you can usually test them with a simple GET request in a browser, cURL, or a tool like Postman. If an endpoint does require access, the documentation should say whether to send an API key or token in a header such as Authorization or X-API-Key.

A good first test is to request one documented endpoint and inspect the returned HTTP status codes and JSON body. If the request fails, the most common causes are a wrong endpoint, a missing parameter, a version mismatch, or a missing header.

Search Results vs. Single-Head Response

The API commonly returns two different response shapes:

  • Search results: a list of matching heads
  • Single-head response: one head object for a specific head ID

Use search endpoints when you want browsing, filtering, or keyword lookup. Use the single-head endpoint when you already know the ID and need one exact record.

This distinction matters because the JSON structure is often different. Search responses usually include an array of results plus pagination metadata, while a single-head response usually returns one object with the full details for that head.

How to Get a Minecraft Head by ID

To fetch one head, use the endpoint’s path parameters with the head ID. A typical pattern looks like /heads/{id} or another documented route in the API docs.

Example request pattern:

curl -i "https://api.example.com/v2/heads/12345"

If the ID exists, the API should return one JSON object for that head. If the ID does not exist, you should expect a 404 or another documented not-found response.

How to Search Minecraft Heads with the API

Search endpoints use query parameters to filter results. Common parameters include q or search for keywords, category, tag, page, limit, and sometimes sort.

Example search pattern:

curl -i "https://api.example.com/v2/heads?q=creeper&category=mob&tag=hostile&page=1&limit=24"

Search is useful when you want to find multiple heads that match a theme, keyword, or category. The API may return partial matches, exact matches, or both, depending on how the endpoint is designed.

Pagination and Filtering

Pagination lets the API return results in smaller pages instead of sending every match at once. A paginated response often includes metadata such as the current page, page size, total results, and total pages.

Filtering usually happens through query parameters. For example:

  • q=creeper filters by keyword
  • category=mob filters by category
  • tag=hostile filters by tag
  • page=2 moves to the next page
  • limit=24 changes how many results are returned

Pagination and filtering work together: you can search for a category, narrow it by tag, and then page through the matching results.

What the JSON Response Looks Like

A typical Minecraft Heads API JSON response may look like this for a search request:

{
  "data": [
    {
      "id": "12345",
      "name": "Creeper Head",
      "category": "mob",
      "tags": ["hostile", "green"],
      "texture": "https://cdn.example.com/textures/12345.png",
      "preview": "https://cdn.example.com/previews/12345.png"
    }
  ],
  "meta": {
    "page": 1,
    "limit": 24,
    "total": 1,
    "pages": 1
  }
}

A single-head response may return one object instead of an array:

{
  "data": {
    "id": "12345",
    "name": "Creeper Head",
    "category": "mob",
    "tags": ["hostile", "green"],
    "texture": "https://cdn.example.com/textures/12345.png",
    "preview": "https://cdn.example.com/previews/12345.png"
  }
}

The exact field names depend on the API version, but common fields include:

  • id or headId
  • name
  • category
  • tags
  • texture
  • preview
  • pagination fields in meta

How to Parse the JSON Response in JavaScript or Python

JavaScript fetch

If you are building a browser API integration or a Node.js app, fetch is a straightforward way to parse the response:

const url = "https://api.example.com/v2/heads?q=creeper&page=1&limit=5";

async function loadHeads() {
  const res = await fetch(url);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);

  const json = await res.json();
  const results = Array.isArray(json.data) ? json.data : [json.data];
  console.log(results);
}

loadHeads().catch(console.error);

Python requests

For scripts, bots, or backend tools, requests is a simple option:

import requests

url = "https://api.example.com/v2/heads?q=creeper&page=1&limit=5"
response = requests.get(url, timeout=10)
response.raise_for_status()

payload = response.json()
results = payload["data"]
if isinstance(results, dict):
    results = [results]
print(results)

In both cases, check whether data is an array or a single object before processing it.

Error Handling and Common HTTP Status Codes

Good error handling starts with checking the HTTP response before parsing the body.

Common HTTP status codes include:

  • 200 — success
  • 400 — bad request, often caused by invalid query parameters
  • 401 — unauthorized, if authentication is required
  • 403 — forbidden, if your credentials or origin are blocked
  • 404 — not found, often for an invalid endpoint or head ID
  • 429 — too many requests, usually related to rate limiting
  • 500 — server error

Error responses may include an error object with a message, code, or details. If the API returns an empty response, confirm whether the request was actually successful or whether the endpoint returned an empty data array.

Rate Limiting, CORS, and Caching

The API may enforce rate limiting to protect the service. If you receive 429, slow down requests, add retries with backoff, and cache repeated lookups.

For websites, CORS matters. If the API sends the right CORS headers, you can call it directly from the browser. If not, route requests through your own server or proxy.

Caching is useful for both search results and single-head lookups. Cache stable head details, reuse identical responses when possible, and avoid refetching the same data on every page load.

Using the API in a Website or Minecraft-Related App

You can use the API in a website, a Minecraft-related app, a bot, or a plugin workflow. A common pattern is:

  1. Send a GET request to the documented endpoint
  2. Parse the JSON response
  3. Render the head name, preview, and tags
  4. Cache the result for future use
  5. Handle errors and empty results gracefully

For a website, you might show search results in a grid and let users filter by category or tag. For a Minecraft tool, you might use the head ID to link a head to a profile, catalog entry, or command output.

Categories and Tags

Categories and tags help organize heads for discovery.

  • Categories group heads into broader buckets, such as mob or theme-based collections
  • Tags add more specific labels, such as hostile, seasonal, or color-based descriptors

Depending on the endpoint, categories and tags may appear in the response, in the query string, or both. They are useful for filtering search results and for displaying metadata in your UI.

What to Do If the API Returns an Error or Empty Response

If the API returns an error or empty response, check the following:

  • The base URL and version are correct
  • The endpoint path matches the API documentation
  • Query parameters are spelled correctly
  • The head ID exists
  • You are not hitting a rate limit
  • The browser is not blocked by CORS

Use developer tools to inspect the network request, response headers, and JSON body. If the response is empty but successful, it may simply mean no heads matched your filters. If the response is an error, the status code and payload should tell you whether the issue is authentication, routing, filtering, or rate limiting.

FAQ

What is the Minecraft Heads API JSON response?
It is the JSON payload returned by the Minecraft Heads API when you request head data from MCHeads.

Does the Minecraft Heads API require authentication?
Many read-only endpoints do not, but the API documentation should confirm the requirement for each endpoint.

What is the difference between search results and a single-head response?
Search results return multiple matches and usually include pagination metadata. A single-head response returns one head object for a specific head ID.

How do I search Minecraft heads with the API?
Use query parameters such as q, category, tag, page, and limit on the documented search endpoint.

How do I parse the JSON response in JavaScript or Python?
Use fetch(...).then(res => res.json()) or requests.get(...).json(), then check whether data is an array or a single object.

Is there a rate limit for the API?
There may be one. Check the API documentation and handle 429 responses with backoff and caching.

What should I do if the API returns an error or empty response?
Verify the endpoint, parameters, version, and head ID, then inspect the HTTP status code and JSON body in developer tools.