SDK Overview
Quick summary
Choose an SDK by the job: browser activation, server-side enforcement, Nuxt integration, or donation/feedback embeds. These are not interchangeable packages.
License SDKs are currently consumed from source or packed artifacts; public registry installation has not been verified.
The SDK surface splits along the two brands — the split is codified in naming-policy and is not going to be renamed:
| Namespace | Packages | Surface |
|---|---|---|
@yetdapay/* | @yetdapay/license-web, @yetdapay/license-server, @yetdapay/license-nuxt, @yetdapay/cli | License enforcement SDKs + developer CLI |
@yetdapay/* | @yetdapay/sdk | Commerce/embed — donation & feedback only |
Rules of thumb: new license-plane additions use @yetdapay/*; new commerce/embed additions use @yetdapay/*; MCP tools/env stay yetdapay_*/YETDAPAY_* regardless of which package they wrap.
Package status (version 0.1.0 each)
| Package | private | Install story | Scope |
|---|---|---|---|
@yetdapay/license-web | false | npm pack / file: dep — publishable by design | Browser: device keypair, PoP proofs, entitlement store, signedFetch |
@yetdapay/license-server | false | same | Node 22 host: entitlement/proof/capability verification, LicenseStore (memory + SQLite) |
@yetdapay/license-nuxt | false | same | Nuxt 3 adapter over the two above |
@yetdapay/sdk | true | copy-in source bundle — copy sdk/core.ts + sdk/vue//sdk/react/ files | Public donation/feedback only |
@yetdapay/cli | true | npm pack → npm i -g <tarball> | yp binary |
No registry release
None of these are on a public npm registry in this wave. private:false marks publishable intent, not a published artifact.
Two independent contracts
Do not conflate them:
- License wire (PoP) —
@yetdapay/license-web↔ backend/licenses/{activate,capability,execute,status}or a BYOS@yetdapay/license-server. Entitlement JWS + DPoP-style proof +jktdevice binding. Normative reference: interface contract matrix. - Commerce REST —
@yetdapay/sdk↔/public/integrations/{public_id}[/donations|/feedbacks]. Unauthenticated, manifest-driven, sandbox donations only. There is no overlap in endpoints, credentials, or trust domain.
The worker preset
SDK defaults (activatePath: /api/license/activate, iss: devpay, optional aud) differ from the hosted Worker (/api/v1/licenses/activate, iss: devpay-lic, no aud). Pairing is one line on each side:
// browser — @yetdapay/license-web
import { createLicenseClient, createWorkerConfig } from '@yetdapay/license-web';
const client = createLicenseClient(
createWorkerConfig({ baseUrl: 'https://api.example.com', productId: 'prod_…' })
);
// host — @yetdapay/license-server
import { createLicenseServer, createWorkerConfig as serverWorkerConfig } from '@yetdapay/license-server';
const server = createLicenseServer(serverWorkerConfig({ store, keys }));2
3
4
5
6
7
8
9
createWorkerConfig() sets activatePath: '/api/v1/licenses/activate' on the client and issuer: 'devpay-lic' with no aud requirement on the server. Everything else stays overrideable via overrides.
What the SDKs deliberately do not do
- No client-bundle obfuscation or integrity checking.
- No DRM, no offline-execution protection.
- No user authentication — licensing is orthogonal to login.
@yetdapay/sdkcovers donation/feedback only — it does not wrap the checkout/order/license REST surface.