> ## Documentation Index
> Fetch the complete documentation index at: https://developers.squads.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Overview of the Smart Account REST API v1

The Smart Account API v1 provides a RESTful interface for interacting with the Squads smart account program on Solana. It simplifies the construction and management of smart account operations, making it easier to work with multi-signer setups, permissions, and security policies through familiar REST patterns.

## Base URL

```bash theme={null}
https://developer-api.squads.so/api/v1
```

## Resource Structure

The API is organized around the following resource hierarchy:

```
/smart-accounts
└── /{smart_account_address}
    ├── /balances
    └── /spending-limits
        └── /{spending_limit_address}
            └── /debits
```

## Key Concepts

### Smart Accounts

A smart account is a programmable Solana account that can be controlled by multiple signers with different permissions. Each smart account has:

* A unique address
* Multiple signers with specific permissions
* A signing threshold
* Optional admin control
* Optional time lock settings
* Optional spending limits

### Security Policies

Smart accounts support multiple security policies:

1. **Thresholds**

   * Defines minimum number of approvals required (M-of-N setup)
   * Based on signers with CAN\_VOTE permission
   * Required for all transactions except spending limit debits
   * Can be modified by admin or threshold-based approval

2. **Admin Control**

   * Optional admin address for settings management
   * Admin-only configuration changes
   * Regular transactions still follow threshold rules

3. **Time Locks**

   * Configurable delay between approval and execution
   * Applies to all non-admin transactions
   * Does not affect spending limit debits

4. **Spending Limits**
   * Token-specific allowances
   * Periodic resets (daily, weekly, etc.)
   * Destination restrictions
   * Bypass threshold requirements for routine transactions

### Permissions

Signers can have the following permissions:

* `CAN_INITIATE`: Required to propose transactions
* `CAN_VOTE`: Required to approve transactions (must have enough for threshold)
* `CAN_EXECUTE`: Required to execute approved transactions

### Transaction Handling

Most mutation endpoints return partially-signed gas abstracted transactions that must be:

1. Signed by the required signers (based on threshold or admin mode)
2. Wait for time lock period if configured
3. Submitted to the Solana network

These transactions have a \~2 minute validity window due to Solana's recent blockhash mechanism.

## Authentication

All API requests require authentication using your API key in the header:

```bash theme={null}
Authorization: Bearer YOUR_API_KEY
```

### Optional Headers

#### Network Selection

```bash theme={null}
x-squads-network: mainnet  # or devnet
```

#### Idempotency

For account creation, you can prevent duplicates using an idempotency key:

```bash theme={null}
x-idempotency-key: YOUR_RANDOM_KEY
```

## Response Format

Successful responses follow standard REST conventions:

```json theme={null}
{
  "status": "created", // For idempotent requests
  "smart_account_address": "..."
}
```

Error responses provide detailed information:

```json theme={null}
{
  "error": {
    "code": "ERROR_CODE",
    "message": "Human readable message",
    "details": {
      // Additional context
    }
  }
}
```