Cookies

Cookie-based authentication stores Dynamic’s JWT in a secure, HttpOnly cookie instead of returning it for your app to hold. The browser sends the cookie automatically, and your app can’t read it. The behavior is unchanged from the React SDK — what changes is where you configure it and how you read the session.

Enabling cookies

In the React SDK you set the custom hostname through the provider’s settings. In the JavaScript SDK you pass apiBaseUrl in createDynamicClient()’s coreConfig, pointing at the cookie domain you configured in the dashboard. The dashboard setup (creating the cookie domain and validating DNS) is identical.

import { createDynamicClient } from '@dynamic-labs-sdk/client';

const dynamicClient = createDynamicClient({
  coreConfig: {
    // your configured cookie-domain hostname:
    apiBaseUrl: 'https://auth.example.io/api/v0',
  },
  environmentId: 'YOUR_ENVIRONMENT_ID',
});

In React, pass dynamicClient to DynamicProvider as usual (see Basic setup) — the cookie configuration lives entirely on the client, so nothing else changes.

Accessing the token

In a cookie environment the JWT never reaches your app, so getDefaultClient().token is always null — there is no bearer token to read or attach. Instead of reading the token, let the browser send the cookie automatically rather than adding an Authorization header yourself. fetch’s credentials option defaults to same-origin, which already sends the cookie on requests to the same origin as your page. So if your authenticated endpoints are same-origin, you don’t need to set anything:

// Same-origin request — the cookie is sent automatically, no credentials option needed.
await fetch('/api/protected');

Only set credentials: 'include' when the request is cross-origin — for example, your app is on app.example.io and the cookie domain is auth.example.io. Because the Dynamic cookie is SameSite=Lax, it still only rides on same-site requests (same registrable domain), and the server must opt in with Access-Control-Allow-Credentials: true and an explicit Access-Control-Allow-Origin (never *) — the browser won’t expose the response otherwise. Prefer keeping calls same-origin; reach for include only when you genuinely cross origins.

// Cross-origin request to the cookie domain — opt in explicitly.
await fetch('https://auth.example.io/api/protected', {
  credentials: 'include',
});

Errors you now own

Situation	What to do
`token` is `null` when signed in	Expected in cookie mode — read `user` for auth state and send credentialed requests.
Requests aren’t authenticated	Confirm the request goes to the cookie domain; same-origin sends the cookie by default, cross-origin needs `credentials: 'include'` plus server CORS credentials.
Cookie never set	Re-check the dashboard cookie domain and DNS, and that `coreConfig.apiBaseUrl` matches that hostname.

Installation & Configuration

Chains & Networks

Authenticate

User & Session Management

Wallets

Flow

Swaps

Funding & Onramp

Events

Building UI

Migrating from React

Enabling cookies

Accessing the token

Errors you now own

See also

​Enabling cookies

​Accessing the token

​Errors you now own

​See also

Enabling cookies

Accessing the token

Errors you now own

See also