canonical: https://jentic.com/apis/apidapp.com/apidapp-apidapp

# ApiDapp

Jentic publishes the only available OpenAPI specification for ApiDapp, keeping it validated and agent-ready. ApiDapp is a REST gateway for Ethereum that lets clients read accounts, blocks, blockchains, contracts, ERC-20 tokens, transactions, and wallets without running a full node or speaking JSON-RPC. The API exposes 30 operations across 26 paths so a developer can list block transactions, read an ERC-20 balance, deploy or call a contract, and manage an embedded wallet through plain HTTP. It targets dapp builders who want a hosted Ethereum read/write surface and prefer REST over the standard web3 RPC interface.

## For AI agents

Read Ethereum accounts, blocks, transactions, ERC-20 balances, and contracts over REST without running a node or speaking JSON-RPC.

## Scope

Does not handle private key custody for user wallets, cross-chain bridging, or non-Ethereum networks - use for Ethereum read and write operations over REST only.

## Capabilities

- Fetch account balances and transaction history for any Ethereum address over REST
- Read block headers and the transactions inside a block by index or hash
- Read and write ERC-20 token balances and transfers without crafting raw RPC calls
- Call read-only contract methods and submit signed transactions via HTTP
- Manage server-side wallets including key generation and signing
- Inspect blockchain metadata such as the current chain, version, and node status

## Use cases

### Wallet Balance Display

Show the ETH and ERC-20 holdings for a user-supplied address inside an app without running an Ethereum node. ApiDapp's `/account/{id}` endpoint returns the ETH balance and /erc20 endpoints return token balances for the same address. This pattern is common for portfolio trackers and wallet UIs that want to onboard in hours rather than provisioning Geth or paying for an RPC subscription up front.

Example prompt: GET `/account/0xAbC123...` to read the ETH balance and then GET `/erc20/{contract}/balance/0xAbC123...` for the USDC balance

### Block and Transaction Indexing

Walk the chain block by block to build a custom index of transactions, contract calls, or token transfers. ApiDapp's `/block/{id}` endpoint returns block content and `/block/{id}/transaction` lists the transactions inside that block, so a small worker can ingest data without parsing raw RLP or running a full archive node.

Example prompt: GET `/block/18000000/transaction` to list the transactions in block 18000000 and store the from/to/value tuple for each

### Smart Contract Interaction

Call read-only functions on a deployed Ethereum contract or submit a signed transaction without writing web3.js or ethers boilerplate. ApiDapp's /contract endpoints accept the contract address and method name and return the decoded result. For state-changing calls, the API accepts a signed transaction so private keys can stay in a hardware wallet or signer service.

Example prompt: POST to `/contract/{address}` with the method name 'balanceOf' and an address argument to read the holding without sending a transaction

### AI Agent On-Chain Queries

Give an AI agent a tool to answer on-chain questions like 'what's the ETH balance of vitalik.eth?' or 'is this transaction confirmed?'. Through Jentic, the agent searches for an intent and gets the matching ApiDapp operation. The agent can answer without the developer wiring a JSON-RPC client or running a node.

Example prompt: Search Jentic for 'get ethereum account balance', load the `/account/{id}` schema, and execute with id=0xAbC... to return the current ETH balance

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/account/{id}` | Fetch ETH balance and metadata for an address |
| GET | `/block/{id}` | Read a block by number or hash |
| GET | `/block/{id}/transaction` | List transactions inside a block |
| GET | `/contract` | List or look up deployed contracts known to ApiDapp |
| GET | `/blockchain` | Read chain metadata and latest state |
| GET | `/wallet` | List server-side wallets |

## Key resources

- **Account** — Read account balances and metadata for an Ethereum address
- **Block** — Read block headers and the transactions inside a block by id
- **Blockchain** — Inspect chain metadata, latest block, and node status
- **Contract** — Read contract state and submit signed transactions to call methods
- **ERC20** — Read ERC-20 token metadata, balances, and transfer events
- **Transaction** — Look up a transaction by hash and check confirmation status
- **Wallet** — Generate, list, and manage server-side wallets
- **Key** — Manage signing keys associated with wallets

## Why Jentic

- **Setup:** Wiring ApiDapp by hand means setting up its API key, learning its Ethereum account, block, and contract resource shapes, and framing on-chain reads over REST yourself. Through Jentic you install once, import ApiDapp from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** ApiDapp puts the account and block id in the URL path (`/account/{id}`, `/block/{id}`), so a rule can pin your agent to one account or block for reads and nothing else. You choose the operations it may call, so write operations are not included unless you add them.
- **Credential handling:** Your ApiDapp key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'read an Ethereum account balance' or 'get transactions in a block', and Jentic returns the matching ApiDapp operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Alchemy API** — Production-grade Ethereum and multi-chain node infrastructure as a service
- **QuickNode API** — Hosted Ethereum and multi-chain RPC with a managed dashboard and add-on marketplace
- **Ankr API** — Decentralised RPC service across Ethereum and many other chains

## FAQ

### Why is there no official OpenAPI spec for ApiDapp?

ApiDapp does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call ApiDapp via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the ApiDapp use?

ApiDapp uses an API key passed in the X-Api-Key request header. Through Jentic, the key is stored encrypted in your Jentic One instance and injected at execution time, so the raw key never appears in the agent's prompt or logs.

### Can I read an ERC-20 balance with this API?

Yes. The /erc20 endpoints expose token metadata and balances by token contract address. For a specific holder, use the per-token balance endpoint with the contract address and the holder address - much shorter than encoding a balanceOf call into raw JSON-RPC.

### Which Ethereum networks does the ApiDapp cover?

The base URL https://ethereum.apidapp.com/1 targets Ethereum mainnet (chain id 1). Other networks are not declared in the OpenAPI spec; check the ApiDapp website for any current testnet endpoints.

### What are the rate limits for the ApiDapp?

The OpenAPI spec does not encode hard limits. Standard practice for REST gateways onto Ethereum is to throttle at the API key level and return HTTP 429 on overage, so agents calling through Jentic should retry with backoff on 429.

### How do I look up a transaction status with the ApiDapp through Jentic?

Search Jentic for 'check ethereum transaction status', load the `/transaction/{id}` schema, and execute with id set to the transaction hash. The response surfaces the confirmation count and the receipt status, so the agent can branch on whether the tx is mined.

### Can I limit what my agent is allowed to do with the ApiDapp API?

Yes. Because you run Jentic One yourself, you decide which ApiDapp operations your agent may call, so read-only calls like GET `/account/{id}` and GET `/block/{id}` can be permitted while write operations such as submitting signed transactions or creating wallets stay off unless you add them. Since the account and block id sit in the URL path, your own rules can pin the agent to a single account or block and nothing else. Your stored ApiDapp key is injected only at execution time, so the agent never sees or handles the raw credential.