Embedding Integration
If you are embedding HENGSHI SENSE into your own portal, business system, or OEM page, the hard part is usually not "can it be embedded?" but "how should the embedded page work with the host system?" This page collects the questions that come up most often.
Where should I start when building an embed URL?
Always start from a working share/embed URL generated by the product UI, then append parameters on top of it instead of hand-writing the full URL from scratch.
- If authentication is already integrated, start from the generated app or publish embed URL
- If the URL must carry auth behavior, then append parameters such as
activeAuth,reloadUser, orjwtParam - If you need presentation control, then append parameters such as
header=false,pager=false, orlocale=en-US
This is safer because path levels, resource hashes, and available parameters vary by embedded object.
Related docs:
Which embed URL parameters are used most often?
The most common ones are:
| Need | Common parameter | Notes |
|---|---|---|
| Force language | locale=en-US | Useful for multilingual portals and OEM delivery |
| Hide the page title | header=false | Common for publish-page embedding |
| Hide the pager | pager=false | Useful for compact content-only layouts |
| Hide title and pager together | copyright=false | Equivalent to header=false&pager=false |
| Reduce padding | chartPadding=0 or padding=0 | Useful for card-style layouts |
| Pass parameters to public links | appParam=[...] | Used for public-link parameter control |
If you also need navigation inside the embedded experience, you should consider embed-level path controls such as L0 / L1 / L2 / L3.
Can the host page control refresh, fullscreen, or interaction?
Yes, but the preferred approach is to reuse existing page integration capabilities instead of rebuilding a second interaction layer in the host page.
- Refresh: start from the existing external control patterns in External Control Embedded in Page
- Fullscreen: let the host page drive fullscreen for the iframe container, then combine it with embed layout parameters
- Language switching: switch the host language and rewrite the embed URL
localeconsistently
If you see "the resource changed but the embedded page did not update", first check refresh triggering and caching behavior before assuming the embedding itself is broken.
Why do cross-domain issues show up in embedding scenarios?
The most common reason is that the host system and HENGSHI SENSE are on different domains, while the browser enforces same-origin restrictions for iframe access, cookies, and scripts.
A practical order is:
- Prefer a reverse-proxy setup that puts the host system and HENGSHI SENSE under the same main domain or controlled proxy chain
- Set
ACCESS_CONTROL_ALLOW_ORIGINwhen needed - If the host page tries to directly access iframe internals, confirm whether the browser will block that by design
If "the page loads but JS interaction fails", it is often a browser same-origin restriction problem, not an HENGSHI page rendering problem.
Should I prefer iframe embedding or API integration?
For most projects, prefer page embedding first.
Iframe/page embedding reuses existing charts, permissions, filters, publishing, and styling capabilities, so implementation cost stays lower and product upgrades remain easier to inherit. API-first integration makes more sense only when you intentionally want to rebuild the presentation or orchestration layer yourself.
Start with: