Who is this for? Web developers and TypeScript developers looking to build web3 applications and integrate blockchain features seamlessly.
Packages
Install only what you need:| Package | Purpose | Install |
|---|---|---|
@imtbl/auth | Authentication & sessions | npm i @imtbl/auth |
@imtbl/wallet | Embedded wallets & transactions | npm i @imtbl/wallet |
@imtbl/auth-next-server | Next.js server-side auth (Auth.js v5) | npm i @imtbl/auth-next-server |
@imtbl/auth-next-client | Next.js client-side hooks & components | npm i @imtbl/auth-next-client |
@imtbl/orderbook | NFT trading | npm i @imtbl/orderbook |
@imtbl/blockchain-data | On-chain data queries (Indexer) | npm i @imtbl/blockchain-data |
@imtbl/minting-backend | Server-side minting | npm i @imtbl/minting-backend |
@imtbl/contracts | Smart contract ABIs & types | npm i @imtbl/contracts |
@imtbl/webhook | Webhook signature validation | npm i @imtbl/webhook |
@imtbl/config | Environment configuration | npm i @imtbl/config |
Install individual packages instead of
@imtbl/sdk for smaller bundles and better tree-shaking.Installation
- npm
- yarn
- pnpm
Framework Setup
- Next.js (App Router)
- Vite
- wagmi Integration
Use For login, logout, session management, and wallet operations using the client hooks, see the Next.js tabs on the Authentication and Wallet pages.
@imtbl/auth-next-server and @imtbl/auth-next-client for full Next.js integration with server-side session management, automatic token refresh, and route protection.These packages require Next.js 14+ with the App Router. For Pages Router or other React frameworks, use
@imtbl/auth directly.Prerequisites
- Client ID from your Passport client in Hub
- Next.js 14 or 15 with App Router
- An
AUTH_SECRETenvironment variable (any random string, minimum 32 characters)
Installation
Setup
Create auth configuration
Create your auth configuration:Create the API route handler:Wrap your app with Set environment variables:
SessionProvider:Next.js Configuration
createAuthConfig
Creates an Auth.js v5 configuration object for Immutable authentication.
| Option | Type | Required | Default |
|---|---|---|---|
clientId | string | Yes (when config provided) | Sandbox client ID |
redirectUri | string | Yes (when config provided) | origin + '/callback' |
audience | string | No | "platform_api" |
scope | string | No | "openid profile email offline_access transact" |
authenticationDomain | string | No | "https://auth.immutable.com" |
createAuthConfig() uses sandbox defaults for quick prototyping.
Extending the configuration
You can spread the base config and add any Auth.js options. This is the pattern used in the Passport sample app to support multiple environments:Next.js Server Utilities
Use these in Server Components and Server Actions to handle authentication on the server.getAuthProps
Pass authentication state to a Client Component when data fetching happens client-side.
getAuthenticatedData
Fetch data server-side for faster initial loads, with automatic client-side fallback when the token is expired.
createProtectedFetchers
Define auth error handling once and reuse it across all protected pages.
getValidSession
Get fine-grained control over different authentication states.
Next.js Route Protection
Middleware
Protect entire sections of your app at the routing level before pages render. Use middleware when you have groups of pages that all require authentication (such as/dashboard/* or /settings/*) and you want to redirect unauthenticated users before any page code runs.
Do not use middleware for pages that show different content for authenticated vs unauthenticated users, or for public pages with optional authenticated features. Use page-level checks with
getAuthProps or getValidSession instead.| Option | Type | Description |
|---|---|---|
loginUrl | string | Redirect target for unauthenticated users (default: "/login") |
protectedPaths | (string | RegExp)[] | Paths that require authentication |
publicPaths | (string | RegExp)[] | Paths that skip authentication (takes precedence) |
Protected API Routes
UsewithAuth to protect individual Route Handlers or Server Actions.
Inside
withAuth handlers, the session object includes accessToken directly since these run server-side. This is different from the client-side useImmutableSession hook where you must use getAccessToken().Next.js Session Type Reference
The server-side session (available inwithAuth handlers and getAuthenticatedData fetchers) includes the following fields:
| Field | Type | Description |
|---|---|---|
user.sub | string | Immutable user ID |
user.email | string? | User’s email address |
user.nickname | string? | User’s display name |
accessToken | string | Current access token (server-side only) |
refreshToken | string? | Refresh token |
accessTokenExpires | number | Token expiry timestamp (ms) |
zkEvm.ethAddress | string? | zkEVM wallet address |
zkEvm.userAdminAddress | string? | Admin wallet address |
error | string? | "TokenExpired" or "RefreshTokenError" |
The
idToken is not stored in the session cookie to stay within CDN header size limits. On the client, @imtbl/auth-next-client persists it in localStorage so wallet operations can access it via getUser().Next.js Exported Utilities
The server package exports low-level utilities for manual token handling:| Utility | Description |
|---|---|
isTokenExpired(expiresAt) | Check if an access token has expired |
refreshAccessToken(token) | Manually refresh tokens using a refresh token |
extractZkEvmFromIdToken(idToken) | Extract zkEVM claims (ethAddress, userAdminAddress) from an ID token |
Environment Configuration
| Environment | Chain | API Base |
|---|---|---|
SANDBOX | Immutable Testnet | api.sandbox.immutable.com |
PRODUCTION | Immutable Mainnet | api.immutable.com |
Next Steps
Getting Started
Configure Your Project
Set up credentials and OAuth client in Immutable Hub
Authentication
Initialize Passport and implement login
Wallet Operations
Access wallet addresses and balances
Minting API
Server-side minting for NFTs at scale