data | array | Yes | |
data[].args | object | Yes | Event arguments as a structured JSON value. Parsed from the JSON string the indexer writes into the args column. null when the indexer wrote nothing (no args) or when the stored string failed to parse. The shape is intentionally any-value: the substrate-archive decoder produces an object for named-field composites, an array for tuple-style unnamed composites, and a string for empty variants (composite_inner_to_json in substrate-archive/src/decode.rs). Advertising the schema as object-only would make generated SDKs reject valid rows. utoipa 5's built-in ToSchema for serde_json::Value emits SchemaType::AnyValue (no type constraint), which matches the contract. #[schema(required)] keeps the field always present in responses — when the row's args is None, the JSON value is the explicit literal null rather than an omitted field. |
data[].block_number | integer (int32) | Yes | Block height. |
data[].call_id | string, nullable | Yes | Associated call ID; null when the event hasn't been mapped to a call. |
data[].extrinsic_id | string, nullable | Yes | Parent extrinsic ID; null for Initialization / Finalization phase events. |
data[].id | string | Yes | {block_number}-{event_idx:04} (event_idx is the global index within the block, across all phases). |
data[].index | integer (int32) | Yes | Event index within the block (global across phases). |
data[].name | string | Yes | Event name. |
data[].pallet | string | Yes | Pallet name. |
data[].phase | string | Yes | Event phase: Initialization, Finalization, or ApplyExtrinsic. |
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. |