@clearlaunch/sdk

One project key, every ClearLaunch surface — release notes, user guides, and feedback/ticketing — on your own site.

npm install @clearlaunch/sdk @clearlaunch/core

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

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

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');
</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 sub-packages 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.

Capabilities are opt-in

Each capability lives in its own package, declared as an optional peer, so a docs site isn't forced to ship a ticketing inbox.

| Capability | Package | Install if you use | |---|---|---| | cl.versions | @clearlaunch/versions | release notes | | cl.guides | @clearlaunch/guide-sdk | published guides | | cl.ticketing | @clearlaunch/feedback | feedback / bug reports |

@clearlaunch/core is required. Accessors are lazy — touching cl.ticketing is what resolves and mounts it, so an unused capability costs nothing at runtime.

Reaching for a capability whose package isn't installed throws a message naming the exact package rather than a bare undefined.

If your bundler can't resolve optional peers

Bundlers resolve import statically, so some will fail the build on an optional peer that isn't present. Register the module yourself:

import * as feedback from '@clearlaunch/feedback';
import { register, clearSDK } from '@clearlaunch/sdk';

register('@clearlaunch/feedback', feedback);
const cl = clearSDK({ projectKey: 'pk_…' });

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. |

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. See @clearlaunch/versions for its options.

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. The capability option and widget types are re-exported, so you can annotate without depending on the sub-packages directly.

Links

• ClearLaunch
• Documentation