canonical: https://jentic.com/apis/nem.io/nem # Nem Catapult REST Endpoints The Catapult REST API is the public HTTP interface for nodes running the Symbol blockchain (the protocol born from the NEM ecosystem). It exposes 81 endpoints covering accounts, blocks, transactions, mosaics, namespaces, finalisation, and node and network metadata, so a client can query chain state, broadcast signed transactions, and watch finality progress without running its own node. The API is designed for wallets, explorers, and back-office services that need a read and submit interface to the Symbol chain. ## For AI agents Read accounts, blocks, transactions, and chain state from a Symbol blockchain node, and broadcast signed transactions to the network. ## Scope Does not handle wallet key management, transaction signing, or fiat conversion - use for Symbol blockchain node reads and signed transaction broadcast only. ## Capabilities - Look up account state, including balances and supplemental keys, by address or public key - Submit signed transactions to a Symbol node through the transactions endpoint - Query block headers, full blocks, and merkle proofs for any block height - Read mosaic and namespace records to resolve token metadata and human-readable aliases - Track chain progression and finalisation through the chain info and finalization endpoints - Inspect node identity, peers, and network properties for health monitoring ## Use cases ### Wallet Account Lookup Wallet front-ends call `/accounts/{accountId}` to render a Symbol account: balance, mosaics held, and account type. The merkle variant under `/accounts/{accountId}/merkle` returns a proof, useful for light clients that want to verify state against a block hash rather than trusting the node outright. Example prompt: Fetch the account state for address TBLOCKCHAINSAMPLEADDRESS and return the list of mosaics and balances. ### Transaction Broadcast and Confirmation Services that build and sign transactions off-node use the Catapult REST API to push them to the network. The transactions endpoints accept the signed payload, expose status lookups for unconfirmed and confirmed states, and the finalization endpoints confirm when a block is irreversible. This pattern keeps signing keys off the node host while still using the node for broadcast. Example prompt: Submit a signed transfer transaction to the Symbol testnet and poll until it is confirmed in a block. ### Block Explorer Backend Block explorers fan out reads against /blocks, `/blocks/{height}`, and the merkle endpoints to build a full chain view. Combined with `/chain/info` for current height and /node for identity, an explorer can render block, transaction, and account pages without running its own indexer for primary data. Example prompt: Get the current chain height, then fetch the block at that height and list every transaction it contains. ### AI Agent Integration via Jentic An AI agent uses Jentic to call Symbol nodes without needing a hand-coded SDK. Jentic exposes the Catapult REST operations by intent, so an agent asking to read a Symbol account or submit a transaction is routed to the correct endpoint with a typed schema, which is valuable when integrating chain reads into a wider workflow. Example prompt: Use Jentic to search for read symbol blockchain account, load the schema for `/accounts/{accountId}`, and return the balance for a given address. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/accounts/{accountId}` | Get account state by address or public key | | GET | `/accounts/{accountId}/merkle` | Get account state with merkle proof | | GET | `/blocks/{height}` | Get a block by height | | GET | `/blocks/{height}/transactions/{hash}/merkle` | Get a transaction merkle proof for a block | | GET | `/chain/info` | Get current chain height and finalisation state | ## Key resources - **Accounts** — Read account state, mosaics, and merkle proofs by address or public key - **Blocks** — Read block headers, full blocks, and transaction merkle proofs by height - **Transactions** — Submit signed transactions and query confirmation status - **Chain** — Get current chain height, score, and finalised state - **Mosaics and Namespaces** — Resolve token metadata and human-readable aliases - **Node** — Inspect node identity, peers, and network configuration ## Why Jentic - **Setup:** Wiring the Catapult REST endpoints by hand means pointing calls at the correct Symbol node host and port, reading account and block data through their merkle variants, and broadcasting only pre-signed transactions yourself. Through Jentic you install once, import the Catapult endpoints from the API Directory, and your agent calls it, with any gateway credential stored once. - **Permission scoping:** Catapult puts the account id and block height in the URL path (`/accounts/{accountId}`, `/blocks/{height}`), so a rule can pin your agent to reads for one account or block and nothing else. You choose the operations it may call, so anything beyond the reads you list is not included unless you add it. - **Credential handling:** Catapult REST is unauthenticated, so your Jentic One instance stores no node credential, and any gateway or proxy token is stored once, encrypted, and injected at execution time. No secret enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'read a Symbol account state' or 'fetch chain info', and Jentic returns the matching Catapult REST operation with its schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Neon API** — Postgres-as-a-service often used to index and store derived data from chain reads - **MongoDB Atlas** — Document store commonly used by chain explorers to cache block and account snapshots - **New Relic** — Observability platform for monitoring node health and request latency ## FAQ ### What authentication does the Catapult REST API use? Catapult REST endpoints are unauthenticated by default - a Symbol node serves public chain data and accepts pre-signed transactions. When fronting a node with a gateway that adds an API key, store that key in your Jentic One instance so it never reaches the agent context. ### Can I submit signed transactions through the Catapult REST API? Yes. Sign the transaction off-node, then PUT the signed payload to the transactions endpoint exposed by Catapult REST. The node validates and gossips it. Use the `/chain/info` and finalization endpoints to confirm inclusion and irreversibility. ### What are the rate limits for the Catapult REST API? Rate limits are not defined in the spec - they depend on which node operator is hosting the endpoint. For the public testnet at reference.symboltest.net, treat reads as moderate and avoid hammering /blocks for full chain scans; use `/chain/info` to drive incremental fetches. ### How do I read a Symbol account balance with the Catapult REST API through Jentic? Search Jentic for read symbol blockchain account, load the schema for GET `/accounts/{accountId}`, and execute with the address. The full flow is pip install jentic, search, load, execute. ### Does the API include endpoints for finalisation? Yes. The spec covers finalisation proof endpoints alongside `/chain/info`, so a client can verify when a block is irreversible rather than relying on confirmation depth heuristics. ### Can I limit what my agent is allowed to do with the Symbol blockchain API? Yes. Because you self-host Jentic One, your own rules decide which Catapult REST operations the agent may call, so you can allow account reads on GET `/accounts/{accountId}` and block reads on GET `/blocks/{height}` while withholding the transactions endpoint that broadcasts signed payloads. Since the account id and block height sit in the URL path, a rule can pin the agent to reads for a single account or block and nothing else. Any gateway or proxy token stays in your instance and is injected only for the operations you list, so anything you do not add is not available to the agent.