> ## 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.

# Accounts

> The top-level container for wallets, agents, API keys, and team members.

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

| Resource         | Description                                                                 |
| ---------------- | --------------------------------------------------------------------------- |
| **Wallets**      | Privy server wallets that hold USDC. See [Wallets](/wallets).               |
| **Agents**       | The identities you attach to spending and analytics. See [Agents](/agents). |
| **API keys**     | Authenticate your server to Tally. Mode-specific.                           |
| **Members**      | The users authorized on the account, each with a role.                      |
| **Webhooks**     | Endpoints subscribed to events from this account.                           |
| **Transactions** | Every 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:

| Role        | What it can do                                                                     |
| ----------- | ---------------------------------------------------------------------------------- |
| `owner`     | Full access. Manage members, billing, API keys, wallets, agents, grants.           |
| `admin`     | Same as owner except can't transfer ownership or close the account.                |
| `developer` | Create and manage API keys, agents, webhooks. Can't add members or change billing. |
| `viewer`    | Read-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.