> For the complete documentation index, see [llms.txt](https://canopy-network.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://canopy-network.gitbook.io/docs/build/rpc-reference.md).

# RPC Reference

The complete HTTP RPC reference for Canopy is maintained in the repository alongside the source code, so it stays current as endpoints are added or updated.

The complete Canopy HTTP RPC specification is maintained in the repository alongside the implementation:

[View the official RPC Reference on GitHub](https://github.com/canopy-network/canopy/blob/main/cmd/rpc/README.md)

Use that reference for the current routes, HTTP methods, request fields, response schemas, and examples. It is the source of truth for application and infrastructure integrations.

This page explains which RPC surface to use, how an application should interact with a Canopy node, and the security boundaries that must remain in place.

### Choose the right RPC surface

Canopy provides separate interfaces for public application access, node administration, and Ethereum-compatible tooling.

| **Surface**  | **Use it for**                                                                                      | **Keep in mind**                                                |
| ------------ | --------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Public RPC   | Reading chain data and submitting signed transactions.                                              | This is the normal integration surface for applications.        |
| Admin RPC    | Local keystore operations, node configuration, diagnostics, logs, and operator transaction helpers. | Keep it private to the node host.                               |
| Ethereum RPC | Supported integrations with Ethereum-compatible wallets, exchanges, and indexers.                   | This is an interoperability surface, not a Canopy Template API. |

Your node configuration defines the RPC URLs and ports for each environment. Do not hard-code a local development URL into a deployed application.

### Public RPC for application development

Application clients should use the public RPC to read chain data and submit already signed transactions. The official reference documents the available queries for accounts, blocks, transactions, events, parameters, supply, validators, and other protocol data.

A typical application flow is straightforward:

1. Read the state or protocol parameters needed to prepare an action.
2. Construct a transaction that matches the application’s supported message schema.
3. Sign the transaction in a user-controlled signing environment.
4. Submit the signed transaction to the public RPC.
5. Wait for inclusion, then confirm the resulting transaction status and application state.

A returned transaction hash identifies a submission. It does not by itself prove that the transaction finalized successfully or that its application logic completed. Applications should query the transaction result and resulting state before presenting an action as complete.

For reproducible reads, use a specific chain height where the RPC route supports one. Reading the latest state is appropriate for an interactive interface. Pinning a height is better when producing a report, validating a multi-step workflow, or comparing related values.

### Admin RPC is for node operators

The admin RPC provides powerful local capabilities, including keystore access, transaction helpers, configuration, peer information, consensus diagnostics, and logs.

It is not a browser-facing application backend. Never expose it through a public firewall rule, reverse proxy, or frontend configuration.

A production application should never send a private key, keystore password, or seed material to its own backend in order to use an admin signing helper. Users should sign in a wallet or another controlled environment, then submit only the signed transaction through the public RPC.

### Application-specific endpoints

The built-in RPC exposes Canopy protocol and node data. Your application may also need its own read interface, such as retrieving a post by ID, listing recent posts, or returning an application-specific view of state.

Define those endpoints explicitly in your Canopy Template. Keep each endpoint narrow, validated, and stable. Avoid treating internal state keys or raw state exports as a public application API.

Every custom endpoint should have an end-to-end test. That test should start a local node, execute the relevant application action, query the endpoint, and verify the response shape and values.

### Ethereum-compatible access

Canopy exposes an Ethereum-compatible RPC surface for supported ecosystem tooling. Use it when integrating a compatible wallet, exchange, or indexer.

Review the current compatibility notes in the repository before relying on a particular Ethereum RPC method. Compatibility should be treated as an explicit integration requirement, not assumed from the existence of the endpoint.

### Keep integrations resilient

Treat the GitHub RPC reference as a versioned contract. When upgrading Canopy, review the relevant release and revalidate every endpoint your application depends on.

Keep RPC URLs configurable by environment. Keep operator credentials and admin access out of the application client. Treat transaction submission as asynchronous, and handle inclusion, execution failure, and timeouts as distinct outcomes.

For local testing and transaction lifecycle guidance, see [Run, Test, and Configure](https://canopy-network.gitbook.io/docs/app-builder/run-test-and-configure).

Next, learn how a Canopy Template exchanges transactions, state, and custom RPC behavior with the node in the [Canopy Template Runtime Reference](https://canopy-network.gitbook.io/docs/app-builder/plugin-api-reference).