Minecraft:Mojang API - Revision history

SyncBot: Sync: updated from Minecraft

2026-07-21T12:29:40Z

Sync: updated from Minecraft

← Older revision		Revision as of 12:29, 21 July 2026
Line 1,505:		Line 1,505:
	#* Waits for player approval before accepting or rejecting the join request.		#* Waits for player approval before accepting or rejecting the join request.
	# On acceptance, B records (A's <code>PMID</code> and <code>sessionId</code>), and sends <code>JOIN_ACCEPTED</code> with the same <code>sessionId</code>.		# On acceptance, B records (A's <code>PMID</code> and <code>sessionId</code>), and sends <code>JOIN_ACCEPTED</code> with the same <code>sessionId</code>.
	# A receives <code>JOIN_ACCEPTED</code>, builds the peer connection, creates a data channel ~~labelled~~ <code>"minecraft"</code>, and sends the SDP as <code>OFFER</code>. A also starts a 10-second handshake timer.		# A receives <code>JOIN_ACCEPTED</code>, builds the peer connection, creates a data channel labeled <code>"minecraft"</code>, and sends the SDP as <code>OFFER</code>. A also starts a 10-second handshake timer.
	# As local ICE candidates appear on A, each is sent as <code>ICE_CANDIDATE</code> with the same <code>sessionId</code>.		# As local ICE candidates appear on A, each is sent as <code>ICE_CANDIDATE</code> with the same <code>sessionId</code>.
	# B receives <code>OFFER</code>, validates that <code>(from, sessionId)</code> matches, builds its own peer connection, generates the SDP answer, and sends it as <code>ANSWER</code>. B starts its own 10-second timer and sends its ICE candidates back as <code>ICE_CANDIDATE</code>.		# B receives <code>OFFER</code>, validates that <code>(from, sessionId)</code> matches, builds its own peer connection, generates the SDP answer, and sends it as <code>ANSWER</code>. B starts its own 10-second timer and sends its ICE candidates back as <code>ICE_CANDIDATE</code>.

SyncBot: Sync: updated from Minecraft

2026-06-23T11:12:21Z

Sync: updated from Minecraft

← Older revision		Revision as of 11:12, 23 June 2026
Line 456:		Line 456:

	; Payload		; Payload
	A JSON array containing the desired keys to update, right now, only ~~orofanityFilterPreferences~~ and friendsPreferences can be updated<div class="treeview">		A JSON array containing the desired keys to update, right now, only profanityFilterPreferences and friendsPreferences can be updated<div class="treeview">
	* '''Example'''		* '''Example'''
	* {{Nbt\|compound}} Root tag		* {{Nbt\|compound}} Root tag

SyncBot: Sync: updated from Minecraft

2026-06-01T11:11:15Z

Sync: updated from Minecraft

← Older revision		Revision as of 11:11, 1 June 2026
Line 1,597:		Line 1,597:
	[[Minecraft:lzh:魔贊卯口]]		[[Minecraft:lzh:魔贊卯口]]
	[[Minecraft:zh:Mojang API]]		[[Minecraft:zh:Mojang API]]
	~~[[Minecraft:ko:Mojang API]]~~

SyncBot: Sync: updated from Minecraft

2026-05-31T11:11:45Z

Sync: updated from Minecraft

← Older revision		Revision as of 11:11, 31 May 2026
Line 1,597:		Line 1,597:
	[[Minecraft:lzh:魔贊卯口]]		[[Minecraft:lzh:魔贊卯口]]
	[[Minecraft:zh:Mojang API]]		[[Minecraft:zh:Mojang API]]
			[[Minecraft:ko:Mojang API]]

SyncBot: Sync: updated from Minecraft

2026-05-27T11:12:35Z

Sync: updated from Minecraft

← Older revision		Revision as of 11:12, 27 May 2026
Line 1,021:		Line 1,021:

	== Peer-to-peer multiplayer networking ==		== Peer-to-peer multiplayer networking ==
			{{outdated\|section=y\|edition=java\|never=y\|This feature was present only in development versions and the related API endpoints are no longer available.}}

	Peer-to-peer (P2P) multiplayer networking was introduced in [[Minecraft:Java Edition 26.2 Snapshot 7\|Minecraft Java Edition 26.2 ~~Snapshot 7~~]]. It allows a host's singleplayer world to be joinable by friends over Peer-to-Peer [https://wikipedia.org/wiki/WebRTC WebRTC] data channels. A Mojang-hosted ''signaling service'' handles the handshake, gameplay traffic flows peer-to-peer (using [[Minecraft:w:Interactive_Connectivity_Establishment\|ICE]]). The protocol described below is unstable and likely to change.		Peer-to-peer (P2P) multiplayer networking was introduced in [[Minecraft:Java Edition 26.2 Snapshot 7]] and removed in [[Minecraft:Java Edition 26.2 Pre-Release 1]]. It allows a host's singleplayer world to be joinable by friends over Peer-to-Peer [https://wikipedia.org/wiki/WebRTC WebRTC] data channels. A Mojang-hosted ''signaling service'' handles the handshake, gameplay traffic flows peer-to-peer (using [[Minecraft:w:Interactive_Connectivity_Establishment\|ICE]]). The protocol described below is unstable and likely to change.

	General Properties:		General Properties:

SyncBot: Sync: updated from Minecraft

2026-05-25T11:12:54Z

Sync: updated from Minecraft

← Older revision		Revision as of 11:12, 25 May 2026
Line 1,231:		Line 1,231:
	\|S→C request		\|S→C request
	\|<code>Signaling_ReceiveMessage_v1_0</code>		\|<code>Signaling_ReceiveMessage_v1_0</code>
	\|<code>{ From, Message, Id }</code>		\|<code>[{ From, Message, Id }]</code>
	\|<code>{}</code> (ACK only if <code>id</code> is present)		\|<code>{}</code> (ACK only if <code>id</code> is present)
	\|}		\|}

