Credentials by operation
The builder key uses
x-builder-api-key. A wallet access token uses Authorization: Bearer <accessToken>. When both are required, send both headers; they serve different purposes.
Wallet access tokens are issued after wallet verification. When requesting a challenge, send both redeem:read and redeem:write in scopes. The access token authorizes private Redeem operations for that wallet and builder.
Keep the builder key on your backend
For browser integrations, send SDK requests through a backend route such as/api/renaiss. The backend forwards to your assigned API and adds its builder key only to routes that accept one. Send public marketplace reads without credentials.
Authenticate requests with your own user session, authorize the requested operation and apply rate limits. Allow only the required upstream routes and methods. Set the upstream key yourself rather than forwarding a client-supplied key. Forward the wallet access token when required and preserve streaming responses for gacha pulls.
Do not put builder keys in NEXT_PUBLIC_* variables or return them to the browser. Exclude bearer tokens, refresh tokens, signatures and shipping details from routine application logs.
Choose the acting wallet
For Gacha and Marketplace HTTP requests, an EOA signs directly. A deployed contract account must validate the action signature through ERC-1271. Use the contract account’s address as the buyer or seller. Its signature validation must bind the account address to the signed intent. For Gacha it must also accept ERC-721 safe transfers. Check that it can receive the card before paying. The builder API excludes Renaiss-managed Safes and EIP-7702 delegated accounts from these flows. Wallet sessions and Redeem require an EOA. The published TypeScript beta uses an EOA signer.Verify a wallet for shipping
Request verification when the user opens private shipping data or starts Redeem. Wallet connection alone does not create this session. The user signs a message allowing shipping access; checkout later requires a separate action signature.signOutRedemptionWallet() and clear private UI state.
Frontend origin and API issuer
Register the exact frontend scheme, host and port for your builder. An origin has no path or trailing slash. Local HTTP loopback origins must be registered explicitly;
http://localhost:3311 and http://127.0.0.1:3311 are separate origins.
Configure the issuer from your deployment details. With a relative proxy it is required; with an absolute API URL the SDK defaults to that origin plus /v2/auth/wallet. An alias may still have a different canonical issuer. Never take the expected issuer from an unvalidated signing challenge.
Session timing
An expired or cancelled signature prompt leaves the wallet unverified. Retry after the user’s next verification action. The signed message explains the permission and session duration; it does not authorize a transaction.
For an HTTP integration, follow the session in order.
- Get a sign-in message. Check the wallet, chain, origin, issuer, audience, scopes and expiry before prompting the user. The SDK performs these checks for you.
- Sign the message byte for byte and verify the signature to obtain the token pair.
- Refresh the session with its current refresh token. On sign-out, revoke the session.