DPS SDKs
Public, framework-agnostic packages on npm for building on top of DPS — the cross-app subscription registry and the mobile artifact / release pipeline.
As of @duabalabs/dps-client v0.2.0 the money-creation surface
(donations, subscriptions, invoices, product checkout) was removed from
this client. Those checkout flows now live in
@duabalabs/sellub-client and are served by
sellub-server. DPS owns only the read-only subscription registry (a
Parse object fed by Sellub → DPS webhooks) plus the mobile release CLI.
Source for both packages lives in the monorepo:
packages/dps-clientanddps-cli.
The two DPS packages
| Package | What it’s for | Runs in |
|---|---|---|
@duabalabs/dps-client | Read the cross-app subscription registry and the event log bridged from Sellub. The auth-gate / entitlement layer. | Node, browser, edge, React Native |
@duabalabs/dps-cli | The dps command-line tool — upload mobile artifacts, create / publish / roll back releases, validate repos and trigger remote builds. | Node 18+ CLI / CI |
Typed Parse-backed client for the DPS subscription registry. Two modes: a browser client (Parse JS SDK + JS key) and a server client (fetch + master key). Same method surface either way.
@duabalabs/dps-clientThe dps CLI. Authenticate with a deploy token, then upload artifacts,
create releases, publish to stores, and run managed-build dispatch.
Install
# Subscription / entitlement client
npm install @duabalabs/dps-client # or: pnpm add @duabalabs/dps-client
# Release CLI (global)
npm i -g @duabalabs/dps-cli # or: pnpm add -g @duabalabs/dps-cliBrowser vs server client
@duabalabs/dps-client ships two factories with an identical method
surface — pick the one that matches where your code runs:
| Factory | Transport | Credentials | Use from |
|---|---|---|---|
createDpsClient({ Parse }) | Parse JS SDK Cloud.run | App ID + public JS key | Browser, static-export Next.js, React Native |
createDpsServerClient({ serverUrl, appId, masterKey }) | fetch to /functions/* | App ID + master key | Server routes, trusted backends, CI |
Never ship a master key to a browser bundle. Public landings use
createDpsClient with a JS key only; trusted backends use
createDpsServerClient.
Where payments live now
dps-client no longer creates payments. The split is:
@duabalabs/dps-client— reads subscription status and bridged events. This is what an app calls to gate access (checkSubscription).@duabalabs/sellub-client— creates money: one-off payments (externalPayments), subscriptions, and hosted invoices. Sellub captures the payment, then bridges the lifecycle event to DPS, which is whatdps-clientlater surfaces throughcheckSubscription/listEvents.
So a typical integration uses both: sellub-client to start a checkout, and
dps-client to read whether the resulting subscription is active.
Versioning
- Packages are versioned independently with semver.
dps-clientis at0.3.x; anything below1.0.0may break between minor versions, so pin exact versions in production until a package hits1.x.
Related
- DPS API Reference — the
dps_*cloud functions and REST endpoints these SDKs call. - Mobile Builds & Releases — end-to-end build/publish guide that the CLI drives.
- Sellub SDKs — the commerce / money-layer packages.