Skip to main content
POST

Create an offer to directly transfer a given amount of Amulet to another party. Direct transfers are a three-step process: 1. The sender creates a transfer offer 2. The receiver accepts the offer 3. The sender’s wallet automation consumes the accepted offer and transfers the amount. Amulets are not locked for direct transfers. If the sender’s wallet does not have enough Amulet to fulfill the offer at this point, the transfer will fail.

Authorizations

walletUserAuth

string
required
HTTP bearer authentication. Send the token as Authorization: Bearer <token>. Bearer format: JWT. JWT token as described by the spliceAppBearerAuth security scheme. The subject of the token must be ledger API user of the user whose wallet the endpoint affects.

Body

application/json
string
required
The party id of the receiver.
string
required
The amount of Amulet to transfer.
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.
number
required
OpenAPI type: integer (int64).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.
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.

Responses

200

The transfer offer has been created.
application/json
string
required

400

Invalid request, check the error response for details.
application/json
string
required

404

The submitter’s wallet could not be found.
application/json
string
required

409

A transfer offer with the same tracking id has been created. Check the status endpoint for the current status.
application/json
string
required

429

A transfer offer with the same tracking id is currently being processed, which may or may not succeed. Retry submitting the request with exponential back-off.
application/json
string
required

500

internal server error
application/json
string
required

History

Added0.5.10