Platform status endpoints

Overview

The platform-status endpoints expose the same operational panels that back the DALP status view. Use them when an operations console, support runbook, or monitoring integration needs a compact view of platform health across data freshness, transaction infrastructure, API activity, and workflow execution. To read the same signals in the Console instead, see Monitor platform status.

The API surface is read-only. It reports current and recent operational signals. It does not change token, wallet, compliance, workflow, or chain state.

Access and scope

Platform-status calls require an authenticated DALP account with access to the platform status view for the active organisation and system. Responses are assembled from DALP operational telemetry and can return no_data when a fresh deployment or clean environment has not produced enough rollup data yet.

Treat no_data as an honest neutral state, not as proof that the platform is healthy. Use degraded and outage for incident handling, then move to the panel-specific endpoint to see which signal changed.

Endpoint summary

Read the panel and stat-card endpoints for current state, and the history endpoint for the trailing strip.

Two detail-list endpoints sit one level below the panels. Use them to drill from a panel verdict into the underlying transactions or workflow invocations.

A legacy aggregate endpoint, GET /api/v2/platform-status/snapshot, is being retired. See Legacy snapshot aggregate before you build on it.

Verdict values

Platform-status responses use four verdict values:

The platform rolls verdicts up in severity order: outage wins over degraded, degraded wins over operational, and no_data applies only when no panel has operational data. Combine the four panel verdicts the same way when you want a single header signal for a dashboard.

Platform API verdict thresholds

The Platform API panel uses the trailing 24-hour request counts for its verdict. DALP treats zero requests as no_data because there is no activity to classify.

Authentication failures are not counted as platform 4xx degradation. Treat them as client or credential signals and use API monitoring to inspect the request path before escalating the platform-status verdict.

Workflow verdict thresholds

The Workflows panel compares currently stalled workflows against the completed-workflow count from the trailing 24-hour window. When DALP cannot determine the completed count, the panel returns no_data. This matters because zero stalled workflows and an unknown completed count are different states: the first is clean, the second is inconclusive.

Use the Workflows panel to decide whether to inspect workflow recovery. See Workflow engine recovery when stalled or missing workflow signals need operator follow-up.

Read a focused panel

Each panel endpoint covers one operating area. A dashboard or runbook calls the data-freshness, transactions, platform-api, or workflows endpoint directly and reads only the signals it needs.

curl "$DALP_API_URL/api/v2/platform-status/data-freshness"   --header "X-Api-Key: ${DALP_API_TOKEN}"

curl "$DALP_API_URL/api/v2/platform-status/platform-api"   --header "X-Api-Key: ${DALP_API_TOKEN}"

Each panel response includes generatedAt, a verdict, a sparkline, and a panel-specific stats object. Sparkline points use hour-aligned bucketHour timestamps and a numeric value; value can be null when the bucket has no observations.

The data-freshness panel reports chainsInSync, totalChains, and syncErrors24h. The platform API panel reports totalRequests24h, error4xxRate, and error5xxRate. Rates are returned as fractions from 0 to 1; multiply by 100 only in the display layer.

Workflow fields such as completed24h and stalled can be null until workflow telemetry is available. Do not coerce those values to zero in monitoring code, because zero and unknown mean different things.

How the Transactions panel reads redundant RPC

A bank running production assets points each chain at more than one RPC upstream so the platform keeps serving when a node fails. The Transactions panel reflects that redundancy. The panel stays operational while one upstream of a chain is down, and degrades only when a whole chain loses every reachable upstream. Read this section when a panel verdict looks surprising next to a node you know is offline.

DALP rolls the chain-RPC upstreams up in two steps:

• Within a chain, take the healthiest upstream. A chain is as healthy as its best reachable upstream. One upstream degraded or unreachable while another stays healthy leaves the chain operational.
• Across chains, take the worst chain. The panel is only as healthy as its least healthy chain, in the same severity order the rest of the page uses: outage wins over degraded, degraded wins over operational.

So a single redundant node going down does not move the panel, while a whole chain going dark turns it degraded or outage.

The panel reads only the upstreams in the active RPC pool. When an administrator removes or replaces an upstream, the upstream's last recorded health stops counting against the verdict, so a retired endpoint cannot hold the panel degraded after it leaves the pool.

The stats.chainCount value counts distinct chains, not upstream rows. A chain served by three upstreams contributes one to chainCount, so the number matches the chains you operate rather than the size of each redundant pool.

Drill into the detail lists

The panels report a verdict and a sparkline. When you need the rows behind the number, call the matching detail-list endpoint. Both are read-only and require the same access as the panels. The transactions list is scoped to the active organisation; the workflows list reports platform-wide workflow-engine activity and is not organisation-scoped.

Transactions list

The transactions-list endpoint returns the organisation-wide transaction queue: every wallet in the organisation, including the system, executor, and onboarding wallets that the wallet-scoped transaction APIs hide. Use it to investigate a transactions panel that has turned degraded or to build an admin transaction view.

curl -G "$DALP_API_URL/api/v2/platform-status/transactions-list"   --header "X-Api-Key: ${DALP_API_TOKEN}"   --data-urlencode "filter[status]=FAILED"   --data-urlencode "sort=-createdAt"   --data-urlencode "page[limit]=50"

The transactions-list endpoint is a standard collection endpoint. It accepts the usual filter, sort, and pagination parameters, defaults to newest first, and supports global search with filter[q]. You can filter on status, operationType, fromAddress, chainId, createdAt, and updatedAt. The response uses the collection envelope: a data array of transaction rows, a meta object with the matched total and facets, and links for paging.

