Toggle search
Toggle menu
20.8K
1.7K
7
111.7K
SAS Gaming Wiki
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Minecraft:Mojang API

From SAS Gaming Wiki
More actions
Revision as of 11:18, 17 May 2026 by SyncBot (talk | contribs) (Sync: updated from Minecraft)

This page provides documentation for API endpoints provided by Minecraft:Mojang Studios which allows user to query player data and make changes programmatically.

Most of the API has a per-IP ratelimit of 200 requests per 2 minutes. For IPv6, the ratelimits are bucketed by /56 subnet. Some endpoints have different ratelimits.

Request and response

For requests with a payload, the following restrictions apply:

  • Request must include the Content-Type header, which must be application/json. Otherwise, the server returns HTTP 415.
  • Payload must be a valid json. Otherwise, the server returns HTTP 400.

If the request is successful, the server:

  • Returns a successful response code (HTTP 2XX)
  • Returns an empty payload (with HTTP 204) or a valid json

Otherwise, if the request fails, the server returns a non-2XX HTTP status code with this payload:

These are some common causes:

HTTP status code Template:Cd Template:Cd Explanation
400 IllegalArgumentException Depends on the endpoint Incorrect or invalid argument in the request.
MismatchedInputException JSON payload does not meet the required schema or payload is not an invalid JSON.
JsonParseException
401 (empty payload) (empty payload) Endpoint requires authentication, but request header does not have an Authorization header or the token is invalid.
Unauthorized The request requires user authentication Endpoint requires authentication, but request header does not have an Authorization header.
403 ForbiddenOperationException Forbidden Invalid auth token.
Template:Tc Your account has been suspended. Please contact customer service. Account has been banned/suspended state by triggering a high volume of erroneous requests. See #Account suspensions.
404 Not Found The server has not found anything matching the request URI Endpoint does not exist.
405 Method Not Allowed The method specified in the request is not allowed for the resource identified by the request URI Request method is not supported.
415 Unsupported Media Type The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method Template:Cd request header does not match the type the endpoint allows.

Account suspensions

A Minecraft account can be entered into a banned/suspended state by triggering a high volume of erroneous requests, such as a high volume of 429s while uploading a skin.

These suspensions appear to be temporary, although this is speculation and the exact functionality of this automatic suspension system is unknown. 

POST https://api.minecraftservices.com/authentication/login_with_xbox

Returns 403 with the following JSON data <syntaxhighlight lang="json"> { "path": "/authentication/login_with_xbox", "details": { "reason": "ACCOUNT_SUSPENDED" }, "errorMessage": "Your account has been suspended. Please contact customer service." } </syntaxhighlight>

Other services will report that the account is banned, such as servers serving the otherwise unused message You are banned from playing online.

These suspensions typically clear within 24 hours but may require contacting Minecraft support if they don't.

Query player information

These endpoints do not need an access token, and some endpoints can query registered account that do not own the game.

Query player's username

Input

Player's name (case insensitive).

Request (GET)
Response
Example

https://api.mojang.com/users/profiles/minecraft/jeb_
Player jeb_'s UUID.

<syntaxhighlight lang="json"> { 

   "name": "jeb_",
   "id": "853c80ef3c3749fdaa49938b674adae6"

} </syntaxhighlight>

Error
  • HTTP 404 is returned if no player with such name exists.

Query player's UUID

Input

Player's UUID.

Request (GET)

https://api.minecraftservices.com/minecraft/profile/lookup/<UUID>

Response

The same as #Query player's username.

Query player UUIDs in batch

Payload

A JSON array with no more than 10 player names (case insensitive).

Request (POST)
  • https://api.mojang.com/profiles/minecraft
  • https://api.minecraftservices.com/minecraft/profile/lookup/bulk/byname
  • https://api.mojang.com/minecraft/profile/lookup/bulk/byname
Response
Example

Request with payload ["jeb_","notch"]. <syntaxhighlight lang="json">[ 

   {
       "id": "853c80ef3c3749fdaa49938b674adae6",
       "name": "jeb_"
   },
   {
       "id": "069a79f444e94726a5befca90e38aaf5",
       "name": "Notch"
   }

]</syntaxhighlight>

HTTP status code Template:Cd Template:Cd Explanation
400 CONSTRAINT_VIOLATION size must be between 1 and 10 RequestPayload is an empty array.
RequestPayload is has more than 10 elements.
Invalid profile name RequestPayload includes an empty string.

Query player's skin and cape

Input

Player UUID and whether the request is signed.

Request (GET)
  • https://sessionserver.mojang.com/session/minecraft/profile/<UUID>
    • Ratelimited at about 400 requests per 10 seconds.
  • https://sessionserver.mojang.com/session/minecraft/profile/<UUID>?unsigned=false
Response
Example

