Documentation/canton-network-docs/Splice APIsValidator APIsWallet API (External)View on canton-network-docs ↗
canton-network-docs/Splice APIsValidator APIsWallet API (External)

POST /v0/wallet/transfer

POST
/
v0
/
wallet
/
transfer-offers
Try it
POST /v0/wallet/transfer-offers

cURL

curl --request POST \
  --url https://example.com/api/validator/v0/wallet/transfer-offers \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "receiver_party_id": "<string>",
  "amount": "<string>",
  "description": "<string>",
  "expires_at": 123,
  "tracking_id": "<string>"
}
'
200
400
404
409
429
500
{
  "offer_contract_id": "<string>"
}

Authorizations

​
Authorization
string
header
required

JWT token as described in spliceAppBearerAuth [blocked]. The subject of the token must be ledger API user of the user whose wallet the endpoint affects.

Body

application/json
​
receiver_party_id
string
required

The party id of the receiver.

​
amount
string
required

The amount of Amulet to transfer.

​
description
string
required

An arbitrary, user chosen text. This should be a human readable string that describes the purpose of the transfer. It will be shown to the receiver when they decide whether to accept the offer.

​
expires_at
integer<int64>
required

Expiry time of the transfer offer as unix timestamp in microseconds. After this time, the offer can no longer be accepted and automation in the wallet will eventually expire the transfer offer. Note that this time is compared against the ledger effective time of the Daml transaction accepting or expiring an offer, and can skew from the wall clock time measured on the caller's machine. See https://docs.daml.com/concepts/time.html for how ledger effective time is bound to the record time of a transaction on a domain.

​
tracking_id
string
required

Tracking id to support exactly once submission. Once submitted, all successive calls with the same tracking id will get rejected with a 409 or 429 status code unless the command fails and the offer did not get created. Clients should create a fresh tracking id when they try to create a new transfer offer. If that command submission fails with a retryable error or the application crashed and got restarted, successive command submissions must reuse the same tracking id to ensure they don't create the same offer multiple times.

Response

200
application/json

The transfer offer has been created.

​
offer_contract_id
string
required