Host API on Polkadot Web¶

Introduction¶

The Host API surface a Product calls on Polkadot Web is the same TrUAPI surface as on Polkadot Desktop. The same method groups, the same signatures, and the same SDK packages apply. Code written for Desktop runs on Web. This page documents the exceptions to that statement, focusing on the small number of capabilities whose underlying behavior is materially different because the runtime is a browser, not an installed application.

For the full TrUAPI reference (method groups, versioning, package table), see Protocol: TrUAPI.

What Is the Same¶

By default, assume the following behavior is the same on Web as on Desktop:

• Chain interaction, storage reads, transaction building, and signAndSubmit work identically.
• Per-Product sub-accounts derive the same way and resolve to the same addresses.
• Permissions are declared the same way in the manifest and gate the same capabilities at the Host API boundary.
• Signing routes to the paired Polkadot App with the same per-transaction approval model.

A Product that targets Web can use the same @parity/product-sdk packages and the same TrUAPI method group calls; the SDK abstracts away the Host difference at every point where it matters.

Where Browser-Context Differs¶

Three categories are where browser-context behavior diverges and a Product developer may need Web-specific handling:

• Local storage backing: The Product SDK's KvStore routes through the Host on Web exactly as on Desktop, but the underlying backend the Host uses is different: browser-managed storage rather than the installed app's on-device storage. Capacity, eviction behavior, and clear-history semantics follow the browser's rules.
• Outbound requests under the ExternalRequest permission: Pattern-scoped outbound requests still work, but the request itself is dispatched from a browser context. CORS, cookies, and the browser's network policies all apply on top of the Host's pattern enforcement. A request the Host would allow may still be blocked by the browser if the target server's CORS policy rejects it.
• Media capabilities: Media-access permissions such as Microphone are gated by both the Host's permission system and the browser's media-permission prompt. The user has to grant both. Build UI that handles the two-prompt path gracefully.

A Product that uses none of those three categories needs no Web-specific code.

Where to Go Next¶