https://sessionserver.mojang.com/session/minecraft/profile/853c80ef3c3749fdaa49938b674adae6
Returns: <syntaxhighlight lang="json"> { 

   "id": "853c80ef3c3749fdaa49938b674adae6",
   "name": "jeb_",
   "properties": [
       {
           "name": "textures",
           "value": "ewogICJ0aW1lc3R..."
       }
   ]

} </syntaxhighlight> Content in Template:Nbt after Base64 decoded: <syntaxhighlight lang="json"> { 

   "timestamp": 1653838459263,
   "profileId": "853c80ef3c3749fdaa49938b674adae6",
   "profileName": "jeb_",
   "textures": {
       "SKIN": {
           "url": "http://textures.minecraft.net/texture/7fd9ba42a7c81eeea22f1524271ae85a8e045ce0af5a6ae16c6406ae917e68b5"
       },
       "CAPE": {
           "url": "http://textures.minecraft.net/texture/9e507afc56359978a3eb3e32367042b853cddd0995d17d0da995662913fb00f7"
       }
   }

} </syntaxhighlight>

Error
HTTP status code Template:Cd Template:Cd Explanation
204 (empty payload) (empty payload) This UUID does not have an associated player
400 (empty) Not a valid UUID: <inputted argument> UUID is invalid.

Microsoft authentication

Template:For

Authentication for Microsoft accounts. Before using Microsoft auth, an Microsoft Azure Application must be created to obtain OAuth 2.0 client ID and token, which can then be used to obtain a Microsoft token. When obtaining the token, the Template:Cd parameter should include Template:Samp to obtain an Xbox Live token.

Obtain an Xbox Live token with Microsoft token

Payload
Request (POST)

https://user.auth.xboxlive.com/user/authenticate

SSL renegotiation required in SSL implementation.

Response

Obtain an XSTS token with Xbox Live token

Payload
Request (POST)

https://xsts.auth.xboxlive.com/xsts/authorize

SSL renegotiation required in SSL implementation.

Response
Error

HTTP 401 is returned if an error occurs in obtaining the XSTS token.

Obtain Minecraft access token with XSTS token

Payload
Request (POST)

https://api.minecraftservices.com/authentication/login_with_xbox

Response

Check if the account owns Minecraft

Request header

Authorization should be Bearer <Minecraft access token>.

Request (GET)

https://api.minecraftservices.com/entitlements/license?requestId=<v4 UUID>

Response

If the account owns Minecraft, returns:

If the account does not own Minecraft or is playing with Xbox Game Pass, empty payload is returned.

Player config

These endpoints are at https://api.minecraftservices.com, and all requires the Authorization header in request with value Bearer <Minecraft access token>. HTTP 401 is returned if token is missing or invalid.

Query player profile

Request (GET)

/minecraft/profile

Response

Query player attributes

Request (GET)

/player/attributes

Response

Modify player attributes

Payload

A JSON array containing the desired keys to update, right now, only orofanityFilterPreferences and friendsPreferences can be updated

Request (POST)

/player/attributes

Response

The same as #Query player attributes.

Get list of blocked users

Request (GET)

/privacy/blocklist

Response

Get keypair for signature

Request (POST)

/player/certificates

Response

Query player's name change information

Request (GET)

/minecraft/profile/namechange

Response

Check gift code validity

Request (GET)

/productvoucher/giftcode

Response

Returns HTTP 200 or 204 if the gift code is valid. Otherwise returns HTTP 404.

Check name availability

Request (GET)

/minecraft/profile/name/<name to be checked>/available

  • This endpoint has a per-account ratelimit of 20 requests per 5 minutes.
Response
  • Template:Nbt Root tag
    • Template:Nbt: Status of the name. DUPLICATE means the name is taken. AVAILABLE means the name is available.NOT_ALLOWED means the name does not meet requirements.

Change name

Input

Name to change to

Request (PUT)

/minecraft/profile/name/<name to change to>

Response
Error
HTTP status code Template:Cd Template:Cd Explanation
400 CONSTRAINT_VIOLATION changeProfileName.profileName: Invalid profile name Name does not meet requirement. The name must have less than or equal to 16 characters and must consist of alphanumericals and underscores.
403 (empty) Could not change name for profile Cannot change name. If detail.status is DUPLICATE, the name has already been taken.
429 - - Too many rename requests sent.

Change skin

Payload
Request (POST)

/minecraft/profile/skins

Response

Returns the profile if operation succeeds.

Upload skin

Payload

Payload is made up of two parts:

  • Template:Cd: Skin variant. classic for the Steve model and slim for the Alex model.
  • Template:Cd: Image data for the new skin. See example below.
Request (POST)

/minecraft/profile/skins

Example

<syntaxhighlight lang="bash"> curl -X POST -H "Authorization: Bearer <access token>" -F variant=classic -F file="@steeevee.png;type=image/png" https://api.minecraftservices.com/minecraft/profile/skins </syntaxhighlight>

Response

Returns the profile if operation succeeds.

Reset skin

Input

Player's UUID.

Request (DELETE)

/minecraft/profile/skins/active

Response

Returns the profile if operation succeeds.

Hide cape

Request (DELETE)

/minecraft/profile/capes/active

Response

Returns the profile if operation succeeds.

Show cape

Payload
Request (PUT)

/minecraft/profile/capes/active

Response

Returns the profile if operation succeeds.

