Account Modules — Move REST API on Movement

Overview

The account modules endpoint lists all Move modules published under a specific on-chain account. Each module in the response includes its compiled bytecode and ABI (Application Binary Interface), which describes the module's structs, functions, and type parameters. This endpoint is essential for module discovery, ABI extraction, contract verification, and building developer tooling on Movement.

Movement uses the Aptos-compatible REST API format. If you have existing Aptos tooling, it works with Movement by changing the base URL to the Dwellir Movement endpoint.

Operational note: On Dwellir shared Movement mainnet, account module listing depends on indexer-backed storage helpers. If the indexer reader is unavailable, this route can return internal_error instead of a module array.

Endpoint

GET /v1/accounts/{address}/modules

Base URL: https://api-movement-mainnet.n.dwellir.com/YOUR_API_KEY/v1

Code Examples

Basic Module Listing

# List all modules under the 0x1 framework account
curl -s "https://api-movement-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/modules" \
  -H "Accept: application/json" | jq '.[].abi.name'

Paginated Module Retrieval

# Fetch first page (5 modules)
curl -s "https://api-movement-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/modules?limit=5" \
  -H "Accept: application/json" | jq '.[].abi.name'

# Fetch the next page using the opaque cursor returned by your previous page
curl -s "https://api-movement-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/modules?limit=5&start=OPAQUE_CURSOR" \
  -H "Accept: application/json" | jq '.[].abi.name'

Extracting ABI for a Specific Module

# Get a specific module by name (use the single-module endpoint)
curl -s "https://api-movement-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/module/coin" \
  -H "Accept: application/json" | jq '.abi.exposed_functions[] | {name, is_entry, is_view, params, return}'

Common Use Cases

Module Discovery

Enumerate all modules deployed by a protocol to understand its on-chain footprint. This is useful for auditors, indexers, and block explorers that need to catalog deployed contracts.

ABI Extraction for Frontend Integration

Extract function signatures and parameter types to auto-generate TypeScript types or form-based UIs for interacting with Move modules. The ABI's exposed_functions array provides everything needed to build transaction payloads.

Bytecode Verification

Compare on-chain bytecode against locally compiled bytecode to verify that a deployed module matches its published source code. This is a critical step in smart contract auditing.

Historical State Analysis

Use the ledger_version parameter to query module state at specific historical points. This is useful for debugging deployments or tracking module upgrades over time.

Movement-Specific Notes

• Module names on Movement follow the same conventions as Aptos: lowercase with underscores (e.g., coin, managed_coin, aptos_coin).
• The framework modules at 0x1 include the standard library, coin operations, and governance. These are the same as Aptos framework modules with Movement-specific extensions.
• Module bytecode can be large. When listing modules for accounts with many deployments, use pagination (limit and start) to avoid timeout issues.

Related Endpoints

• GET /v1/accounts/{address} -- Get basic account info including sequence number.
• GET /v1/accounts/{address}/module/{module_name} -- Get a single module by name.
• GET /v1/accounts/{address}/resources -- List resources stored under an account.
• POST /v1/view -- Execute view functions from modules without a transaction.