Develop and configure

Confirm that the application works independently before connecting it to Console. All adaptation uses public platform contracts and lives in your application's repository.

1. 1Web application overview
2. 2Develop and configure
3. 3Development testing
4. 4Review and publish

Configure the application entry

Under “Application management → Application listing”, fill in these fields and save a draft.

Field	Description
Application URL	Your HTTPS business entry; retained for redirect and embedded modes
Opening mode	Redirect by default; choose isolated iframe or trusted qiankun after adaptation
Manifest URL	Required for embedding; an anonymously readable HTTPS JSON URL on the same origin as the application URL

Redirect mode needs no container SDK. Saving an embedded draft automatically queues public Manifest and asset digest checks. The page updates with the result; failure preserves the draft and allows another check.

Integrate each opening mode

Mode	Application work	Configuration and runtime
Redirect	Independent pages, sign-in, and business routes	Set the application URL; customers use the application's own page
Isolated iframe	Also deliver the Manifest, container, and lifecycle below	Select isolated iframe; business code runs on the application's origin
Trusted qiankun mount	Reuse the embedded artifacts and lifecycle; explicitly target the application's origin for APIs, sessions, and resources	Select trusted mounting; business DOM mounts directly in Console after independent review and publication

Iframe and trusted mounting use the public protocol, with separate security boundaries, approval requirements, and acceptance tests. Third parties do not use the internal micro-application registry or submit business code or application-specific routes to Console.

Prepare embedded artifacts

Download the public Manifest Schema, TypeScript protocol, and container SDK. Build both TypeScript files in your own application with qiankun@2.10.16.

{
  "schema_version": "1.0",
  "runtime": "qiankun",
  "artifact_version": "1.0.0",
  "entry": "/embedded/1.0.0/entry.html",
  "container": "/embedded/1.0.0/container.html",
  "assets": [
    { "path": "/embedded/1.0.0/entry.html", "sha256": "<64 lowercase SHA256 characters>" },
    { "path": "/embedded/1.0.0/container.html", "sha256": "<64 lowercase SHA256 characters>" }
  ]
}

List all runtime artifacts in assets, including scripts, styles, and the container. Replace the example digests with SHA-256 of the actual response bytes. Paths must be absolute paths on the same origin, without queries or fragments. Use immutable version URLs; changed bytes require another check and release.

Call startThirdPartyContainer from a container on your application's origin. Supply your application identity, environment, registered host, Manifest path/digest, mount ID, and DOM container using the downloaded SDK types. Application identity and allowed host origins come from your own server configuration.

Adapt the lifecycle and interface

Lifecycle	Application responsibility
bootstrap	Initialize independent application resources
mount	Display the business interface directly; reuse an existing session
update	Apply theme and language changes
unmount	Clean up DOM, listeners, timers, and other resources

Lifecycle methods return Promises. Declare UTF-8 in HTML. Use host.path for the internal route and host.applicationOrigin for application requests; relative API URLs must not target the host. A trusted mount may maintain its BFF requests and session through a hidden transport frame on its own origin.

Avoid repeating portal navigation, marketing pages, or sign-in intermediaries. Keep application business navigation and adapt to workspace size, light/dark themes, and language.

Configure security and sign-in

• Allow only registered Console origins in the container's frame-ancestors; do not block that host with X-Frame-Options.
• Validate parent_origin, manifest_sha256, and mount_id in the startup fragment. Bridge messages must match the exact origin, event.source, application, environment, and mount ID. Reject unknown fields and old mount messages.
• Use the listening → initialize → ready handshake. Initialization carries only locale, theme, and the internal route. Handle subsequent context, navigation, unsaved-state, and disposal messages using the protocol.
• Keep sign-in in your own BFF with OAuth/PKCE. Open an authorization window after an explicit user action; show sign-in recovery inside the application when its session expires.
• Never pass platform tokens, cookies, sessions, or a general API proxy through the bridge. Keep secrets on the application server.

Trusted mounting requires independent security review; artifact checks cannot grant trust.

Handle subscription checkout and return

The application's opening mode and the platform commercial page's embedding mode are separate choices. An application embedded in Console can still embed platform pricing or subscription components; payment must open in a separate top-level window.

1. Handle validated goodvision.customer-billing.checkout_started as described in the billing guide. A redirect application can continue from its standalone page. An embedded application preserves Console and its original mount, then asks the customer to click “Continue payment” to open the original checkout_url. Never navigate the application iframe to checkout.
2. Use the original platform-provided payment URL. Accept only the documented payment provider's HTTPS origin; never add amounts or return_url. If a popup is blocked, retry the same payment without creating another order.
3. When payment returns to the registered application entry, use application-owned window communication to resume the original mount. Verify the exact origin, original payment Window, random correlation value, application, and environment. Allow only configured host origins; reject wildcard origins, arbitrary return URLs, and late receipts. This communication is implemented by the application, not a new platform payment message.
4. On success, cancellation, or manual window closure, call the public host.navigate('/app/subscription') in the original application and read platform state again. Return parameters and messages only trigger reads; they never change orders or access. Dispose listeners and timers on unmount or context change, and never restore an old mount.

If the browser or payment provider severs window communication, tell the customer to return to the original Console and refresh status. A missing receipt cannot establish payment failure or justify a new purchase. Standalone access returns to the standalone application; embedded access should remain on the original application's subscription page in Console.

Next: test in a real PC browser.