Error
HTTP status code Template:Cd Template:Cd Explanation
400 (empty) profile does not own cape The player does not own the cape.

Server

Query blocked server list

Request (GET)

https://sessionserver.mojang.com/blockedservers

Response

A text file where every line is the SHA-1 hash of a blocked server.


Verify login session on client

Payload

Server ID is obtained from the following algorithm:

<syntaxhighlight lang="java"> public static String generateServerId(String baseServerId, // Base server ID, usually an empty string"" 

                                     PublicKey publicKey,   // Server's RSA public key
                                     SecretKey secretKey    // The symmetric AES secret key used between server and client
                                    ) throws Exception { 
   MessageDigest messageDigest = MessageDigest.getInstance("SHA-1");
   messageDigest.update(baseServerId.getBytes("ISO_8859_1"));
   messageDigest.update(secretKey.getEncoded());
   messageDigest.update(publicKey.getEncoded());
   byte[] digestData = messageDigest.digest();
   return new BigInteger(digestData).toString(16);

} </syntaxhighlight>

Request (POST)

https://sessionserver.mojang.com/session/minecraft/join

  • This endpoint has a per-account ratelimit of 6 joins per 30 seconds.
Response

Returns HTTP 204 if authentication passes.

Verify login session on server

Input

Case insensitive player name, server ID obtained by the above algorithm and the client IP (optional).

Request (GET)

https://sessionserver.mojang.com/session/minecraft/hasJoined?username=<player name>&serverId=<Server ID>&ip=<Client IP>

Response

Returns this payload if verification passes.

Get Mojang public keys

Request (GET)

https://api.minecraftservices.com/publickeys

Response
  • Template:Nbt Root tag
    • Template:Nbt: A list of public keys used for verifying player properties (such as skin and cape textures), from e.g. https://sessionserver.mojang.com/session/minecraft/profile/<UUID>?unsigned=false. A player property is considered valid by the client iff signed by any of these keys.
    • Template:Nbt: A list of public keys used for verifying player public keys, e.g. from https://api.minecraftservices.com/player/certificates. A player certificate is considered valid by the client iff signed by any of these keys.
    • Template:Nbt: A list of public keys used for verifying authentication tokens, like the JWT access token used in the Authorization Header in most requests to the Minecraft API.

Friends list

The friends list was introduced in Minecraft Java Edition 26.2 Snapshot 7. The API and client behavior are as such unstable and likely to change.

These endpoints are located on https://api.minecraftservices.com, and all require the Authorization header to be provided in the request with a value of Bearer <Minecraft access token>. An HTTP 401 error is returned if the token is missing or invalid.

Get list of friends and friend requests

Request (GET)

/friends

You may send an optional If-None-Match request header. See below for details.

Response

The response has an ETag response header, which you may save and reuse as the value for filling the If-None-Match request header in further requests.

If the friends list has not changed since the last request, and the value of the If-None-Match request header matches the value of the ETag response header in the last request, Mojang will return a HTTP 304 Not Modified response.

Example

<syntaxhighlight lang="json"> { 

   "friends": [
       {
           "profileId": "61699b2ed3274a019f1e0ea8c3f06bc6",
           "name": "Dinnerbone"
       }
   ],
   "incomingRequests": [
       {
           "profileId": "853c80ef3c3749fdaa49938b674adae6",
           "name": "jeb_"
       }    
   ],
   "outgoingRequests": [
       {
           "profileId": "069a79f444e94726a5befca90e38aaf5",
           "name": "Notch"
       }
   ],
   "empty": false

} </syntaxhighlight>

Friend management

Request (PUT)

/friends

Payload
  • Template:Nbt
    • Template:Nbt: Profile name of the player to add or remove. Optional.
    • Template:Nbt: UUID of the player to add or remove, Optional.
    • Template:Nbt: Action to perform. Values: ADD for sending or accepting friend requests, REMOVE for removing friends or denying friend requests.

name and profileId are optional, but at least one must be provided. If both are present, profileId will be prioritized.

Example

<syntaxhighlight lang="json"> { 

   "profileId": "069a79f444e94726a5befca90e38aaf5",
   "updateType": "ADD"

} </syntaxhighlight>

Response

Identical to #Get list of friends and friend requests.

Error
HTTP status code Template:Cd Template:Cd Explanation
400 UNKNOWN_PROFILE Name or profile does not exist
CANNOT_ADD_SELF Cannot add yourself as friend
NOT_FRIENDS Not friend with Template:Cd cannot remove
ALREADY_FRIENDS Already friend with Template:Cd
INVALID_JSON Depends on request body All required arguments presents in request body, but somehow cannot be decoded (e.g. wrong enum values, invalid UUID)
CONSTRAINT_VIOLATION Depends on request body Some required arguments are missing
403 INVITE_REJECTED User does not have friends enabled or accept invites

Presence

This API is used for both querying friends' presences and reporting your current presence status. There is no standalone API for querying friends' presences.

Request (POST)

/presence

