Skip to main content

Embedded UI Components

Kaunt's embedded UI components are prebuilt browser-side experiences you drop into your own application. They render parts of the Kaunt product directly inside your shell — typically inside an <iframe> next to your existing screens — without you having to build the UI yourself or call low-level APIs from the browser.

Each component is anchored to a specific resource (usually a Document AI document) and a specific end user. You mint a short-lived session from your backend using your Kaunt API key, and the resulting URL is what the browser opens. The browser-side code talks to Kaunt directly using a JWT scoped to that session — your API key never reaches the browser.

Available components​

Component identifierWhat it does
documentai-feedback-agentChat experience grounded on a single Document AI document. The user describes how extraction should change in plain language; the agent proposes rules the user can preview and confirm.

More components are planned. The session model, the embedding mechanics, and the authentication model are the same for all of them — switching components is a matter of changing the component identifier and the data payload.

High-level flow​

  1. Your backend calls POST /v1/tenants/{tenantId}/embedded-components/sessions with the component identifier, the access mode, and a component-specific data payload describing what the component should show.
  2. Kaunt returns a session ID, a JWT (iframe mode only), and a URL pointing at the components host.
  3. Your frontend embeds that URL — typically in an <iframe>, optionally as a one-shot direct link — and delivers the JWT to the iframe via postMessage if you're using iframe mode.
  4. The component boots, validates the JWT, and renders. End-user actions inside the component (giving feedback, applying a rule) are sent directly to Kaunt; you don't need to proxy them.

You can revoke an active session at any time via DELETE /v1/tenants/{tenantId}/embedded-components/sessions/{sessionId} — for example when the user logs out of your application. Open browser tabs using that session will see a session-revoked error event.

When to use embedded components​

Embedded components are a good fit when:

  • You want to give your users access to a Kaunt feature without designing and building the UI yourself.
  • The feature is naturally tied to a single document or workflow step — embedded UI tends to work best when the user understands the surrounding context from your own application.
  • You want updates to that feature (new fields, better rule proposals, UX polish) to flow to your users automatically without you shipping a frontend release.

If you instead want full control over the user experience, or you're building a non-browser surface (mobile native, batch job), call the Kaunt Document AI API directly.

Hosts and regions​

Embedded component URLs always point at the components host in the same region as your API:

RegionAPI host (your backend uses this)Components host (browsers load this)
EUapi.kaunt.comcomponents.kaunt.com
USapi.us1.kaunt.comcomponents.us1.kaunt.com

The components host serves only static assets and short-lived session traffic; you do not proxy requests through it.

Authentication​

The session-creation endpoint lives on the standard Kaunt API host and authenticates with your normal Kaunt API key as a Bearer token. The browser-side calls the component makes are authenticated with the JWT minted for that session, signed by Kaunt. Your API key never leaves your backend.

For full request/response schemas including the per-component data payloads, see the Embedded Components section of the API reference.

Next steps​