Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tallyforagents.com/llms.txt

Use this file to discover all available pages before exploring further.

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

ResourceDescription
WalletsPrivy server wallets that hold USDC. See Wallets.
AgentsThe identities you attach to spending and analytics. See Agents.
API keysAuthenticate your server to Tally. Mode-specific.
MembersThe users authorized on the account, each with a role.
WebhooksEndpoints subscribed to events from this account.
TransactionsEvery payment, attributed to an agent + wallet.

​
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:
RoleWhat it can do
ownerFull access. Manage members, billing, API keys, wallets, agents, grants.
adminSame as owner except can’t transfer ownership or close the account.
developerCreate and manage API keys, agents, webhooks. Can’t add members or change billing.
viewerRead-only access. Useful for finance or compliance reviewers.
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: 
tly_test_…   ← test mode
tly_live_…   ← live mode
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.