Frontend rule: read initData (the raw signed string) and send it to your backend for verification. initDataUnsafe is for UI display only and is never proof of identity.
Overview
Two ways to open a MiniApp: a sendMessage web_app button, or a direct link. Once open, the MPChat SDK exposes initialization data synchronously.
Send an entry button
{
"chat_id": "12345",
"text": "Open Demo MiniApp",
"reply_markup": {
"inline_keyboard": [[
{ "text": "Open", "web_app": { "url": "https://mini.example.com/demo" } }
]]
}
}
The body does not need miniapp_id; the server resolves web_app.url against the current bot's MiniApp entryUrl (or the last path segment as a shortName).
Load the SDK
<script src="https://mp.net/i/mpchat-web-app.js"></script>
const initData = window.MpChat.WebApp.initData; // signed string -> backend const initDataUnsafe = window.MpChat.WebApp.initDataUnsafe; // UI only, untrusted
initData vs initDataUnsafe
Value | Use for authorization? |
initData (raw signed string) | Yes — after backend verification. |
initDataUnsafe (parsed object) | No — UI display only. |
Field support (current phase)
Supported:
initData; ininitDataUnsafe:query_id,auth_date,hash,chat_type,start_param, and coreuser/chatfields.Partially supported: the
initDataUnsafeobject structure anduser/chatsubsets.Not supported yet: runtime metadata, view state, native UI controls (BackButton/MainButton), storage/device APIs, and methods like
sendData,openLink, popups, QR — do not rely on client return flows.
Security must-dos
Never put the bot token in frontend code, WebView storage, URLs, logs, or analytics.
Send the raw
initDatato the backend and verify before trusting any field.
Related
Only call native methods via window.MpChat.WebApp.call(name, params) when your MPChat client version explicitly announces support.