Payload
  • Template:Nbt
    • Template:Nbt: Your current presence status. See the table below for all available statuses.
    • Template:Nbt: Information relating to peer-to-peer multiplayer invites. Should be omitted in certain situations, see below.
      • Template:Nbt: The 26.2-snapshot-7 client always sends null. See below.
      • Template:Nbt: List of invited players. Optional.
        • Template:Nbt: UUID of a invited player. Must be UUID with dashes.

For all presence statuses you may choose to omit the entire joinInfo object, even while reporting a PLAYING_HOSTED_SERVER status. Your friends' game client won't show "Request to join world" button in this situation. This is likely unintended behavior, and is subject to change in the near future.

To report an OFFLINE, ONLINE, PLAYING_OFFLINE or PLAYING_SERVER status, you must have a string (1 <= length <= 256) or a numeric joinInfo.value present or omit the entire joinInfo object, otherwise Mojang will return a HTTP 400 Bad Request response.

To report a PLAYING_HOSTED_SERVER status, you must have a null joinInfo.value present or omit the entire joinInfo object, otherwise Mojang will return a HTTP 400 Bad Request response.

To report a PLAYING_REALMS status, you must have a numeric joinInfo.value present or omit the entire joinInfo object, otherwise Mojang will return a HTTP 400 Bad Request response.

You can add non-friends (even dummy UUIDs, such as all zeroes) to joinInfo.invites, and Mojang will not return an error. However, since you're not friends, you won't appear in their friends list, so they won't receive your peer-to-peer multiplayer invite.

Response
  • Template:Nbt
    • Template:Nbt: List of presence statuses. Only online friends will be included within this list.
      • Template:Nbt: A presence status.
        • Template:Nbt: UUID of the player, with dashes.
        • Template:Nbt: PMID used in peer-to-peer multiplayer. UUID with dashes.
        • Template:Nbt: Player's presence status. See the table below for all available statuses.
        • Template:Nbt: May be omitted in certain situations, see below.
          • Template:Nbt: Typically the same as the PMID, but can also be other values.
          • Template:Nbt: Whether you are invited to join the peer-to-peer multiplayer session.
        • Template:Nbt: Timestamp of the most recent presence report from this player.

joinInfo will be omitted if your friends omitted it when reporting their presence. This should not happen in vanilla Minecraft clients.

For most cases joinInfo.value should be same as the PMID, but could also be something else if your friends send a non-null value while reporting their presences. This shouldn't happen in vanilla Minecraft clients. The meaning of this key is unclear, since the 26.2-snapshot-7 client ignores it.

joinInfo.invited could be true when status is ONLINE. This means your friend set "Presence: LIMITED" in their settings, which restricts the status to reporting either ONLINE or OFFLINE, while still allowing them to invite others to join their peer-to-peer multiplayer session.

Currently, the game client doesn't seem to report the OFFLINE status before shutting down. After 10 minutes the server will consider the player offline due to their lack of presence updates.

All available presence statuses
Template:Cd Text shows on UI Explanation Comment
OFFLINE Offline The player is offline Offline players won't appear in their friends' presence responses
ONLINE Online The player is online but not playing any world or server (e.g. idling on the main menu, tweaking settings, etc.) If the player set "Presence: LIMITED" in settings, the game will always report this
PLAYING_OFFLINE In a world The player is playing a world which isn't open to peer-to-peer multiplayer (Multiplayer set to "OFF" or "LAN")
PLAYING_HOSTED_SERVER In a joinable world The player is playing a world which is open to peer-to-peer multiplayer
PLAYING_REALMS In a Realm The player is playing a Realms server 26.2-snapshot-7 will not report this
PLAYING_SERVER On a server The player is playing on a third-party server 26.2-snapshot-7 will not report this
Error

Nearly identical to #Friends management, with only INVALID_JSON and CONSTRAINT_VIOLATION present. If you have joinInfo.value present but violate the rules mentioned above, Mojang will return a HTTP 400 Bad Request error with only path and errorMessage.

Example request

<syntaxhighlight lang="json"> { 

 "status": "PLAYING_HOSTED_SERVER",
 "joinInfo": {
   "value": null,
   "invites": [
     "069a79f4-44e9-4726-a5be-fca90e38aaf5",
     "853c80ef-3c37-49fd-aa49-938b674adae6",
     "61699b2e-d327-4a01-9f1e-0ea8c3f06bc6"
   ]
 }

} </syntaxhighlight>

Example response

<syntaxhighlight lang="json"> { 

 "presence": [
   {
     "profileId": "069a79f4-44e9-4726-a5be-fca90e38aaf5",
     "pmid": "c41da2ff-0874-4bbe-a28b-d122bc467b1f",
     "status": "ONLINE",
     "lastUpdated": "2026-05-15T19:25:58Z"
   },

{ 

     "profileId": "853c80ef-3c37-49fd-aa49-938b674adae6",
     "pmid": "87c83220-965c-4d65-867f-8718f5ba04a6",
     "status": "ONLINE",

"joinInfo": { "value": "87c83220-965c-4d65-867f-8718f5ba04a6", "invited": true } 

     "lastUpdated": "2026-05-15T19:26:12Z"
   },

{ 

     "profileId": "61699b2e-d327-4a01-9f1e-0ea8c3f06bc6",
     "pmid": "f289feed-30ab-4039-bef8-5752ea9d2c1c",
     "status": "PLAYING_HOSTED_SERVER",

"joinInfo": { "value": "f289feed-30ab-4039-bef8-5752ea9d2c1c", "invited": false } 

     "lastUpdated": "2026-05-15T19:26:32Z"
   }
 ]

} </syntaxhighlight>

