# FastNear Builder Docs Full Documentation Archive AI-readable Markdown mirrors for authored docs plus canonical `/rpcs/**` and `/apis/**` routes. --- ## RPC / API Reference - HTML path: https://docs.fastnear.com/ - Markdown path: https://docs.fastnear.com/index.md **Source:** [https://docs.fastnear.com/](https://docs.fastnear.com/) FastNear docs overview Choosing the FastNear API or reference. Use RPC for canonical JSON-RPC state reads, contract calls, and transaction submission. Use indexed APIs for balances, holdings, activity history, and recent block-family data. [Start with FastNear API](https://docs.fastnear.com/api) [Start with RPC](https://docs.fastnear.com/rpc) [Get API key](https://docs.fastnear.com/auth) Authentication FastNear API keys work across the RPC and APIs. Header Authorization: Bearer ... Query parameter ?apiKey=... Quick routing Most teams start here [FastNear API](https://docs.fastnear.com/api) Indexed account, asset, staking, and public-key endpoints for account-centric application reads. Protocol-native [RPC Reference](https://docs.fastnear.com/rpc) Canonical JSON-RPC methods for blocks, contract calls, validators, and transaction submission. Execution history [Transactions API](https://docs.fastnear.com/tx) Account activity, receipts, transaction lookups, and block-scoped history from indexed execution data. Low-latency reads [NEAR Data API](https://docs.fastnear.com/neardata) Recent optimistic and finalized blocks, headers, and redirect helpers for polling and lightweight monitoring. Main APIs and references These are the main FastNear entry points. Start with the API or reference section that matches the data you need, then move into the detailed reference for the specific endpoint. Indexed account views [FastNear API](https://docs.fastnear.com/api) Use indexed REST endpoints for balances, NFTs, staking positions, and public-key lookups without raw JSON-RPC request and response envelopes. Try out [Full account state](https://docs.fastnear.com/api/v1/account-full) [Fungible token balances](https://docs.fastnear.com/api/v1/account-ft) [NFT holdings](https://docs.fastnear.com/api/v1/account-nft) [Public key lookups](https://docs.fastnear.com/api/v1/public-key) Canonical JSON-RPC [RPC Reference](https://docs.fastnear.com/rpc) Use protocol-native methods for direct state reads, transaction submission, contract calls, and chain inspection. Try out [Account state](https://docs.fastnear.com/rpc/account/view-account) [Block lookups](https://docs.fastnear.com/rpc/block/block-by-id) [Contract view calls](https://docs.fastnear.com/rpc/contract/call-function) [Validator data](https://docs.fastnear.com/rpc/validators/validators-current) Execution history [Transactions API](https://docs.fastnear.com/tx) Use indexed endpoints for account activity, receipts, transaction lookups, and block-scoped execution history. Try out [Account activity](https://docs.fastnear.com/tx/account) [Transaction lookups](https://docs.fastnear.com/tx/transactions) [Receipt tracing](https://docs.fastnear.com/tx/receipt) [Block transaction history](https://docs.fastnear.com/tx/blocks) Recent block-family reads [NEAR Data API](https://docs.fastnear.com/neardata) Use NEAR Data for recent optimistic and finalized blocks, block headers, and latest-block helper routes when you need near-realtime reads or lightweight monitoring. Try out [Optimistic block reads](https://docs.fastnear.com/neardata/block-optimistic) [Latest finalized block](https://docs.fastnear.com/neardata/last-block-final) [Block header polling](https://docs.fastnear.com/neardata/block-headers) Ops and access What teams ask before going live. Keep these close when you are moving from exploration to production. Higher limits [Auth & Access](https://docs.fastnear.com/auth) Use one FastNear API key across both the RPC and REST APIs. Keys and billing [FastNear Dashboard](https://dashboard.fastnear.com) Sign in, create keys, and move to higher-limit usage patterns when you need them. Live operations [Status](https://status.fastnear.com) Check incidents or degraded service before you start debugging application behavior. Infra bootstrap [Snapshots](https://docs.fastnear.com/snapshots) Stand up RPC or archival infrastructure faster without replaying the chain from scratch. Agents and automation Building with AI agents or background workers? Use the agent docs for credential posture, routing logic, and prompt-friendly markdown exports. [Open Agents hub](https://docs.fastnear.com/agents) [Routing guide](https://docs.fastnear.com/agents/choosing-surfaces) --- ## Agents on FastNear - HTML path: https://docs.fastnear.com/agents - Markdown path: https://docs.fastnear.com/agents.md **Source:** [https://docs.fastnear.com/agents](https://docs.fastnear.com/agents) # Agents on FastNear {/* FASTNEAR_AI_DISCOVERY: This is the operational entry point for AI agents, crawlers, and automation runtimes. It explains what information to gather before the first request, which FastNear API to start with, how auth works across APIs, and what an agent answer should contain. */} This page is the operational starting point for AI agents, crawlers, and automation runtimes using FastNear. The goal is simple: identify the user's actual task, choose one FastNear API first, fetch the smallest useful result, and only widen to another API when there is a clear missing piece. ## If you only need the next step - Need to decide which FastNear API to start with? Use [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces). - Need credential handling rules? Use [Auth for Agents](https://docs.fastnear.com/agents/auth). - Need example multi-step workflows? Use [Agent Playbooks](https://docs.fastnear.com/agents/playbooks). - Need exact endpoint docs now? Go directly to [RPC Reference](https://docs.fastnear.com/rpc), [FastNear API](https://docs.fastnear.com/api), [Transactions API](https://docs.fastnear.com/tx), [Transfers API](https://docs.fastnear.com/transfers), [NEAR Data API](https://docs.fastnear.com/neardata), or [KV FastData API](https://docs.fastnear.com/fastdata/kv). ## FastNear for agents in one minute - Use indexed APIs when the user wants a product-shaped answer such as balances, holdings, account history, or transfer history. - Use [RPC Reference](https://docs.fastnear.com/rpc) when the user needs canonical protocol-native fields, contract calls, or transaction submission. - If you are using the hosted JS runtime at [js.fastnear.com](https://js.fastnear.com), start with low-level methods such as `near.view`, `near.queryAccount`, and `near.tx.*`, and use `near.recipes.*` only when a task helper is the shortest path to the answer. - Use [NEAR Data API](https://docs.fastnear.com/neardata) when the question is about recent optimistic or finalized blocks and explicit polling. - Use [Snapshots](https://docs.fastnear.com/snapshots) for operator workflows, not application-level data reads. - One FastNear API key works across the RPC and API endpoints. - Stop after the first sufficient answer. Do not collect from multiple APIs unless the current result is insufficient. ## What to resolve before the first request Try to identify these inputs before you make a call: - **Network**: mainnet or testnet. - **Primary identifier**: account ID, public key, transaction hash, receipt ID, block height/hash, contract ID plus storage key, or node/bootstrap task. - **Answer shape**: summary, history, canonical protocol output, or operator instructions. - **Freshness requirement**: historical, current, optimistic/latest, or finalized/latest. - **Precision requirement**: indexed summary is acceptable, or exact canonical node semantics are required. If one of these is missing, make a small assumption when the likely starting API does not change. Ask a clarifying question only when the wrong API choice would materially change the result. ## FastNear APIs at a glance | API | Start here when... | Typical inputs | Widen only if... | | --- | --- | --- | --- | | [FastNear API](https://docs.fastnear.com/api) | The user wants balances, NFTs, staking, public-key resolution, or an account summary | `account_id`, public key | The user needs exact canonical node fields | | [RPC Reference](https://docs.fastnear.com/rpc) | The user wants canonical protocol output, contract calls, validator data, or transaction submission | `account_id`, block height/hash, method-specific params | The user also needs a higher-level summary or indexed history | | [Transactions API](https://docs.fastnear.com/tx) | The user wants transaction, receipt, account, or block execution history | transaction hash, receipt ID, `account_id`, block identifiers | The user needs exact RPC-level follow-up or finality semantics | | [Transfers API](https://docs.fastnear.com/transfers) | The user wants transfer-only history | `account_id`, transfer filters | The question broadens to general execution context | | [NEAR Data API](https://docs.fastnear.com/neardata) | The user wants recent optimistic or finalized blocks, headers, or latest-block helpers | block height/hash, freshness requirement | The user needs exact canonical block/state follow-up | | [KV FastData API](https://docs.fastnear.com/fastdata/kv) | The user wants indexed contract key history or latest indexed key-value state | contract ID, storage key | The user needs exact on-chain current state | | [Snapshots](https://docs.fastnear.com/snapshots) | The user is standing up infrastructure | network, node type, operator goal | The user shifts to application-level chain questions | ## Default workflow Use this loop unless the task clearly needs something more specialized: 1. Translate the user's wording into the task they actually need solved. Examples: account summary, canonical state inspection, transaction investigation, transfer-only history, recent block monitoring, or node bootstrap. 2. Pick one FastNear API first. Do not gather from multiple APIs until the first result proves insufficient. 3. Pull the smallest relevant docs context. Use the API index page, endpoint page, or Markdown mirror instead of broad unrelated docs. 4. Make the first request that matches the user's identifier and expected answer shape. 5. Stop if the result is already sufficient to answer the user's question. 6. Widen only when you can name the missing piece precisely. Examples: canonical confirmation, broader execution history, fresher block-family data, or exact protocol fields. ## Good defaults When the user's wording is short but the intent is common, these defaults are usually correct: - "Check this account" usually starts with [FastNear API](https://docs.fastnear.com/api). - "Check this public key" usually starts with [FastNear API](https://docs.fastnear.com/api) for key-to-account resolution. - "Check this transaction" usually starts with [Transactions API](https://docs.fastnear.com/tx). - "Check this receipt" usually starts with [Transactions API](https://docs.fastnear.com/tx). - "Check this block" usually starts with [NEAR Data API](https://docs.fastnear.com/neardata) for recent-block monitoring or [RPC Reference](https://docs.fastnear.com/rpc) for exact canonical block data. - "Check this contract key/history" usually starts with [KV FastData API](https://docs.fastnear.com/fastdata/kv). - "Help me bootstrap a node" starts with [Snapshots](https://docs.fastnear.com/snapshots). Full routing rules and tradeoffs live in [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces). ## Widen carefully Good escalation patterns: - Start with [FastNear API](https://docs.fastnear.com/api), then move to [RPC Reference](https://docs.fastnear.com/rpc) if the user asks for exact canonical confirmation. - Start with [Transactions API](https://docs.fastnear.com/tx), then move to [RPC Reference](https://docs.fastnear.com/rpc) if the user needs protocol-level transaction or receipt follow-up. - Start with [Transfers API](https://docs.fastnear.com/transfers), then widen to [Transactions API](https://docs.fastnear.com/tx) if the user broadens the question beyond transfer events. - Start with [NEAR Data API](https://docs.fastnear.com/neardata), then move to [RPC Reference](https://docs.fastnear.com/rpc) if the user needs exact canonical block or state inspection. Bad pattern: - Pull from several FastNear APIs before you know what the user actually needs. That usually produces a noisier answer, not a better one. ## Authenticate once, reuse everywhere Start with a FastNear API key and reuse it across every FastNear API above, including the regular and archival RPC hosts. Send it either as an HTTP header or a URL parameter: ```bash title="Authorization header" : "${FASTNEAR_API_KEY:?Set FASTNEAR_API_KEY in your shell before running this example.}" curl "https://rpc.mainnet.fastnear.com" \ -H "Authorization: Bearer $FASTNEAR_API_KEY" \ -H "Content-Type: application/json" \ --data '{"method":"block","params":{"finality":"final"},"id":1,"jsonrpc":"2.0"}' ``` ```bash title="URL parameter" : "${FASTNEAR_API_KEY:?Set FASTNEAR_API_KEY in your shell before running this example.}" curl "https://rpc.mainnet.fastnear.com?apiKey=$FASTNEAR_API_KEY" ``` Get your API key from [FastNear Dashboard](https://dashboard.fastnear.com). Operational posture for non-interactive runtimes: [Auth for Agents](https://docs.fastnear.com/agents/auth) — keys go in env vars or a secret manager, never in browser storage, chat logs, or prompts. Full flow and header details: [Auth & Access](https://docs.fastnear.com/auth). ## Pull clean docs into a prompt - Every page has a **Copy Markdown** button in the top-right toolbar. It emits a navigation-chrome-free Markdown version of the page, ready to paste into a prompt or RAG store. - The `llms.txt` convention is mirrored here: - [`/llms.txt`](https://docs.fastnear.com/llms.txt) — index of pages and short descriptions. - [`/llms-full.txt`](https://docs.fastnear.com/llms-full.txt) — the full docs corpus concatenated into one file. - Russian-locale equivalents live at [`/ru/llms.txt`](https://docs.fastnear.com/llms.txt) and [`/ru/llms-full.txt`](https://docs.fastnear.com/llms-full.txt). - Machine-readable site structure for graph-aware ingestion: [`/structured-data/site-graph.json`](https://docs.fastnear.com/structured-data/site-graph.json) (mirrored in `/ru/`). - Per-page Markdown mirrors live under the same slug with a `.md` suffix if you prefer direct fetches over the Copy Markdown button. ## Per-call hints an agent should know - Parameter names, response fields, and example payloads are rendered live on each endpoint page. The underlying registry lives at `src/data/generatedFastnearPageModels.json` if you are mirroring schema into another system. - `?network=testnet` is supported on specific pages only. Each page calls out its network support in the **Auth and availability** section; do not assume it works globally. - Pagination tokens (`resume_token`, `page_token`) are opaque. Reuse them verbatim and only with the endpoint plus filter set that produced them. - Status routes: every REST family ships a `/status` and `/health` path for liveness and sync-latency inspection. ## What a useful agent answer should contain - A brief statement of which FastNear API was used and why, especially if the choice was an inference. - The answer in the shape the user is likely to need next: summary first for humans, exact fields or next-call guidance when the caller is technical. - Any important caveat about freshness, canonicality, pagination, or network choice. - A follow-up path only when it is likely to help. Examples: "use RPC for canonical confirmation" or "use Transactions API if you need broader execution context." Avoid dumping raw payloads when the user is really asking for interpretation. ## Next docs by need - Need routing depth and tradeoffs? [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces) - Need credential posture and secret handling? [Auth for Agents](https://docs.fastnear.com/agents/auth) - Need example workflows? [Agent Playbooks](https://docs.fastnear.com/agents/playbooks) --- ## Auth for Agents - HTML path: https://docs.fastnear.com/agents/auth - Markdown path: https://docs.fastnear.com/agents/auth.md **Source:** [https://docs.fastnear.com/agents/auth](https://docs.fastnear.com/agents/auth) # Auth for Agents Agents should authenticate to FastNear the same way production backends do. Do not copy the browser-demo posture used by the docs UI into an agent, worker, or automation runtime. One FastNear API key works across the RPC and API endpoints. For agents, the important question is not whether auth exists. It is where the credential lives, how it gets attached to requests, and how to avoid leaking it into prompts, logs, or browser state. ## If you only need the rule - Store the key in an env var or secret manager. - Inject it server-side or from the worker runtime. - Prefer the `Authorization: Bearer ...` header. - Apply the same key and transport rules to both regular and archival RPC hosts. - Never ask a user to paste a FastNear key into chat, a prompt, or a browser-only agent. ## Recommended runtime patterns Use one of these patterns: - **Server-side worker or automation**: load the key from env vars or a secret manager and attach it directly to outbound FastNear requests. - **Thin backend proxy**: if the user-facing app runs in the browser, send the request to your backend first and let the backend inject the FastNear credential. - **Multi-tenant service**: keep per-tenant keys in a proper secrets store and make the agent select the right credential by tenant or project context. Avoid browser-only agent architectures that need the FastNear key in client-side storage. ## Choose the credential transport | Transport | Use it when... | Notes | | --- | --- | --- | | `Authorization: Bearer ${FASTNEAR_API_KEY}` | you control the HTTP client or backend | Best default for agents. Less likely to leak into URL logs, analytics, or copied links. | | `?apiKey=${FASTNEAR_API_KEY}` | you are using simple curl or a system that cannot easily set headers | Still valid, but URLs tend to travel further through logs and tooling. Use it intentionally. | If you have a choice, use the header form. ## Minimum secure flow 1. Read the key from an env var or secret manager at runtime. 2. Attach it to the request as a header or query parameter. 3. Keep prompts, traces, and logs scrubbed so the raw key never lands in transcripts. 4. Rotate the key if it appears in a prompt, debug trace, browser storage, or a copied URL. Example: ```js const apiKey = process.env.FASTNEAR_API_KEY; const response = await fetch('https://rpc.mainnet.fastnear.com', { method: 'POST', headers: { 'Authorization': `Bearer ${apiKey}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'block', params: {finality: 'final'}, }), }); ``` ## If the runtime is missing the key Agents should normally start with a configured FastNear API key. Some public FastNear reads may still work without one, but that should not be the default operating posture. If the configured runtime does not have the key yet: - tell the user to create or retrieve a key from [FastNear Dashboard](https://dashboard.fastnear.com) - ask them to configure it in an env var, secret manager, or backend configuration - do not ask them to paste the raw key into chat so the agent can carry it around If the agent cannot access the configured secret, it should say that clearly and stop rather than improvising insecure storage. ## Do not do this - Do not lift a key out of browser `localStorage` and treat it as an agent credential. - Do not embed keys into browser-delivered agent apps. - Do not keep keys in prompts, notebook cells, or plaintext config checked into source control. - Do not prefer `?apiKey=` just because it is shorter if your infrastructure logs full URLs aggressively. ## What the agent should tell a user When auth is relevant, a useful agent answer usually contains: - whether the current request can proceed unauthenticated - whether the user needs to configure a FastNear API key next - where that key should live, usually env vars, a secret manager, or a backend proxy - which transport the agent is using, usually `Authorization: Bearer ...` ## Related guides - [Auth & Access](https://docs.fastnear.com/auth) - [Agents on FastNear](https://docs.fastnear.com/agents) - [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces) --- ## Choosing the Right Surface - HTML path: https://docs.fastnear.com/agents/choosing-surfaces - Markdown path: https://docs.fastnear.com/agents/choosing-surfaces.md **Source:** [https://docs.fastnear.com/agents/choosing-surfaces](https://docs.fastnear.com/agents/choosing-surfaces) # Choosing the Right Surface {/* FASTNEAR_AI_DISCOVERY: This page is for AI agents deciding which FastNear surface to use from a user's intent. It explains how to route from the user's goal to the best first surface, when to combine surfaces, and which common mistakes to avoid. */} Do not start by exposing every FastNear API to an agent. Start by translating the user's request into the job they actually want done, then pick the one FastNear API or reference section that most directly answers that job. For agents, the important question is usually not "which endpoint exists?" It is "what kind of answer will help the user next?" ## What decides the route Before you pick an API, identify four things: - **Object**: account, public key, transaction hash, receipt, block, contract storage, or infrastructure setup. - **Answer shape**: product-style summary, execution history, canonical protocol output, or operator instructions. - **Freshness**: historical, current, or latest/near-realtime. - **Exactness**: indexed summary is acceptable, or canonical node-shaped correctness is required. In practice: - account plus summary usually means [FastNear API](https://docs.fastnear.com/api) - account plus exact canonical state usually means [RPC Reference](https://docs.fastnear.com/rpc) - transaction or receipt usually means [Transactions API](https://docs.fastnear.com/tx) - transfer-only history usually means [Transfers API](https://docs.fastnear.com/transfers) - newest blocks usually means [NEAR Data API](https://docs.fastnear.com/neardata) - contract key history usually means [KV FastData API](https://docs.fastnear.com/fastdata/kv) - node bootstrap usually means [Snapshots](https://docs.fastnear.com/snapshots) ## Start from user intent - If the user wants a wallet-style or explorer-style answer, prefer indexed APIs. - If the user wants canonical protocol behavior or exact node-shaped state, use raw [RPC Reference](https://docs.fastnear.com/rpc). - If the user wants history, receipts, or event sequences, use history-oriented APIs before falling back to RPC. - If the user wants the newest block-family data, use [NEAR Data API](https://docs.fastnear.com/neardata) for polling-oriented freshness. - If the user wants infrastructure bootstrap instructions, route them to [Snapshots](https://docs.fastnear.com/snapshots) instead of application query surfaces. ## Decision ladder Use this order of operations before you pick a surface: 1. Is the user trying to stand up infrastructure rather than query chain data? If yes, use [Snapshots](https://docs.fastnear.com/snapshots). 2. Is the user asking for a product-shaped summary such as balances, NFTs, staking, or account holdings? If yes, start with [FastNear API](https://docs.fastnear.com/api). 3. Is the user asking what happened over time: transactions, receipts, transfers, or activity history? If yes, start with [Transactions API](https://docs.fastnear.com/tx) or [Transfers API](https://docs.fastnear.com/transfers) for transfer-only questions. 4. Is the user focused on the newest blocks or low-latency block-family reads? If yes, use [NEAR Data API](https://docs.fastnear.com/neardata). 5. Does correctness depend on canonical node behavior, protocol fields, or exact on-chain state? If yes, use [RPC Reference](https://docs.fastnear.com/rpc). 6. Is the user asking about indexed key-value storage history or latest indexed contract state? If yes, use [KV FastData API](https://docs.fastnear.com/fastdata/kv). If more than one surface could work, prefer the one that gives the most directly useful answer with the least reconstruction by the agent. ## Before the first call Try to resolve these inputs before you make a request: - network: mainnet or testnet - primary identifier: account ID, public key, transaction hash, receipt ID, block height/hash, contract ID plus storage key - expected output: summary, history, canonical fields, or operator steps - freshness requirement: latest, finalized, historical, or "whatever is current" If one of these is missing: - make a small assumption when the likely starting API does not change - ask a clarifying question only when the wrong choice would materially change the result ## Route common user asks | If the user says... | They probably want... | Start here | Only switch when... | | --- | --- | --- | --- | | "What is the exact on-chain account state?" | Canonical protocol-native state | [RPC Reference](https://docs.fastnear.com/rpc) | You also need a higher-level summary for humans. | | "What does this account own?" | Product-shaped balances, NFTs, staking, and holdings | [FastNear API](https://docs.fastnear.com/api) | You need exact node fields the indexed view does not expose. | | "What activity touched this account?" | Indexed transaction and receipt history | [Transactions API](https://docs.fastnear.com/tx) | The user only wants transfer events, or you need canonical protocol follow-up details. | | "Show me transfers only." | Account-centric transfer history | [Transfers API](https://docs.fastnear.com/transfers) | The user actually needs broader transaction execution context. | | "What changed in the latest blocks?" | Fresh optimistic or finalized block-family reads | [NEAR Data API](https://docs.fastnear.com/neardata) | You need canonical RPC details for a specific block or state read. | | "What is the contract storage history here?" | Indexed key-value state history | [KV FastData API](https://docs.fastnear.com/fastdata/kv) | You need current canonical on-chain state rather than indexed history. | | "Why did this transaction fail?" | An execution timeline first, then canonical details | [Transactions API](https://docs.fastnear.com/tx) | You need RPC-level confirmation of final protocol status or transaction submission behavior. | | "How do I submit a transaction or inspect a protocol field?" | Canonical node behavior | [RPC Reference](https://docs.fastnear.com/rpc) | You later need to summarize the resulting account state or activity for a human. | | "How do I bootstrap a node or archival setup?" | Infrastructure workflow, not app data | [Snapshots](https://docs.fastnear.com/snapshots) | The user then starts asking application-level chain questions. | ## When the identifier is the clue If the user's wording is vague but the identifier is clear, let the identifier shape your first move: | If you have... | Default first move | Why | | --- | --- | --- | | an `account_id` | Start with [FastNear API](https://docs.fastnear.com/api) for summaries, or [RPC Reference](https://docs.fastnear.com/rpc) if the user explicitly asks for exact state | Account questions usually mean balances/holdings first unless the user says canonical. | | a public key | Start with [FastNear API](https://docs.fastnear.com/api) for key-to-account resolution | This is usually an account discovery task, not an RPC-first task. | | a transaction hash | Start with [Transactions API](https://docs.fastnear.com/tx) | Most users want execution context and readable history before raw protocol fields. | | a receipt ID | Start with [Transactions API](https://docs.fastnear.com/tx) | Receipt tracing is already indexed there. | | a block height or block hash | Start with [NEAR Data API](https://docs.fastnear.com/neardata) for freshness-oriented monitoring, or [RPC Reference](https://docs.fastnear.com/rpc) for exact canonical block data | The user's need is usually either recency or canonicality. | | a contract ID plus storage key | Start with [KV FastData API](https://docs.fastnear.com/fastdata/kv) for indexed key history, or [RPC Reference](https://docs.fastnear.com/rpc) for exact current chain state | The storage question usually decides whether indexed history or canonical state matters. | | a node or archival setup task | Start with [Snapshots](https://docs.fastnear.com/snapshots) | This is operator workflow, not application data access. | ## What each surface is best at ### RPC Reference Use [RPC Reference](https://docs.fastnear.com/rpc) when the user needs exact protocol-native data or behavior: - exact account state, access keys, validators, chunks, blocks, protocol metadata - contract view calls and transaction submission - answers where field names and semantics should stay close to NEAR nodes Do not lead with RPC when the user really wants a clean summary of holdings or history. That forces the agent to rebuild a product-shaped answer from lower-level data. ### FastNear API Use [FastNear API](https://docs.fastnear.com/api) when the user wants an answer that already looks like application data: - balances - NFTs - staking positions - public-key lookups - combined account snapshots This should usually be the first stop for wallet, portfolio, explorer, and account overview requests. ### Transactions API Use [Transactions API](https://docs.fastnear.com/tx) when the user wants execution history: - account activity - transaction lookup - receipt tracing - block-scoped transaction history This is the default history surface when the user asks "what happened?" rather than "what exists right now?" ### Transfers API Use [Transfers API](https://docs.fastnear.com/transfers) when the user's question is explicitly about transfer events and not full execution context: - incoming and outgoing transfers - transfer-centric pagination flows - transfer-only account activity views If the user starts asking about receipts, non-transfer actions, or full transaction behavior, move up to [Transactions API](https://docs.fastnear.com/tx). ### NEAR Data API Use [NEAR Data API](https://docs.fastnear.com/neardata) when freshness matters more than a product-shaped summary: - optimistic or recently finalized blocks - latest block-family reads - explicit polling workflows Do not present this as a websocket or webhook product. It is a polling-oriented read surface. ### KV FastData API Use [KV FastData API](https://docs.fastnear.com/fastdata/kv) when the question is about indexed contract storage history or latest indexed key-value state: - storage analysis - key history - contract state lookups where indexed key-value access is the right abstraction ### Snapshots Use [Snapshots](https://docs.fastnear.com/snapshots) when the workflow is about operators standing up infrastructure: - mainnet or testnet bootstrap - RPC or archival node initialization - operator runbooks This is not an application query path. ## Immediate next steps after choosing Once you choose a starting API, the next move should also be predictable: | Chosen API | First thing to do | What success looks like | Widen only if... | | --- | --- | --- | --- | | [FastNear API](https://docs.fastnear.com/api) | Pick the endpoint that matches the user's identifier or summary request | You can answer balances, holdings, staking, or account-summary questions directly | The user needs exact canonical node fields or protocol-native confirmation | | [RPC Reference](https://docs.fastnear.com/rpc) | Choose the exact RPC method that matches the object and the required canonical field set | You can return protocol-native fields or perform the exact state/submit action requested | The user also needs a higher-level summary or indexed history | | [Transactions API](https://docs.fastnear.com/tx) | Start from the transaction hash, receipt, account history, or block-history endpoint that matches the question | You can explain what happened and in what order | The user needs exact RPC-level finality or submission semantics | | [Transfers API](https://docs.fastnear.com/transfers) | Fetch transfer history for the account or asset scope in question | You can answer transfer-only questions without unrelated execution detail | The user broadens the question to receipts, actions, or full transaction context | | [NEAR Data API](https://docs.fastnear.com/neardata) | Fetch the latest optimistic or finalized block-family data that matches the freshness requirement | You can answer "what changed recently?" or "what is the latest block-family state?" | The user needs exact canonical block/state follow-up | | [KV FastData API](https://docs.fastnear.com/fastdata/kv) | Fetch latest indexed key-value state or indexed key history | You can answer contract storage inspection questions in indexed form | The user needs exact on-chain current state instead of indexed storage views | | [Snapshots](https://docs.fastnear.com/snapshots) | Choose the right network and node type, then follow the bootstrap guide | You can give operator steps, prerequisites, and bootstrap guidance | The user shifts from infra setup to application-level chain queries | ## Stop conditions before you widen Do not widen to a second API just because it exists. Stay on the first API when: - the answer already matches the user's expected shape - the current API already exposes the fields the user asked about - the user asked for history and you already have indexed history - the user asked for a summary and you already have a summary Widen when: - the user explicitly asks for canonical confirmation - the current API lacks the field, freshness, or execution detail required - the user broadens from transfer-only history to general transaction behavior - the user broadens from summary output to protocol-native inspection ## Combine surfaces only when it helps the user Good multi-surface patterns: - Start with [FastNear API](https://docs.fastnear.com/api), then drop to [RPC Reference](https://docs.fastnear.com/rpc) if the user asks for exact canonical confirmation. - Start with [Transactions API](https://docs.fastnear.com/tx), then use [RPC Reference](https://docs.fastnear.com/rpc) if you need final protocol details for a specific transaction or receipt. - Start with [NEAR Data API](https://docs.fastnear.com/neardata) for the newest blocks, then use [RPC Reference](https://docs.fastnear.com/rpc) for exact follow-up inspection of a specific block or state query. - Start with [Transfers API](https://docs.fastnear.com/transfers) for transfer-only questions, then widen to [Transactions API](https://docs.fastnear.com/tx) if the user asks for more execution context. Bad multi-surface pattern: - Pull data from several surfaces before you know what the user actually wants. That usually produces a noisier answer, not a better one. ## What the agent should infer from common phrasing - "What does this wallet have?" usually means balances, NFTs, staking, and maybe public-key resolution. Start with [FastNear API](https://docs.fastnear.com/api). - "Why did this transaction fail?" usually means the user wants a readable execution story first, not raw protocol output. Start with [Transactions API](https://docs.fastnear.com/tx). - "Is this the exact chain state?" usually means canonical correctness matters more than convenience. Start with [RPC Reference](https://docs.fastnear.com/rpc). - "What just happened in the last block?" usually means freshness is the main requirement. Start with [NEAR Data API](https://docs.fastnear.com/neardata). - "How do I get a node online quickly?" is an operator workflow. Start with [Snapshots](https://docs.fastnear.com/snapshots). ## Common routing mistakes - Do not start with RPC just because it is canonical. Canonical is not the same as helpful for every user task. - Do not use snapshots for application-level reads. - Do not describe [NEAR Data API](https://docs.fastnear.com/neardata) as a streaming surface. - Do not widen from transfer history to full transaction history unless the user's question actually broadens. - Do not switch away from an indexed API just because raw RPC exists. Switch only when the indexed answer is insufficient. ## If user intent is ambiguous When the user is vague, make the smallest useful routing assumption: - "Check this account" should usually begin with [FastNear API](https://docs.fastnear.com/api), because most users want a readable account summary. - "Check this transaction" should usually begin with [Transactions API](https://docs.fastnear.com/tx), because most users want execution context, not only protocol fields. - "Check this block" can start with [NEAR Data API](https://docs.fastnear.com/neardata) for recency-oriented monitoring or [RPC Reference](https://docs.fastnear.com/rpc) when the user explicitly cares about canonical node output. If you do make an assumption, state it briefly in the answer and move forward. Ask for clarification only when choosing the wrong surface would materially change the result. ## What the agent should do after the first result After the first response comes back: 1. Check whether you can now answer the user's question directly. 2. If yes, answer in the user's expected shape instead of collecting more data. 3. If no, name the missing piece precisely. Examples: canonical confirmation, broader history, fresher block data, exact protocol field, or infra-specific context. 4. Only then switch APIs. The goal is not to prove that multiple FastNear APIs exist. The goal is to answer the user's next real question with the fewest necessary steps. ## Related guides - [Agents on FastNear](https://docs.fastnear.com/agents) for the full surface map, base URLs, and prompt-ingestion hints. - [Auth for Agents](https://docs.fastnear.com/agents/auth) for credential handling and runtime posture. - [Agent Playbooks](https://docs.fastnear.com/agents/playbooks) for example multi-step workflows. --- ## Agent Playbooks - HTML path: https://docs.fastnear.com/agents/playbooks - Markdown path: https://docs.fastnear.com/agents/playbooks.md **Source:** [https://docs.fastnear.com/agents/playbooks](https://docs.fastnear.com/agents/playbooks) # Agent Playbooks {/* FASTNEAR_AI_DISCOVERY: This page gives AI agents concrete multi-step workflows for common FastNear tasks. Each playbook names the minimum inputs, the first API to use, when to widen to another API, and what a useful answer should contain. */} Use this page when the agent already knows the kind of task it is handling and needs the default next steps. Each playbook starts with one FastNear API, names the minimum useful inputs, and tells you when to stop versus when to widen. The core rule stays the same across all playbooks: start with one API, get the smallest useful result, and only widen when you can name the missing piece. ## How to use these playbooks 1. Match the user's request to the closest playbook below. 2. Gather the minimum inputs. 3. Make the first request from the suggested starting API. 4. Stop as soon as you can answer in the shape the user actually needs. 5. Widen only for a specific missing field, freshness requirement, or canonicality requirement. ## Quick map | If the user wants... | Start with... | Widen only if... | | --- | --- | --- | | account balances, holdings, staking, or wallet-style summary | [FastNear API](https://docs.fastnear.com/api) | exact canonical node fields are required | | transaction, receipt, or account execution history | [Transactions API](https://docs.fastnear.com/tx) | exact RPC-level status or submission semantics are required | | transfer-only history | [Transfers API](https://docs.fastnear.com/transfers) | the question broadens beyond transfers | | latest optimistic or finalized blocks | [NEAR Data API](https://docs.fastnear.com/neardata) | exact canonical block or state follow-up is required | | indexed contract key state or key history | [KV FastData API](https://docs.fastnear.com/fastdata/kv) | exact current on-chain state is required | | node bootstrap or operator setup | [Snapshots](https://docs.fastnear.com/snapshots) | the task shifts back to application-level chain data | If you still are not sure which one applies, use [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces) first. ## Account summary and holdings Use this when the user says things like "check this account", "what does this wallet hold", "what NFTs does this account have", or "which account does this key belong to?" **Minimum inputs** - network - `account_id` or public key - whether the user wants a broad summary or one specific asset class **Start here** - [V1 Full Account View](https://docs.fastnear.com/api/v1/account-full) for the broad account summary - [V1 Public Key Lookup](https://docs.fastnear.com/api/v1/public-key) when the starting identifier is a public key - [FastNear API index](https://docs.fastnear.com/api) when you need to choose a narrower endpoint first **Default sequence** 1. If the starting identifier is a public key, resolve it to one or more account IDs with [V1 Public Key Lookup](https://docs.fastnear.com/api/v1/public-key). 2. Fetch the broadest useful account view with [V1 Full Account View](https://docs.fastnear.com/api/v1/account-full). 3. If the user asked for only one asset family or needs narrower detail, move to the targeted endpoints such as [FT balances](https://docs.fastnear.com/api/v1/account-ft), [NFT holdings](https://docs.fastnear.com/api/v1/account-nft), or [staking positions](https://docs.fastnear.com/api/v1/account-staking). 4. Stop once you can answer the holdings question directly. **Widen only if** - the user asks for exact canonical state fields rather than indexed summary data - the user needs protocol-native account or access-key semantics When that happens, widen to [View Account](https://docs.fastnear.com/rpc/account/view-account) or other relevant pages in [RPC Reference](https://docs.fastnear.com/rpc). **A useful answer should contain** - the account identity you resolved - the balances or holdings the user asked about - a brief note if the answer is indexed summary data rather than raw RPC state ## Transaction or receipt investigation Use this when the user says things like "did this transaction succeed", "why did it fail", "what happened to this receipt", or "show recent activity for this account." **Minimum inputs** - network - transaction hash, receipt ID, or `account_id` - whether the user wants one item inspected or a history range **Start here** - [Transactions by Hash](https://docs.fastnear.com/tx/transactions) for a transaction hash - [Receipt Lookup](https://docs.fastnear.com/tx/receipt) for a receipt ID - [Account History](https://docs.fastnear.com/tx/account) for account-centric activity **Default sequence** 1. Choose the starting endpoint that matches the identifier you already have. 2. Fetch the indexed execution record and reconstruct the execution story in readable order. 3. Pull out the status, affected accounts, major receipts, and the block context if that is relevant. 4. Stop if you can explain what happened without needing canonical RPC confirmation. **Widen only if** - the user explicitly asks for exact RPC status semantics - the indexed record is not enough to answer a protocol-level question - the question shifts into transaction submission behavior When that happens, widen to [Transaction Status](https://docs.fastnear.com/rpc/transaction/tx-status) or another relevant method in [RPC Reference](https://docs.fastnear.com/rpc). **A useful answer should contain** - whether the transaction or receipt succeeded, failed, or is still pending - the main execution takeaway first, before raw fields - any follow-up path only if it adds value, such as "use RPC for canonical confirmation" ## Transfer-only history Use this when the user cares about asset movement and does not need broader receipt or action context. **Minimum inputs** - network - `account_id` - optional filters such as token, direction, or time range **Start here** - [Query Transfers](https://docs.fastnear.com/transfers/query) - [Transfers API index](https://docs.fastnear.com/transfers) **Default sequence** 1. Query transfer history for the relevant account and filters. 2. Use pagination only as far as needed to answer the question. 3. Keep the answer focused on transfers rather than reconstructing the full transaction story. 4. Stop if the user only asked who sent what, when, and in what asset. **Widen only if** - the user starts asking about non-transfer actions - the user needs receipt traces or broader execution context - the user wants to explain why an action happened, not just that a transfer occurred When that happens, widen to [Account History](https://docs.fastnear.com/tx/account) or another relevant page in [Transactions API](https://docs.fastnear.com/tx). **A useful answer should contain** - the incoming or outgoing transfer events that matter - any filter assumptions you made - a note that this is transfer history, not full execution history ## Recent block monitoring Use this when the user wants the latest optimistic or finalized block-family data, or asks "what changed recently?" **Minimum inputs** - network - freshness requirement: optimistic or finalized - optional block height or hash if the user is anchoring to a specific block **Start here** - [Last Final Block Redirect](https://docs.fastnear.com/neardata/last-block-final) for the latest finalized head - [Optimistic Block by Height](https://docs.fastnear.com/neardata/block-optimistic) when the workflow is explicitly optimistic - [Block Headers](https://docs.fastnear.com/neardata/block-headers) when header-level polling is enough - [NEAR Data API index](https://docs.fastnear.com/neardata) when you need to choose among these **Default sequence** 1. Decide whether the user needs optimistic freshness or finalized stability. 2. Use the latest-block helper or block-family route that matches that freshness requirement. 3. Poll explicitly and keep the answer clear about what freshness mode you used. 4. Stop if the user only needs recent block-family information and not canonical protocol follow-up. **Widen only if** - the user asks for exact canonical block output - the user wants to inspect state or protocol fields beyond the block-family data - the user needs exact RPC semantics for a specific block follow-up When that happens, widen to [RPC Reference](https://docs.fastnear.com/rpc), usually starting with [Block by Height](https://docs.fastnear.com/rpc/block/block-by-height) or [Block by Id](https://docs.fastnear.com/rpc/block/block-by-id). **A useful answer should contain** - whether the data came from optimistic or finalized reads - the latest block or header details that actually answer the user's question - a note when a deeper canonical follow-up would materially change interpretation ## Contract storage inspection Use this when the user wants indexed contract key history, latest indexed key state, or contract-storage analysis by key. **Minimum inputs** - network - contract ID - exact key, key prefix, or account/predecessor scope - whether the user wants latest indexed state or historical key changes **Start here** - [GET Latest by Exact Key](https://docs.fastnear.com/fastdata/kv/get-latest-key) for one exact key - [KV FastData API index](https://docs.fastnear.com/fastdata/kv) when the question is broader than one key **Default sequence** 1. Decide whether the user wants one key, a key family, or account-scoped storage history. 2. Fetch the smallest indexed key-value view that matches that scope. 3. If the user needs history rather than the latest value, stay inside [KV FastData API](https://docs.fastnear.com/fastdata/kv) and switch to the matching history endpoint. 4. Stop if indexed key-value data already answers the question. **Widen only if** - the user needs exact current on-chain state rather than indexed storage state - the user needs protocol-native contract-state semantics - the indexed storage view is insufficient for the exact key or prefix requested When that happens, widen to [View State](https://docs.fastnear.com/rpc/contract/view-state) in [RPC Reference](https://docs.fastnear.com/rpc). **A useful answer should contain** - the contract and key scope you inspected - whether the result is latest indexed state or key history - a note if canonical RPC state would differ in freshness or semantics ## Node bootstrap and operator setup Use this when the user is trying to get infrastructure online rather than query chain data. **Minimum inputs** - network - node type, such as RPC or archival - whether the goal is bootstrap speed, sync recovery, or an operational runbook **Start here** - [Snapshots](https://docs.fastnear.com/snapshots) **Default sequence** 1. Route immediately to the relevant snapshot or operator guide. 2. Keep the answer focused on prerequisites, bootstrap path, and operational next steps. 3. Do not pull application-level APIs unless the user later changes the task. **Widen only if** - the user stops asking about infrastructure and starts asking about chain data itself When that happens, return to [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces) and pick the correct data API from there. **A useful answer should contain** - the network and node type you are assuming - the operator steps the user should follow next - any clear prerequisite or caveat that changes the bootstrap path ## Cross-playbook rules - State the network if you had to infer it. - State the API you chose if the choice was an inference. - Prefer one sufficient answer over an exhaustive multi-API answer. - Treat pagination tokens as opaque and reuse them only with the endpoint and filter set that produced them. - Do not widen just because a more canonical API exists. ## If no playbook fits cleanly If the request is still ambiguous after reading this page: - use [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces) to pick the first API - use [Auth for Agents](https://docs.fastnear.com/agents/auth) if the blocker is credential handling - return to [Agents on FastNear](https://docs.fastnear.com/agents) for the default workflow and answer-shape rules --- ## FastNear API - HTML path: https://docs.fastnear.com/api - Markdown path: https://docs.fastnear.com/api.md **Source:** [https://docs.fastnear.com/api](https://docs.fastnear.com/api) # FastNear API FastNear API is the indexed REST family for builder-facing account views. It is the fastest way to answer questions like "what does this account own?" or "which accounts map to this public key?" without stitching together raw RPC calls. ## Base URLs ```bash title="FastNear API Mainnet" https://api.fastnear.com ``` ```bash title="FastNear API Testnet" https://test.api.fastnear.com ``` ## Best fit - Wallet balances and asset overviews. - NFT and fungible-token account views. - Public-key to account lookups. - Combined account snapshots for dashboards, explorers, and agents. ## When not to use it - Use [RPC Reference](https://docs.fastnear.com/rpc) when you need protocol-native JSON-RPC methods. - Use [Transactions API](https://docs.fastnear.com/tx) when the primary job is transaction or receipt history. - Use [NEAR Data API](https://docs.fastnear.com/neardata) when the job is block-family polling and freshness checks. ## Auth and network availability - FastNear public REST endpoints often work without an API key. - The same FastNear key format still works across API endpoints when you want a consistent authenticated posture or higher limits, and the docs UI can forward it for interactive examples. - Add `?network=testnet` to move compatible pages to the testnet backend and seeded testnet defaults. ## Shareable live examples - Use `Copy example URL` on any interactive API page to share the selected network and filled request state. - Shared example URLs run automatically on load whenever they include operation state. - Saved API keys and tokens are never included in those shared docs URLs. ## Common starting points - [V1 full account view](https://docs.fastnear.com/api/v1/account-full) for a combined account snapshot. - [V1 account FT](https://docs.fastnear.com/api/v1/account-ft) and [V1 account NFT](https://docs.fastnear.com/api/v1/account-nft) for product-facing asset views. - [V1 public key](https://docs.fastnear.com/api/v1/public-key) when you need account resolution from a key. - [V1 FT top holders](https://docs.fastnear.com/api/v1/ft-top) for token-distribution views. ## Need a workflow? Use [FastNear API Examples](https://docs.fastnear.com/api/examples) for worked examples like account summaries, key-to-account resolution, and asset-specific follow-up. ## Troubleshooting ### I only need one low-level value from chain state Use raw RPC instead. The indexed surface is optimized for product views, not for mirroring every RPC method. ### My page is still on mainnet data Check whether the page supports `?network=testnet`. Some flows are mainnet-only; the docs call that out when it applies. ### I need transactions, not balances Move to [Transactions API](https://docs.fastnear.com/tx) so you do not overload the account-view surface with history queries. --- ## API Examples - HTML path: https://docs.fastnear.com/api/examples - Markdown path: https://docs.fastnear.com/api/examples.md **Source:** [https://docs.fastnear.com/api/examples](https://docs.fastnear.com/api/examples) ## Examples All shell examples below work on the public FastNear API hosts as-is. If `FASTNEAR_API_KEY` is set in your shell, they pass it as an `apiKey` query parameter automatically; if it is unset, they fall back to the public unauthenticated path. Bearer auth with `Authorization: Bearer ${FASTNEAR_API_KEY}` is also supported when headers fit your client better. ### Summarize one account in one call `/v1/account/{id}/full` is the FastNear API's account aggregator — one call bundles the account's NEAR state, every FT contract it's touched, every NFT collection it's received, and every validator pool it's delegated to. When you already have the `account_id`, this is the fastest "what does this account look like?" read. ```bash ACCOUNT_ID=root.near curl -s "https://api.fastnear.com/v1/account/$ACCOUNT_ID/full?apiKey=${FASTNEAR_API_KEY:-}" \ | jq '{ account_id, near_balance_yocto: .state.balance, ft_contracts: (.tokens | length), nft_contracts: (.nfts | length), staking_pool_contracts: (.pools | length) }' ``` For `root.near`: 150 FT contracts in the list, 102 NFT collections, 2 staking pools. The contract counts alone tell you this is a busy mainnet account. Every example below drills into one of those surfaces — start here when all you have is the account ID. ### Resolve a public key, then fetch the account snapshot Look up which account a key belongs to, then read that account's holdings in one call. ```bash PUBLIC_KEY='ed25519:CCaThr3uokqnUs6Z5vVnaDcJdrfuTpYJHJWcAGubDjT' LOOKUP="$(curl -s "https://api.fastnear.com/v1/public_key/$(jq -rn --arg k "$PUBLIC_KEY" '$k | @uri')?apiKey=${FASTNEAR_API_KEY:-}")" echo "$LOOKUP" | jq '{matched: (.account_ids | length), account_ids}' ACCOUNT_ID="$(echo "$LOOKUP" | jq -r '.account_ids[0]')" curl -s "https://api.fastnear.com/v1/account/$ACCOUNT_ID/full?apiKey=${FASTNEAR_API_KEY:-}" \ | jq '{account_id, state, tokens: (.tokens|length), nfts: (.nfts|length), pools: (.pools|length)}' ``` If `matched` is greater than 1, switch to [V1 Public Key Lookup All](https://docs.fastnear.com/api/v1/public-key-all) and loop over every returned account. ### How much of this account's NEAR is actually spendable? NEAR account state has three buckets that wallet UIs tend to conflate: `balance` is the unstaked amount, `locked` is NEAR tied up in validator stake or a lockup contract, and `storage_bytes` implies a separate amount pinned to the trie at the current rate of 10^19 yoctoNEAR per byte. One pipeline over `/full` breaks them apart. ```bash ACCOUNT_ID=root.near curl -s "https://api.fastnear.com/v1/account/$ACCOUNT_ID/full?apiKey=${FASTNEAR_API_KEY:-}" \ | jq ' (.state.balance | tonumber) as $amount | (.state.locked | tonumber) as $locked | (.state.storage_bytes * 10000000000000000000) as $pinned | 1e24 as $ynear | { account_id, near: { total_owned: (($amount + $locked) / $ynear), unstaked: ($amount / $ynear), stake_or_lockup: ($locked / $ynear), pinned_to_storage: ($pinned / $ynear), spendable: (($amount - $pinned) / $ynear) } }' ``` For `root.near`: ~3914.67 NEAR total, all unstaked, ~0.28677 NEAR pinned to 28,677 bytes of on-chain state, and ~3914.38 NEAR spendable. New accounts feel this most acutely — a fresh named account of ~182 bytes has ~0.00182 NEAR stuck to storage, which is why CLI tools refuse to let you send an account's full balance. Point the same pipeline at a validator pool like `astro-stakers.poolv1.near` and the numbers invert: ~730 K unstaked, ~27.68 M in `locked`. That `locked` is the pool's own protocol-level validator stake, not the delegators' funds (those are tracked inside the pool contract's state). The same field means different things on different account types. jq uses IEEE-754 doubles, so the NEAR values above are display-precision only — keep the raw yocto strings if you need exact bookkeeping. ### When did anything about this account last change? Every entry under `/full`'s `tokens`, `nfts`, and `pools` arrays carries its own `last_update_block_height` — the block at which the indexer last saw that row change for this account. Taking the max across all three arrays gives a cheap "latest activity" signal without touching the transaction API. ```bash ACCOUNT_ID=root.near curl -s "https://api.fastnear.com/v1/account/$ACCOUNT_ID/full?apiKey=${FASTNEAR_API_KEY:-}" \ | jq ' [ (.tokens // [])[].last_update_block_height, (.nfts // [])[].last_update_block_height, (.pools // [])[].last_update_block_height ] as $heights | ($heights | map(select(. != null))) as $tracked | { account_id, total_entries: ($heights | length), tracked_entries: ($tracked | length), most_recent_block: ($tracked | max), oldest_tracked_block: ($tracked | min) }' ``` For `root.near`, this returns 254 total entries across FT, NFT, and pool contracts, 158 with a tracked block, and a most-recent block of `194301659`. That's enough to tell you the wallet is still active without touching transaction history. This is the right question for "has this wallet been recently active?" or "has anything moved since block X?" — cheap, one call, no transaction history needed. For the transaction that caused the latest change, widen to the [Transactions API](https://docs.fastnear.com/tx). Entries with `last_update_block_height: null` predate the indexer's per-row tracking (typically older airdrops) and are ignored here rather than counted as recent. ### Show NFT collections this wallet holds from a specific publisher NEAR account names encode a hierarchy: `mint.sharddog.near` is a subaccount of `sharddog.near`, which is a subaccount of `near`. Publishers that ship multiple NFT collections usually deploy each one as its own subaccount, so a single suffix filter over the account's NFT list recovers everything under one publisher tree — no external collection registry required. ```bash ACCOUNT_ID=root.near PUBLISHER=sharddog.near curl -s "https://api.fastnear.com/v1/account/$ACCOUNT_ID/nft?apiKey=${FASTNEAR_API_KEY:-}" \ | jq --arg publisher "$PUBLISHER" ' ("." + $publisher) as $suffix | { account_id: .account_id, publisher: $publisher, collections: [ .tokens[] | select(.contract_id | endswith($suffix)) | { contract_id, last_update_block_height, status: (if .last_update_block_height == null then "dormant" else "active" end) } ] | sort_by(.last_update_block_height // 0) }' ``` For `root.near` and `sharddog.near`, this returns four subaccount contracts: `ndcconstellationnft`, `mint`, `harvestmoon`, and `claim`. Only `claim` carries a non-null `last_update_block_height` (`131402024`), so that's the one contract where the wallet's position clearly changed. The others are dormant — common for drop-era contracts an account received into but never interacted with again. Swap `PUBLISHER` to any account to scope the filter to a different publisher tree. ### Does this wallet show direct staking, liquid staking tokens, or both? Direct pool positions live on `/staking`; liquid staking tokens (stNEAR, LiNEAR, etc.) sit on `/ft` like any other FT. Read both, classify the wallet — `root.near` shows up as `mixed`. ```bash ACCOUNT_ID=root.near LIQUID_PROVIDERS_JSON='["meta-pool.near","lst.rhealab.near","linear-protocol.near"]' STAKING="$(curl -s "https://api.fastnear.com/v1/account/$ACCOUNT_ID/staking?apiKey=${FASTNEAR_API_KEY:-}")" FT="$(curl -s "https://api.fastnear.com/v1/account/$ACCOUNT_ID/ft?apiKey=${FASTNEAR_API_KEY:-}")" jq -n \ --argjson staking "$STAKING" \ --argjson ft "$FT" \ --argjson providers "$LIQUID_PROVIDERS_JSON" ' ($staking.pools // []) as $direct | (($ft.tokens // []) | map(select(.contract_id as $id | $providers | index($id)))) as $liquid | { classification: ( if ($direct|length)>0 and ($liquid|length)>0 then "mixed" elif ($direct|length)>0 then "direct_only" elif ($liquid|length)>0 then "liquid_only" else "no_visible_staking_position" end ), direct_pools: ($direct | map(.pool_id)), liquid_tokens: ($liquid | map({contract_id, balance})) }' ``` The classifier only knows what you teach it — extend `LIQUID_PROVIDERS_JSON` as new liquid-staking products ship, and treat the result as observational rather than exhaustive. ## Common mistakes - Leading with the broad account snapshot when the user only asked about one asset family. - Using FastNear API when the user explicitly needs exact RPC fields or permissions. - Staying in account-summary pages after the question turns into transaction history. ## Related guides - [FastNear API](https://docs.fastnear.com/api) - [API Reference](https://docs.fastnear.com/api/reference) - [RPC Reference](https://docs.fastnear.com/rpc) - [Transactions API](https://docs.fastnear.com/tx) - [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces) - [Agent Playbooks](https://docs.fastnear.com/agents/playbooks) --- ## API Reference - HTML path: https://docs.fastnear.com/api/reference - Markdown path: https://docs.fastnear.com/api/reference.md **Source:** [https://docs.fastnear.com/api/reference](https://docs.fastnear.com/api/reference) # API Reference This route explains what belongs in FastNear's REST layer and how to choose among the REST families before dropping to raw JSON-RPC. The `/api` sidebar is intentionally the **FastNear API** sidebar, not a catch-all REST sidebar. Other REST families such as [Transactions API](https://docs.fastnear.com/tx), [Transfers API](https://docs.fastnear.com/transfers), [NEAR Data API](https://docs.fastnear.com/neardata), and [KV FastData API](https://docs.fastnear.com/fastdata/kv) each live at their own top-level section. ## REST families at a glance | Family | Start here when... | Move elsewhere when... | | --- | --- | --- | | [FastNear API](https://docs.fastnear.com/api) | you want indexed account, token, NFT, staking, or public-key views | you need canonical protocol-native RPC semantics | | [Transactions API](https://docs.fastnear.com/tx) | you want transaction, receipt, account, or block history | you only need transfer events or exact RPC-level behavior | | [Transfers API](https://docs.fastnear.com/transfers) | the question is specifically about NEAR or FT movement | the question broadens to general execution history | | [NEAR Data API](https://docs.fastnear.com/neardata) | you want recent optimistic or finalized block-family reads | you need exact canonical block or state follow-up | | [KV FastData API](https://docs.fastnear.com/fastdata/kv) | you want indexed key-value history or latest indexed key state | you need exact current on-chain contract state | ## What `/api` itself is for Use the [FastNear API](https://docs.fastnear.com/api) section when the user wants a product-shaped answer without stitching raw node responses together: - account summaries - FT balances - NFT holdings - staking positions - public-key to account resolution Good starting pages in this sidebar: - [V1 Full Account View](https://docs.fastnear.com/api/v1/account-full) - [V1 Account FT](https://docs.fastnear.com/api/v1/account-ft) - [V1 Account NFT](https://docs.fastnear.com/api/v1/account-nft) - [V1 Account Staking](https://docs.fastnear.com/api/v1/account-staking) - [V1 Public Key](https://docs.fastnear.com/api/v1/public-key) ## When not to use `/api` Do not start in this sidebar when: - the primary job is history; use [Transactions API](https://docs.fastnear.com/tx) or [Transfers API](https://docs.fastnear.com/transfers) - the primary job is recent block polling; use [NEAR Data API](https://docs.fastnear.com/neardata) - the answer must stay close to canonical node request and response shapes; use [RPC Reference](https://docs.fastnear.com/rpc) ## For agents If the caller is an AI agent and the choice is still unclear, use: - [Agents on FastNear](https://docs.fastnear.com/agents) - [Choosing the Right Surface](https://docs.fastnear.com/agents/choosing-surfaces) --- ## Auth & Access - HTML path: https://docs.fastnear.com/auth - Markdown path: https://docs.fastnear.com/auth.md **Source:** [https://docs.fastnear.com/auth](https://docs.fastnear.com/auth) # Auth & Access One FastNear API key works across the RPC and API endpoints. Keep the auth model simple: use the same credential everywhere and send it either as a Bearer header or an `apiKey` query parameter. Get a key in [FastNear Dashboard](https://dashboard.fastnear.com). Live example pages also support `Copy example URL` for sharing prefilled requests. Shared example URLs run automatically on load whenever they include operation state, and saved API keys and tokens are never included in those public docs URLs. ## If you only need the rule - One FastNear API key works across RPC and API endpoints. - Set `FASTNEAR_API_KEY` in your shell, runtime, or secret manager. - Prefer `Authorization: Bearer ${FASTNEAR_API_KEY}` for production backends. - Use `?apiKey=${FASTNEAR_API_KEY}` when headers are awkward or you are doing quick curl/debug work. - Agents and automations should keep the key in env vars or a secret manager, not in browser storage. - Building a browser or frontend app? Ship a [browser key](https://docs.fastnear.com/auth/browser-keys) restricted to your domains, not a plain server key. ## Choose the auth form | Form | Best for | Notes | | --- | --- | --- | | `Authorization: Bearer ${FASTNEAR_API_KEY}` | production backends, workers, automations, and proxies | Best default. Keeps credentials out of copied URLs and most URL logs. | | `?apiKey=${FASTNEAR_API_KEY}` | simple curl, one-off debugging, systems that cannot set headers easily | Valid, but the key may end up in shell history, logs, analytics, or copied links. | If you control the client, use the header form. ## Authorization header example ```bash : "${FASTNEAR_API_KEY:?Set FASTNEAR_API_KEY in your shell before running this example.}" curl "https://rpc.mainnet.fastnear.com" \ -H "Authorization: Bearer $FASTNEAR_API_KEY" \ -H "Content-Type: application/json" \ --data '{"method":"block","params":{"finality":"final"},"id":1,"jsonrpc":"2.0"}' ``` ## `?apiKey=` query parameter example ```bash : "${FASTNEAR_API_KEY:?Set FASTNEAR_API_KEY in your shell before running this example.}" curl "https://rpc.mainnet.fastnear.com?apiKey=$FASTNEAR_API_KEY" \ -H "Content-Type: application/json" \ --data '{"method":"block","params":{"finality":"final"},"id":1,"jsonrpc":"2.0"}' ``` ## Where this applies - [RPC Reference](https://docs.fastnear.com/rpc) uses the shared FastNear key model on both the regular and archival hosts. - API families reuse the same key shape across the REST surfaces. - The docs UI can forward a saved FastNear key for supported pages, but that browser storage behavior is a docs convenience, not a production pattern. For agent and automation runtimes, use [Auth for Agents](https://docs.fastnear.com/agents/auth). ## Production defaults Use these defaults unless you have a specific reason not to: - keep the key in an env var or secret manager - inject it at the backend, worker, or proxy layer - prefer the Bearer header over the query parameter - rotate the key if it leaks into a prompt, URL, or debug log ## Common failure modes ### The request works without a key in one context but not another That usually means you moved from public traffic to a higher-limit or authenticated path. Add the same FastNear key you use elsewhere. ### I switched from regular RPC to archival RPC Use the same FastNear key and the same header or query-param transport on both hosts. Only the retention profile changes. ### My key is showing up in logs Switch to the `Authorization` header if you are currently using `?apiKey=`. URLs tend to travel through more logging and observability systems. ### The docs UI worked, but my backend does not Do not rely on browser storage behavior from the docs UI. Production backends should inject credentials explicitly. ### I am building an agent or automation Use [Auth for Agents](https://docs.fastnear.com/agents/auth) for the runtime posture. Browser `localStorage` is a docs convenience, not an agent secret store. ### I am building a browser or frontend app Do not ship a server key in your frontend. Use a [browser key](https://docs.fastnear.com/auth/browser-keys) restricted to your site's domains, with a per-key rate cap, so a copied key is hard to reuse and cannot drain your quota. --- ## Browser Keys - HTML path: https://docs.fastnear.com/auth/browser-keys - Markdown path: https://docs.fastnear.com/auth/browser-keys.md **Source:** [https://docs.fastnear.com/auth/browser-keys](https://docs.fastnear.com/auth/browser-keys) # Browser Keys A FastNear API key normally lives on a backend. But if your app talks to FastNear directly from the browser, you can publish a key in your frontend and **restrict it to your website's domains** so a copied key is hard to reuse elsewhere. This is the *browser key* (or *UI key*) posture. Two postures, one credential model: | Posture | Where the key lives | How it is protected | | --- | --- | --- | | **Server key** (default) | backend, worker, proxy, secret manager | kept secret; never shipped to clients. See [Auth & Access](https://docs.fastnear.com/auth). | | **Browser key** | shipped in your frontend bundle | restricted to your site's `Origin`/`Referer`, plus a per-key rate cap. This page. | A browser key is **not a secret** — anyone can read it from your page source. The restriction makes it inconvenient to reuse and the rate cap limits the damage if it is. For anything that must stay secret, use a server key. :::info Availability Website restrictions are a **paid-plan** feature. On the free tier the control is disabled — upgrade your project in [FastNear Dashboard](https://dashboard.fastnear.com) to enable browser keys. ::: ## If you only need the rule - Create a key in the dashboard, then turn on **Restrict to websites** and list your domains. - A restricted key only works from a browser on a matching `Origin` (or `Referer`); everything else gets `403 origin_not_allowed` — including your own backend. - Calling from the browser works with either `Authorization: Bearer ...` or `?apiKey=...`; FastNear's RPC answers the CORS preflight, so both forms work. - Set a **Rate cap** on the key so a lifted key cannot burn your whole plan's quota. - A restriction is a **deterrent, not a secret**. Keep a separate, unrestricted server key for backend work. ## Restrict a key to your website 1. Open your project in [FastNear Dashboard](https://dashboard.fastnear.com) and create (or pick) an API key. 2. Turn on **Restrict to websites**. 3. List the domains your app is served from, comma-separated: ```text example.com, *.example.com ``` - Matching is **exact** on the hostname. `example.com` does **not** cover `www.example.com` or `app.example.com` — add each host, or use a wildcard. - `*.example.com` matches any direct subdomain (`app.example.com`, `www.example.com`). - You can list up to **20 domains** per key. - Do not include the scheme, port, or path — just the hostname (`app.example.com`, not `https://app.example.com/`). Turning the restriction **on** hard-blocks every caller without a matching `Origin`/`Referer`, *including your own server-side traffic with that key*. Use a separate unrestricted key for backend calls. ## How the restriction is enforced The check runs at the edge, before the request reaches the RPC, against the browser-set `Origin` header (with `Referer` as a fallback): | Request | Result | | --- | --- | | `Origin` matches an allowed domain | ✅ passes | | No `Origin`, but `Referer` matches | ✅ passes | | `Origin` present but not allowed | ⛔ `403 origin_not_allowed` | | Neither `Origin` nor `Referer` (e.g. curl, a backend) | ⛔ `403 origin_not_allowed` | | A subdomain of an allowed domain, with no wildcard | ⛔ `403 origin_not_allowed` | `Origin` takes precedence over `Referer` — a request with a disallowed `Origin` is rejected even if the `Referer` would have matched. The `403` body is `{"error":"origin_not_allowed"}`. A key with **no** website restriction is treated as a server key: the origin check is skipped and it works from anywhere (so keep it secret). ## Call FastNear from the browser FastNear's RPC endpoint returns permissive CORS headers and answers the preflight `OPTIONS` request, so a browser `fetch()` works directly — no proxy required. ```js // Served from https://app.example.com (an allowed domain on this key) const FASTNEAR_API_KEY = 'YOUR_BROWSER_KEY'; // restricted to app.example.com const res = await fetch('https://rpc.mainnet.fastnear.com', { method: 'POST', headers: { 'Authorization': `Bearer ${FASTNEAR_API_KEY}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'block', params: { finality: 'final' }, }), }); const data = await res.json(); ``` The browser sends your site's `Origin` automatically, so the edge can enforce the restriction. The `?apiKey=` query form works too and is handy when setting headers is awkward: ```js const res = await fetch(`https://rpc.mainnet.fastnear.com?apiKey=${FASTNEAR_API_KEY}`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'block', params: { finality: 'final' } }), }); ``` :::note If a browser call exceeds your rate limit, the `429` response may not yet include CORS headers, so the browser can surface it as a generic network error rather than the JSON limit message. Treat a sudden `fetch` failure under load as a possible rate-limit hit. ::: ## Limit the blast radius A published key will eventually be copied. Two controls keep that cheap: - **Rate cap** — set a per-key cap (requests per minute) below your plan default. A lifted key can then only consume up to that cap, not your whole quota. Leave it blank to use the plan default. - **Rotate** — if a key is abused, use **Rotate** to issue a new value while keeping the same restrictions and cap. Update your site with the new value; the old value stops working at the edge shortly after, once the change syncs. ## This is a deterrent, not a secret :::caution `Origin` and `Referer` are set by the browser, but a non-browser client (curl, a script) can forge them. So a website restriction stops **casual reuse of a key lifted from your page**, but it is **not** a hard security boundary. ::: What this means in practice: - The risk of a leaked browser key is **quota and cost abuse** — someone running up usage against your plan. FastNear API keys are rate-limit/billing credentials, not NEAR account keys, so a leaked browser key cannot move funds or sign transactions on your accounts. - Your real backstops are the **rate cap** (bounds the damage) and **rotation** (ends it). - Never put a credential that must stay secret in the browser. Use a [server key](https://docs.fastnear.com/auth) behind your backend for anything sensitive or unrestricted. ## Common failure modes ### `403 origin_not_allowed` from curl or my backend Expected — a restricted key only works from a browser on an allowed domain. Backends and curl send no `Origin`/`Referer`. Use a separate unrestricted server key for backend traffic. ### It works on `example.com` but not `www.example.com` Hostname matching is exact. Add `www.example.com` to the key, or use `*.example.com` to cover subdomains. ### My browser call fails with no useful error If you are over your rate limit, the `429` may arrive without CORS headers and show up as a generic network error. Check your usage, and consider whether your key's rate cap is too low. ### The docs UI worked, but my app does not The docs site can forward a saved key for convenience; that is not the production pattern. Ship your own restricted browser key, served from a domain you listed on the key. ### I need both browser and backend access Use two keys: a restricted browser key for the frontend, and an unrestricted server key for the backend. Do not try to share one key across both. ### My key fails from inside an embedded or sandboxed iframe A sandboxed `