Skip to main content

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.

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

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: 
Authorization: Bearer YOUR_API_KEY

​
Optional Headers

​
Network Selection

x-squads-network: mainnet  # or devnet

​
Idempotency

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

​
Response Format

Successful responses follow standard REST conventions: 
{
  "status": "created", // For idempotent requests
  "smart_account_address": "..."
}
Error responses provide detailed information: 
{
  "error": {
    "code": "ERROR_CODE",
    "message": "Human readable message",
    "details": {
      // Additional context
    }
  }
}