accounts_transactions

Overview

Returns committed transactions where the account is the sender. This is the canonical REST endpoint for building account activity feeds, transaction history pages, reconciliation jobs, and "recent actions" views keyed to one Aptos address.

Operational note: On Dwellir shared Aptos fullnodes, this route depends on indexer-backed history readers. If the node reports Indexer reader is None or another internal_error, switch to GraphQL for indexed account history.

Endpoint

GET /v1/accounts/{address}/transactions

Use this endpoint when you want all transactions submitted by one account and you do not need cross-account joins. If you need a specific transaction by hash, use transactions_by_hash. If you need indexed analytics or richer joins, use GraphQL.

Response Shape

Each item in the response is a committed transaction object. For user_transaction entries, the most commonly-used fields are:

[
  {
    "version": "238497201",
    "hash": "0x5bb5d8f4...",
    "type": "user_transaction",
    "sender": "0x1",
    "sequence_number": "352",
    "max_gas_amount": "2000",
    "gas_used": "8",
    "success": true,
    "vm_status": "Executed successfully",
    "timestamp": "1736443872382624"
  }
]

For account history pages, version, hash, sequence_number, success, and timestamp are usually enough to render a first-pass list. Pull the full transaction by hash only when the user opens a detail view.

Code Examples

# Get the latest 25 transactions for an account
curl -X GET "https://api-aptos-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/transactions?limit=25" \
  -H "Accept: application/json"

# Paginate from a specific sequence number
curl -X GET "https://api-aptos-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/transactions?start=100&limit=50" \
  -H "Accept: application/json"

Pagination Guide

This endpoint paginates by sequence number using start and limit:

1. First page: Omit start to begin at the account's earliest committed transactions.
2. Next page: Use last_sequence_number + 1 as the next start value.
3. End detection: An empty array or a short page means you have reached the end of the account's committed sender history.

Sequence numbers are per-sender and increment by 1 for every committed transaction from that account.

Practical Guidance

• This endpoint is sender-scoped. It does not show incoming transfers or third-party activity that merely touched the account.
• For first-pass account history, render version, hash, sequence_number, success, and timestamp, then fetch a single transaction detail only when the user drills in.
• For richer joins or cross-account analytics, use Aptos GraphQL instead of repeatedly walking sender histories.

Sequence Number Gaps: If the account has failed transactions (which still consume gas and increment the sequence number), they appear in the results with success: false. Account for these when building activity feeds.

Limit Selection: Use limit=100 for bulk retrieval to minimize API calls. Use smaller limits (10-25) for UI pagination where you display a few items per page.

Caching Strategy: Older transactions are immutable. Cache pages of historical transactions permanently and only re-fetch the latest page to check for new transactions.

Address Normalization: Ensure addresses are fully expanded to 66 characters (0x + 64 hex digits) with leading zeros. Short-form addresses like 0x1 are accepted but normalizing avoids inconsistencies.

Performance Considerations

Query response time scales with the limit parameter. Fetching 25 transactions typically completes in 50-100ms, while 100 transactions may take 100-200ms depending on transaction complexity and payload sizes.

Accounts with thousands of transactions can be paginated efficiently because sequence numbers provide a natural index. The database uses the (address, sequence_number) pair as a primary key, making lookups O(1) for any page.

For accounts with high transaction volume, consider storing the last-seen sequence number in your application and only fetching new transactions since that point.

Related Endpoints

• /v1/accounts/{address} - Get account info including current sequence number
• /v1/accounts/{address}/resources - Get account resources (balances, state)
• /v1/accounts/{address}/events/{creation_number} - Get events for an account
• /v1/transactions/by_hash/{hash} - Look up a specific transaction by hash

What to Watch For

• This endpoint is sender-scoped. Incoming transfers are not guaranteed to appear unless the queried account actually submitted the transaction.
• Results are committed ledger history, so this is the right source for confirmed account activity rather than pending transaction tracking.
• Keep limit small while developing. System accounts such as 0x1 can return large histories quickly.
• Use the cursor fields your client already stores for pagination instead of re-reading from the beginning on every sync.
• Treat GraphQL as the fallback for bulk history jobs if the shared node's indexer-backed reader is unavailable.

Practical Patterns

Activity Feed

Use limit plus your last stored cursor to incrementally extend an account history view without re-fetching older pages.

Retry and Reconciliation

If your application stores transaction hashes after submission, compare the stored sender and sequence number against this endpoint to verify that account history is complete.

Compliance and Auditing

Because the response is committed ledger data, it is suitable for downstream audit logs and reconciliation jobs that should not include mempool noise.

Related Endpoints

• transactions_by_hash for one known transaction
• blocks_by_height for block-scoped reads
• GraphQL Overview for indexed history and analytics