Each transaction row carries the queue identifier, the submitted operation and a decoded label, the current queue status and any sub-status, and the sender address and target chain. Once the transaction broadcasts, the row also reports the assigned nonce, gas price, transaction hash, and confirmation-check count. Failure rows add the error message, the decoded revert reason, and a DALP contract-error code when one was decoded. Each row also includes a traceId that links the request across DALP services for deeper investigation. Broadcast and failure fields are null until the transaction reaches that stage, so keep the unknown state distinct from an empty value.

Workflows list

The workflows-list endpoint returns a bounded snapshot of recent and in-flight workflow invocations. Use it to inspect the activity behind the workflows panel.

curl -G "$DALP_API_URL/api/v2/platform-status/workflows-list"   --header "X-Api-Key: ${DALP_API_TOKEN}"   --data-urlencode "limit=100"

limit accepts 1 to 500 and defaults to 100. Unlike the transaction queue, this list has no page cursor: the response is a single bounded page. It returns generatedAt, an items array, the total returned after monitoring-only invocations are excluded, and a truncated flag that is true when older invocations were dropped to fit the limit. Each invocation reports its identifier, the workflow type, the current lifecycle status, the terminal outcome (success or failure, or null while still in flight), and the submitted and last-advanced timestamps.

The list is not a plain newest-first feed. It ranks stalled active invocations first, then fresh active ones, then legitimately waiting ones, then terminal ones, and orders by most recently advanced within each group. This keeps the rows behind a degraded panel visible even when newer healthy invocations would otherwise push them past the limit. When truncated is true, raise the limit rather than assuming the omitted rows are the oldest, because a recent terminal invocation can rank below an older stalled one.

The list merges two independent sources so it reflects reality even when no single store holds everything: live in-flight and stalled invocations from the workflow engine, and the durable history of completed invocations. Each source degrades on its own and the request still returns HTTP 200. If live workflow-engine state is briefly out of reach, the response still carries the durable completion history, and if the completion history cannot be read, the response still carries the live invocations. A transient blip in one source never empties the page. The list goes empty only when both sources are unavailable at once, matching how the workflows panel degrades to no_data. Treat an empty items array on a single poll as inconclusive, not as proof that no workflows are running.

Read the stat cards

Use the stat-cards endpoint when a dashboard needs the compact operational numbers alongside the current-versus-previous comparison window.

curl "$DALP_API_URL/api/v2/platform-status/stat-cards"   --header "X-Api-Key: ${DALP_API_TOKEN}"

The response reports trailing-24-hour values and the matching previous-24-hour values for completed operations, success rate, and P95 completion time, plus the worst data-delay in blocks, the timestamp that delay was measured at, and the total indexed block height. Each value can be null when DALP could not produce that metric for the window, so keep the unknown state distinct from zero in display and alerting code.

Read trailing history

Use history when you need a compact strip of recent severity by service.

curl -G "$DALP_API_URL/api/v2/platform-status/history"   --header "X-Api-Key: ${DALP_API_TOKEN}"   --data-urlencode "days=14"

days defaults to 30 and is capped at 30. Each row carries a status kind, a human-readable serviceLabel, and oldest-first day cells, each with a UTC date and the worst severity observed for that row on that date.

How rows map to services

The kind field is one of dataFreshness, transactions, platformApi, or workflows, matching the four panels. A kind can expand to more than one row, because history reports severity per service rather than per panel:

• dataFreshness returns one row per observed indexer service with rollup data in the requested window, labelled by network and chain, such as Indexer · Sepolia (11155111). An indexer that is configured but has no rollup rows in the window is omitted.
• transactions returns one row per observed chain RPC upstream with rollup data in the requested window, labelled by network, chain, and upstream host, such as Chain RPC · Sepolia (11155111) · rpc.example.com. A chain served by several redundant upstreams therefore produces several rows here. The history view is per upstream, while the panel's stats.chainCount counts one per chain. An upstream in the active pool that has no rollup rows in the window is omitted.
• platformApi and workflows each return a single aggregated row.

Only upstreams in the active RPC pool produce transactions rows, so a removed or replaced upstream stops appearing once it leaves the pool. Upstream rows are labelled by host only, never by full endpoint URL, so a provider key embedded in an endpoint never reaches the response.

Legacy snapshot aggregate

GET /api/v2/platform-status/snapshot returns the header verdict, all four panel verdicts, and stat-card values in one response. This aggregate is a legacy convenience endpoint and is being retired. Its responses carry standard HTTP Deprecation and Sunset headers, along with Link headers pointing to the successor endpoints.

Build new integrations on the panel and stat-card endpoints instead. They return the same signals, let each dashboard or runbook read only what it needs, and are not scheduled for removal:

• GET /api/v2/platform-status/data-freshness
• GET /api/v2/platform-status/transactions
• GET /api/v2/platform-status/platform-api
• GET /api/v2/platform-status/workflows
• GET /api/v2/platform-status/stat-cards

If you call snapshot today, read the Sunset header for the retirement date and migrate before it. To reproduce the rolled-up header verdict, combine the four panel verdicts in severity order: outage wins, then degraded, then operational, then no_data.

Operational notes

• These endpoints are status and observability reads, not availability guarantees.
• no_data should be displayed separately from operational.
• Nullable stat-card values mean DALP could not produce that metric for the current window.
• Use the transactions-list and workflows-list endpoints to drill from a panel verdict into the underlying rows.
• Use API monitoring when you need request logs, endpoint metrics, and API traffic timelines.
• Use blockchain monitoring when you need chain, RPC, indexer, or transaction operational checks.

Related guides

• API reference for the generated OpenAPI contract.
• API monitoring for request logs and API traffic metrics.
• Workflow engine recovery for operator recovery steps after checking workflow state.
• Blockchain monitoring for chain and transaction monitoring workflows.