Skip to content

SDKs

View as Markdown

The Sudomimus SDKs are strongly typed clients generated from the public OpenAPI 3.1 contracts in sudomimus/sudomimus-spec: connect.yaml (Connect protocol), native.yaml (native-api direct-issue), and device.yaml (device-api device authorization). The SDK source lives in sudomimus/sudomimus — TypeScript, Python, and C# in one monorepo. SDKs wrap the raw HTTPS calls with serialization, request/response types, JWT parsing, application public-key caching, signature verification helpers, and structured errors — everything you’d otherwise build by hand.

If you’d rather call the API directly, see Web applications for curl, Node.js, Python, and Go HTTP snippets.

All packages are currently at alpha stability — usable, with the API surface tracking the spec, but expect some churn before the first stable release.

The three packages per language split along responsibility:

  • connect — full Connect API client (Establish, StatusPoll, Redeem, Refresh, Info, Introspect, Logout, RevokeAll). Use this in your application backend.
  • native — Native API client (Steam ticket direct-issue, AccessKey direct-issue). Use this in desktop apps, games, CLIs.
  • token — token-parsing utilities only (verifyAccessToken, verifyRefreshToken, the kty constants). Useful when a service only needs to verify tokens and doesn’t call the API.

The connect and native packages already depend on token internally, so most integrations don’t need to install it explicitly.

The Device API has a published OpenAPI reference for direct HTTP clients. A dedicated SDK package will appear here after it is introduced in the SDK repository.

Tabs below are synchronised: pick your language once and every block on the page switches with it.

Terminal window
# pnpm
pnpm add @sudomimus/connect
# npm
npm install @sudomimus/connect
# yarn
yarn add @sudomimus/connect

The client needs to know how to sign /establish requests with your application’s client-auth private key. Supply the key once at construction time; the SDK signs internally on every relevant call.

import { ConnectClient } from "@sudomimus/connect";
const client = new ConnectClient({
baseUrl: "https://connect-api.sudomimus.com",
// clientAuth: configure with your application's client-auth private key
// so the SDK can sign /establish and /revoke-all internally.
// See the package README for the exact option shape.
});
const inquiry = await client.establish({
applicationAnchor: process.env.SUDOMIMUS_APPLICATION_ANCHOR!,
returnMethods: [
{
type: "CALLBACK",
payload: { callbackUrl: "https://your-app.com/auth/callback" },
},
],
});
const { exposureKey, hiddenKey } = inquiry;
const status = await client.statusPoll({ exposureKey, hiddenKey });
if (status.status === "REALIZED") {
const { confirmationKey } = status;
// hand off to redeem
}

The response is discriminated on status ("PENDING" or "REALIZED"); only REALIZED carries a confirmationKey.

const tokens = await client.redeem({
exposureKey,
hiddenKey,
confirmationKey,
});
const { accessToken, refreshToken } = tokens;
// Refresh rotates the token — capture and persist the new one for next time.
const { accessToken, refreshToken: newRefreshToken } = await client.refresh({ refreshToken });
await store.saveRefreshToken(newRefreshToken);
const { status, recommendedRecheckSeconds } = await client.introspect({ accessToken });
// status: "active" | "revoked" | "expired" | "not_found"
await client.logout({ refreshToken });
const { revokedCount } = await client.revokeAll({ subject });

Endpoint semantics are documented in Managing sessions. /refresh rotates the refresh token — it returns a fresh accessToken and a new refreshToken, and the presented one is consumed; persist the replacement and use it next time. /refresh, /introspect, and /logout are self-authenticating (the token is the credential); /revokeAll requires the client-auth credentials configured at construction time.

const info = await client.info({
applicationAnchor,
locale: "en-US",
});
// info.applicationName, info.applicationPublicKey
import { TokenError } from "@sudomimus/token";
try {
const token = await client.verifyAccessToken(rawJwt);
// token.body.subject, token.body.firstName, token.body.lastName?
} catch (error) {
if (error instanceof TokenError) {
// structured token verification failure
}
throw error;
}

verifyAccessToken parses the JWT, checks kty === "Access", validates expiration, then calls /info for the applicationPublicKey (cached per applicationAnchor) and checks the signature. Use verifyRefreshToken for the matching kty === "Refresh" flow, and clearPublicKeyCache() to force a refetch after a key rotation.

Connect access tokens are verified per-application, not against a shared JWKS. See Tokens and verification for the full picture.

import { ConnectApiError } from "@sudomimus/connect";
try {
await client.redeem({ exposureKey, hiddenKey, confirmationKey });
} catch (error) {
if (error instanceof ConnectApiError) {
// error.status — HTTP status
// error.reason — stable machine-readable code (when present)
// error.body — raw `{ reason?: string }` payload (when present)
}
throw error;
}

The reason field is omitted when the underlying failure symbol is marked PRIVATE; in that case only the HTTP status carries signal.

The C# SDK ships two packages today, both alpha:

  • Sudomimus.Native — direct-issue client for native-api (Steam ticket, AccessKey).
  • Sudomimus.Token — token-parsing utilities, the same role as @sudomimus/token.

A Sudomimus.Connect package is not yet shipped — for the Connect protocol from C#, call the HTTPS endpoints directly (see Web applications for the request shapes) and use Sudomimus.Token to verify the tokens you receive. Source: sdks/csharp/src.