@schibsted/account-sdk-browser 6.0.0-alpha.5 → 6.0.0-alpha.7

package/README.md

@@ -2,287 +2,341 @@
 [![Code coverage](https://codecov.io/gh/schibsted/account-sdk-browser/branch/master/graph/badge.svg)](https://codecov.io/gh/schibsted/account-sdk-browser)
 [![Snyk](https://snyk.io/test/github/schibsted/account-sdk-browser/badge.svg?targetFile=package.json)](https://snyk.io/test/github/schibsted/account-sdk-browser)
 
-# Schibsted account SDK for browsers
+# Schibsted Account SDK for browsers
 
-Welcome! This is the home of the Schibsted account JavaScript SDK for use by any website that wishes
-to use Schibsted account to sign up and log in users. Use it to generate URLs for your site's "Log
-in" button, query the logged-in status of your users, and to check whether they have access to
-products and subscriptions, etc.
+Welcome! This is the home of the Schibsted Account JavaScript SDK for browsers. Use it to let users
+sign up and log in with Schibsted Account, read the current session, and check access to products
+and features.
 
-## Getting started
+## Public API
 
-This sdk mainly communicates with a service named Session Service, which is available on brand
-domains (i.e. id.vg.no) to avoid Third-Party Cookie request.
+Create one SDK instance with `createAccountSdk()`. Use `getAccountSdk()` when another module needs
+to wait for that initialized `Account` instance.
 
-Since browsers started to block Third-Party Cookies, your top domain from local machine needs to
-match your Session Service top domain. Otherwise, the Session Service cookie will be a third-party cookie
-and will not be sent with a XHR request.
+The package publishes ES modules and modern JavaScript, including async/await and WHATWG browser
+APIs. It does not include polyfills.
 
-The same applies to cross scheme requests. The Session Service is hosted on https and therefore you need to [run your site with HTTPS locally](https://web.dev/how-to-use-local-https/).
+## Installation
 
-For example if your `pre` domain is pre.sdk-example.com, and it uses id.pre.sdk-example.com Session Service
-domain, your local domain should be local.sdk-example.com.
+```sh
+npm install --save @schibsted/account-sdk-browser
+```
 
-1. Do `npm install --save @schibsted/account-sdk-browser`
-2. Use this library as you would any other npm module: `import { createAccountSdk, getAccountSdk } from '@schibsted/account-sdk-browser'`.
-3. Build your site as you prefer. This library is published as ES modules and uses modern JavaScript
-   syntax (including async/await and other ES2017 and WHATWG features). We recommend that you do
-   any transpilation yourself for the browser versions you need to cater to. We do not add polyfills.
-4. Initiate the SDK with `createAccountSdk` and provide `clientId`, `redirectUri` and `sessionDomain`.
-   Set `env` if you do not want to use the default `PRE` environment.
+```js
+import { createAccountSdk, getAccountSdk } from '@schibsted/account-sdk-browser';
+```
 
-If this is for a new site and there is no sessionDomain yet, contact
-[support](mailto:schibstedaccount@schibsted.com) to initiate the process.
+## Before You Start
 
-## Migration to 5.x.x (ITP)
+The SDK communicates mainly with Session Service on a brand domain such as `id.vg.no`. Your website
+and Session Service domain must share the same top-level site so browser cookies are sent with XHR
+requests.
 
-Follow the [migration guide](./MIGRATION.md).
+For local development:
 
-## Simplified login widget
+- serve your site over HTTPS, because Session Service is hosted over HTTPS
+- use a local hostname with the same top-level site as the configured Session Service domain
 
-1. Ensure that your site has no site specific terms and conditions in the Schibsted account login flow.
-1. Define rules for when and how often the simplified login prompt should be shown to unique users on your site. How you do this is up to you, but we recommend starting with showing the prompt once per user before potentially increasing this frequency over time.
-1. Set up a function to check if users landing on your domain [are logged in](https://schibsted.github.io/account-sdk-browser/classes/Account.html#isloggedin) to your site.
-1. If the user is not logged-in to your site, call the [showSimplifiedLoginWidget](https://schibsted.github.io/account-sdk-browser/classes/Account.html#showsimplifiedloginwidget) function. The `showSimplifiedLoginWidget` accepts the same params as login function (`state` is required, it might be string or async function). If the simplified login prompt is to be loaded, `showSimplifiedLoginWidget` will return `true`.
-1. Set up a way to store information about which users have been shown the simplified login prompt. How you do this is up to you, but one way is to use localStorage. Use this information to execute on the rules defined in #2.
+For example, if your pre-production site is `pre.sdk-example.com` and uses
+`id.pre.sdk-example.com` as Session Service, use a local hostname such as
+`local.sdk-example.com`.
 
-## Example project
+If this is a new site and you do not have a `sessionDomain` yet, contact
+[support](mailto:schibstedaccount@schibsted.com).
 
-There is an example that demonstrates how the SDK can be used. The code is
-[here](https://schibsted.ghe.com/user-identity/sdk-example), and you can see it live
-[here](https://pro.sdk-example.com). You have a use-case that we haven't thought of? Ask us to add
-it by creating an [issue](https://schibsted.ghe.com/user-identity/sdk-example/issues/new).
+## Initialize the SDK
 
-You can use that code as inspiration or just fork and play with it. The account-sdk-browser NPM
-module is used for authenticating the user with Schibsted account. Take a look at how the SDK is
-initialized.
+Create the SDK once during application startup:
 
-When a user wants to log in to your site, you direct them to a UI flow hosted by **Schibsted Account**.
-We authenticate the user and redirect them back to your site. This final redirect back to your site is performed in accordance with the OAuth2 specification.
-This means we pass a `code` in the query string of that redirect URI.
-You can use that `code` on your site's backend, along with your client credentials (client ID and secret), to obtain an *Access Token* (AT) and a *Refresh Token* (RT).
-You should not send the AT (and **never** the RT!) to the browser. Instead, keep them on the server side and associate them with the specific user session.
-This allows you to call Schibsted Account APIs on behalf of that user.
+```js
+import { createAccountSdk } from '@schibsted/account-sdk-browser';
 
-## Events
+const account = createAccountSdk({
+    clientId: '56e9a5d1eee0000000000000',
+    redirectUri: 'https://awesomenews.site/callback',
+    sessionDomain: 'https://id.awesomenews.site',
+    env: 'PRE',
+});
+```
+
+Required configuration:
+
+- `clientId`: your Schibsted Account client id
+- `redirectUri`: the callback URL registered for your client
+- `sessionDomain`: your client-configured Session Service domain
+
+Optional configuration:
+
+- `env`: defaults to `PRE`; supported keys include `LOCAL`, `DEV`, `PRE`, `PRO`, `PRO_NO`,
+  `PRO_FI`, and `PRO_DK`
+- `callbackBeforeRedirect`: called before a full-page session refresh redirect
+- `log`: receives SDK debug log lines
+- `varnish`: enables Varnish cookie handling
+- `window`: overrides the browser window object, mostly useful in tests
+
+`createAccountSdk()` registers the instance on `window.schAccount` and emits
+`schAccount:ready` event.
+
+```js
+window.addEventListener('schAccount:ready', (event) => {
+    const account = event.detail.instance;
+});
+```
+
+If another module needs the initialized instance, use `getAccountSdk()`:
+
+```js
+import { getAccountSdk } from '@schibsted/account-sdk-browser';
+
+const account = await getAccountSdk();
+```
 
-The SDK fires events on the Account instance when something we deem interesting is happening. For
-example, the Account instance emits events when the user is logged in or logged out. This SDK uses a
-familiar interface that's very similar to Node's [EventEmitter](https://nodejs.org/api/events.html). The most important
-methods are `.on(eventName, listener)` (to subscribe to an event) and `.off(eventName, listener)`
-(to unsubscribe to an event).
+`getAccountSdk()` resolves immediately if the SDK has already been initialized. Otherwise it waits
+for `schAccount:ready` and rejects if initialization does not happen within 4000 ms.
 
-The SDK also emits a global event on the `window` when a new Account instance is created.
+## Basic Usage
 
-| Class        | event name              |
-| ------------ | ----------------------- |
-| Account      | `schAccount:ready`      |
+After initialization, use the `Account` instance to render user state and start login when needed:
 
 ```js
-window.addEventListener('schAccount:ready', e => {
-    // The event contains the initialized instance (e.detail.instance);
+async function renderLoginState() {
+    const container = document.getElementById('login-container');
+
+    if (await account.isConnected()) {
+        const user = await account.getUser();
+        container.textContent = `Hello ${user.givenName || user.displayName || user.userId}`;
+        return;
+    }
+
+    container.innerHTML = '<button type="button">Log in</button>';
+    container.querySelector('button').addEventListener('click', () => {
+        account.login({ state: createLoginState() });
+    });
 }
+```
+
+## Login Flow
+
+Use `account.login()` to start the OAuth authorization flow:
 
+```js
+account.login({
+    state: createLoginState(),
+    scope: 'openid',
+    preferPopup: false,
+});
 ```
 
-## Account
+By default the SDK redirects the current window. Set `preferPopup: true` when login is triggered by
+a user gesture and you want to try a popup first. If the popup cannot be opened, the SDK falls back
+to the redirect flow.
+
+If you only need the URL, use `account.loginUrl()`:
 
-Let's start with a bit of example code:
+```js
+const url = account.loginUrl({ state: createLoginState() });
+```
 
-#### Example
+### Handling `state`
 
-```javascript
-import { createAccountSdk } from '@schibsted/account-sdk-browser';
+`state` is an opaque OpenID Connect value that is returned to your `redirectUri` with the
+authorization `code`. Use it to protect against CSRF and to restore application state.
+
+A common pattern is:
+
+1. Your backend creates a random token and stores it temporarily.
+2. Your frontend calls `account.login({ state })` with that token, or with an encoded payload that
+   contains it.
+3. Schibsted Account redirects back to your `redirectUri` with `code` and `state`.
+4. Your backend validates the returned `state` before exchanging `code` for tokens.
+
+Keep Access Tokens and Refresh Tokens on your backend. Do not send them to the browser.
+
+### Authentication Methods
+
+Use `acrValues` when you need to request a specific authentication method:
+
+```js
+account.login({
+    state: createLoginState(),
+    acrValues: 'otp-email',
+});
+```
+
+Supported values include `password`, `otp`, `sms`, `otp-email`, `eid`, `eid-no`, `eid-se`,
+`eid-fi`, and `eid-dk`. Values other than `otp-email` can be combined as a space-separated string
+where supported by the account flow. Verify the resulting AMR claim in the ID token on your backend
+if you need to enforce a completed authentication method.
+
+## Session and User Data
+
+Use these methods to inspect the current Session Service state:
+
+- `account.hasSession()` returns the raw SDK-known session response
+- `account.isLoggedIn()` returns whether the browser has a Schibsted Account session
+- `account.isConnected()` returns whether the user is connected to your client
+- `account.getUser()` returns the connected user session data
+- `account.getUserId()` returns the realm-specific user id as a string
+- `account.getUserUuid()` returns the globally unique user id
+- `account.getUserSDRN()` returns the user SDRN
+- `account.getSpId()` returns the Varnish `sp_id` value when present
 
+Some session methods can trigger a full-page Session Service refresh redirect, especially for
+Safari-based browsers. Use `callbackBeforeRedirect` if you need to persist client state before that
+happens.
+
+```js
 const account = createAccountSdk({
-    clientId: '56e9a5d1eee0000000000000',
-    redirectUri: 'https://awesomenews.site', // ensure it's listed in selfservice
-    env: 'PRE', // Schibsted account env. A url or a special key: 'PRE', 'PRO', 'PRO_NO', 'PRO_FI' or 'PRO_DK'
-    sessionDomain: 'https://id.awesomenews.site', // client-configured session-service domain
+    clientId,
+    redirectUri,
+    sessionDomain,
+    callbackBeforeRedirect: () => {
+        saveCurrentUiState();
+    },
 });
+```
 
-async function whenSiteLoaded() {
-    const loginContainer = document.getElementById('login-container');
-    if (await account.isLoggedIn()) {
-        const user = await account.getUser();
-        const span = document.createElement('span');
-        span.textContent = `Hello ${user.givenName}`;
-        loginContainer.appendChild(span);
-    } else {
-        loginContainer.innerHTML = '<button class="login-button">Log in</button>';
-    }
+## Logout and Account Page
+
+Use `account.logout()` to remove the brand Session Service session and redirect the browser:
+
+```js
+account.logout('https://awesomenews.site/logged-out');
+```
+
+Use `account.logoutUrl()` when you need the logout URL without navigating immediately:
+
+```js
+const logoutUrl = account.logoutUrl('https://awesomenews.site/logged-out');
+```
+
+Use `account.accountUrl()` to send the user to their Schibsted Account profile page:
+
+```js
+window.location.href = account.accountUrl('https://awesomenews.site/account-return');
+```
+
+## Access Checks
+
+Use `account.hasAccess()` to check access to Schibsted Account product ids or Zuora feature ids:
+
+```js
+const userId = await account.getUserId();
+const access = await account.hasAccess(['product-id'], userId);
+
+if (access?.entitled) {
+    showPremiumContent();
+} else {
+    showPaywall();
 }
+```
+
+`hasAccess()` requires `sessionDomain`. Results are cached according to the Session Service TTL.
+Use `account.clearCachedAccessResult(productIds, userId)` when you need to invalidate that cache.
 
-function userClicksLogIn() {
-    account.login({ state: 'some-random-string-1234-foobar-wonky-pig' });
+## Simplified Login Widget
+
+Before using the simplified login widget, make sure your site has no site-specific terms and
+conditions in the Schibsted Account login flow.
+
+The widget is shown only when the SDK can read enough user context from the global account session.
+Your application decides when and how often to show it.
+
+```js
+if (!(await account.isConnected()) && shouldShowSimplifiedLogin()) {
+    const opened = await account.showSimplifiedLoginWidget(
+        { state: createLoginState },
+        { locale: 'nb' },
+    );
+
+    if (opened) {
+        rememberSimplifiedLoginWasShown();
+    }
 }
 ```
 
-If your code needs the initialized singleton from another module, use `getAccountSdk()`:
+`state` may be a string or a function that returns a string or `Promise<string>`. The function is
+called only if the user continues from the widget.
 
-```javascript
-import { getAccountSdk } from '@schibsted/account-sdk-browser';
+## Events
 
-const account = await getAccountSdk();
+The SDK exposes fluent `on()` and `off()` aliases for browser-native event listeners.
+Payload-bearing events are `CustomEvent` instances and expose their payload through `detail`:
+
+```ts
+import type { AccountEventListener } from '@schibsted/account-sdk-browser';
+
+const handleLogin: AccountEventListener<'login'> = (event) => {
+    console.log('Login started', event.detail.url, event.detail.method);
+};
+
+account.on('login', handleLogin);
+account.off('login', handleLogin);
 ```
 
-#### Regarding `state`
-
-This parameter is an OpenID Connect parameter (described in [this paragraph in the
-spec](http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.2.1)). It's formatted as
-an opaque string. This means you can send anything that can be serialized to a string. In practice,
-we have good experience sending something like a JSON value like a base64-url-encoded value — it's
-just an easy way to avoid browsers or backends messing with special characters.
-
-But as a trivial example, if you call `account.login(..)` with params
-`redirectUri=https://site.com&state=article%3D1234` — then at the end of the authentication flow,
-the user will be sent back to your redirectUri, and the `state` parameter will be forwarded along
-with the auth `code` parameter.
-
-It is recommended that you provide a unique identifier as part of the state, to prevent CSRF
-attacks. For example this can be accomplished by:
-
-1. Your backend generates random token: `1234abcd`, saves it in some tokenCache, and forwards to
-   your browser frontend
-1. Your frontend calls `account.login` with `state = base64Urlencode({ token: '1234abcd', article:
-'1234', ... })`
-1. When auth flow completes, the user is redirected back to your site. Then, your backend sees the
-   query parameters `code` (which it can exchange for OAuth tokens for the user) and `state`
-1. Your backend can do `decodedState = base64Urldecode(query.state)` and then verify that its
-   `tokenCache.contains(decodedState.token)`. If that fails, then possibly a CSRF attack was
-   attempted. If successful, remove the token from the tokenCache so the same token can't be used
-   again, and continue to show `decodedState.article`
-
-#### Authentication methods
-
-Although Schibsted account abstracts away the details of how the users sign up or log in, it's worth
-mentioning that your end users have a few ways to log in:
-
-* Username & password: pretty self-explanatory; users register using an email address and a
-    self-chosen password
-*  Passwordless - email: here, the users enter their email address and receive a one-time code that
-    they can use to log in
-*  Multifactor authentication: first client indicates which methods should be preferred, later these
-    will be included (if fulfilled) in `AMR` claim of IDToken
-
-The default is username & password. If you wish to use one of the passwordless login methods,
-`account.login()` takes an optional parameter called `acrValues` (Authentication Context Class Reference).
-The `acrValues` parameter with multifactor authentication can take following values:
-
-*  `eid` - authentication using BankID (for DEV and PRE environments you can choose between country specific solution by specifying `eid-no` or `eid-se` instead)
-*  `otp-email` - passwordless authentication using code sent to registered email
-*  `password` - force password authentication (even if user is already logged in)
-*  `otp` - authentication using registered one time code generator (https://tools.ietf.org/html/rfc6238)
-*  `sms` - authentication using SMS code sent to phone number
-*  `password otp sms` - those authentication methods might be combined
-
-The classic way to authenticate a user, is to send them from your site to the Schibsted account
-domain, let the user authenticate there, and then have us redirect them back to your site. If you
-prefer, we also provide a popup that you can use. In this method, the authentication happens on a
-separate popup window and at the end of the auth flow. We recommend that you make the popup send a
-signal to your main page — using
-[postMessage](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) or something
-similar — to indicate that the user is logged in. If the popup window fails to open, it'll
-automatically fall back to the redirect flow. The SDK Example project mentioned above demonstrates
-how it can work. Again, you can see [sdk-example](https://schibsted.ghe.com/user-identity/sdk-example) if you
-want a working example.
-
-#### Is the user logged in?
-
-Schibsted account relies on browser cookies to determine whether a user is recognized as logged in.
-The SDK provides functions that can be used to check if the user that's visiting your site is
-already a Schibsted user or not.
-
-*  `account.isLoggedIn()`
-    tells you if the user that is visiting your site is already logged in to Schibsted account or not.
-
-*  `account.isConnected()`
-    tells you if the user is connected to your client. A user might have `isLoggedIn=true` and at the
-    same time `isConnected=false` if they have logged in to Schibsted account, but not accepted terms
-    and privacy policy for your site.
-
-If you've lately changed your terms & conditions, maybe the user still hasn't accepted them. In that
-case they are considered *not connected*. In that case, if they click "Log in" from your site, we
-will just ask them to accept those terms and redirect them right back to your site.
-
-#### Logging out
-
-If you want to log the user out of Schibsted account, you can call
-`account.logout()`. This
-will remove the Schibsted account brand session. User will still be logged into Schibsted account.
+Available Account events:
 
-## Access Checks
+- `login` — a `CustomEvent` whose `detail` contains `url` and the `method` (`popup` or `default`)
+- `logout` — a `CustomEvent` whose `detail` contains the logout `url`
+- `simplifiedLoginOpened` — an `Event` emitted when the widget is displayed
+- `simplifiedLoginCancelled` — an `Event` emitted when the widget is closed
 
-The preferred method for checking whether a user has access to a product/subscription is
-`account.hasAccess()`.
-It requires using Session Service, and supports both Schibsted account productId's and Zuora
-feature id's.
+The SDK also emits `schAccount:ready` on `window` when an Account instance is created.
 
-#### Example
+## Errors
 
-```javascript
-import { getAccountSdk } from '@schibsted/account-sdk-browser';
+Validation, network, and service failures from API calls reject or throw `SDKError`. Convenience
+methods such as `isLoggedIn()`, `isConnected()`, and `getSpId()` return fallback values instead of
+throwing when the session lookup fails.
+
+```js
+import { SDKError } from '@schibsted/account-sdk-browser';
 
 try {
-    // Check if the user has access to a particular product
-    const account = await getAccountSdk();
-    const userId = await account.getUserId();
-    const data = await account.hasAccess([productId], userId);
-    alert(`User has access to ${productId}? ${data.entitled}`);
-} catch (err) {
-    alert(`Could not query if the user has access to ${productId} because ${err}`);
+    await account.getUser();
+} catch (error) {
+    if (error instanceof SDKError) {
+        console.error(error.toString());
+    }
 }
 ```
 
-#### Cookies
-
-There are some cookies used by Schibsted account. They should all be considered opaque on the
-browser side. Nevertheless, here is a short description of them.
-
-1. The **autologin** cookie (often called 'the remember-me-cookie'): The cookie name in the
-   production environments is `vgs_email`, because reasons (on PRE, it is called `spid-pre-data`).
-   It's a JSON string that's encoded using the standard `encodeURIComponent()` function and is an
-   object that contains two pieces of information that's important:
-    * `remember`: if set to `true`, the user chose to be remembered and this means we usually support
-      auto-login (that is, if you call the Schibsted account hassession service, and no session can
-      be found in the session database, it will automatically create a new one for the user so that
-      they don't have to authenticate again. If it is `false`, it should be interpreted as the user
-      does not want to be automatically logged in to any site when their session expires
-    * `v`: the version number
-1. The **session** cookies: Cookie names in production environments are `identity`, and `SPID_SE` or
-   `SPID_NO`. It contains:
-    * `user`: an object (if it's missing, a call to hassession will return a `401` with a
-      `UserException` that says `No session found`)
-        * `userId` identifies the user. We use this property to compare "old" user with "new" user and
-          fire events that indicate that the user has changed
-        * `is_logged_in` indicates if the user is logged in
-    * `user_tags`: a map that contains some flags about the user; namely:
-        * `is_logged_in` indicates if the user is logged in (this seems to be a duplicate of a
-          property with a similar name in the parent `user` object)
-        * `terms`: a map of term ids that indicate if they've been accepted by the user.
-    * `referer` (yep, missing the double "rr"..): If this is missing, a call to hassession will
-      return a `401` with a `UserException` that says `No session found`.
+## API Documentation
 
-## Publishing
+Public API documentation is generated from TypeScript source comments with TypeDoc.
 
-Versioning and changelog are handled by [Release Please (GitHub Action)](https://github.com/googleapis/release-please). Publishing to [npmjs.org](https://www.npmjs.com/package/@schibsted/account-sdk-browser) is handled by the [npm-publish workflow](./.github/workflows/npm-publish.yml). See the [Release Please workflow](./.github/workflows/release-please.yml) and [`release-please-config.json`](./release-please-config.json).
+```sh
+npm run docs:build
+npm run docs:open
+```
 
-When publishable changes have been merged to `master`, Release Please will create (or update) a release pull request.
-The suggested version is based on the commit messages in accordance with the [Conventional Commits](https://www.conventionalcommits.org/) specification — `fix:` bumps the patch version, `feat:` bumps the minor version, and `feat!:` or a `BREAKING CHANGE:` footer bumps the major version.
-Other prefixes (`chore:`, `docs:`, `test:`, `refactor:`, `ci:`, `build:`, `style:`) do not trigger a release and are hidden from the changelog.
+During documentation work, use:
 
-To release/publish the changes simply merge the corresponding pull request and wait for the publish workflow to finish.
-Release-please will create a git tag (e.g. `v5.2.7`) and a GitHub Release, and the [publish workflow](./.github/workflows/npm-publish.yml) will push the package to npmjs.org.
+```sh
+npm run docs:watch
+```
 
+Generated docs are written to `docs/` and are not committed.
 
-## LICENSE
+## Example Project
 
-Copyright (c) 2026 Schibsted Products & Technology AS
+An example integration is available in the
+[sdk-example repository](https://schibsted.ghe.com/user-identity/sdk-example), with a live example
+at [pro.sdk-example.com](https://pro.sdk-example.com).
 
-Licensed under the [MIT
-License](https://schibsted.ghe.com/user-identity/account-sdk-browser/blob/master/LICENSE.md)
+## Publishing
+
+Versioning and changelog updates are handled by
+[Release Please](https://github.com/googleapis/release-please). The release configuration lives in
+[`release-please-config.json`](./release-please-config.json), and publishing to
+[npmjs.org](https://www.npmjs.com/package/@schibsted/account-sdk-browser) is handled by the
+[npm-publish workflow](./.github/workflows/npm-publish.yml) when a GitHub Release is published.
+
+Use [Conventional Commits](https://www.conventionalcommits.org/) for changes that should be picked
+up by release automation.
+
+## License
+
+Copyright (c) 2026 Schibsted Products & Technology AS
 
-Unless required by applicable law or agreed to in writing, software distributed under the License is
-distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-implied. See the License for the specific language governing permissions and limitations under the
-License.
+Licensed under the [MIT License](./LICENSE.md).

package/dist/account-sdk.d.ts

@@ -1,4 +1,22 @@
 import { Account } from './account.js';
 import { AccountConfig } from './types/account.js';
+/**
+ * Creates and registers the single Account SDK instance for the current browser window.
+ *
+ * The created instance is stored on `window.schAccount` and the SDK emits
+ * `schAccount:ready` with the instance in `event.detail.instance`.
+ *
+ * @param config - Client, redirect, environment, and Session Service configuration.
+ * @throws {SDKError} If the SDK cannot run in the current browser context, if an Account instance
+ * has already been initialized, or if configuration validation fails.
+ * @group Core API
+ */
 export declare function createAccountSdk(config: AccountConfig): Account;
+/**
+ * Resolves the Account SDK instance registered by `createAccountSdk()`.
+ *
+ * If the instance already exists, the promise resolves immediately. Otherwise it waits for
+ * `schAccount:ready` and rejects if initialization does not happen within the SDK timeout.
+ * @group Core API
+ */
 export declare function getAccountSdk(): Promise<Account>;