POST /v2/parties

Allocates a new party on a ledger and adds it to the set managed by the participant. Caller specifies a party identifier suggestion, the actual identifier allocated might be different and is implementation specific. Caller can specify party metadata that is stored locally on the participant. This call may:

  • Succeed, in which case the actual allocated identifier is visible in the response.
  • Respond with a gRPC error

daml-on-kv-ledger: suggestion's uniqueness is checked by the validators in the consensus layer and call rejected if the identifier is already present. canton: completely different globally unique identifier is allocated. Behind the scenes calls to an internal protocol are made. As that protocol is richer than the surface protocol, the arguments take implicit values The party identifier suggestion must be a valid party name. Party names are required to be non-empty US-ASCII strings built from letters, digits, space, colon, minus and underscore limited to 255 chars

post/v2/parties

Request body

partyIdHintstring

A hint to the participant which party ID to allocate. It can be ignored. Must be a valid PartyIdString (as described in value.proto).

Optional

identityProviderIdstring

The id of the Identity Provider If not set, assume the party is managed by the default identity provider or party is not hosted by the participant.

Optional

synchronizerIdstring

The synchronizer, on which the party should be allocated. For backwards compatibility, this field may be omitted, if the participant is connected to only one synchronizer. Otherwise a synchronizer must be specified.

Optional

userIdstring

The user who will get the act_as rights to the newly allocated party. If set to an empty string (the default), no user will get rights to the party.

Optional

Response

Changes

No recorded changes to this endpoint across all 1 revision of this API.