SDKs¶

First-party clients for TypeScript and Python wrap the parts of this API that are protocol rather than payload: token minting and refresh, retry behavior, WebSocket resume, and webhook signature verification. They are the fastest correct path, and everything they do is documented here as raw HTTP if you would rather not use them.

Not published to a package registry yet

The SDKs are not on npm or PyPI. There is no npm install or pip install for them that works today, and the package names are not final. They are delivered as source with your integration pack; add them to your project the way you would any vendored dependency. Publication is part of general availability and will be a changelog entry.

What they handle for you¶

Concern	What the SDK does
Tokens	Mints on first use, caches, and refreshes ahead of expiry — including across concurrent callers, so a cold start does not become a burst of token requests.
Retries	Retries only what is safe to retry, honors `Retry-After`, and backs off with jitter. It never retries a `409`.
Errors	Raises a typed error per error code, each carrying the `code` and the `request_id`.
Streaming	A resumable socket that negotiates the subprotocol, tracks the last processed `seq`, and re-subscribes with `after_seq` after a drop.
Webhooks	Signature verification, including the two-signature rotation window, with a constant-time compare and the timestamp tolerance already applied.
Versioning	Asserts at build time that the SDK's major matches the API's, so a mismatched pairing fails loudly instead of at runtime.

Request and response shapes are generated from the same definition that produces the reference, so they cannot drift from it.

Both SDKs also carry the write-side helpers: an Idempotency-Key is minted for you when you do not supply one, and a read-modify-write helper handles the ETag/If-Match cycle so a stale update is re-read rather than blindly replayed. Neither SDK auto-retries a 409 — reusing a key on a changed request is never safe, and that is a decision only your code can make.

Shape of the TypeScript client¶

// The package name is finalized at general availability. Your integration pack
// names the current one.
import { PlatformClient } from '<platform-sdk>';

const client = new PlatformClient({
  baseUrl: process.env.PLATFORM_BASE_URL!,
  credentials: {
    clientId: process.env.PLATFORM_CLIENT_ID!,
    clientSecret: process.env.PLATFORM_CLIENT_SECRET!,
    scope: 'accounts:read transactions:read'
  }
});

Shape of the Python client¶

# The distribution name is finalized at general availability. Your integration
# pack names the current one.
from platform_sdk import ClientCredentials, PlatformClient

client = PlatformClient(
    os.environ["PLATFORM_BASE_URL"],
    credentials=ClientCredentials(
        client_id=os.environ["PLATFORM_CLIENT_ID"],
        client_secret=os.environ["PLATFORM_CLIENT_SECRET"],
        scope="accounts:read transactions:read",
    ),
)

The Python client runs on the standard library — installing it pulls nothing into your dependency tree. If you already depend on an HTTP library, you can supply it through the client's transport hook instead.

Dependencies and support¶

TypeScript: Node 22 or later.
Python: 3.10 or later.

Both are covered by your platform agreement rather than an open-source license; they are yours to embed in your own application, not to redistribute.

SDKs¶

What they handle for you¶

Shape of the TypeScript client¶

Shape of the Python client¶

Dependencies and support¶

Related¶