canonical: https://jentic.com/apis/googleapis.com/blockchainnodeengine

# Google Blockchain Node Engine API

Blockchain Node Engine is Google Cloud's managed Ethereum-compatible node service. The API provisions and manages dedicated archive and full nodes that you can query via JSON-RPC for on-chain data, transaction submission, and indexing without operating execution and consensus client pairs yourself. The API exposes blockchainNodes resources plus the surrounding long-running operations and locations metadata. It targets teams building wallets, indexers, analytics, and dApp backends that need a stable RPC endpoint with Google's reliability and IAM model.

## For AI agents

Provision and manage dedicated Ethereum nodes on Google Cloud's Blockchain Node Engine. Agents can create nodes, list operations, and inspect node endpoints.

## Scope

Does not submit transactions, broadcast blocks, or query on-chain state - use for managing dedicated blockchain node resources only.

## Capabilities

- Provision dedicated Ethereum mainnet or testnet nodes in a Google Cloud region
- List blockchainNodes under a project and location
- Get node details including the JSON-RPC endpoint and current sync state
- Update node configuration such as type and Polygon-specific settings
- Delete nodes that are no longer needed
- Cancel long-running operations that are still in progress
- List operations to monitor provisioning and update progress

## Use cases

### Dedicated dApp Backend

Provision a dedicated Ethereum node so a dApp backend has a stable JSON-RPC endpoint without sharing rate limits with other tenants. blockchainNodes are managed at /v1/{parent}/blockchainNodes and the create call returns a long-running operation under /v1/{name}/operations. Once ready, the node exposes both a JSON-RPC and a WebSocket endpoint for the application.

Example prompt: Create a fullnode of type GETH on the MAINNET network in us-central1 under project myproj, then poll the operation until done.

### Archive Node for Indexing

Run an archive node to support historical state queries that full nodes prune. blockchainNodes accept a nodeType of ARCHIVE and a network (MAINNET, GOERLI, SEPOLIA, or POLYGON_MAINNET). Archive nodes are larger and slower to provision but unlock building custom indexers and analytics over chain history.

Example prompt: Create an archive node of type GETH on POLYGON_MAINNET in us-east4 named indexer-1 under project myproj.

### Operations Monitoring

List long-running operations on a node and inspect their state to track provisioning and updates. Operations are exposed at /v1/{name}/operations and individual operations at /v1/{name} where name is the operation resource. Cancel an in-progress provisioning if requirements change before it completes.

Example prompt: List all operations under projects/myproj/locations/us-central1 and return any in state RUNNING for blockchain nodes.

### Agent-Driven Node Lifecycle

Let an AI agent take a request like 'spin up a Sepolia full node and tear it down after the test' and run the create+delete sequence through Jentic. The agent handles operation polling and reports the JSON-RPC endpoint when ready. OAuth credentials never leave your Jentic One instance.

Example prompt: From the request 'create a Sepolia testnet node, return its endpoint, and delete it after I confirm', execute create, poll until done, return the endpoint, then delete.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v1/{+parent}/blockchainNodes | Create a new blockchain node |
| GET | /v1/{+parent}/blockchainNodes | List blockchain nodes in a project and location |
| GET | /v1/{+name} | Get a node, operation, or location by resource name |
| PATCH | /v1/{+name} | Update a blockchain node |
| DELETE | /v1/{+name} | Delete a blockchain node |
| POST | /v1/{+name}:cancel | Cancel a long-running operation |
| GET | /v1/{+name}/operations | List long-running operations |

## Key resources

- **Blockchain Nodes** — Provision, list, update, and delete managed Ethereum or Polygon nodes.
- **Operations** — Track long-running provisioning, update, and delete operations.
- **Locations** — Discover the regions where Blockchain Node Engine is available.

## Why Jentic

- **Setup:** Wiring the Blockchain Node Engine API by hand means setting up its Google OAuth 2.0 flow, refreshing scoped access tokens, and driving node provisioning through the long-running operations model yourself. Through Jentic you install once, import the Blockchain Node Engine API from the API Directory, store the OAuth credentials once, and your agent calls it.
- **Permission scoping:** The API puts the project and node in the URL path (/v1/{+parent}/blockchainNodes and /v1/{+name}), so a rule can pin your agent to one project's blockchain nodes: it can create and inspect nodes there and nowhere else. You choose the operations it may call, so deleting a node is not included unless you add it.
- **Credential handling:** Your Google OAuth client credentials and refresh token are stored once, encrypted, by your own Jentic One instance and injected at execution time. The agent receives only short-lived scoped access tokens and never sees the refresh token in its prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an Ethereum node on Google Cloud', and Jentic returns the create blockchainNode operation with its full ethereumDetails schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Kubernetes Engine API** — Hosts the dApp backend that consumes the node's JSON-RPC endpoint.
- **Alchemy API** — Multi-tenant Ethereum and L2 node-as-a-service with enhanced APIs.
- **QuickNode API** — Multi-chain managed RPC provider supporting many networks.

## FAQ

### What authentication does the Blockchain Node Engine API use?

The API uses Google OAuth 2.0 with the cloud-platform scope. Through Jentic the OAuth refresh token is stored encrypted and the agent receives short-lived scoped access tokens for each call.

### Can I provision an archive Ethereum node with this API?

Yes. POST /v1/{parent}/blockchainNodes with ethereumDetails.nodeType set to ARCHIVE and the desired network (MAINNET, GOERLI, SEPOLIA, or POLYGON_MAINNET) returns a long-running operation. Archive nodes take longer to sync because they retain full historical state.

### What are the rate limits for the Blockchain Node Engine API?

Control-plane quotas are project-level: typically a small write QPS on the same node and bursty read QPS for list and get. Heavy provisioning churn is rate-limited per project. JSON-RPC traffic to the node itself is governed by the node's own throughput, not by this control-plane API.

### How do I create a node through Jentic?

Search Jentic for 'create a Blockchain Node Engine node', load the schema for POST /v1/{parent}/blockchainNodes, and execute with blockchainType ETHEREUM and the desired ethereumDetails. Jentic forwards the OAuth token and returns the long-running operation name to poll.

### Does this API submit transactions or read on-chain state?

No. This control-plane API only manages the node resource. Submit transactions and read state via the node's JSON-RPC endpoint (returned in the node's connectionInfo) using a standard Ethereum client library.

### What networks are supported?

Ethereum mainnet, Goerli, Sepolia testnets, and Polygon mainnet are exposed via the ethereumDetails.network enum on the blockchainNode resource. Other chains are not currently supported by Blockchain Node Engine.

### Can I limit what my agent is allowed to do with the Blockchain Node Engine API?

Yes. Because Jentic One is self-hosted, your own rules decide which operations and credentials the agent may use, and this API puts the project and node in the URL path (/v1/{parent}/blockchainNodes and /v1/{name}), so you can pin the agent to a single project's blockchain nodes and nowhere else. You choose exactly which operations it may call, so you can allow it to create, list, and get nodes while withholding the delete and cancel operations unless you add them. The Google OAuth credentials stay in your own instance, and the agent only ever receives short-lived scoped access tokens at execution time.