@clearlaunch/sdk

One project key, one install — search, user guides, release notes, feedback and feature flags, on your own site.

npm install @clearlaunch/sdk

import { clearSDK } from '@clearlaunch/sdk';
import { mountSearch } from '@clearlaunch/sdk/search';

const cl = clearSDK({ projectKey: 'pk_…' });

cl.versions.mount('#whats-new');                 // release notes
cl.guides.mount({ target: '#docs' });            // published user guides
cl.ticketing.mount({ service: 'dealership' });   // feedback / bug reports
mountSearch({ projectKey: 'pk_…' });             // ⌘K search palette

Or without a build step:

<script src="https://unpkg.com/@clearlaunch/sdk/dist/clearlaunch.js"></script>
<script>
  const cl = ClearLaunch.init({ projectKey: 'pk_…' });
  cl.versions.mount('#whats-new');
  ClearLaunch.mountSearch({ projectKey: 'pk_…' });
</script>

This build inlines every capability, so there is nothing else to install. Pin a version in production — @clearlaunch/[email protected] — rather than tracking latest.

One credential

You pass a single pk_ project key. The guide slug and feedback token the capabilities need are resolved server-side and returned in the SDK config, so callers never handle them. Both were already public — guide slugs appear in /docs/:slug URLs — so this exposes nothing new.

The key is publishable: it identifies a project and grants only the read and submit operations these widgets perform. It is not a secret, and it is not interchangeable with the sk_ key, which never belongs in browser code.

Entry points

Everything ships in one package. Each capability is its own entry point, so importing one never pulls in the others:

| Import | Capability | |---|---| | @clearlaunch/sdk | the shell — cl.versions, cl.guides, cl.ticketing | | @clearlaunch/sdk/search | mountSearch() — the ⌘K palette | | @clearlaunch/sdk/guides | mountGuide() — a guide on its own | | @clearlaunch/sdk/versions | createVersions() | | @clearlaunch/sdk/feedback | mountFeedback() | | @clearlaunch/sdk/flags | clearFlags() — feature flags |

Why subpaths rather than one big export: the search engine bundles a fuzzy matcher (~30KB) for local sources, and an app that only wants feedback should not pay for it. A separate entry point makes that a guarantee rather than something you hope your bundler works out.

Approximate cost of each entry, minified:

| Entry | Size | |---|---| | root shell | 3.7 KB | | /flags | 1.8 KB | | /versions | 6.3 KB | | /feedback | 18.7 KB | | /guides | 18.0 KB | | /search | 34.9 KB |

API

clearSDK(config) → ClearLaunchClient

Also exported as init, and as ClearLaunch.init for the script-tag build.

| Option | Type | Notes | |---|---|---| | projectKey | string | Required. Your pk_… key. | | apiUrl | string | Defaults to https://api.clearlaunch.ai. |

mountSearch(options)

import { mountSearch } from '@clearlaunch/sdk/search';

const search = mountSearch({
  projectKey: 'pk_…',
  onSelect: (result) => router.push(result.route),
});

A ⌘K / Ctrl-K command palette across your published guides, the pages you declare, and your library elements. Configure what it searches in ClearLaunch → project → Integrate → Search.

| Option | Notes | |---|---| | projectKey | Required. | | hotkey | { key, meta, ctrl }, or false to disable. Default ⌘K / Ctrl-K. | | onSelect | Defaults to navigating to result.route. | | sources | Extra local sources merged into the same palette. | | theme | bg, fg, muted, accent, border, radius. | | placeholder | Overrides the one set in ClearLaunch. |

Returns { open, close, toggle, destroy, registry }. Use registry to add your own sources after mount — recent items, in-memory entities — so one palette covers both your data and ClearLaunch's.

cl.ticketing

const widget = await cl.ticketing.mount({ service: 'dealership' });
widget.open('bug');

mount(options?) returns a widget with open(type?), close(), destroy().

Useful options: service (the touchpoint this widget sits on — stored on the submission and the resulting card, so feedback can be filtered by surface), trigger, theme, types, defaultType, user, metadata, text, and the onSubmit / onError / onOpen / onClose callbacks.

services() lists the touchpoints declared on the project, for building your own picker. enabled() reports whether feedback is switched on.

service must be one of the services declared on the project.

cl.guides

await cl.guides.mount({ target: '#docs' });

mount(options?) renders a published guide into options.target, defaulting to the project's first published guide unless you pass a slug.

slugs() lists every published guide; defaultSlug() returns the one a bare mount() would open.

cl.versions

cl.versions.mount('#whats-new');

Renders published release notes.

clearFlags

import { clearFlags } from '@clearlaunch/sdk/flags';

const flags = clearFlags({
  projectKey: 'pk_…',
  environment: 'production',
  fallbacks: { 'new-checkout': false },
});

await flags.load({ id: user.id, plan: user.plan });
if (flags.isOn('new-checkout')) showNewCheckout();

Evaluating server-side instead? Use @clearlaunch/flags-node, which evaluates locally against a downloaded ruleset rather than calling out per check.

cl.config

The resolved project config — name, theme, and which widgets are enabled. Fetched once and shared across capabilities.

TypeScript

Types ship with the package, including for every subpath.

Links

• ClearLaunch
• Documentation