Interact With Portal
Introduction
This feature enables your widget to communicate with the portal via the postMessage API. You can request user authentication and navigation actions through standardized message events.
Event Data Structure
Widget Send To Portal:
{
type: string, // Event type identifier (e.g., "widget.request.login")
message?: string, // Optional payload
// Additional properties as needed for specific event types
}Portal Send To Widget
The portal will actively send a message to the widget:
{
type: "portal.send.[TYPE]",
message: string | object
}Portal Responses
The portal will send standardized responses to your widget:
Error Handle
Error responses use the portal.response.error type with descriptive messages. Always handle these errors gracefully in your widget implementation.
Events From Iframe
When embedding the Portal via <iframe>, implement cross-origin messaging using the Web API window.postMessage. The host page (parent) can dispatch structured messages, now we support below message:
redirect
redirectThis event allows the portal redirect to the specified page.
Example:
Events To Widget
portal.send.access_token
portal.send.access_tokenThis message is sent by the portal to the widget when the user's login status changes and an access token becomes available (e.g., upon successful login). This token can be used by the widget to authenticate requests to backend services.
The message body structure is as follows:
Trigger: User login status changes, and an access token is issued.
portal.send.remove_token
portal.send.remove_tokenThis message is sent by the portal to the widget when the user's login status changes and an existing access token is removed or becomes invalid (e.g., upon logout or token expiry). Widgets should clear any stored tokens upon receiving this message.
The message body structure is as follows:
Trigger: User login status changes, and the access token is removed or invalidated.
portal.send.app_info
portal.send.app_infoThis message is sent by the portal to the widget after the widget sends the WIDGET_READY message. It contains essential information about the application or environment the widget is running in.
The message body structure you can refer here: Get Portal Info
Trigger: Sent after the widget sends
WIDGET_READY
portal.send.source_link_id
portal.send.source_link_idThis message is sent by the portal to inform the widget about the specific link from which it was loaded. This is particularly relevant when the widget is accessed via a short link or any other specific link generated by the portal.
Trigger: Sent after the widget sends
WIDGET_READY, when the widget is loaded via a portal-generated link (e.g., a short link).Purpose: To provide the unique identifier of the source link. This message contains both the
source_link_idand thelink_detail. Thesource_link_ididentifies the source link, and thelink_detailobject contains the detailed information about that link.
Message Structure (portal.send.source_link_id):
portal.send.link_message
portal.send.link_messageWhen accessing a widget using our short link service, the portal will send a message to the widget based on the parameters defined in the short link. This action occurs after the widget sends the WIDGET_READY message to the portal.
The message body structure is as follows:
The message is a string with a maximum length of 2048 characters. If you need to transmit JSON data, it is recommended to use Base64 encoding.
portal.send.credit_top_up_success
portal.send.credit_top_up_successWhen a user successfully tops up their credit, the portal sends a credit_top_up_success message to the widget. This message is triggered after the top-up success event occurs on the portal.
The message body structure is as follows:
The message field now directly contains a JSON object with an amount property. This amount represents the credit amount that was successfully topped up.
portal.send.subscribed_detail
portal.send.subscribed_detailThis is the primary message used by the portal to inform the widget about the user's subscription status and provide the unique identifier required for per-user configuration.
Trigger: This message is sent by the portal in two scenarios:
When a user opens the management interface specifically for this widget.
When any user loads and initializes the widget in the main frontend portal view.
Purpose: The message contains a
typefield identifying the message and amessagefield whose value is an object containing detailed information about the user's subscription to this specific widget instance. This includes subscription status information, configuration fields, and a unique identifier (subscription_idfield) that is unique for each user's subscription instance for this specific widget. This uniquesubscription_idserves as the key you should use on your backend to store and retrieve per-user configuration settings.
Message Structure (protal.send.subscribed_detail):
The message body structure is as follows:
Important Note: Based on the structure and discussion, the
subscription_idfield within the nestedmessageobject should be treated as the unique identifier for retrieving and saving per-user configuration settings. Please use this field as the key for your backend configuration storage.
Events From Widget
widget.request.login
widget.request.loginTo request user authentication:
Responses:
Success:
{ type: "portal.response.ok", message: "" }Error:
{ type: "portal.response.error", message: "user already login" }
widget.request.to_profile
widget.request.to_profileTo request navigation to the user's profile page:
Responses:
Success:
{ type: "portal.response.ok", message: "" }Error:
{ type: "portal.response.error", message: "user not login" }
widget.request.send_token
widget.request.send_tokenTo request a send token pop-up
Responses:
Success:
{ type: "portal.response.ok", message: "" }Error:
{ type: "portal.response.error", message: "user not login" }
widget.request.top_up
widget.request.top_upTo request a top up pop-up so user can top-up USDC
Responses:
Success:
{ type: "portal.response.ok", message: "" }Error:
{ type: "portal.response.error", message: "user not login" }
widget.request.top_up_credit
widget.request.top_up_creditTo request a top up pop-up so user can top-up Credit
Request:
message.min_value: number, Optional. Specifies the minimum amount the user can top up. Example: 500.
message.quick_values: number[] Optional. Provides a list of suggested, or "quick," values for the user to easily select for their top-up amount. Example: [1000, 2000, 5000].
message.callback_url: number[] Optional. A URL to which the system will send a callback notification after the top-up transaction status is updated.
Responses:
Success:
{ type: "portal.response.ok", message: "" }Error:
{ type: "portal.response.error", message: "user not login" }
widget.request.logout
widget.request.logoutTo request user logout
Responses:
Success:
{ type: "portal.response.ok", message: "" }Error:
{ type: "portal.response.error", message: "user not login" }
Last updated