The forte CLI, language SDKs, and testing against Forte locally.
On macOS and Linux, "brew tap FortePlatforms/tap && brew install forte". Anywhere with a POSIX shell (including Git Bash or WSL on Windows), "curl -fsSL https://tryforte.dev/install.sh | bash". Standalone binaries for every platform are on the GitHub releases page. Then run "forte login" — it opens a browser to authenticate.
No — creating projects, deploying services and websites, and monitoring can all be done from the web console. The CLI earns its keep for scripting, CI/CD integration, and local proxy testing with "forte proxy".
Run your service on its usual port, then start "forte proxy" in another terminal and point your client at the proxy (http://localhost:8080 by default). The proxy sends each request to Forte for authorization and forwards approved requests to your local service with the same authenticated user context it would get in production — real sessions, no mocking. It also shows a live log of recent requests with their authorization status.
TypeScript, Java, and Python. Inside a deployed service the SDK loads credentials automatically from the injected environment variables — construct the client with no arguments and start calling. In a browser, the same no-argument constructor relies on the user's session cookie instead.
Every authenticated request Forte forwards to your service carries an X-Forte-User-Id header. Read it and, when you need more than the ID, fetch the full profile with the SDK's getUser call — contact methods, verification state, and any custom attributes you've stored.
If your frontend calls the Forte API directly, the session cookie is set on Forte's domain — a third-party cookie that modern browsers block. Every service reserves the /_forte path prefix for exactly this: point the SDK's baseUrl at https://your-service-domain/_forte and the cookie is set first-party on your own domain.
Only client-side (forte.users.*) routes travel through the prefix, and those requests don't count toward your service's logs or metrics.
Use the SDK's putUserCustomAttributes to attach key-value metadata to a user — subscription tiers, feature flags, app preferences — and read it back from the user object's custom attributes. Each call replaces all attributes, so read-merge-write to update a single field. Keys are 1–64 characters (letters, numbers, underscores, hyphens) and values are strings.
By default the proxy listens on 8080 and forwards to the port from your service's health check configuration (falling back to 3000). Use -p to change where it forwards (your app's port) and --proxy-port to change where it listens. You can also skip the interactive pickers with --project-id and --service-id.
Yes. For server-side code running outside a deployed service — local development, CI scripts, an external system — pass the project API token to the client constructor, or set FORTE_API_TOKEN as an environment variable and use the no-argument constructor. The token is project-scoped, so keep it in your CI secret store.
Yes. Install the Forte plugin in Claude Code ("/plugin marketplace add forteplatforms/claude-plugin" then "/plugin install forte@forteplatforms") and Claude picks it up automatically when you ask about Forte. Prefer a one-off setup? Run the skill install script from your repository root and commit the generated .claude/skills/forte/ directory for your whole team.