Peer-to-peer friends networking

Peer-to-peer (P2P) friends networking was introduced in Minecraft Java Edition 26.2 Snapshot 7. It allows a host's singleplayer world to be joinable by friends over Peer-to-Peer WebRTC data channels. A Mojang-hosted signaling service handles the handshake, gameplay traffic flows peer-to-peer (using ICE). The protocol described below is unstable and likely to change.

General Properties:

  • The transport is DTLS-encrypted at the WebRTC layer; the client treats the resulting channel as a secure transport (Connection.isSecureTransport() == true). The Minecraft in-protocol AES encryption is skipped, but the standard Mojang online-mode handshake (encryption request, key packet, Yggdrasil hasJoinedServer check) is still performed, without adding the Encryption/Decryption layers.
  • Both peers must be friends with each other (see #Friends list).
  • Only one handshake is permitted per client and host at a time.
  • The integrated server, when published peer-to-peer, forces online mode on regardless of any singleplayer-side configuration. The guest's identity is verified twice: once at signaling (via the PMID) and at the normal Minecraft login sequence.

Identification

The signaling service routes messages by the PMID. A friend's PMID is obtained from the pmid field of their entry in their presence response.

When a peer-to-peer connection completes, the host resolves the guest's profile UUID locally from the PMID via its presence cache and pins it to the connection. The standard ServerboundHelloPacket profile UUID sent from the guest is ignored; the server obtains the guest's profile UUID via the normal login flow, and rejects the connection if the result does not match the UUID from its PMID presence cache. See Security model below.

Authentication uses the same Mojang access token as the rest of the Mojang API, but is sent in the x-mojangauth HTTP header rather than as a Bearer token.

The client also includes two stable identifiers for every request:

  • Session-Id: a UUID created once at startup. Sent on every subsequent request.
  • Request-Id: a fresh UUID generated per request.

For each join attempt a third identifier is used:

  • sessionId: a fresh UUID generated by the guest. Every FriendJoin and WebRtc signaling message belonging to that join attempt includes this id. Reusing an old session id will be rejected by the host.

Signaling service

Environment

The client selects one of two environments using the signaling.environment environment variable, falling back to a JVM system property of the same name, and finally defaulting to PRODUCTION.

Template:Cd Base URL
stage / staging https://signaling-afd.stage-6fd5f759.franchise.minecraft-services.net
prod / production (default) https://signaling-afd.franchise.minecraft-services.net

Discover the signaling WebSocket URL

Request (GET)

/api/v1.0/configuration/java

Headers (required on every signaling HTTP request):

  • x-mojangauth: Minecraft access token
  • Session-Id: stable per-launch UUID
  • Request-Id: fresh per-request UUID
Response
Example

<syntaxhighlight lang="json"> { 

 "result": {
   "signalingUri": "wss://signal-westeurope.franchise.minecraft-services.net",
   "pingFrequency": "00:01:00"
 }

} </syntaxhighlight>

The client caches signalingUri for 5 minutes.

Open the signaling WebSocket

Request

GET {signalingUri}/ws/v1.0/messaging/connect/java with a WebSocket upgrade, using the same three headers (x-mojangauth, Session-Id, Request-Id).

Once the connection is open:

  • The client sends a System_Ping_v1_0 JSON-RPC notification every 50 seconds. The server is expected to reply with a System_Pong_v1_0 notification, which the client otherwise ignores. The pingFrequency from the discovery request is ignored by the client.
  • The server may push Signaling_ReceiveMessage_v1_0 requests to the client at any time.

If the WebSocket disconnects, and the client still needs signaling, it schedules a reconnect 1 second later. If the client no longer needs signaling, it stays disconnected.

The WebSocket server disconnects the client automatically after 120 seconds of inactivity. This includes all messages and isn't limited to System_Ping_v1_0 messages.

WebSocket Framing

The WebSocket protocol is JSON-RPC 2.0 over text frames. The framing rules used by the client are:

  • One JSON-RPC envelope per text message. Multi-frame messages are accumulated until the WebSocket flags the last frame.
  • The total size of a single message is capped at 65 536 bytes. Oversize messages are dropped with a warning.
  • Outgoing requests use increasing integer ids starting at 1.
  • Unknown server-to-client methods are answered with the error {"code":-32601,"message":"Method not found"} (METHOD_NOT_FOUND).
  • Handler exceptions on incoming requests are answered with a JSON-RPC error {"code":-32603,"message":"Internal error"} (INTERNAL_ERROR).
  • For server-to-client requests, the client tolerates both params: [ {…} ]and params: {…}.

Standard JSON-RPC 2.0 envelopes:

<syntaxhighlight lang="json"> // Request (id must be a JSON integer) { "jsonrpc": "2.0", "id": 1, "method": "<name>", "params": [...] }

// Notification (id omitted or null) { "jsonrpc": "2.0", "method": "<name>", "params": [...] }

// Success response { "jsonrpc": "2.0", "id": 1, "result": <any> }

// Error response { 

 "jsonrpc": "2.0",
 "id": 1,
 "error": {
   "code": -32601,
   "message": "...",
   "data": {
     "Namespace": "ServiceRuntime",
     "Code": "<Name for the error code field>",
     "Message": "<Same content as in 'message'>",
     "CustomData": {},
     "StackTrace": null,
     "InnerError": null
   }
 }

} </syntaxhighlight>

