Actions feed and live updates

The actions feed is the work queue behind an asset operation. Every time-bound task a user can act on becomes an action: a bond maturity, a yield claim, an allowance approval, an XvP settlement step, a KYC update request, a multisig approval, or a pending custody approval. An operator running regulated assets needs to see that queue the way a back office sees a pending-work list. Read what is pending now, what is scheduled, what has executed, and what expired, then keep that view current without re-polling.

Use this reference when your integration drives an operator console over the actions queue or surfaces pending approvals to a user. The list endpoint returns a filtered, paginated snapshot. The stream endpoint pushes changes to that same list as they happen. Both are scoped to the caller and return the same row shape, so a console can load the list once and then follow the stream.

All endpoints are versioned under /api/v2. The feed is scoped to the authenticated user and the active organization.

List actions

GET /api/v2/actions

Return a paginated list of actions for the caller. Each row carries the action's type, display name, target, status, and lifecycle timestamps. The list spans both on-chain actions indexed from blockchain events and off-chain actions held in the platform, such as KYC update requests and pending custody approvals.

Filter with JSON:API query parameters. Combine filters to narrow a console view.

Results sort by activeAt descending by default. Override with sort and page with page[limit] (default 50, maximum 200) and page[offset].

status reports where an action sits in its lifecycle:

actionType filters on the canonical type of work an action represents. This type is stable: it stays the same even when the human-facing display name changes, so an integration can group tabs or route handling on it. The feed emits these action types:

curl --globoff -X GET \
  "$DALP_API_URL/api/v2/actions?filter[status]=PENDING&page[limit]=20" \
  --header "X-Api-Key: $DALP_API_TOKEN"

{
  "data": [
    {
      "id": "action-001",
      "actionType": "ClaimYield",
      "name": "Claim yield for Series A bond",
      "target": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
      "tokenAddress": "0x9aE2B1f3C0D4e5F6789012345678901234567890",
      "activeAt": "2026-03-09T10:00:00.000Z",
      "status": "PENDING",
      "executedAt": null,
      "executedBy": null,
      "expiresAt": "2026-04-09T10:00:00.000Z",
      "source": "on-chain"
    }
  ],
  "meta": {
    "total": 1,
    "facets": {
      "status": [{ "value": "PENDING", "count": 1 }],
      "actionType": [{ "value": "ClaimYield", "count": 1 }]
    }
  },
  "links": {
    "self": "/v2/actions?filter[status]=PENDING&page[limit]=20&page[offset]=0",
    "first": "/v2/actions?filter[status]=PENDING&page[limit]=20&page[offset]=0",
    "prev": null,
    "next": null,
    "last": "/v2/actions?filter[status]=PENDING&page[limit]=20&page[offset]=0"
  }
}

target is the contract an action acts on, such as the yield schedule for a ClaimYield row or the settlement for an XvP step. tokenAddress points at the underlying token when it differs from target, so a token-detail view can group every action attached to one asset. The two values are not always distinct: XvP settlement rows set tokenAddress to the settlement address, the same value as target, so do not read it as an underlying asset token for those rows. Off-chain rows behave differently per type: a multisig approval sets target to the smart wallet that holds the operation, while KYC and pending-custody rows leave target as null. tokenAddress is always null for off-chain rows. meta.facets reports counts per status and per action type for the current filter, which a console uses to label tabs and group counts.

Subscribe to live updates

GET /api/v2/actions/stream

For a continuously updating console, open the server-sent events stream instead of re-polling the list. The stream accepts the same filters as the list endpoint and delivers the same response shape on every event. It sends an initial snapshot of the filtered list, then sends a new snapshot whenever the list changes, until a time limit closes the connection. Reopen the stream to continue following the feed.

The stream is built for the browser session that powers the Console. It requires a same-origin request. A programmatic client that authenticates with an API key may also open the stream, but a client that polls on a schedule should keep calling GET /api/v2/actions rather than holding a stream open. A cross-origin request without an API key is rejected with ACTIONS_STREAM_ORIGIN_REJECTED.

curl --globoff -N -X GET \
  "$DALP_API_URL/api/v2/actions/stream?filter[status]=PENDING" \
  --header "X-Api-Key: $DALP_API_TOKEN"

Each event payload is one full list response: the same data, meta, and links the list endpoint returns. Replace the view's current snapshot with each event rather than merging individual rows, and read meta.facets on each event to keep tab counts current.

Related

• Actions work queue: operate the queue in the Console across its pending, upcoming, completed, and expired tabs.
• Transaction queue lifecycle and recovery: read and recover the queued transactions an executed action produces.
• Platform API error reference: the full public error envelope returned across REST, RPC, and stream surfaces.