Support

A portal block runs in an <iframe>. A support form opened inside it would be clipped to the iframe, disconnected from the portal's ticketing integration, and unable to collect host-owned session data. The block should not talk to Zendesk (or any other helpdesk) itself.

openSupport asks the parent portal to open its support form. Your block sends a report type, an allowlisted diagnostic context, and — for bug reports — JSON snapshots of the current device and/or vendor. The host owns the form, the ticket, and any extra fields.

import { openSupport } from '@epilot/spark-sdk'

openSupport({
  reportType: 'bug',
  context: {
    appVersion: '0.0.5',
    screen: 'device-detail',
    deviceId: '30969b19-6cf8-466b-91a6-719fed298be6',
    connectionState: 'online',
  },
  device: {
    id: '30969b19-6cf8-466b-91a6-719fed298be6',
    name: 'Denim Flash',
    capabilities: [{ name: 'core', data: { connectivityStatus: 'online' } }],
  },
})

reportType is 'feedback' or 'bug'. Unknown values and non-allowlisted context keys are dropped by the parser; invalid payloads are not posted. device and vendor are accepted only on 'bug' reports and must be JSON objects (not arrays). Feedback payloads never keep those fields, even if they are sent.

Context allowlist

Every field is optional. Omit unknowns rather than sending empty strings. Never include tokens, secrets, energy histories, or unrestricted logs in context.

Dashboard feedback must not include device or vendor fields, or a device / vendor snapshot, even if those were viewed earlier in the session.

Device snapshot

Bug reports from a device detail page should also send device: the live get_device payload already on that page (id, name, externalId, model, capabilities). Do not fetch a second copy. Omit UI-only fields such as openPage. The parser JSON-clones the object so non-JSON values are dropped.

Vendor snapshot

Bug reports from onboarding after a vendor is selected should also send vendor with at least id and name. Include other get_vendors fields (identifier, flow, maturity) when that row is already in memory.

Wire protocol

// block → parent, on openSupport()
{
  "source": "spark-bridge",
  "event": "spark-block:open-support",
  "reportType": "bug",
  "context": { "deviceId": "…", "screen": "device-detail" },
  "device": { "id": "…", "name": "…", "capabilities": [] },
  "vendor": { "id": "…", "name": "…" },
}

There is no reply. The host opens the form; the block does not wait. Until the portal implements the listener, openSupport is a silent no-op.

The host

The customer portal owns the support form. It listens for spark-block:open-support, validates the payload with parseSparkBlockOpenSupportRequest, and renders its own form over the page. Ticketing (Zendesk or otherwise) stays on the host side.