Skip to main content
Every Tally resource — every wallet, agent, payment, API key — lives inside an account. The account is the boundary for billing, authorization, and the test-versus-live split. If you’ve used Stripe’s account model, you’ll find Tally’s familiar.

​
Mental model

Think of an account as the unit that says “this is one developer’s (or team’s, eventually) Tally setup.” A single user can belong to multiple accounts — your personal account, plus any team accounts you’re a member of — and a single account can have multiple users with different roles. Right now most Tally accounts are single-user. The multi-member model is in the schema and exposed in the dashboard, but the product is built around the individual-developer case today; SSO and team-management polish lands later. The account is also the trust boundary between API keys. Every API key is scoped to one account and one mode (test or live); a key from account A can never touch account B’s resources, even if the same person owns both.

​
What’s in an account

​
Account creation

Accounts are created automatically on first sign-in. When you sign up, Tally provisions a personal account (named after your email by default), makes you the owner, and creates a starter test-mode wallet. No setup wizard, no separate onboarding step. You can rename an account from the dashboard later. The slug — used in URLs like tallyforagents.com/<slug>/overview — is derived from the name at creation and stays stable thereafter.

​
Member roles

Multiple users can belong to one account. Each member has a role that determines what they can do: On first sign-in, you become the owner of your auto-provisioned account. Invitations to other roles are sent from the dashboard.

​
Test mode and live mode

Every account-scoped resource — wallets, agents, API keys, transactions — carries a mode: either test or live. The two are fully partitioned:
  • Test mode runs on Base Sepolia with testnet USDC. Nothing costs real money. Default for new accounts.
  • Live mode runs on Base mainnet with real USDC. Gated behind an explicit opt-in once your account is approved for production.
Resources don’t cross modes. A test-mode API key can’t see live-mode wallets, a test-mode agent doesn’t appear in live-mode lists, and a live-mode payment can’t be sent from a test-mode wallet. Mistakes in one mode are isolated from the other — that’s the whole point. API keys carry their mode in the prefix:
If you mix them up, the SDK rejects the key before making a single request — Tally’s not going to let you accidentally fire test-mode logic at a live-mode key.

​
Intended use

When an account is created, it’s labeled as one of:
  • individual — solo developers, hobby projects, internal tools.
  • business — products that will eventually serve end users with their own funds.
This label drives a few downstream defaults (compliance prompts, what shows up on the dashboard) but does not currently restrict feature access. The intended use can be changed from the dashboard if a project graduates from individual to business scope.

​
Where account ID shows up

You don’t usually pass an account ID directly to the SDK — your API key already scopes every request. But you’ll see the account’s slug in:
  • Dashboard URLs: tallyforagents.com/acme-corp/overview
  • Webhook payloads: every event carries the originating account ID
  • Server-side API paths: the /api/wallets, /api/agents/[id]/permissions endpoints take an account_slug body field for dashboard auth
For SDK callers, the slug is mostly informational — your API key is the source of truth for which account you’re operating in.

​
What’s on the roadmap

  • Account-level audit log — a single feed of every administrative action across members, keys, wallets, and grants.
  • SSO and SCIM for business accounts.
  • Sub-accounts — nested accounts for orgs that need finer billing or access splits than one flat list of members.