Sign in

POST /v2/parties/external/allocate

The external party must be hosted (at least) on this node with either confirmation or observation permissions It can optionally be hosted on other nodes (then called a multi-hosted party). If hosted on additional nodes, explicit authorization of the hosting relationship must be performed on those nodes before the party can be used. Decentralized namespaces are supported but must be provided fully authorized by their owners. The individual owner namespace transactions can be submitted in the same call (fully authorized as well). In the simple case of a non-multi hosted, non-decentralized party, the RPC will return once the party is effectively allocated and ready to use, similarly to the AllocateParty behavior. For more complex scenarios applications may need to query the party status explicitly (only through the admin API as of now).

post/v2/parties/external/allocate

Request body

synchronizerstring required

Synchronizer ID on which to onboard the party

Required

identityProviderIdstring

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

Optional

waitForAllocationboolean

When true, this RPC will attempt to wait for the party to be allocated on the synchronizer before returning. When false, the allocation will happen asynchronously. This is a best effort only as this synchronization is only possible for non decentralized parties (single hosting node). For decentralized parties, this flag is ignored. Defaults to true.

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

partyIdstring required

The allocated party id

Required

Changes