Skip to content

Plugins in Livespace

A plugin embeds an external web application as an <iframe> widget inside a Livespace profile — Deal, Company, Person, or Space. The widget receives the current record's data and, when needed, temporary Livespace API credentials over the browser postMessage API.

This documentation is for developers building or configuring the embedded application.

Plugin kinds

Every plugin carries a type discriminator:

type What it is Who ships it
iframe An external HTTPS page embedded in an <iframe> — what the rest of this documentation describes You
native A first-party widget built into Livespace and rendered directly, with no iframe, no foreign origin and no credential handshake Livespace

Both kinds occupy the same slots, so one profile can mix yours and ours. A native plugin carries no iframeOrigin; it is identified by a stable nativeKey (for example deal-health) instead.

An administrator places and resizes both kinds the same way, through the same endpoint, choosing between three preset heights. Both kinds state that height when they are created — a native widget's catalog entry carries no size of its own, because how tall it needs to be is a property of the widget as it is drawn rather than something the API can describe.

Both kinds may carry a config object that Livespace stores and returns without interpreting. It holds exactly two keys, each any valid JSON value: settings, the values collected for the settings form the plugin itself declared, and displayOptions, presentation options the Livespace frontend owns. Neither is read by the API, and any other top-level key is refused. Your application does not need to read or write either one: an iframe plugin may keep its own settings in its own backend instead.

New native plugins ship without a coordinated frontend release, so any client rendering slots must ignore nativeKey values it does not recognise rather than failing on them.

How it works

  1. An account administrator registers a plugin with a name and an HTTPS URL, then configures which profiles display it, where, its size, and who can see it.
  2. When a user opens a supported profile, the widget loads in the configured position and receives the current record's data via postMessage.
  3. Your application reacts to that context and renders accordingly.

Where to start

  • Security — HTTPS, domain allowlist, iframe sandbox, and origin validation your application must comply with.
  • Context Messages — the data Livespace sends to your widget and how to receive it.
  • API Credentials — optional temporary credentials for calling the Livespace API.
  • Widget Environment — widget sizes, placement, and responsive-design guidance.