> ## Documentation Index > Fetch the complete documentation index at: https://docs.range.org/llms.txt > Use this file to discover all available pages before exploring further. # Working with responses > Interpret Platform API pagination, transaction identity, amounts, freshness, and operational statuses. Use this page when parsing workspace records from our Platform API. For public blockchain data, see [Data API responses](https://docs.range.org/data-api/product-info/working-with-responses.md). Authentication belongs in the [shared quickstart](https://docs.range.org/introduction/quickstart.md); failures and retries belong in [Errors and rate limits](https://docs.range.org/resources/errors-and-rate-limits.md). ## Pagination Platform lists have seven contracts. All operations in this table are `GET` requests. | Endpoints | Page parameters | Default and maximum | Continuation | | - | - | - | - | | `/v2/accounts`, `/v2/account-connections` | `size`, `cursor` | `50`, maximum `1000` | `items` and `meta.next_cursor` | | `/v2/accounts/{id}/transfers` | `size`, `cursor` | `100`, maximum `1000` | `items` and `meta.next_cursor` | | `/v2/accounts/transfers` | `size`, `cursor` | `5`, maximum `100` | `items` and `meta.next_cursor` | | `/v2/counterparties`, `/v2/parties`, `/v2/cases` | `limit`, `cursor` | `50`, maximum `200` | `items` and `meta.next_cursor` | | `/v2/workflows/runs`, `/v2/workflows/templates/{template}/accounts` | `limit`, `cursor` | `20`, maximum `100` | `items` and `meta.next_cursor` | | `/v2/investigations` | `limit`, `offset` | `50`, maximum `100`; offset defaults to `0` | `items` and `total` | | `/v2/groups`, `/v2/workflows` | None | Unpaginated | `items`, without a pagination `meta` | For cursor lists, reuse `meta.next_cursor` with the same filters and stop at `null`. Treat it as opaque. Do not assume every list returns `previous_cursor`, `total_count`, or `page_number`. For investigations, increase `offset` by the number of returned items. Stop at an empty page or when the next offset reaches `total`. ## Transaction identity and amounts On persisted transaction reads, `id` and `transaction_id` identify the stored transaction row. `provider_transaction_id` is the provider's event identifier; a public `hash` is a separate, optional field. On live adapter responses, `id` carries the provider-native identifier instead. See [Workspace data model](https://docs.range.org/platform-api/product-info/workspace-data-model.md#identifiers) before joining records. Read `kind` before interpreting the event payload: `TRANSFER` uses `transfers`, while `TRADE` uses `trade`. A transfer can have no parsed legs, so an empty `transfers` array does not establish that no event occurred. Keep decimal quantities as strings until you use decimal arithmetic. Transfer-leg `amount` and `usd_amount` are unsigned magnitudes; `transfers[].direction` supplies the account-relative direction (`IN`, `OUT`, or `SELF`). Custom-ingestion movement `quantity` is also unsigned, with `in` or `out` in its separate `direction`; snapshot quantities may be signed. The event's top-level `direction` is workspace-relative (`in`, `out`, or `internal`), based on the first transfer leg and all saved workspace accounts. A group filter does not redefine the workspace boundary. It is `null` for trades or transfers without parsed legs. Do not substitute it for the account-relative direction on each leg. ## Missing, hidden, and stale data * A balance's `usd: null` means no USD price is available. It is distinct from the decimal string `"0"`. * `hidden_count` counts holdings excluded by workspace token visibility settings. An empty visible `balances` array can coexist with hidden holdings; `hidden_usd` is only their aggregate known USD value. * `balances_updated_at` tracks a successful balance read. `last_balance_refresh_at` tracks the latest attempt, including failure. Read it with `last_balance_refresh_status` and `last_balance_refresh_reason`. * Transaction freshness is separate: `last_synced_at` is the last successful transaction sync, `transactions_history_from` marks its history coverage floor, and `sync_status` describes the latest sync run. A failed sync does not advance `last_synced_at`. These account fields describe persisted accounts. Connection previews can omit fields for records that have not been imported. A failed preview balance lookup is not evidence of a zero balance. ## Reconciliation outcomes `GET /v2/reconciliation/roll-forward` separates account eligibility from quantity tie-out: | Field | Meaning | | - | - | | Account `status` | `ok`, `no_observation`, or `unreconcilable`; the latter two have no lines. | | `effective_period` | Observation timestamps actually used, which may differ from `requested_period`. | | `reconcilable_from`, `synced_through`, `unreconcilable_reason` | Coverage boundaries and reasons the requested result cannot be fully evaluated. | | `tie_out_status` | `tied`, `explained`, `break`, or `not_evaluated`; separate from account `status`. | | `lines`, `declared_gaps` | Asset-level quantities and counter-assets missing from the connection's accounts. | An `ok` account with no lines can be `tied`. Check the expected account, asset, and nonempty quantities before treating a result as evidence of a reconciliation. A tie-out compares observed quantities; it does not prove complete transaction ingestion. An incomplete sibling scan can leave account `status: ok` while the account rollup is `not_evaluated`, so inspect `unreconcilable_reason` as well. ## Workflow execution, sync, and delivery Workflow runs expose four status fields: | Field | Values | What it answers | | - | - | - | | `execution_status` | `queued`, `running`, `succeeded`, `failed`, `cancelled`, `skipped` | Did the workflow execute? | | `tx_sync_status` | `not_applicable`, `waiting`, `completed`, `expired` | What happened to its transaction-sync phase? | | `delivery_status` | `not_required`, `pending`, `sending`, `sent`, `failed`, `cancelled`, `held` | What happened to notification delivery? | | `review_status` | `not_required`, `needs_labels`, `awaiting_review`, `sent` | What happened to CARF review? `needs_labels` and `awaiting_review` hold delivery at `held`; `sent` means released. | Execution success alone does not establish delivery success. Read these fields on `GET /v2/workflows/runs`; use the [API reference](https://docs.range.org/platform-api/api-reference-introduction.md) for run details and output contracts. ## Case status and resolution Case `status` is `open`, `in_review`, or `resolved`. `resolution` is separate and nullable, with `dismissed`, `escalated`, `paid`, and `explained` as its non-null values. `available_actions` describes actions for the case's source and current state; write permissions still apply. Follow [Triage a manual case](https://docs.range.org/platform-api/guides/triage-a-manual-case.md) for the transition sequence. A manual-case example does not establish the same actions for screening or redemption cases. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.