data | array | Yes | |
data[].args | object | | Call arguments as a structured JSON value. Parsed from the JSON string the indexer writes into the args column. null when the indexer didn't record args. Omitted by default on this listing endpoint to keep payloads small (a Sudo.sudo_unchecked_weight wrapping System.set_code inlines an 8.78 MB WASM blob). Opt back in with ?include_args=true, by selecting it via ?fields=args, or by targeting a single row with id= (the detail path). When omitted the column is not read from ClickHouse at all. The derived args_summary is always present. Schema-optional (not in required): unlike other nullable fields, args may be absent from a response — that is the #41 default — so SDKs must model it as optional, not present-but-null. |
data[].args_summary | object | Yes | Always-present (~100 B) summary of the call's single inner/wrapped call. The inner_call* sub-fields are null when the row has no inner call. Lets a client flag a runtime upgrade, and size it, without fetching the blob. See [ArgsSummary]. |
data[].args_summary.args_size_bytes | integer (int64) | Yes | Exact byte length of the row's whole stored args column — always present, always exact, and cheap to read (length(args) never transfers the value). 0 when the row has no args. |
data[].args_summary.inner_call | string, nullable | Yes | Inner call's full name (Pallet.Name, e.g. "System.set_code"), or null when the row has no inner call. |
data[].args_summary.inner_call_kind | string, nullable | Yes | Coarse classification of the inner call, or null when the row has no inner call. One of runtime_upgrade, wrapped_call. |
data[].args_summary.inner_call_size_bytes | integer (int64), nullable | Yes | Byte length of the inner call's JSON-encoded args (the heavy payload). null when the row has no inner call, and when the row's args did not fit in the [ARGS_HEAD_CHARS] prefix the listing reads and the caller did not request the column: measuring it would mean reading a multi-MiB blob, which is the read that killed the pods (#574). args_size_bytes carries the magnitude in that case, and ?include_args=true (or id=) makes this field exact again. |
data[].block_number | integer (int32) | Yes | Block height. |
data[].error | object | Yes | Error details (JSON) if the call failed. Root calls carry System.ExtrinsicFailed; child calls carry the boundary-event error. |
data[].extrinsic_id | string | Yes | Parent extrinsic ID (the root call's id). Same value as id on root rows. |
data[].extrinsic_index | integer (int32) | Yes | Extrinsic index within the block. |
data[].id | string | Yes | Call ID. Format: {block}-{ext_idx:04}[-N[-N...]]. |
data[].name | string | Yes | |
data[].origin | object | Yes | RuntimeOrigin JSON. Populated on root rows; null on children. |
data[].origin_address | string, nullable | Yes | SS58 address of this call's RuntimeOrigin account, set by the immediate parent wrapper. Equal to signer_address on the root of a signed extrinsic; on children follows the wrapper (proxied real, sudo_as who, etc.). |
data[].pallet | string | Yes | |
data[].parent_id | string, nullable | Yes | Parent call ID, or null on root calls. |
data[].signer_address | string, nullable | Yes | SS58 address of the extrinsic signer — same on every call in a signed extrinsic; null for unsigned extrinsics. |
data[].success | boolean | Yes | |
data[].timestamp | string | Yes | ISO 8601 timestamp with millisecond precision, e.g. "2024-05-15T10:30:00.000Z". |
pagination | object | Yes | Pagination metadata appended to collection responses. next_page / prev_page are explicitly required+nullable in the OpenAPI spec: per docs/api_standards.md we emit null rather than omitting the field, so the SDK should model them as Option/nullable types that are always present in the response. total_items is the exact number of matching rows on every route (issue #992). It used to stop at 1,000,000, which reported a million transfers when finney holds 7,513,252 and a million events when the real figure is 981,179,110; the cap was removed on 29 Sep 2026 and nothing may reintroduce one — crate::pagination::exact_count_sql is the only count form, and no_capped_count_reaches_the_api_surface in data-debug-scripts fails the build if a capped one comes back. total_pages is still bounded, to crate::pagination::max_reachable_page(per_page), because the page parameter is capped to a 1,000,000-row window: deep OFFSET paging reads every skipped row (24.7M rows / 36.6 GiB / 42 s measured on one endpoint, issue #413). So total_pages is exactly the last page this API will serve and next_page / prev_page stay coherent at the window edge, while total_items tells the caller how many rows there really are. History beyond the window is reached with each endpoint's range filters, not a larger page. |
pagination.current_page | integer (int32) | Yes | 1-indexed page that produced the rows in data. |
pagination.next_page | integer (int32), nullable | Yes | Next page number, or null if this is the last page. |
pagination.per_page | integer (int32) | Yes | Number of items requested per page. |
pagination.prev_page | integer (int32), nullable | Yes | Previous page number, or null if this is the first page. |
pagination.total_items | integer (int64) | Yes | Number of items matching the query across all pages. This is the exact count — every matching row, however many there are. It is not bounded by total_pages, so a listing can legitimately report far more items than total_pages × per_page. |
pagination.total_pages | integer (int32) | Yes | Number of pages at the current per_page that this API will serve: ceil(total_items / per_page), capped at ceil(1000000 / per_page) because the page parameter only reaches into the first 1,000,000 rows. When the cap bites, total_items is still the true total and this is the last page a request can ask for; reach deeper history with the endpoint's range filters instead of a larger page. |