---
title: "Get a Block"
method: POST
path: "/block"
tags: ["Block"]
---

# Get a Block

`POST /block`

Get a block by its Block Identifier. If transactions are returned in
the same call to the node as fetching the block, the response should
include these transactions in the Block object. If not, an array of
Transaction Identifiers should be returned so /block/transaction
fetches can be done to get all transaction information.

When requesting a block by the hash component of the BlockIdentifier,
this request MUST be idempotent: repeated invocations for the same
hash-identified block must return the exact same block contents.

No such restriction is imposed when requesting a block by height,
given that a chain reorg event might cause the specific block at
height `n` to be set to a different one.

## Request body

- BlockRequest — A BlockRequest is utilized to make a block request on the /block endpoint.
  - `network_identifier` NetworkIdentifier, required — unresolved $ref
  - `block_identifier` PartialBlockIdentifier, required — unresolved $ref

## Response `200`

Expected response to a valid request

- BlockResponse — A BlockResponse includes a fully-populated block or a partially-populated block with a list of other transactions to fetch (other_transactions). As a result of the consensus algorithm of some blockchains, blocks can be omitted (i.e. certain block indices can be skipped). If a query for one of these omitted indices is made, the response should not include a `Block` object. It is VERY important to note that blocks MUST still form a canonical, connected chain of blocks where each block has a unique index. In other words, the `PartialBlockIdentifier` of a block after an omitted block should reference the last non-omitted block.
  - `block` Block — unresolved $ref
  - `other_transactions` TransactionIdentifier[] — Some blockchains may require additional transactions to be fetched that weren't returned in the block response (ex: block only returns transaction hashes). For blockchains with a lot of transactions in each block, this can be very useful as consumers can concurrently fetch all transactions returned. — unresolved $ref

## Other responses

- `500` — unexpected error

## Changes

> 50 revisions in range; 1 could not be searched.

- **2020-08-21** `4037360db911` — 1 breaking
  - the response property `block` became optional for the status `200`
- **2020-08-21** `cbaf3fa1475f` — 1 info
  - the response property `block` became required for the status `200`
- **2020-08-08** `5df19558c023` — 1 breaking
  - removed the required property `block_omitted` from the response with the `200` status
- **2020-08-08** `8790cdae576b` — 1 breaking, 1 info
  - the response property `block` became optional for the status `200`
  - added the required property `block_omitted` to the response with the `200` status
- **2020-08-07** `97f3c6540212` — 1 info
  - the response property `block` became required for the status `200`

[Change history](https://skmtc.dev/coinbase/apis/rosetta/changes/block/post.md)

---

[API](https://skmtc.dev/coinbase/apis/rosetta.md) · [All operations](https://skmtc.dev/coinbase/apis/rosetta/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/coinbase/rosetta/revisions/758497aacc08/schema)