A licence check in six languages,
and a REST client in one.

What the verifier actually does

In Node it is not a second implementation: the signature check and the offline-file envelope are the platform's own code, re-exported, so there is no second canonicaliser to drift out of agreement with the server. What the package adds is the decision around them — and every port below makes the same decision, in the same order.

Six languages, one set of fixtures

The other five are ports of the Node package, not reinterpretations of it: each is run against the same signed responses and has to reach the same verdict, down to the failure reason. Only the Node package is published so far — the rest are built and tested, and say so below instead of printing an install command that would fail for you.

Failure is a reason, not a boolean

“Invalid” is not an answer a support agent can act on. Eight outcomes, each with a different fix, and the same eight names in every language above.

The clock, and why it only goes forward

An offline grace window is a promise about elapsed time, and the machine measuring it belongs to the customer. Winding the clock back is the obvious attack, and the obvious defence — “invalidate if the clock goes behind issuedAt” — has a hole: with a 30-day window, winding day 29 back to day 1 never passes issuedAt, and can be repeated forever.

@sellstamp/sdk — the REST client

Typed, hand-written against the routes rather than generated from a spec there isn’t, and built so the three things that bite an integration on day 90 — paging, scopes and retries — are decided in the package instead of in your try/catch.

import { SellstampClient } from "@sellstamp/sdk";

const client = new SellstampClient({ token: process.env.SELLSTAMP_API_KEY! });

for await (const order of client.orders.all()) {
  console.log(order.id, order.totalCents);
}

await client.orders.refund(order.id, { reason: "Duplicate" }, {
  idempotencyKey: crypto.randomUUID(),
});

@sellstamp/cli — the same client, in a terminal

Built on the SDK rather than beside it, so there is one HTTP layer to keep honest. JSON on stdout by default, because the second reader of a developer tool is usually another program.

sellstamp login --api-key sellstamp_live_…   # ~/.sellstamp/config.json, 0600

sellstamp orders list --all | jq -r 'select(.status == "paid") | .id'
sellstamp products create --shop "$SHOP" --data '{"name":"Widget","priceCents":2500}'

sellstamp licenses list > /dev/null
[ $? -eq 3 ] && echo "this key is missing the licenses.read scope"

The integration guide, for any language

The written guide is the other half of this, and it is not a template you edit. Open a product with licensing on and the dashboard generates an integration guide from that product's real policy — its binding mode, its activation limit, its validity rule, its lease timing, its entitlements — and states the HTTP contract in language-agnostic terms.

And a remote MCP server

Not an SDK, but the other way code reaches a store: a merchant can connect Claude, ChatGPT or Gemini to one of their stores over OAuth. It is listed here because a developer evaluating the API should know it exists and how tightly it is bounded.

Limits worth knowing before you build on it