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
Four components, registered as framework-agnostic custom elements:
| Component | Tag | Purpose |
|---|---|---|
| Resource editor | <ss-resource-editor> |
Author or edit a blueprint, template, asset, schema, or function inside your app |
| Workflow editor | <ss-workflow-editor> |
Edit a single workflow — documents, participants, signing steps, and current state |
| Workflow monitor | <ss-workflow-monitor> |
List/dashboard view of workflows in the active namespace (a "my agreements" inbox) |
| Signing experience | <ss-signing-embed> |
Embed the e-signing flow for a participant in a workflow |
All four 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 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 the same minimum config, wired through HTML attributes or properties on the custom element:
| Attribute | Purpose |
|---|---|
embed-token |
Short-lived embed token issued by your backend that authorizes the user for a specific intent |
org-id |
Your SignStack organization ID |
namespace-key |
The namespace this embed targets — which tenant and which environment |
Components also accept intent-specific props (e.g. workflow-id on <ss-signing-embed>) and emit events you can listen to from your app (signed, declined, signing-error, closed, etc.).
Authentication Model
Embed components don't use API keys directly. The flow is:
- Your backend (server-side) calls
POST /v1/orgs/{orgId}/namespaces/{namespaceKey}/auth/embedwith an API key, requesting an embed token for a specific intent — e.g. signing for participant X on workflow Y, or editing resource Z. - SignStack returns a short-lived JWT scoped to that intent.
- You pass that JWT to the web component as
embed-token. - The component uses the token for all its API calls. When it expires, the component fires a
session-expiredevent 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 | <ss-resource-editor> |
| Edit a single workflow's documents, participants, or steps | <ss-workflow-editor> |
| Build a "my agreements" inbox or admin dashboard | <ss-workflow-monitor> |
| Have a participant sign a document inside your app | <ss-signing-embed> |
Related
- Securely Embedding Components (Session Tokens) — Embed-token issuance, intents, and security model
- Namespaces — Custom Branding — Per-tenant branding for SignStack-managed surfaces