SyncBot: Sync: updated from Minecraft

2026-05-24T11:12:32Z

Sync: updated from Minecraft

← Older revision		Revision as of 11:12, 24 May 2026
Line 1,226:		Line 1,226:
	\|C→S request		\|C→S request
	\|<code>Signaling_SendClientMessage_v1_0</code>		\|<code>Signaling_SendClientMessage_v1_0</code>
	\|<code>~~[null~~, ~~"<toPmid>"~~, ~~"<innerJsonString>"]~~</code>		\|<code>{ messageId, toPlayerId, message }</code>
	\|<code>null</code> / <code>{}</code> (client ignores on success)		\|<code>null</code> / <code>{}</code> (client ignores on success)
	\|-		\|-
	\|S→C request		\|S→C request
	\|<code>Signaling_ReceiveMessage_v1_0</code>		\|<code>Signaling_ReceiveMessage_v1_0</code>
	\|<code>[{ From, Message, Id~~? }]</code> or <code>{ …~~ }</code>		\|<code>{ From, Message, Id }</code>
	\|<code>{}</code> (ACK only if <code>id</code> is present)		\|<code>{}</code> (ACK only if <code>id</code> is present)
	\|}		\|}

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

	==== Server-side errors ====		==== Server-side errors ====
Line 1,433:		Line 1,433:
	"id": 2,		"id": 2,
	"method": "Signaling_SendClientMessage_v1_0",		"method": "Signaling_SendClientMessage_v1_0",
	"params": [		"params": {
	null,		"messageId": "5c2a87a0-2bd1-4b9f-9c50-1c2d5b4f8a91", // could be UUID with dashes or null, if it's null, signaling server server will generate a random UUID as messageId
	"069a79f4-44e9-4726-a5be-fca90e38aaf5",		"toPlayerId": "069a79f4-44e9-4726-a5be-fca90e38aaf5", // PMID of recipient
	"{\"type\":\"JOIN_REQUEST\",\"sessionId\":\"6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e\"}"		"message": "{\"type\":\"JOIN_REQUEST\",\"sessionId\":\"6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e\"}" // message to send
	]		}
	}		}
	</syntaxhighlight>		</syntaxhighlight>
Line 1,455:		Line 1,455:
	"method": "Signaling_ReceiveMessage_v1_0",		"method": "Signaling_ReceiveMessage_v1_0",
	"params": {		"params": {
	"From": "61699b2e-d327-4a01-9f1e-0ea8c3f06bc6",		"From": "61699b2e-d327-4a01-9f1e-0ea8c3f06bc6", // PMID of sender
	"Message": "{\"type\":\"~~OFFER~~\",\"sessionId\":\"6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e~~\",\"sdp\":\"v=0\\r\\no=- ...~~\"}",		"Message": "{\"type\":\"JOIN_REQUEST\",\"sessionId\":\"6b8b4567-327d-4ee8-90c2-0d8c1f9f1d9e\"}", // message received
	"Id": "5c2a87a0-2bd1-4b9f-9c50-1c2d5b4f8a91"		"Id": "5c2a87a0-2bd1-4b9f-9c50-1c2d5b4f8a91" // messageId
	}		}
	}		}
	</syntaxhighlight>		</syntaxhighlight>

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

	If the request carries a numeric <code>id</code>, the client must immediately replies with <code>{"jsonrpc":"2.0","id":<id>,"result":{}}</code> as an ACK, otherwise the signaling service will not deliver later <code>Signaling_ReceiveMessage_v1_0</code> requests on the same WebSocket connection.		If the request carries a numeric <code>id</code>, the client must immediately replies with <code>{"jsonrpc":"2.0","id":<id>,"result":{}}</code> as an ACK, otherwise the signaling service will not deliver later <code>Signaling_ReceiveMessage_v1_0</code> requests on the same WebSocket connection.

SyncBot: Sync: updated from Minecraft

2026-05-23T11:13:20Z

Sync: updated from Minecraft