Methods

Direction Method Params Result
C→S notification System_Ping_v1_0 [] —
S→C notification System_Pong_v1_0 (ignored) —
C→S request Signaling_TurnAuth_v1_0 [] TurnAuthResult (see #TURN credentials)
C→S request Signaling_SendClientMessage_v1_0 [null, "<toPmid>", "<innerJsonString>"] null / {} (client ignores on success)
S→C request Signaling_ReceiveMessage_v1_0 [{ From, Message, Id? }] or { … } {} (ACK only if id is present)

The third parameter of Signaling_SendClientMessage_v1_0 is a stringified JSON value, not a nested JSON object. The signaling service treats it opaquely and forwards it verbatim as the Message field of Signaling_ReceiveMessage_v1_0 on the recipient's side.

Server-side errors

On C→S requests, the server may return a JSON-RPC error whose data is an object. The client checks an optional string field data.Code:

Template:Cd Mapped client-side behaviour
MissingOrExpiredIdentity Generic signaling-rejected exception; the matching outgoing request fails and connection listeners are notified.
UnknownPlayer Same as above.
(any other Code, or if message body contains the substring not registered) Unknown-player exception; same downstream effects.
(missing or unrecognised) Generic signaling-rejected exception.

TURN credentials

Before creating a peer connection, the client fetches TURN authentication credentials from the WebSocket connection. The result is cached for 60 seconds.

Request

<syntaxhighlight lang="json"> { 

 "jsonrpc": "2.0",
 "id":      1,
 "method":  "Signaling_TurnAuth_v1_0",
 "params":  []

} </syntaxhighlight>

Response (result)
Example

<syntaxhighlight lang="json"> { 

 "jsonrpc": "2.0",
 "id": 1,
 "result": {
   "ExpirationInSeconds": 604799,
   "TurnAuthServers": [
     {
       "Username": "<long base64 string>",
       "Password": "<base64 string>",
       "Urls": [
         "stun:relay.communication.microsoft.com:3478",
         "turn:relay.communication.microsoft.com:3478"
       ]
     }
   ]
 }

} </syntaxhighlight>

The client constructs a single RTCIceServer by taking the Username and Password of the first entry and the union of Urls from all entries. The peer-connection configuration disables TCP candidates and enables IPv6 (including on Wi-Fi).

SignalingMessage format

All application-level signaling traffic between two peers is exchanged as SignalingMessage envelopes, encoded as a string in the third parameter of Signaling_SendClientMessage_v1_0 (outbound) or in the Message field of Signaling_ReceiveMessage_v1_0 (inbound).

Envelope
  • Template:Nbt
    • Template:Nbt: Message kind. One of JOIN_REQUEST, JOIN_ACCEPTED, JOIN_REJECTED, INVITE_DECLINED, OFFER, ANSWER, ICE_CANDIDATE.
    • Template:Nbt: UUID identifying the join attempt this message belongs to. Always present.
    • Template:Nbt: Full SDP body. Required for OFFER and ANSWER; omitted otherwise. May also carry the candidate string in the legacy ICE_CANDIDATE fallback (see below).
    • Template:Nbt: ICE candidate. Required for ICE_CANDIDATE; omitted otherwise.
      • Template:Nbt: Candidate attribute line, e.g. candidate:842163049 1 udp 2122260223 192.0.2.1 49152 typ host.
      • Template:Nbt: SDP Media stream Id. Optional and defaults to "0".
      • Template:Nbt: SDP m-line index, e.g. 0.

If an ICE_CANDIDATE message arrives without a valid iceCandidate object, the decoder falls back to using the sdp field as the candidate attribute, with the defaults sdpMid="0" and sdpMLineIndex=0.

Message types:

<syntaxhighlight lang="json"> // JOIN_REQUEST { "type": "JOIN_REQUEST", "sessionId": "6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e" }

// JOIN_ACCEPTED { "type": "JOIN_ACCEPTED", "sessionId": "6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e" }

// JOIN_REJECTED { "type": "JOIN_REJECTED", "sessionId": "6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e" }

// INVITE_DECLINED { "type": "INVITE_DECLINED","sessionId": "a3f1c8d2-1111-2222-3333-444455556666" }

// OFFER { "type": "OFFER", "sessionId": "6b8b4567-...", "sdp": "v=0\r\no=- ...\r\n" }

// ANSWER { "type": "ANSWER", "sessionId": "6b8b4567-...", "sdp": "v=0\r\no=- ...\r\n" }

// ICE_CANDIDATE { 

 "type": "ICE_CANDIDATE",
 "sessionId": "6b8b4567-...",
 "iceCandidate": {
   "candidate": "candidate:842163049 1 udp 2122260223 192.0.2.1 49152 typ host",
   "sdpMid": "0",
   "sdpMLineIndex": 0
 }

} </syntaxhighlight>

