POST /v2/updates

curl --request POST \
  --url https://scan.sv-1.global.canton.network.sync.global/api/scan/v2/updates \
  --header 'Content-Type: application/json' \
  --data '
{
  "page_size": 123
}
'

{
  "transactions": [
    {
      "update_id": "<string>",
      "migration_id": 123,
      "workflow_id": "<string>",
      "record_time": "<string>",
      "synchronizer_id": "<string>",
      "effective_at": "<string>",
      "root_event_ids": [
        "<string>"
      ],
      "events_by_id": {},
      "external_transaction_hash": "<string>"
    }
  ]
}

POST /v2/updates

Returns the update history in ascending order, paged, from ledger begin or optionally starting after a record time. Compared to /v1/updates, the /v2/updates removes the offset field in responses, which was hardcoded to 1 in /v1/updates for compatibility, and is now removed. /v2/updates sorts events lexicographically in events_by_id by ID for convenience, which should not be confused with the order of events in the transaction, for this you should rely on the order of root_event_ids and child_event_ids. Updates are ordered lexicographically by (migration id, record time). For a given migration id, each update has a unique record time. The record time ranges of different migrations may overlap, i.e., it is not guaranteed that the maximum record time of one migration is smaller than the minimum record time of the next migration, and there may be two updates with the same record time but different migration ids.

POST

/

v2

/

updates

POST /v2/updates

curl --request POST \
  --url https://scan.sv-1.global.canton.network.sync.global/api/scan/v2/updates \
  --header 'Content-Type: application/json' \
  --data '
{
  "page_size": 123
}
'

{
  "transactions": [
    {
      "update_id": "<string>",
      "migration_id": 123,
      "workflow_id": "<string>",
      "record_time": "<string>",
      "synchronizer_id": "<string>",
      "effective_at": "<string>",
      "root_event_ids": [
        "<string>"
      ],
      "events_by_id": {},
      "external_transaction_hash": "<string>"
    }
  ]
}

Body

application/json

page_size

integer<int32>

required

The maximum number of transactions returned for this request.

after

object

The transactions returned will either have a higher migration id or the same migration id and a record_time greater than the migration id and record time specified.

Show child attributes

daml_value_encoding

enum<string>

How daml values should be encoded in the response. "compact_json" is a compact, human-readable JSON encoding. It is the same encoding as the one used in the HTTP JSON API or the JavaScript codegen. "protobuf_json" is a verbose JSON encoding that is more difficult to parse, but contains type information, i.e., the values can be parsed losslessly without having access to the Daml source code. Optional and defaults to "compact_json".

Available options:

compact_json,

protobuf_json

Response

ok

transactions

object[]

required

An individual item in the update history. May be a transaction or a contract reassignment.

Option 1
Option 2

Show child attributes

POST /v0/open-and-issuing-mining-rounds GET /v2/updates/:update_id

⌘I