> For the complete documentation index, see [llms.txt](https://docs.hello-lisa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hello-lisa.com/developers/guides/player-communication/common-message-flows.md).

# Common Message Flows

The Message API Reference describes each message on its own. This section describes how they fit together.

Most integrations are built from five exchanges. Each one is a round trip: the LiSA Player states what it needs, and the host app answers from what only it knows — who the visitor is, how big the viewport really is, what a product costs today.

* [Handshake](/developers/guides/player-communication/common-message-flows/handshake.md) — establish who the visitor is, and when it is safe to start talking
* [Visual Viewport](/developers/guides/player-communication/common-message-flows/visual-viewport.md) — keep the player stable while the on-screen keyboard is open
* [Presentation Mode](/developers/guides/player-communication/common-message-flows/presentation-mode.md) — move the player between floating and fullscreen
* [Product Hydration](/developers/guides/player-communication/common-message-flows/product-hydration.md) — refresh price and availability from the live catalogue
* [Add to Cart](/developers/guides/player-communication/common-message-flows/add-to-cart.md) — turn a visitor's intent into a line in your cart

### Two rules that apply to all of them

{% hint style="warning" %}
**Wait for App — Listen.** Nothing the host sends before the player emits `lsc:app:listen` is guaranteed to arrive, because the player has not yet attached its message listener.
{% endhint %}

{% hint style="info" %}
**Address every message to the player.** The player ignores anything without `recipient: "LiSA"`. This is what keeps unrelated `postMessage` traffic on the host page from being misread as player input — and what lets you attach your own handler to the same channel safely.
{% endhint %}

### Acknowledgements

Set a `messageId` on a message to the player and it replies with App — Message Acknowledge carrying the same id. Use it where delivery matters, such as the visitor's identity.

Leave it off for messages that are sent often and superseded by the next one, such as viewport updates: an acknowledgement round trip would only add latency to something you are about to send again.

### Forward compatibility

LiSA adds message types without a breaking change. Treat a `messageType` you do not recognise as a no-op rather than an error, so a player update never breaks a host that has not been redeployed.