Application semantics

Template:Cd Direction Meaning
JOIN_REQUEST Guest → Host Request to join the hosted world. Sent by the joiner with a fresh sessionId.
JOIN_ACCEPTED Host → Guest The host accepted the request. The guest must follow up by initiating the WebRTC handshake using the same sessionId.
JOIN_REJECTED Host → Guest The host rejected the request due to any reason.
INVITE_DECLINED Guest → Host The guest declined an invite that the host had previously listed in their joinInfo.invites. The host clears the corresponding presence invite.
OFFER Initiator (guest) → Host WebRTC SDP offer for the handshake identified by sessionId.
ANSWER Host → Initiator (guest) WebRTC SDP answer for the same sessionId.
ICE_CANDIDATE Either direction ICE candidate produced by the local peer-connection. Always tagged with the same sessionId.

Host-side validation:

  • If the host is not currently hosting a world, an incoming JOIN_REQUEST is rejected with JOIN_REJECTED immediately.
  • If the host and the sender are not mutual friends, the JOIN_REQUEST is silently dropped, no JOIN_REJECTED is sent.
  • If the sender's PMID is in the host's outstanding presence joinInfo.invites, the host auto-accepts (sends JOIN_ACCEPTED).
  • Otherwise, the request waits to be Accepted or Rejected by the user.

The host filters incoming OFFER messages against the sender PMID and sessionId pair it previously sent JOIN_ACCEPTED for. Offers that do not match (no prior accept, wrong session id) are silently dropped.

Sending and receiving signaling messages

Sending (Signaling_SendClientMessage_v1_0)

Every outbound application message is wrapped as follows. The third positional parameter is the SignalingMessage envelope serialised to a JSON string, not a nested JSON object.

<syntaxhighlight lang="json"> { 

 "jsonrpc": "2.0",
 "id":      2,
 "method":  "Signaling_SendClientMessage_v1_0",
 "params":  [
   null,
   "069a79f4-44e9-4726-a5be-fca90e38aaf5",
   "{\"type\":\"JOIN_REQUEST\",\"sessionId\":\"6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e\"}"
 ]

} </syntaxhighlight>

On success the server responds with a JSON-RPC result that the client ignores.

Receiving (Signaling_ReceiveMessage_v1_0)

Inbound application messages arrive as server-initiated JSON-RPC requests:

<syntaxhighlight lang="json"> { 

 "jsonrpc": "2.0",
 "id":      17,
 "method":  "Signaling_ReceiveMessage_v1_0",
 "params":  [{
   "From":    "61699b2e-d327-4a01-9f1e-0ea8c3f06bc6",
   "Message": "{\"type\":\"OFFER\",\"sessionId\":\"6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e\",\"sdp\":\"v=0\\r\\no=- ...\"}",
   "Id":      "5c2a87a0-2bd1-4b9f-9c50-1c2d5b4f8a91"
 }]

} </syntaxhighlight>

  • From: PMID of the sending peer, as a UUID string with dashes.
  • Message: stringified JSON envelope as described above.
  • Id: optional server-side delivery id; opaque to the client.

If the request carries a numeric JSON-RPC id, the client immediately replies with {"jsonrpc":"2.0","id":<id>,"result":{}} as an ACK.

Service envelope (delivery failure)

The inner Message may also be a service envelope indicating a delivery failure rather than a peer message. A service envelope is a JSON object with a top-level numeric Code and a Message field:

<syntaxhighlight lang="json"> { "Code": 1, "Message": "Player 069a79f4-... is not reachable" } </syntaxhighlight>

Template:Cd Symbolic name Meaning
1 PLAYER_UNREACHABLE The target PMID is not currently connected to signaling.
2 MESSAGE_DELIVERY_FAILED The signaling service could not deliver the message.
3 TURN_AUTH_FAILED Server-side TURN auth failure for the underlying flow.

Full Connection sequence

