Embedding Components

SignStack ships its main Studio surfaces as embeddable web components. Drop them into your own application for a fully white-labeled experience — your users never leave your product, and every touchpoint carries your brand.

What You Can Embed

Three components, registered as framework-agnostic custom elements:

Component Tag Purpose
Builder <signstack-builder> Author or edit a blueprint, template, asset, schema, or function inside your app
Workflow <signstack-workflow> One component for both editing and monitoring a workflow — auto-detects from workflow status; override with mode="editor" / mode="monitor"
Participant <signstack-participant> Embed the e-signing flow for a participant in a workflow

All three work in React, Vue, Svelte, Angular, plain HTML, or anything else that speaks the DOM. They inherit your app's CSS — typography, colors, button styles — so the surfaces pick up your design system automatically.

The participant signing component is sandboxed for security: the actual signature capture runs in an isolated context to keep the signing UX separated from the rest of your app's DOM.

How They're Configured

Every component takes a single config attribute:

Attribute Purpose
embed-token Short-lived embed token issued by your backend. Carries the org, namespace, intent, and target (e.g. workflow ID) baked in as claims — the component reads them automatically.

That's the whole config surface. Components emit events you can listen to from your app (signed, declined, signing-error, session-expired, closed, etc.) so you can react to lifecycle moments without polling.

Authentication Model

Embed components don't use API keys directly. The flow is:

  1. Your backend (server-side) calls POST /v1/orgs/{orgId}/namespaces/{namespaceKey}/auth/embed with an API key, requesting an embed token for a specific intent — e.g. signing for participant X on workflow Y, or editing resource Z. The intent + target (workflow ID, resource key, etc.) get baked into the token.
  2. SignStack returns a short-lived JWT scoped to that intent.
  3. You pass that JWT to the web component as embed-token. Nothing else — no org ID, no namespace key, no target ID. They're all claims inside the token, extracted server-side at mint time and read by the component on the client.
  4. The component uses the token for all its API calls. When it expires, the component fires a session-expired event so your app can refresh.

This keeps the long-lived API key on your server, gives the browser only the permissions it needs for one embed session, and lets you revoke or expire access without touching the API key.

The full intent catalog (signing, workflow editing, resource editing, etc.) and token mechanics are covered in Securely Embedding Components.

Branding

Embedded components pick up branding from two sources:

  • Your app's CSS — flows through naturally. No theme override or token overrides needed.
  • The active namespace's brand settings — drive any SignStack-managed surfaces around the embed (signing emails, the signing page chrome, the completed document), so what your end-customer's signers see carries the right identity. See Namespaces — Custom Branding.

The combination means: in-product UI matches your design system; out-of-product touchpoints match the namespace's brand. Multi-tenant products get this per-tenant for free.

Choosing a Component

Use case Component
Let your users author or edit a blueprint, template, or schema <signstack-builder>
Edit a single workflow's documents, participants, or steps <signstack-workflow mode="editor">
Build a "my agreements" inbox or admin dashboard <signstack-workflow mode="monitor">
Have a participant sign a document inside your app <signstack-participant>

<signstack-workflow> auto-picks the editor (when the workflow is still pending) or the monitor (once it has started). Pass mode="editor" or mode="monitor" only when you want to force one — typical apps can omit it.