Returns the update with the given update_id.
Compared to /v1/updates/{update_id}, the /v2/updates/{update_id} removes the offset field in responses,
which was hardcoded to 1 in /v1/updates/{update_id} for compatibility, and is now removed.
/v2/updates/{update_id} 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.
Documentation Index
Fetch the complete documentation index at: https://docs.canton.network/llms.txt
Use this file to discover all available pages before exploring further.
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".
compact_json, protobuf_json ok
An individual item in the update history. May be a transaction or a contract reassignment.
The id of the update.
The migration id of the synchronizer.
This transaction's Daml workflow ID; a workflow ID can be associated with multiple transactions. If empty, no workflow ID was set.
The time at which the transaction was sequenced, with microsecond resolution, using ISO-8601 representation.
The id of the synchronizer through which this transaction was sequenced.
Ledger effective time, using ISO-8601 representation. This is the time
returned by getTime for all Daml executed as part of this transaction,
both by the submitting participant and all confirming participants.
Roots of the transaction tree. These are guaranteed to occur as keys
of the events_by_id object.
Changes to the ledger that were caused by this transaction, keyed by ID and sorted lexicographically by ID for display consistency.
Values are nodes of the transaction tree.
Within a transaction, IDs may be referenced by root_event_ids or
child_event_ids in ExercisedEvent herein, which are sorted in the order as they occurred in the transaction.
For transaction externally signed, contains the external transaction hash signed by the external party. Can be used to correlate an external submission with a committed transaction.