Skip to main content
A Next.js integration has two boundaries: your server reads or manages workspace resources, while a browser displays the experience. Giving the browser a workspace API key would collapse those boundaries.
Server-side resource reads can use the public API today. A live browser conversation needs a released session-initiation and client transport path; it is not established by this guide.

​
Prepare the application

1

Keep credentials on the server

Store THREETONE_API_KEY in a server environment variable. Never give it a NEXT_PUBLIC_ prefix or pass it through client component props. Keep the module that reads it server-only.
2

Authorize your own users

Before a server action or route reads private workspace data, verify the caller’s identity and resource access. Hiding an agent ID in the interface is not authorization.
3

Read only the required data

Use Get agent or List agents. Validate the response and return only fields needed by the interface. Avoid sharing private configuration through a public cache.
4

Prepare browser behavior

Provide loading, failure, and unavailable states. For a future voice experience, request microphone access only after a deliberate user action and include keyboard-accessible stop and mute controls.
Use the TypeScript REST example for authenticated resource reads. Review the web deployment checklist before adding a live experience.

​
Frequently asked questions

No first-party installable SDK is verified in this documentation release. The example uses server-side HTTP requests, not an invented package.
Route privileged workspace operations through an authorized server boundary. A future supported session transport may connect independently with appropriately scoped session access.