accounts_module

Overview

Fetch a specific Move module published under an account by module name.

Endpoint

GET /v1/accounts/{address}/module/{module_name}

Request

Path Parameters

Name	Type	Required	Description
address	string	Yes	Account address
module_name	string	Yes	Module name (no address prefix)

Code Examples

Text

curl -X GET https://api-aptos-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/module/aptos_account \
  -H "Accept: application/json"

Response

Success Response (200)

Returns a Move module object containing:

JSON

{
  "bytecode": "0xa11ceb0b060000000...",
  "abi": {
    "address": "0x1",
    "name": "aptos_account",
    "friends": [],
    "exposed_functions": [...],
    "structs": [...]
  }
}

The ABI includes complete type information, function signatures, and struct definitions for the module.

Error Responses

Status	Error Code	Description
400	invalid_input	Invalid address or module name format
404	module_not_found	Module doesn't exist at this address
404	account_not_found	Account doesn't exist

Use Cases

This endpoint is essential for several blockchain development workflows:

Smart Contract Verification: Verify the bytecode and ABI of deployed modules to ensure they match expected implementations before interacting with them.
ABI Discovery: Retrieve complete type information and function signatures for integration with wallets, dapps, or SDKs without requiring the original Move source code.
Upgrade Auditing: Compare module versions across different ledger versions to track changes and validate upgrade compatibility rules.
Development Tools: IDE plugins and debugging tools use this endpoint to provide autocomplete, type checking, and inline documentation for on-chain modules.
Security Analysis: Security researchers analyze deployed module bytecode to identify potential vulnerabilities or verify formal verification properties.
Cross-Contract Integration: Before calling functions in another module, applications can inspect the ABI to ensure compatibility and understand input/output types.

Best Practices

Module Name Format: The module name parameter should not include the address prefix. Use aptos_account not 0x1::aptos_account.

Caching Strategy: Module bytecode rarely changes. Implement client-side caching with ledger version as the cache key to minimize API calls. Only refetch when you detect a module upgrade event.

ABI Type Resolution: When parsing generic types in the ABI, ensure your client handles nested generics like CoinStore<AptosCoin> correctly. Use the full type path for disambiguation.

Version Pinning: For production applications, consider querying modules at specific ledger versions rather than always using the latest state. This provides deterministic behavior even during network upgrades.

Error Handling: A 404 response could mean either the account doesn't exist or the module doesn't exist at that account. Check the error message to distinguish these cases.

Performance Considerations

Module queries are relatively lightweight operations. The response size depends on module complexity - simple modules return a few KB, while complex framework modules may return 100KB+ of bytecode and ABI data. If you only need specific information from the ABI, consider parsing it client-side and caching the relevant portions.

The REST API serves modules from the node's storage layer with minimal processing overhead. Response times are typically under 100ms for hot data.

On this page