Skip to content
Vera Support

SDK Include

Add this script tag to your entry HTML file:

<script src="/bridge/sdk.js"></script>

The SDK creates a window.pipeline namespace with all available methods. All methods return Promises. The SDK waits internally for the bridge to be ready — you do not need to poll or delay before calling methods.

Namespaces

Section titled “Namespaces”

The current SDK (v2.5.0) exposes:

window.pipeline.context.get()
window.pipeline.customers.list({ page, pageSize })
window.pipeline.products.list({ page, pageSize })
window.pipeline.taskTemplates.list({ codes, page, pageSize })   // since v2.1.0
window.pipeline.costItems.list({ codes, page, pageSize })       // since v2.1.0
window.pipeline.jobCostTemplates.list({ codes, page, pageSize }) // since v2.2.0
window.pipeline.settings.get(key)                               // since v2.3.0
window.pipeline.settings.set(key, value)                        // since v2.3.0
window.pipeline.jobs.list({ page, pageSize })
window.pipeline.quotes.list({ page, pageSize })
window.pipeline.quotes.create(request)
window.pipeline.quotes.addLines(lines, { sections })             // quoting_extension only; sections since v2.5.0
window.pipeline.quotes.addSections(sections)                    // quoting_extension only; since v2.5.0

window.pipeline.version reports the SDK version string at runtime.

Runtime environment

Section titled “Runtime environment”

Marketplace tools run inside a sandboxed iframe. A few host constraints to design around:

Native modals are blocked

Section titled “Native modals are blocked”

alert(), confirm(), and prompt() are silently ignored — the iframe is sandboxed without the allow-modals capability. Calls to these functions log a warning to the DevTools console and return immediately without showing anything to the user.

Use in-page UI for all user feedback instead:

  • For ephemeral confirmations and errors, render a toast (a small, non-interactive div positioned fixed; bottom: 1rem; right: 1rem; that auto-hides after 2-3 seconds).
  • For persistent warnings (e.g. “couldn’t reach Vera catalogue, submit unavailable”), render a banner at the top of the tool with an inline retry button.
  • For destructive confirmations (e.g. “clear all rows?”), use a two-click pattern: the first click changes the button label to “Click again to confirm” for a few seconds, the second click commits.

Storage

Section titled “Storage”

Use settings.get(key) and settings.set(key, value) (since v2.3.0) for tool-side preferences such as pricing, defaults and the operator’s last-used settings. The host stores them per tenant and per tool, so they survive across sessions and devices.

Do not rely on localStorage: the tool runs in a sandboxed iframe with an opaque origin, where browser storage is not dependable.

Do not persist the in-progress quote in settings — Vera owns the quote. Submit-or-discard is the expected lifecycle.

XSS hygiene

Section titled “XSS hygiene”

If you build HTML via template strings (element.innerHTML = \…``), escape every interpolated user-supplied value. A 6-line helper is enough:

function escHtml(s) {
  return String(s == null ? "" : s)
    .replaceAll("&", "&amp;").replaceAll("<", "&lt;").replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;").replaceAll("'", "&#39;");
}

Apply it to anything the operator typed (notes, location names, free-text specifications) and to anything coming back from customers.list or products.list (supplier names, descriptions). Numeric and boolean values are safe.

Send the host plain text, not HTML. Section notes are always rendered as plain text, so HTML in them prints literally; do not put markup in line descriptions either.