Skip to main content
POST
/
v0
/
wallet
/
buy-traffic-requests
/v0/wallet/buy-traffic-requests
curl --request POST \
  --url https://example.com/api/validator/v0/wallet/buy-traffic-requests \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "receiving_validator_party_id": "<string>",
  "domain_id": "<string>",
  "traffic_amount": 123,
  "tracking_id": "<string>",
  "expires_at": 123
}
'
{
  "request_contract_id": "<string>"
}

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.

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
​
receiving_validator_party_id
string
required

Traffic will be purchased for the validator hosting this party. If the party is hosted on multiple participants, the request will fail with 400 Bad Request.

​
domain_id
string
required

The domain to purchase traffic for.

​
traffic_amount
integer<int64>
required

traffic to purchase in bytes.

​
tracking_id
string
required

Tracking id to support exactly once submission. Once submitted, all succeessive calls with the same tracking id will get rejected with a 409 or 429 status code unless the command fails and the traffic did not get purchased. Clients should create a fresh tracking id when they try to send a new request to buy traffic. 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 purchase traffic multiple times.

​
expires_at
integer<int64>
required

Expiry time of the request to buy traffic as unix timestamp in microseconds. If the request does not succeed before this time, the wallet automation will reject and expire it. 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.

Response

Request to buy traffic got created

​
request_contract_id
string
required