Skip to main content
Use this page for the most common integration questions before or during implementation. If you are already debugging a failure, start with Troubleshooting.

​
Integration basics

Not for the standard hosted integration path described in these docs. Load the SDK through nsdk-loader.js, render a host container, and provide a short-lived Embed Token from your backend.
The hosted SDK approach works with any frontend stack that can load a script, render a DOM container, and fetch a backend token route. React, Vue, Angular, and server-rendered applications can all support this pattern.
The standard documented integration path uses a single container and single mount target. If you need multiple widgets on one page, confirm the supported pattern and runtime constraints with Narrative before implementation.
Use a modern evergreen browser with standard support for secure iframes, HTTPS, and current JavaScript features. If you support older enterprise browsers, validate your exact host environment before launch.

​
Authentication

Keep it short-lived. Current guidance is typically 5–15 minutes, with iat and exp expressed in Unix seconds.
No. Treat it as a short-lived bootstrap credential. Do not store it in local storage or other long-lived browser persistence.
It can no longer be used to start a new embedded session. If the user needs to boot the SDK again, fetch a fresh token from your backend.
It must be an HS256 JWT with aud = nsdk-embed and the required claims: iss, sub, aud, iat, exp, and jti. Include nsdk.user.name and nsdk.user.email so the session has the expected user context.
Fetch it only after the tenant application has already established its own authenticated user session and shortly before mount or boot time.

​
Embedding runtime

Use declarative boot when you have a stable host page and container. Use imperative boot when your application needs explicit control over mount timing, route transitions, or cleanup.
Your application should treat route changes as part of the host lifecycle. If the mount container is removed or recreated, re-run the boot flow and clean up prior runtime state when needed.
Yes when you use imperative mode and your SPA unmounts or replaces the widget container. This helps prevent stale runtime state between navigations.
Yes. That is a common reason to choose imperative mode. Make sure the container exists, the user session is ready, and the Embed Token is fresh before calling NSDK('boot', ...).

​
Security

No. Keep the Connected App secret and all token-signing logic on your backend only.
At minimum, your host application must allow the SDK origin for the hosted loader script and embedded frame. Review script-src, frame-src, and any related network policies used by your environment.
It may be observable in the browser during normal page operation, which is why it must be short-lived, minimally scoped, and never contain secrets.
Yes, but keep it small and non-sensitive. Use optional metadata only for values the embedded experience actually needs at runtime.

​
API & data

Start with the basic path: the loader script loads, the token route returns a fresh token, the widget renders, and protected downstream requests succeed after boot.
It usually means bootstrap succeeded but the downstream request is still missing the expected user, tenant, or product-surface access state. Check the exact API or experience you are trying to reach next.
Data freshness depends on the upstream data source, synchronisation timing, and the provisioned experience. If expected data is missing, verify environment, tenant-user mapping, and sync completion before assuming an auth problem.
Yes. That is often the fastest way to validate token minting, host-page boot logic, and environment wiring before moving to broader tenant-user coverage.
Not in the current v1.5.11 experience. The SDK currently supports one bank account connection while full multi-account support is prepared.
New users must provide business name, first name, and last name before continuing into onboarding. Existing users with stored identity data are not asked to re-enter it.
Your journey is the progress experience. It shows the user’s current phase, completed milestones, next action hints, and follow-through progress across Money, Growth, and Coach.
Distinct Money action responses can advance journey progress. Repeating the same card interaction does not count as multiple progress events, and bookmarked actions can later be marked done when the user follows through.
The first visit now focuses on a short welcome, the user’s stated goal, and two or three personalised Money quick-win cards so users can review useful actions soon after setup completes.
Money actions are designed to focus on one specific opportunity, name the relevant counterparty or category where available, show an estimated impact when supported, and include source or comparison context for research-enriched actions.
Yes. In v1.5.9, Money can ask targeted follow-up questions when transaction data alone cannot confirm eligibility or usage. The item is then resolved into a confirmed recommendation or dismissed with context.
Financial reports and competitor or market intelligence reports are requested from the product experience and delivered by email after preparation.
Yes. In v1.5.8, Money insights can be snoozed when they are relevant but not actionable today. Snoozed items are retained across refresh cycles and can be managed from a dedicated view.
The initial Money load uses backend latest selection so newly onboarded users can see fresh metrics as soon as they are available. Explicit dated contexts should still be preserved when the user intentionally arrives from a dated flow.
Yes. Research into grants, tax reliefs, public finance programmes, training support, and similar SME support opportunities can feed relevant matches into Money as scheme-type insights when enough business context is available.

​
Partner customisation

Yes. Tenant experiences can be white-labelled with partner colours, selected typography, email presentation, and partner-specific visual treatment.
Yes. v1.5.7 supports partner-specific coaching personality configuration so the assistant can better match a tenant’s preferred tone and vocabulary.
Approved remote custom font URLs are supported for tenant themes. Uploaded font files are not supported in this release.

​
Getting help

If you are debugging a concrete failure, use Troubleshooting. If you still need help after self-service checks, use Support.