Integrate Morph Embed

Morph Embed is a drop-in script that adds an AI prompt bar to your web product. Your users type what they're missing ("add a box showing how much we lost in the last 15 days") and get a real widget computed from your data, rendered safely, saved for them, and reapplied on every visit. It's the same engine as the Morph browser extension, packaged as an SDK.

What it is

Three capabilities, in increasing order of integration effort:

Install

Script tag (exposes window.Morph):

<script src="https://unpkg.com/morph-embed/dist/morph-embed.js"></script>

npm (bundlers, the ESM build):

npm install morph-embed

import { init } from 'morph-embed';

Get a publishable key

Create an account at usemorph.xyz/dashboard, add the origins your product is served from, and copy the pk_live_… key. Keys are publishable: like a Stripe pk_ key, they're meant to appear in page source. Each key is bound to your origins server-side and rate-limited; it gates cost, not data (there is no data behind it).

• Origins are exact: https://app.example.com. www and the apex are different origins; register both if you serve both.
• Use a single * origin on a dev/preview key, then replace it with a pinned key before launch.
• Revoking a key takes effect within ~60 seconds.

Quickstart

The complete integration surface, a CRM registering one source and one action:

Morph.init({
  key: 'pk_live_…',

  sources: {
    deals: {
      fetch: async (query) => api.deals(),   // your API, your auth, your data
      schema: {                             // field → 'string' | 'number' | 'date' | 'boolean'
        name:     'string',
        stage:    'string',
        amount:   'number',
        closedAt: 'date',
      },
      description: 'All CRM deals (stage: won|lost|open)',
    },
  },

  actions: {
    createTask: {
      run: async (args) => api.tasks.create(args),  // your callback
      argsSchema: { note: 'string' },              // string | number args only
      description: 'Create a follow-up task',
      confirm: true,                              // user must approve every run
    },
  },
});

Your users press Alt+M or click the ✦ launcher and describe what they want. That's it.

Morph.init(config) reference

After init, these are available on window.Morph:

• Morph.open() opens the prompt bar from your own UI (pair with trigger:'none').
• Morph.bar is the prompt-bar controller (.show(), .hide(), .toggle()).

Data sources

A source is how the model turns "lost deals this month" into a real number. You register a fetch function and a field schema; the model only ever sees the schema and description, never a record. When it wants numbers it emits a query description; trusted SDK code validates that query against your schema, runs your fetch in the browser (under your existing auth), aggregates client-side, and renders the result itself.

The query language

Deliberately tiny: enough for "show me X", small enough to audit. The model emits it; trusted code runs it. Every referenced field must exist in your source's schema.

The engine caps input at 10,000 records and output at 60 rows. If a question needs more than this language expresses, expose it as a purpose-built source (do the work in fetch and return a pre-shaped array).

Charts

Widgets the model can generate over a query result, all rendered by trusted code as SVG:

• stat: a single big number + caption (e.g. total lost this month). Numbers format as 14.4k / 1.2M.
• bar: one bar per group (needs groupBy).
• line: a line over grouped/time-bucketed values.

Layout reshapes and added elements use the same sanitized DSL as the rest of Morph; the model can also restyle, hide, move, and add plain elements around your widgets.

Actions

An action lets the model add a button that performs something in your app. It is inert JSON until a real user clicks it: the model can only name a registered action and supply schema-checked args; it can never invoke one.

Storage

Generated features are saved per user and reapplied on every visit. By default they live in the browser's localStorage (per-origin, per-device). To make a user's features follow them across devices, pass a three-method adapter that persists to your backend:

Morph.init({
  key: 'pk_live_…',
  storage: {
    get:    async (key)        => myBackend.get(key),      // → value | undefined
    set:    async (key, value) => myBackend.set(key, value),
    remove: async (key)        => myBackend.del(key),
  },
});

Values are JSON-serializable. Keys are namespaced by Morph. Methods may be sync or return Promises. Storage failures never throw; a broken adapter degrades gracefully and never breaks your page. Morph itself stores nothing per-user on its servers.

The end-user experience

What your users get out of the box, with no work from you:

• A launcher: a small ✦ button (bottom corner, themeable, or hidden) with a badge showing how many edits are active. It never auto-opens; one subtle pulse on first visit only (and none under prefers-reduced-motion).
• Forgiveness: every change applies instantly and shows an Undo toast. No confirmation dialogs to click through.
• Control & history: an "edits panel" lists every saved edit in the user's own words, with a per-edit on/off toggle, per-edit delete, and a reset.
• A narrated wait: "Reading this page… → Designing your change…" instead of a blank spinner.
• An element picker: the ⌖ button lets a user click one element to scope a change to it.

Why it's safe to put in your product

Most teams can't let an LLM touch their UI because model output might execute. Morph is built so it can't:

• The model never returns code. It answers only in a fixed declarative JSON DSL (hide, injectCSS, renderData, …). Every op is validated and sanitized in the browser: HTML is whitelist-sanitized, CSS is neutralized (including a block on external url() so nothing can beacon out), and there is no execution op to reach for.
• Your data never leaves the page. The model sees only your source names and field schemas. It emits a query description; trusted SDK code runs it against your fetch in the browser and renders the numbers itself. Morph's servers never see a record, and the model never emits a number.
• Actions are allowlisted by construction. Unknown names and off-schema args are dropped; a registered action runs only on a real user click, behind a confirm dialog if you say so.
• Keys are publishable. Bound to your origins server-side, rate-limited per vendor. They gate cost, not data.
• Generated features live client-side, in localStorage or your own adapter. Morph stores nothing per user.
• Signals are shape plus samples, never data. For vendor-keyed requests Morph retains the structured shape of generated changes (op, source, field names) and truncated prompt samples, aggregated per vendor, to power the dashboard's Signals panel. No end-user identifier, no records, no page content.

Signals: your users are writing your roadmap

Every generated feature is fingerprinted into a cluster: a value-free shape of what the user built (op type, source name, field names), never the field values, records, or the prompt text of a specific request. Each cluster carries four running counters: built (generated), kept, undone, and reapplied (seen again on a later visit), plus up to five truncated prompt samples so you can read a cluster in your users' own words.

The transform response carries the fingerprints it touched as signal.fps. The SDK stores them on the saved recipe and, on keep, undo, or reapply, calls POST /api/embed/event with header X-Morph-Key and body { kind, fps }. No new page data leaves the browser: the event only reports which known clusters moved, and unknown fingerprints are dropped server-side.

See the ranked clusters in your dashboard's Signals panel, sorted by kept count then built count. Signals is a vendor-only view: disclosing it to your own end users, like any other product telemetry you run, is your responsibility. See the privacy policy for the full retention statement.

The DSL (what the model can emit)

You don't write these (the model does), but knowing the vocabulary helps you reason about what a prompt can and can't do. Every op is sanitized before it touches your DOM.

Full op grammar, field-by-field, is in the AI-agent docs.

Browser support

Any modern evergreen browser (Chrome, Edge, Firefox, Safari). The SDK is dependency-free, ships as a single ~140KB IIFE (or an ESM build for bundlers), and isolates its UI in a Shadow DOM so it can't collide with your styles. The hotkey matches the physical key, so Alt+M works on macOS (where Option+M types "µ") and never fires while a user is typing in your inputs.

Troubleshooting