The full sequence for guest A joining host B

  1. A sends Signaling_TurnAuth_v1_0 to obtain TURN credentials and constructs an RTCIceServer.
  2. A generates a fresh sessionId and sends JOIN_REQUEST targeted at B's PMID, wrapped in Signaling_SendClientMessage_v1_0. The join request expires in one minute on As side.
  3. B's client receives JOIN_REQUEST via Signaling_ReceiveMessage_v1_0. After friend and hosting checks, it either:
    • Auto-accepts (if A is in B's outstanding presence invites); or
    • Silently drops (if A is not a friend); or
    • Sends JOIN_REJECTED immediately (if B is not hosting); or
    • Waits for player approval before accepting or rejecting the join request.
  4. On acceptance, B records (A's PMID and sessionId), and sends JOIN_ACCEPTED with the same sessionId.
  5. A receives JOIN_ACCEPTED, builds the peer connection, creates a data channel labelled "minecraft", and sends the SDP as OFFER. A also starts a 10-second handshake timer.
  6. As local ICE candidates appear on A, each is sent as ICE_CANDIDATE with the same sessionId.
  7. B receives OFFER, validates that (from, sessionId) matches, builds its own peer connection, generates the SDP answer, and sends it as ANSWER. B starts its own 10-second timer and sends its ICE candidates back as ICE_CANDIDATE.
  8. Both sides add incoming ICE_CANDIDATE messages into addIceCandidate. When the data channel reaches the OPEN state, the handshake is considered complete and both 10-second timers are cancelled.
  9. A wraps the open data channel as a Netty channel and runs the standard Minecraft login flow over it: sends ServerboundHelloPacket announcing its profile name and profile UUID. The host does perform the standard online-mode handshake (ClientboundHelloPacket → ServerboundKeyPacket → Mojang hasJoinedServer check); the only difference from a normal TCP login is that the negotiated symmetric key is not applied to the channel (the connection is already DTLS-encrypted, so setEncryptionKey is skipped). The auth-derived profile UUID is then checked against the connection's pinned intendedProfileId; if they do not match, the host disconnects with a Connection failed message.
  10. B wraps the open data channel similarly and hands it to its integrated server as a pre-authenticated connection bound to A's profile UUID (resolved from A's PMID).
  11. A and B both check whether they still need signaling; if not, the WebSocket is closed.

RTCConfiguration used by the client

For both sides, the configuration is identical:

<syntaxhighlight lang="java"> RTCConfiguration cfg = new RTCConfiguration(); cfg.iceServers.add(turnAuth); cfg.portAllocatorConfig 

  .setDisableTcp(true)
  .setEnableIpv6(true)
  .setEnableIpv6OnWifi(true);

</syntaxhighlight>

Data channel parameters (initiator only)

<syntaxhighlight lang="java"> RTCDataChannelInit init = new RTCDataChannelInit(); init.ordered = true; init.maxRetransmits = -1; init.priority = RTCPriorityType.HIGH; peerConnection.createDataChannel("minecraft", init); </syntaxhighlight>

The responder does not create its own data channel; it receives the initiator's channel via onDataChannel.

Hand-off to standard Minecraft Protocol

Once the data channel reaches OPEN:

  • Guest side: constructs a Netty channel adapter over the data channel, builds a Minecraft serverbound play connection using "rtc-peer" as the placeholder host name and port 0, sends a single ServerboundHelloPacket(profileName, profileId). From that point on the standard login, configuration and play protocol runs over the data channel.
  • Host side: constructs the same Netty channel adapter and passes it, together with the guest's profile UUID (resolved from the PMID), into the integrated server's authenticated channels. The server thereafter treats the connection as a normally-authenticated, connected player.

Outbound chunking and backpressure

The client and server enforce the following on outbound data-channel writes:

  • Every Netty write that exceeds 256 KiB is split into 256 KiB chunks before being sent.
  • When the WebRTC bufferedAmount on the data channel exceeds 1 MiB, the Netty channel is marked non-writable and the application is expected to back off.
  • When bufferedAmount falls back below 256 KiB, the Netty channel is marked writable again and writes resume.


History

Template:HistoryTable

References

This article is partially adapted from Mojang API on wiki.vg.

Examples

  • C# - Full API wrapper
  • C# - Full API wrapper with Mojang/Microsoft Authentication
  • Dart - Almost full API wrapper with Mojang Authentication
  • Go - Full API wrapper
  • Go - UUIDs or names to profiles with skins, capes and name histories
  • Python - Full API Wrapper. Also supports authentication & parts of the Minecraft website
  • Python - Pymojang is a full wrapper around de Mojang API and Mojang Authentication API. Also support RCON, Query and Server List Ping
  • Python - Full API wrapper (not updated since 2018)
  • Python - UUIDs or names to profiles (not updated since 2018)
  • PHP - Complete Mojang's API wrapper
  • PHP - Almost full API wrapper with Mojang Authentication. Also support head rendering
  • PHP - UUIDs or names to profiles with skins, heads and name histories
  • PHP - UUIDs to names
  • PHP - UUIDs to names, names to uuids
  • Java - Almost full API Wrapper
  • Java - Almost full API Wrapper with auth
  • Java - Almost full API with Mojang Authentication and can also work as a console Application.
  • JavaScript - UUIDs or names to profiles with skins, capes and name histories
  • JavaScript/TypeScript - Almost full API wrapper

References

Template:Reflist

Navigation

Template:Navbox Java Edition technical Template:License wiki.vg

Minecraft:de:Mojang API Minecraft:lzh:魔贊卯口 Minecraft:zh:Mojang API

Retrieved from "https://wiki.sasgaming.net/index.php?title=Minecraft:Mojang_API&oldid=118600"
Contents