Initialization

Create the client

import { RisingTideSDK } from "@rising-tide/sdk";

const rtClient = new RisingTideSDK({
  baseUrl: process.env.NEXT_PUBLIC_RT_API_URL!,
  apiKey: process.env.NEXT_PUBLIC_API_KEY,
});

Configuration options

RisingTideConfig is the constructor input shape.

The SDK does not take a network flag - the network is implied by the baseUrl you point at. Client apps select testnet vs mainnet by setting NEXT_PUBLIC_RT_API_URL per environment.

Singleton pattern

In Next.js, create the client as a module-level singleton with lazy initialization:

// lib/sdk/client.ts
import { RisingTideSDK, type RisingTideConfig } from "@rising-tide/sdk";

const sdkConfig: RisingTideConfig = {
  baseUrl: process.env.NEXT_PUBLIC_RT_API_URL || "http://localhost:3001",
  apiKey: process.env.NEXT_PUBLIC_API_KEY,
  timeout: 30000,
};

let sdkInstance: RisingTideSDK | null = null;

export const rtClient = (() => {
  if (!sdkInstance) {
    sdkInstance = new RisingTideSDK(sdkConfig);
  }
  return sdkInstance;
})();

Import rtClient from this module wherever you need it. This is the pattern every Rising Tide client app uses.

Auth token threading

For authenticated operations, set the user's session token on the client. The SDK forwards it as Authorization: Bearer <token> on every request:

rtClient.setAuthToken(token);

// Clear on sign-out
rtClient.clearAuthToken();

// Or hand the client a refresher callback to fetch a fresh token on demand
rtClient.setAuthTokenRefresher(async () => privy.getAccessToken());

When using the React layer, mount ProtocolUserProvider from @rising-tide/ui/auth and it wires this up for you.

Server vs browser

The SDK runs in both. In the browser, it carries the app-scoped NEXT_PUBLIC_API_KEY and the active user's session token. The protocol API treats the API key as an app identifier, not a secret - never put the master key in NEXT_PUBLIC_*.