Deploy

Host your frontend using your framework and hosting provider’s instructions. Apply the following 01.software settings to every path in Build Options. The environment variable examples below are for Next.js; other runtimes use their own conventions.

Common deployment handoff

1. Configure deployment credentials

Use the Publishable Key for the environment your deployed app should access. Only privileged server operations need a separate production Secret Key. Browser-only workloads and public catalog calls do not need one; the Community Forum starter uses a Publishable Key and customer JWTs without an app-side Secret Key.

Do not copy your local .env.local into the host. Issue a production key in Console when needed and store its one-time reveal in the host’s server-only secret settings. If lost, issue a replacement.

Never put secrets in NEXT_PUBLIC_, VITE_, or REACT_APP_ variables, browser code, command arguments, URLs, or commits. Keeping a secret out of a public env prefix does not prevent your own code from exposing it in responses or logs. A Human CLI pat01_ is not an application credential. See Authentication.

For a first deployment, configure the host now and deploy in step 4. For rotation of an existing deployment, issue a replacement, update the host, deploy or restart, and verify calls with the replacement before revoking the old key.

2. Allow browser origins, if your app calls from the browser

In the workspace record in Console, add the deployed origin under Browser API origins:

https://your-app.example.com

Exact origins and one level of wildcard subdomain are accepted:

https://example.com          exact
https://*.example.com        one level of subdomain
http://localhost:3000        local development

Include preview origins too. An empty allowlist blocks every browser call. A successful server call without a browser Origin does not check this setting. Integrations & Keys covers origin configuration.

3. Register hosted customer OAuth settings, if used

Check your app’s authentication configuration. Hosted customer OAuth requires separate entries on its customer-oauth-clients record:

• allowedOrigins: at least one exact normalized browser Origin, checked on token and refresh requests that carry Origin. Server or non-browser requests without that header are allowed.
• allowedRedirectUris: at least one exact callback URI.
• allowedLogoutUris: every post-logout URI your app uses.

These lists do not replace each other or the workspace API origin allowlist. The authorize page checks redirect URI and scope, rather than allowedOrigins. Unregistered callback URIs are rejected:

redirect_uri is not registered for this client

Use your app’s actual paths. For the Next.js customer OAuth example:

allowedOrigins: https://your-app.example.com
allowedRedirectUris: https://your-app.example.com/api/auth/customer/callback
allowedLogoutUris: https://your-app.example.com/account
allowedLogoutUris: https://your-app.example.com/

OAuth entries must use normalized HTTPS URLs without wildcards or loopback hosts, including localhost. Register each preview origin, callback, and logout URI separately. Social-provider and authentication details belong in Authentication.

For new customer integrations, use the hosted OAuth/PKCE flow. Keep the one-use state and PKCE verifier in a trusted server session; validate the expected state on callback and exchange the code using that verifier. Store access and refresh tokens in an HttpOnly cookie or server session with SDK persistence disabled (persist: false), outside browser-readable storage, URLs and logs. Read the customer's identity with me(); the SDK does not validate an ID token for you.

Apps using direct login, including the Community Forum starter, use legacy compatibility. The Community Forum starter’s logout only clears the app’s HttpOnly session cookie; it does not call SDK logout or revoke tokens on the server. If your app calls direct logoutAsync(), it revokes only the publishable-key workspace's legacy-direct refresh family; it does not immediately revoke issued access JWTs. It clears the local pair even when the server fails and reports that failure. Synchronous logout() only clears local state. Neither replaces hosted logout.

4. Deploy and check each applicable path

Deploy using your framework and host’s process. Vercel is one option for Next.js, not a requirement. Supply only the public values and server-only secrets the app needs.

The Quickstart page explicitly renders dynamically: its catalog call runs on each page request, not during next build. Configure NEXT_PUBLIC_SOFTWARE_PUBLISHABLE_KEY when building the Next.js app and rebuild after changing it; a successful build alone does not verify that key or API access.

• Open the deployed page and confirm an actual API result, including a successful empty result where applicable.
• If server operations need a Secret Key, confirm those operations work with the deployed key. A public product count alone does not exercise it.
• If the app calls from a browser, check a real browser request or use the origin probe below. A server-rendered page alone does not check browser access.
• For hosted customer sign-in, check the registered client/origin/redirect, callback state and PKCE rejection, HttpOnly session, and me() readback. Check refresh rotation and replay rejection, then hosted logout: it revokes the refresh family and sweeps active access-token IDs and refresh families from before the logout fence. Server recovery of an interrupted logout preserves families issued after that intent's fence; a new logout request from the app creates a new fence and sweeps again. Clear the app cookie and cache separately; a failed server logout is not confirmed revocation. Token and identity responses must be no-store. If your app calls direct logoutAsync(), test legacy refresh-family revocation separately. For the Community Forum starter, check cookie removal separately; it is not server token revocation.
• Inspect browser-delivered build output for secrets. A working page does not prove that secrets stayed private.

These checks do not establish Launch Readiness by themselves.

Troubleshoot browser access

An origin rejection returns 403 with origin_not_allowed, but without Access-Control-Allow-Origin the browser hides the response from JavaScript and shows a generic CORS error. A normal keyless preflight can return 200 with Access-Control-Allow-Origin: * even when the subsequent request is blocked.

This diagnostic probe includes a Publishable Key to check the selected workspace’s origin allowlist; it is not a normal browser preflight:

curl -i -X OPTIONS https://api.01.software/api/products \
  -H "X-Publishable-Key: pk01_..." \
  -H "Origin: https://your-app.example.com" \
  -H "Access-Control-Request-Method: GET"

If a key was exposed, remove the exposure and rotate it. See Authentication for credential handling.

Continue with Integrations & Keys, Authentication, and Launch Readiness.