Interface NodeClientConfig

Store API key. When set, the client logs in with it automatically (POST /v1/auth/login/api-key), the same login as client.auth.loginWithApiKey():

• before its first authenticated request, when no token is stored (construction itself sends nothing; concurrent first requests share one login)
• again when a token refresh fails, retrying the request once

A client that already holds a token (from storage, or an explicit login) does not log in. A refused key rejects the request with an AuthError carrying the API's message, and onAuthExpired fires once per failed login.

On a client created with apiKey, clearing the stored tokens doesn't drop the credentials: the next request logs in again. To stop for good, create a client without apiKey. Don't mix another login (email, Google, merchant) on an apiKey client: if that session's refresh fails, the client falls back to the store key.

To read the key's store_id, call client.auth.loginWithApiKey() once yourself; the client then holds a token and doesn't log in again.

Omit when using merchant email/password or buyer auth.

Secret paired with apiKey, sent with the automatic login. When combined with apiKey, grants full (read/write) store permission. When omitted, apiKey alone grants view (read-only) store permission.

Override the API base URL. Defaults to https://api.ledewire.com.

Called when the session fully expires and cannot be refreshed. Handle this by prompting the user to re-authenticate. With apiKey set, the client logs in again with the key instead, and this fires only when an automatic login fails (once per failed attempt).

Called after a successful background token refresh, in addition to storage.setTokens.

Scope: fires only on background token refresh — not on initial login or signup. storage.setTokens fires on both. If you need to persist tokens on every auth event, the storage adapter is the correct hook.

Use onTokenRefreshed only for side-effects that should run specifically when the SDK auto-refreshes a token in the background, e.g. audit logging, cache invalidation, or notifying a secondary system. If you are using a storage adapter, storage.setTokens is already the correct persistence hook — providing both will result in double-writes on every refresh.

Custom token storage implementation. Defaults to MemoryTokenStorage (in-memory).

Serverless / edge warning: MemoryTokenStorage resets on every cold start. Tokens are lost between function invocations, causing a login loop. Always provide a persistent adapter (Redis, database, encrypted httpOnly cookie) when deploying to serverless or edge runtimes.

setTokens is called both on initial login and after every background token refresh — it is the canonical hook for persisting updated credentials.

storage: {
  getTokens: async () => JSON.parse(await redis.get('tokens')),
  setTokens: async (t) => redis.set('tokens', JSON.stringify(t)),
  clearTokens: async () => redis.del('tokens'),
}
Copy