← Older revision		Revision as of 11:13, 23 May 2026
Line 806:		Line 806:
	* {{Nbt\|compound\|Root tag}}		* {{Nbt\|compound\|Root tag}}
	** {{Nbt\|string\|name}}: Profile name of the player to add or remove. Optional.		** {{Nbt\|string\|name}}: Profile name of the player to add or remove. Optional.
	** {{Nbt\|string\|profileId}}: UUID of the player to add or remove, Optional.		** {{Nbt\|string\|profileId}}: UUID of the player to add or remove. Could be UUID with or without dashes Optional.
	** {{Nbt\|string\|updateType}}: Action to perform. Values: <code>ADD</code> for sending or accepting friend requests, <code>REMOVE</code> for removing friends or denying friend requests.		** {{Nbt\|string\|updateType}}: Action to perform. Values: <code>ADD</code> for sending or accepting friend requests, <code>REMOVE</code> for removing friends or denying friend requests.
	</div>		</div>
Line 888:		Line 888:
	*** {{Nbt\|string\|value}}: Currently the game client always sends <code>null</code>. See below.		*** {{Nbt\|string\|value}}: Currently the game client always sends <code>null</code>. See below.
	*** {{Nbt\|list\|invites}}: List of invited players. Optional.		*** {{Nbt\|list\|invites}}: List of invited players. Optional.
	**** {{Nbt\|string}}: UUID of a invited player. ~~Must~~ be UUID with dashes.		**** {{Nbt\|string}}: UUID of a invited player. Could be UUID with or without dashes.
	</div>		</div>

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

SyncBot: Sync: updated from Minecraft

2026-05-21T11:16:06Z

Sync: updated from Minecraft

← Older revision		Revision as of 11:16, 21 May 2026
Line 102:		Line 102:
	These endpoints do not need an access token, and some endpoints can query registered account that do not own the game.		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~~ ===		=== Query player's UUID ===

	; Input		; Input
Line 135:		Line 135:
	* HTTP 404 is returned if no player with such name exists.		* HTTP 404 is returned if no player with such name exists.

	=== Query player's ~~UUID~~ ===		=== Query player's username ===

	; Input		; Input
Line 144:		Line 144:

	; Response		; Response
	The same as [[#Query player's ~~username~~]].		The same as [[#Query player's UUID]].

	=== Query player UUIDs in batch ===		=== Query player UUIDs in batch ===
Line 1,003:		Line 1,003:
	"value": "87c83220-965c-4d65-867f-8718f5ba04a6",		"value": "87c83220-965c-4d65-867f-8718f5ba04a6",
	"invited": true		"invited": true
	}		},
	"lastUpdated": "2026-05-15T19:26:12Z"		"lastUpdated": "2026-05-15T19:26:12Z"
	},		},
Line 1,013:		Line 1,013:
	"value": "f289feed-30ab-4039-bef8-5752ea9d2c1c",		"value": "f289feed-30ab-4039-bef8-5752ea9d2c1c",
	"invited": false		"invited": false
	}		},
	"lastUpdated": "2026-05-15T19:26:32Z"		"lastUpdated": "2026-05-15T19:26:32Z"
	}		}
Line 1,034:		Line 1,034:
	The signaling service routes messages by the '''PMID'''. A friend's PMID is obtained from the <code>pmid</code> field of their entry in their [[#Presence\|presence]] response.		The signaling service routes messages by the '''PMID'''. A friend's PMID is obtained from the <code>pmid</code> field of their entry in their [[#Presence\|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 <code>ServerboundHelloPacket</code> 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\|Security model~~]] below.		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 <code>ServerboundHelloPacket</code> 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 [[#Full Connection sequence]] below.

	Authentication uses the same Mojang access token as the rest of the Mojang API, but is sent in the <code>x-mojangauth</code> HTTP header rather than as a <code>Bearer</code> token.		Authentication uses the same Mojang access token as the rest of the Mojang API, but is sent in the <code>x-mojangauth</code> HTTP header rather than as a <code>Bearer</code> token.
Line 1,089:		Line 1,089:
	The response may contains a <code>Session-Id</code> header matches the one you send in the request as-is, or will also omit it if you omitted it in the request.		The response may contains a <code>Session-Id</code> header matches the one you send in the request as-is, or will also omit it if you omitted it in the request.

	<code>result.signalingUri</code> may vary by where you send the request~~. The server seems always return a signaling server nearest to you~~. It doesn't matter if you and your friends connect to different signaling servers, although P2P multiplayer session invites and join requests are transferred on the signaling server, players connect to differnet signaling servers could still receive invites or join requests.		<code>result.signalingUri</code> may vary by multiple reasons, such as data encoded in access token or where you send the request. It doesn't matter if you and your friends connect to different signaling servers, although P2P multiplayer session invites and join requests are transferred on the signaling server, players connect to differnet signaling servers could still receive invites or join requests.

	For reference, <code>result.signalingUri</code> currently follows the format <code>wss://signal-{location}.franchise.minecraft-services.net</code>, where <code>{location}</code> corresponds to one of the following Microsoft Azure region identifiers:		For reference, <code>result.signalingUri</code> currently follows the format <code>wss://signal-{location}.franchise.minecraft-services.net</code>, where <code>{location}</code> corresponds to one of the following Microsoft Azure region identifiers:

SyncBot: Sync: updated from Minecraft

2026-05-20T11:15:41Z

Sync: updated from Minecraft

Show changes