Creating a Team
Open the team menu
Click your account name in the top-left of the Dashboard and select Create Team.
Inviting Members
Go to Members
Navigate to Dashboard > Members
Roles
Each team member is assigned one of three roles that control what they can do in the dashboard. Roles govern dashboard and management access. All team members, regardless of role, can use the team’s API keys to call models, deploy apps, and run workloads.| Role | What they can do |
|---|---|
| Admin | Full team management: create and delete API keys, view billing and invoices, invite members, and change roles. |
| Developer | Standard access to team resources. Cannot manage API keys, billing, members, or roles. |
| Billing | View and manage billing: invoices, payment methods, credit purchases, and usage. Can also view API keys. Cannot invite members or change roles. |
API Keys and Request Attribution
Roles and key scopes are independent concepts. Roles control what a person can do in the dashboard (manage keys, billing, members). Key scopes control what the key itself can do programmatically (call models, deploy apps). A Developer-role member cannot create keys in the dashboard, but they can use the team’s ADMIN-scoped key to runfal deploy.
API keys are scoped to the team, not to individual members. Any team member can use a team API key, but only Admins can create or delete them. When creating a key, make sure you have the correct team selected in the top-left of the dashboard. See Get Your API Key for the available scopes.
How you authenticate affects how requests are attributed and what you see in the dashboard. When you use fal auth login and select a team, each request carries your individual identity within the team. This means the dashboard shows which team member made each request. When you use a team API key directly, requests are attributed to the team as a whole rather than to a specific member. Both methods access the same team resources and billing, but login-based authentication provides better per-user visibility in the dashboard and request history.
The fal client SDKs (fal_client in Python, @fal-ai/client in JavaScript) support both methods automatically. The SDK checks for credentials in this order:
FAL_KEYenvironment variable (sendsAuthorization: Key ...)- Tokens saved by
fal auth login(sendsAuthorization: Bearer ...)
~/.fal/auth0_token, so they persist across terminal sessions and reboots. You run fal auth login once, and any Python script on the same machine picks up the credentials automatically, even from a completely different process or terminal. This works the same way as gcloud auth login or aws sso login.
FAL_KEY is set, it takes priority over login tokens. To force login-based auth even when FAL_KEY is present, set FAL_FORCE_AUTH_BY_USER=1.
For production apps and CI pipelines, API keys are recommended because they don’t expire and don’t require interactive login. For development, testing, and any workflow where per-user attribution matters, fal auth login is preferred.