Platform status endpoints
Read DALP platform-status panels, stat cards, snapshots, and history from the current API.
Overview
The platform-status endpoints expose the same operational status 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.
This is a read-only API surface. 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
| Purpose | Method and path | Query parameters | Use it for |
|---|---|---|---|
| Data freshness panel | GET /api/v2/platform-status/data-freshness | None | Check indexed-chain freshness, total tracked chains, and 24-hour sync-error count. |
| Transactions panel | GET /api/v2/platform-status/transactions | None | Read transaction infrastructure status and tracked chain count. |
| Platform API panel | GET /api/v2/platform-status/platform-api | None | Review 24-hour API request volume, 4xx rate, and 5xx rate. |
| Workflows panel | GET /api/v2/platform-status/workflows | None | Check completed and stalled workflow counts when workflow telemetry is available. |
| Stat cards | GET /api/v2/platform-status/stat-cards | None | Read compact operational cards for completed workflows, success rate, completion time, data delay, and indexed blocks. |
| Snapshot | GET /api/v2/platform-status/snapshot | None | Fetch the header verdict, all four panel verdicts, and stat-card values in one response. |
| History | GET /api/v2/platform-status/history | days, from 1 to 30 | Read per-service per-day worst severity for the trailing window. |
Verdict values
Platform-status responses use four verdict values:
| Verdict | Meaning |
|---|---|
operational | At least one panel has current healthy observations and no higher-severity panel dominates the rollup. |
degraded | A panel has degraded observations that should be investigated before relying on the affected surface. |
outage | A panel reports outage-level observations. Treat this as incident-response input. |
no_data | DALP has no usable observations for that panel or rollup yet. This often appears in clean or newly deployed environments. |
The snapshot header is rolled up in severity order: outage wins over degraded, degraded wins over operational, and no_data is returned only when no panel has operational data.
Read the current snapshot
Use the snapshot endpoint when you need one call for a dashboard header or runbook gate.
curl "$DALP_API_URL/api/v2/platform-status/snapshot" --header "X-Api-Key: ${DALP_API_TOKEN}"The response includes:
generatedAt, the time DALP assembled the snapshot.headerVerdict, the rolled-up platform verdict.panels.dataFreshness,panels.transactions,panels.platformApi, andpanels.workflows.statCards, including workflow completion, success-rate, completion-time, data-delay, and indexed-block values.
Panel responses include a verdict and a sparkline. Sparkline points use hour-aligned bucketHour timestamps and a numeric value; value can be null when the bucket has no observations.
Read a focused panel
Use the focused endpoints when a dashboard or runbook already knows which operating area 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}"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.
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 identifies the status kind, provides a human-readable service label, and returns oldest-first day cells with a UTC date and the worst severity for that service on that date.
Operational notes
- These endpoints are status and observability reads, not availability guarantees.
no_datashould be displayed separately fromoperational.- Nullable stat-card values mean DALP could not produce that metric for the current window.
- 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 actions after checking workflow state.
- Blockchain monitoring for chain and transaction monitoring workflows.