Contents
Once you create a user, a wallet is automatically created and associated to their user's ID. Throughout these docs you will learn all the actions you can do with the wallets of the users.
You can get the information of a wallet by using the id of the wallet or by using the id of the user that owns it. You can do so by using the following requests:
GET /api/v1/public/wallets/{walletId}
where the parameter walletId
in our example would
be: cd496094-a77a-4e4e-bcd9-3361ff89294a
. Therefore, the request would look like this: /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a
GET /api/v1/public/wallets?userId="XXX"
where the parameter userId
is the user's ID
from which you want to get the associated wallet info. This request will return all the wallets that the user
owns in the system. In our example, using the user ID, the whole request would look like this: /api/v1/public/wallets?userId=91af1cb8-1caa-47d0-8ef8-2c11948baaba
.
As response, you will get all the information of that wallet. If the user had more than one wallet, they would all appear. In our example it would look like this:
{
"_links": {
"self": {
"href": "/api/v1/public/wallets?page=0&size=20&sort=createdAt,asc"
},
"first": {
"href": "/api/v1/public/wallets?page=0&size=20&sort=createdAt,asc"
},
"last": {
"href": "/api/v1/public/wallets?page=0&size=20&sort=createdAt,asc"
}
},
"_embedded": {
"wallets": [
{
"id": "cd496094-a77a-4e4e-bcd9-3361ff89294a",
"availableBalance": 1002.32,
"balance": 1000.32,
"heldBalance": 2.0,
"clientAlias": "alias_test",
"clientId": "f34ed6d7-6703-4486-b591-23ee8f20d8b4",
"dltAddress": "0x95066cdf6a5ac9489eeb28755f0e878eb3de711d",
"iban": "ES7002320521100021450612",
"status": "READY",
"userId": "91af1cb8-1caa-47d0-8ef8-2c11948baaba"
}
]
}
}
Where:
Parameter | Datatype | Description |
---|---|---|
id | string | UUID of the wallet |
availableBalance | numeric | Balance with which the user can operate |
balance | numeric | Total balance of the wallet without taking into account pending operations |
heldBalance | numeric | Balance that is on hold and unavailable for the user due to pending operations or escrows |
clientAlias | string | Name of the client as it is saved in the system |
clientId | string | The UUID of the client which was used to create the user |
dltAddress | string | DLT address associated to the wallet |
iban | string | IBAN number associated to the wallet. Available in KYC1 or higher |
status | string | The status can be either READY or PENDING
|
userId | string | The UUID of the user introduced and that owns the wallet |
Note that the status of the wallet in the JSON example is READY
and therefore it can be used for any
payment or funding operation.
If you want to get the list of all the wallets that exist in your system make the following request:
GET /api/v1/public/wallets
As a response, you will get a JSON array with the information of all the wallets in your system.
The call can be paged. This is specially usefull when you have to retrieve a big amount of elements.
By default, the size of the page is 20 elements, and you can put a maximum size of 2000 elements. The response shows a list of resources to make the paged calls, basically you can set the page, the size, and the field you want to sort the list by.
Example:
GET api/v1/public/wallets?page=0&size=25&sort=createdAt,asc
If you want to try any of these functionalities yourself, please go to the API catalogue.
If your use case needs it, you can create extra wallets for your users. Note, that to be able to create an extra
wallet for a user, this one has to be in status ACTIVATED
. Right now, we have limited the number of
wallets per user to 5. This can be extended if your specific use case requires it.
For creating an extra wallet, you have to make the following request:
POST /api/v1/public/wallets
With the following information provided as JSON:
{
"dltAddress": "0x485De9F4580eDEDB5b16a84028e4Bac64434c36D",
"userId": "a5fec227-17cf-4be8-b2aa-b514e38e2b29"
}
Parameter | Mandatory | Datatype | Description |
---|---|---|---|
dltAddress | no | string | The Ethereum address of the new wallet. The client can either use an already existing address, if the user provides it, or create a new one. This field is optional for use cases that do not want to enable the possibility to directly operate against the dlt, if empty, the system will automatically create a wallet discarding the private key. |
userId | yes | string | The UUID of the user that is creating the new wallet |
As response, you will get the following JSON object:
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/c86db278-6eb4-4af2-b023-753eba091d1c"
}
},
"dltAddress": "0x485De9F4580eDEDB5b16a84028e4Bac64434c36D"
"dltNetwork": "Alastria Telsius",
"status": "READY",
"userId": "91af1cb8-1caa-47d0-8ef8-2c11948baaba",
"walletId": "c86db278-6eb4-4af2-b023-753eba091d1c"
}
Parameter | Datatype | Description |
---|---|---|
dltAddress | string | The value which was provided in the request |
dltNetwork | string | Default network of the client where the wallet is created and in which it will be operating. |
status | string | The status can be either PENDING_IBAN or READY . |
userId | string | The value which was provided in the request |
walletId | string | The UUID generated for the created wallet |
If your use case needs it, you can create an iban for your users' wallets. Note, that to be able to create an
iban for a wallet, this one has to be in status READY
and its user cannot be in status UNSUBSCRIBED
.
In addition, the user has to be in KYC level 1 or higher. The request you have to make is the following:
POST /api/v1/public/wallets/{walletId}/create-iban
where the parameter walletId
in our
example would be: cd496094-a77a-4e4e-bcd9-3361ff89294a
. Therefore, the whole request would look
like this: /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/create-iban
As response, you will get the following JSON object:
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/c86db278-6eb4-4af2-b023-753eba091d1c"
}
},
"iban": "ES2101827295711688143168"
}
Parameter | Datatype | Description |
---|---|---|
iban | string | The new IBAN generated for the wallet |
If your use case needs it, you can unsubscribe wallets for your users. This action is irreversible, i.e. the user will not be able to use the wallet again for any operation. In addition, It will not be possible to create a wallet with the same DLT address as the one of the unsubscribed wallet.
In order to unsubscribe a wallet, the API will check the following:
DELETE /api/v1/public/wallets/{walletId}
where the parameter id
stands for the id of
the wallet.
As response, you will get the following JSON object:
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/c86db278-6eb4-4af2-b023-753eba091d1c"
}
},
"dltAddress": "0x485De9F4580eDEDB5b16a84028e4Bac64434c36D"
"dltNetwork": "Alastria Telsius",
"status": "UNSUBSCRIBED",
"userId": "91af1cb8-1caa-47d0-8ef8-2c11948baaba",
"walletId": "c86db278-6eb4-4af2-b023-753eba091d1c"
}
Parameter | Datatype | Description |
---|---|---|
dltAddress | string | The dltAddress that had the wallet unsubscribed |
dltNetwork | string | The dltANetwork that the unsubscribed wallet belonged to |
status | string | The status of the wallet |
userId | string | The id of the user that the wallet belonged to |
walletId | string | The wallet id value which was provided in the request to be unsunbscribed |
If your users need it, you can add favourite external accounts for their walletw and then perform operations with
these favourites without informing again the account data. Note, that to be able to add a favourite external
account for a wallet, this one has to be in status READY
. Right now, we have limited the number of
favourite external accounts per wallet to 5. This can be extended if your specific use case requires it.
For adding a favourite external account, you have to make the following request:
POST /api/v1/public/wallets/{walletId}/favourite-external-accounts
With the following information provided as JSON:
{
"alias": "My favourite account",
"externalIban": {
"accountNumber": "ES0221004440760100171757"
}
}
Parameter | Mandatory | Datatype | Description |
---|---|---|---|
alias | yes | string | The alias of the favourite external account. The alias must be unique per wallet. |
externalIban | yes | Object | EXTERNAL IBAN object |
Parameter | Required | Datatype | Description |
---|---|---|---|
accountNumber | yes | string | The IBAN of the external bank account |
As response, you will get the following JSON object:
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/c86db278-6eb4-4af2-b023-753eba091d1c/favourite-external-accounts"
}
},
"favouriteExternalAccountId": "91af1cb8-1caa-47d0-8ef8-2c11948baaba",
"alias": "My favourite account",
"externalIban": "ES0221004440760100171757",
"status": "ACTIVE"
}
Parameter | Datatype | Description |
---|---|---|
favouriteExternalAccountId | UUID | The id of the favourite external account |
alias | string | Alias that represents the favourite external account. |
externalIban | string | External account number |
status | string | Favourite external account status can be either ACTIVE or DELETED . |
If you want to access to the information of a favourite external account of a specific wallet you have to send the following request:
GET /api/v1/public/wallets/{walletId}/favourite-external-accounts/{favouriteExternalAccountId}
where
the parameter walletId
in our example would be: cd496094-a77a-4e4e-bcd9-3361ff89294a
and the favouriteExternalAccountId
can be for example
a5fec227-17cf-4be8-b2aa-b514e38e2b29
. Therefore, the whole request would look like this: /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/favourite-external-accounts/a5fec227-17cf-4be8-b2aa-b514e38e2b29
.
As response, you will get a JSON with all the information of that favourite external account.
{
"_links": {
"wallet": {
"href": "/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a"
},
"self": {
"href": "/api/v1/public/wallets/c86db278-6eb4-4af2-b023-753eba091d1c/favourite-external-accounts/a5fec227-17cf-4be8-b2aa-b514e38e2b29"
}
},
"alias": "My favourite account",
"iban": "ES3320801248101464337536",
"id": "a5fec227-17cf-4be8-b2aa-b514e38e2b29",
"status": "ACTIVE",
"walletId": "cd496094-a77a-4e4e-bcd9-3361ff89294a"
}
Where:
Parameter | Datatype | Description |
---|---|---|
alias | string | Alias that represents the favourite external account. |
iban | string | External account number |
id | UUID | The id of the deleted favourite external account |
status | string | Favourite external account status can be either ACTIVE or DELETED . |
walletId | UUID | The id of the wallet |
If you want to get the list of all the favourite external accounts of a specific wallet make the following request:
GET /api/v1/public/wallets/{walletId}/favourite-external-accounts
As a response, you will get a JSON array with the information of all the favourite external accounts of that wallet.
The call can be paged. This is specially usefull when you have to retrieve a big amount of elements.
By default, the size of the page is 20 elements, and you can put a maximum size of 2000 elements. The response shows a list of resources to make the paged calls, basically you can set the page, the size, and the field you want to sort the list by.
Example:
GET api/v2/public/wallets/{walletId}/favourite-external-accounts?page=0&size=25&sort=createdAt,asc
.
If you want to try any of these functionalities yourself and know more about them, please go to the API catalogue.
You can delete favourite external accounts for your wallets. This action is irreversible, i.e. the user will not be able to use the favourite external account again for any operation. But you can add a new favourite external account with the same data.
In order to delete a favaourite external account, you have to make the following request:
DELETE /api/v1/public/wallets/{walletId}/favourite-external-accounts/{favouriteExternalAccountId}
As response, you will get the following JSON object:
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/c86db278-6eb4-4af2-b023-753eba091d1c/favourite-external-accounts"
}
},
"favouriteExternalAccountId": "91af1cb8-1caa-47d0-8ef8-2c11948baaba",
"alias": "My favourite account",
"externalIban": "ES0221004440760100171757",
"status": "DELETED"
}
Parameter | Datatype | Description |
---|---|---|
favouriteExternalAccountId | UUID | The id of the deleted favourite external account |
alias | string | Alias that represents the deletedfavourite external account. |
externalIban | string | External account number |
status | string | Favourite external account status can be either ACTIVE or DELETED . |
If you want to access to the information of a movement of a specific wallet you have to send the following request:
GET /api/v1/public/wallets/{walletId}/movements/{movementId}
where the parameter
walletId
in our example would be: cd496094-a77a-4e4e-bcd9-3361ff89294a
and the movementID
can be for example a5fec227-17cf-4be8-b2aa-b514e38e2b29
. Therefore, the whole request would look
like this: /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/movements/a5fec227-17cf-4be8-b2aa-b514e38e2b29
.
As response, you will get a JSON with all the information of that movement. Below, it is shown a movement of a transfer-in in which the wallet requested made a transaction to another wallet with an amount of 10.
{
"_links": {
"originUser": {
"href": "/api/v1/public/users/cd496094-a77a-4e4e-bcd9-3361ff89294a"
},
"targetUser": {
"href": "/api/v1/public/users/2c36f452-2ea4-4448-962b-365cdb5ae027"
},
"originWallet": {
"href": "/api/v1/public/wallets/02561361-e5a6-4282-8824-a2933eab4d8e"
},
"targetWallet": {
"href": "/api/v1/public/wallets/465107e1-9cb7-4e72-9c75-3989ec37e26e"
},
"self": {
"href": "/api/v1/public/wallets/465107e1-9cb7-4e72-9c75-3989ec37e26e/movements/a5fec227-17cf-4be8-b2aa-b514e38e2b29"
}
},
"id": "a5fec227-17cf-4be8-b2aa-b514e38e2b29",
“originUserId": "cd496094-a77a-4e4e-bcd9-3361ff89294a",
“targetUserId": "2c36f452-2ea4-4448-962b-365cdb5ae027"
"amount": 10,
"clientId": "6f075cab-638e-4e24-95d6-603e72f94056",
"concept": "cash-in from my credit card",
"createdAt": "2018-11-28T10:21:20.198+0000",
“originDltAddress": "0x95066cdf6a5ac9489eeb28755f0e878eb3de711d",
“targetDltAddress": "0xd6341daf46ecb065b00c0baebc098ae06ed01c90",
“originWalletId”: “02561361-e5a6-4282-8824-a2933eab4d8e”,
“targetWalletId”: “465107e1-9cb7-4e72-9c75-3989ec37e26e”,
"dltNetwork": "AlastriaTelsius",
"status": "SUCCESS",
"type": "TRANSFER_IN",
"updatedAt": "2018-11-28T10:21:21.966+0000",
"scheduledOperationId": "8ee441a6-b104-4a29-b3a5-909597468a20"
}
Where:
Parameter | Datatype | Description |
---|---|---|
id | string | UUID of the movement |
originUserId | string | ID of the sender's wallet if the movement type is TRANSFER_IN or TRANSFER_OUT .
Empty if the movement type is any other
|
targetUserId | string | ID of the receiver's wallet if the movement type is TRANSFER_IN or
TRANSFER_OUT . Empty if the movement type is any other
|
userId | string | User id associated to the movement if the movement type is different from TRANSFER_IN or
TRANSFER_OUT |
payerName | string | Payer’s name when movement type is BANK_ACCOUNT_CASH_OUT . Empty if the movement type is any
other
|
amount | numeric | Amount of money moved |
clientId | string | UUID of the client |
concept | string | Description with the purpose of the movement |
createdAt | string | Timestamp of the movement creation |
originDltAddress | string | DLT address associated to the sender's wallet if the movement type is TRANSFER_IN or TRANSFER_OUT .
Empty if the movement type is any other
|
targetDltAddress | string | DLT address associated to the receiver's wallet if the movement type is TRANSFER_IN or
TRANSFER_OUT . Empty if the movement type is any other
|
originWalletId | string | Wallet id associated to the sender's wallet if the movement type is TRANSFER_IN or TRANSFER_OUT .
Empty if the movement type is any other
|
targetWalletId | string | Wallet id associated to the receiver's wallet if the movement type is TRANSFER_IN or TRANSFER_OUT .
Empty if the movement type is any other
|
walletId | string | Wallet id associated to the movement if the movement type is different from TRANSFER_IN or
TRANSFER_OUT |
dltNetwork | string | Blockchain network in which the transaction is done |
status | string | The status can be either SUCCESS , PENDING or ERROR |
type | string | The type of movement can be either CARD_CASHIN , BANK_ACCOUNT_CASHIN , BANK_ACCOUNT_CASHOUT ,
TRANSFER_IN , TRANSFER_OUT , LOCK or RELEASE |
updatedAt | string | Timestamp of the movement update |
scheduledOperationId | string | Scheduled operation UUID id string related to the movement. Only filled if the movement is related to an scheduled operation. |
Note: When a transfer is made between two accounts, there are two movements generated: one when the money
leaves the origin account TRANSFER_OUT
and another when it reaches the target account TRANSFER_IN
.
If you want to get the list of all the movements of a specific wallet make the following request:
GET /api/v1/public/wallets/{walletId}/movements
As a response, you will get a JSON array with the information of all the movements of that wallet.
The call can be paged. This is specially usefull when you have to retrieve a big amount of elements.
By default, the size of the page is 20 elements, and you can put a maximum size of 2000 elements. The response shows a list of resources to make the paged calls, basically you can set the page, the size, and the field you want to sort the list by.
Example of pagination:
GET api/v2/public/wallets/{walletId}/movementspage=0&size=25&sort=createdAt,asc
Additionaly, you can filter the list of movements by startDate, endDate and status. By default, there are no filters
Example with filtering:
GET api/v2/public/wallets/{walletId}/movements?startDate=2020-02-28 12:00:00&endDate=2020-02-28
16:00:00&status=SUCCESS&page=0&size=25&sort=createdAt,asc
If you want to try any of these functionalities yourself and know more about them, please go to the API catalogue.
In order to fund the user’s wallet you can make a credit or debit card top up with the API. Card data should be enter in a form. Our API provides a url form, to get this payment url you should make the following request:
POST /api/v1/public/wallets/{walletId}/cards/cashIns
where the walletId is the UUID of the wallet
which will receive the money.
In our example, the whole request will be
/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/cards/cashIns
{
"amount" : "1000",
"succcessUrl": "http://client/cashIns/success.html"
"rejectUrl": "http://client/cashIns/reject.html"
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
amount | yes | numeric | Amount of money to cash in |
successUrl | yes | object | A http url where you will be redirected in case of success |
rejectUrl | yes | object | A http url where you will be redirected in case of rejection |
As response, you will get the key as shown below:
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/{walletId}/cards/cashIns"
}
},
"movementId": "36650dcc-cccb-4057-820b-6eab3b29c8bb",
"status": "PENDING",
"amoung": "1000",
"paymentUrl": "https://ogone.test.v-psp.com/ncol/test/orderstandard_utf8.asp?ACCEPTURL="
}
Where:
Parameter | Datatype | Description |
---|---|---|
movementId | string | Identifier of the new movement |
status | string | Status for this movement (in this case always will be PENDING) |
paymentUrl | string | The form url where the user have to enter the card datas |
As a summary, steps needed to make a cash-in operation are the following:
CARD_CASHIN
that will turn its status from PENDING
to SUCCESS
when the operation has been finished.
Another option to fund the user's ioCash wallet is through a SEPA cash-in. With this method, a bank transfer is done from an external bank account to the IBAN associated to the user's ioCash wallet. This implies that you do not need to make any request against the API for the accomplishment of this action. The system will read the change in the IBAN and update the ioCash wallet balance. Since the operation is a bank transfer, it can take some time from the order of the cash-in till it reaches ioCash.
This action will generate a movement of type BANK_ACCOUNT_CASHIN
that will turn its status from
PENDING
to SUCCESS
when both the available balance (DLT account balance) and the total
balance (system balance) are increased with the quantity cashed in.
In order for a user to send money from his IoCash wallet to another bank account, the following request has to be sent.
POST /api/v1/public/wallets/{walletId}/cashOuts
where the walletId
is the UUID of the
wallet, which should execute the money cash-out. In our example, the whole request will be /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/cashOuts
.
With the following information provided as JSON:
{
"iban": {
"accountNumber": "ES7921000813610123456789"
},
"amount": "1.50",
"concept": "Cash out from my account"
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
iban | yes | object | An IBAN object |
amount | yes | string | The cash.out amount represented as integer or numeric value |
concept | no | string | Optional description with the purpose of the card cash-out |
Parameter | Required | Datatype | Description |
---|---|---|---|
accountNumber | yes | string | The IBAN of the bank account, which should receive the payment |
This action will generate a movement of type BANK_ACCOUNT_CASHOUT
that will turn its status from
PENDING
to SUCCESS
when both the available balance (DLT account balance) and the total
balance (system balance) are decreased with the quantity cashed out.
If you want to try this functionality yourself and learn more about the cash-out, please go to the API catalogue.
In order for a user to send money from his IoCash wallet to a one of his favourite external accounts, the following request has to be sent.
POST /api/v1/public/wallets/{walletId}/cashout-to-favourite-external-account
where the walletId
is the UUID of the wallet, which should execute the money cash-out. In our example, the whole request will be
/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/cashout-to-favourite-external-account
.
With the following information provided as JSON:
{
"favouriteExternalAccountId": "91af1cb8-1caa-47d0-8ef8-2c11948baaba",
"amount": "1.50",
"concept": "Cash out from my account to my favourite external account"
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
favouriteExternalAccountId | yes | UUID | Id of the favourite external account that you want to send the money |
amount | yes | string | The cash out amount represented as integer or numeric value |
concept | no | string | Optional description with the purpose of the cash-out |
As response, you will get the following JSON object:
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/c86db278-6eb4-4af2-b023-753eba091d1c/movements/4fa85f64-5717-4562-b3fc-2c963f66afa7"
}
},
"movementId": "4fa85f64-5717-4562-b3fc-2c963f66afa7",
"status": "PENDING",
"amount": "1.50",
"favouriteExternalAccountIban": "ES0221004440760100171757",
"favouriteExternalAccountId": "91af1cb8-1caa-47d0-8ef8-2c11948baaba",
"alias": "My favourite account"
}
Parameter | Datatype | Description |
---|---|---|
movementId | UUID | The id of the movement generated |
status | string | The movement status |
amount | BigDecimal | The amount transfered to the external account |
favouriteExternalAccountIban | string | External account number |
favouriteExternalAccountId | UUID | The id of the favourite external account |
alias | string | Alias that represent the favourite external account. |
This action will generate a movement of type BANK_ACCOUNT_CASHOUT
that will turn its status from
PENDING
to SUCCESS
when both the available balance (DLT account balance) and the total
balance (system balance) are decreased with the quantity cashed out.
If you want to try this functionality yourself and learn more about the cash-out, please go to the API catalogue.
In ioCash, transfers can be originated by calling the API or by directly calling to the smart contract.
To make a transfer via API you have to make the following request:
POST /api/v1/public/wallets/{walletId}/transfer
where the walletId
is the UUID of the
wallet, which should execute the money transfer. In our example, the whole request will be /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/transfer
.
With the following information provided as JSON:
{
"amount": "1.50",
"concept": "Centralized transfer from API",
"targetWalletId": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
amount | yes | string | The amount to be transfered represented as integer or numeric value |
concept | no | string | Optional description with the purpose of the transfer |
targetWalletId | yes | string | UUID of the recipient wallet that will receive the transfer |
You can directly use the methods on our smart contracts to make transfers without the need of going through the API. This will specially serve you when you want to trigger transfers after other conditions in other smart contracts are fulfilled. There are two different types of decentralized transfers:
To make a one-step transfer you have to call the transfer
method that resides in our token
contract.
To make a two-step transfer you have to call the orderTransfer
method that resides in our
token contract.
For more details check the Interacting with EmToken docs
You must make this call through the web3 api, and be connected to a network node in order to perform this operation in the DLT.
All three types of transfers explained above will generate two movements:
TRANSFER_OUT
that will turn its status from PENDING
to SUCCESS
when both the sender user's wallet available balance (DLT account balance) and the total balance (system
balance) are decreased with the transferred quantity.
TRANSFER_IN
that will turn its status from PENDING
to SUCCESS
when both the receiver user's wallet available balance (DLT account balance) and the total balance (system
balance) are increased with the transferred quantity.
If you have wallets in different networks you can tranfser money among them using cross ledger transfers. This functionality is only available via smart contract.
To access this functionality you have to use the CrossLedgerLink smart contracts methods.
To order a cross ledger transfer the user has to call the orderTransfer
method that resides
in our CrossLedgerLink contract. In addition, you can retrieve the information of a cross ledger transfer by
using the method getTransferData
. Since the transfer is ordered, there are several checks done
centrally by the platform and the transfer status is updated to different statuses. Though this life cycle,
money is transitioned to/from suspense accounts and minted/burned in the destination and origin networks.
For more information about the methods and the functioning of cross ledger transfers, check the smart contract docs.
TRANSFER_OUT
that will turn its status from PENDING
to SUCCESS
after the transfer has been confirmed and executed in both networks and the sender's wallet available
balance and the total balance are decreased with the transferred quantity.
TRANSFER_IN
that will turn its status from PENDING
to SUCCESS
after the transfer has been confirmed and executed in both networks and the receiver's wallet available
balance and the total balance are increased with the transferred quantity.
In ioCash, holds can be originated by calling the API or by directly calling to the smart contract.
Holds make funds unavailable to users until they are executed.
When a hold is declared, the user has to define the amount that will be blocked in his/her account, the target account that will receive the money when the hold is executed and the notary that will decide if the hold execution is accepted (the money is sent to the target account) or rejected (the money is unlocked in the sender's account).
To create a hold via API you have to make the request shown below. For holds via API, the bank is always set as the notary in the dlt. Therefore, a hold created via API has to be executed or released via API as well.
POST /api/v1/public/wallets/{walletId}/hold
where the walletId
is the UUID of the
wallet, which should hold the money. In our example, the whole request would be /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/hold
.
With the following information provided as JSON:
{
"amount": "1.50",
"targetWalletId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"concept": "Centralized hold from API",
"expiration": "2020-02-06T10:04:45+02"
}
If you leave the field "expiration" empty, the hold will be created perpetual i.e. it will never expired.
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
amount | yes | string | The amount to be held represented as integer or numeric value |
targetWalletId | yes | string | UUID of the recipient wallet that will receive the transfer after the execution of the hold |
concept | no | string | Optional description with the purpose of the hold |
expiration | no | Date | Date in UTC time format in which the hold is expired. When expired, the held amount is automatically made available on the origin account. You can add/substract the time zone you want from UTC. In our example we are adding +02. If you leave the field "expiration" empty, the hold will be created perpetual i.e. it will never expire. |
You can directly use the methods on our smart contracts to create holds without the need of going through the API. This will specially serve you when you want to trigger holds after other conditions in other smart contracts are fulfilled. For these cases, any dlt address can be set as the notary, including another smart contract address. A decentralized hold cannot be executed or released via API (unless the bank address was set as notary).
To create a hold the user has to call the hold
method that resides in our token contract. The
hold can also be done on behalf of another user using holdFrom
if he/she has beforehand given
permission to the orderer using authorizeHoldOperator
For more information about all the hold methods you can check the Interacting with EmToken docs.
Hold creations generate LOCK
movements.
To execute a hold via API you have to make the following request:
POST /api/v1/public/wallets/{walletId}/hold/{holdId}/executeHold
where the walletId
is
the UUID of the wallet that created the hold, which should transfer the money, and the holdId
is
the UUID of the hold which should be executed. In our example, the whole request will be /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/hold/3fa85f64-5717-4562-b3fc-2c963f66afa6/executeHold
.
With the following information provided as JSON:
{
"amount": "1.50",
"concept": "Execute hold from API"
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
amount | yes | string | The amount to be executed represented as integer or numeric value |
concept | no | string | Optional description with the concept of the execution |
When a hold is executed, it is automatically closed. If the amount of the execution is less than the amount on hold, the difference will be released to the origin account. In order to be able to execute a partial hold and keep it open, there is a specific method. To do this you must make the following request
POST /api/v1/public/wallets/{walletId}/hold/{holdId}/executeHoldAndKeepOpen
where the
walletId
is the UUID of the wallet that created the hold, which should transfer the money, and the
holdId
is the UUID of the hold which should be executed. In our example, the whole request would be
/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/hold/3fa85f64-5717-4562-b3fc-2c963f66afa6/executeHoldAndKeepOpen
.
With the following information provided as JSON:
{
"amount": "1.50",
"concept": "Execute hold and keep open from API"
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
amount | yes | string | The amount to be executed represented as integer or numeric value |
concept | no | string | Optional description with the concept of the execution |
In partial executes, the hold is left open and will accept further operations as other executes or a release.
You can directly use the methods on our smart contracts to execute holds or execute holds and keept open without the need of going through the API. This will specially serve you when you want to trigger holds after other conditions in other smart contracts are fulfilled.
To execute a hold the address that was defined as notary should call the executeHold
method.
The money will be transferred from the sender to the receiver.
To execute a hold and keep it open the address that was defined as notary should call the executeHoldAndKeepOpen
method. The money will be transferred from the sender to the receiver.
For more information about all the hold methods you can check the Interacting with EmToken docs.
Hold executions generate transfers that create movements TRANSFER_OUT
and TRANSFER_IN
as explained above for the transfer operation.
To release a hold via API you have to make the following request:
POST /api/v1/public/wallets/{walletId}/hold/{holdId}/releaseHold
where the walletId
is
the UUID of the wallet, which created the hold. In our example, the whole request would be /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/hold/3fa85f64-5717-4562-b3fc-2c963f66afa6/releaseHold
.
With the following information provided as JSON:
{
"concept": "Centralized release hold from API"
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
concept | no | string | Optional description with the purpose of the release hold |
You can directly use the methods on our smart contracts to release holds without the need of going through the API.
To release a hold the notary has to call the releaseHold
method. The money will be not sent
to the receiver but unlocked into the sender's wallet so that he/she can use it again.
For more information about all the hold methods you can check the Interacting with EmToken docs.
Hold releases generate RELEASE
movements.
Renews are used to change the expiration time of an existing hold. You can also change a hold from/to perpetual
(it does not expire) by leaving the field expiration
empty.To renew a hold via API you have
to make the following request:
POST /api/v1/public/wallets/{walletId}/hold/{holdId}/renewHold
where the walletId
is
the UUID of the wallet, which created the hold. In our example, the whole request will be /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/hold/3fa85f64-5717-4562-b3fc-2c963f66afa6/renewHold
.
With the following information provided as JSON:
{
"expiration": "2020-02-07T09:25:18+02"
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
expiration | no | Date | Date in UTC time format in which the hold is expired. You can add/substract the time zone you want from UTC. In our example we are adding +02. If you leave the field "expiration" empty, the hold will be renewed perpetual i.e. it will never expire. |
You can directly use the methods on our smart contracts to create holds without the need of going through the API. This will specially serve you when you want to trigger holds after other conditions in other smart contracts are fulfilled.
To renew a hold the issuer or payer has to call the renewHold
method. The expiration time
will be updated.
For more information about all the hold methods you can check the Interacting with EmToken docs.
You can check the information of holds from our API by using the following request
GET /api/v1/public/wallets/{walletId}/holds/{holdId}
where the parameter walletId
in
our example would be: cd496094-a77a-4e4e-bcd9-3361ff89294a
and the holdID
can be for
example b2462ed0-d3d7-4c8a-abc3-980fd4472876
. Therefore, the whole request would look like this:
/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/holds/b2462ed0-d3d7-4c8a-abc3-980fd4472876
.
As response, you will get a JSON with all the information of the requested hold.
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/holds/b2462ed0-d3d7-4c8a-abc3-980fd4472876"
},
"payerWallet": {
"href": "/api/v1/public/users/cd496094-a77a-4e4e-bcd9-3361ff89294a"
},
"payeeWallet": {
"href": "/api/v1/public/wallets/66a79523-6234-4590-857b-3e745fc41c28"
}
},
"id": "b2462ed0-d3d7-4c8a-abc3-980fd4472876",
"userId": "421fd6a5-95e8-4e90-9ce5-c14fa0904754",
"clientId": "619b4a82-0e68-4f16-bb00-a4a6a250df69",
"issuerDltAddress": "0x95066cdf6a5ac9489eeb28755f0e878eb3de711d",
"payerDltAddress": "0x95066cdf6a5ac9489eeb28755f0e878eb3de711d",
"payeeDltAddress": "0x0e1ff5c25bF0132D476ff999096c21A41143FB4A",
"notaryDltAddress": "0x7c311A5E1b9fED7E56eC37d493901bBcb9063D02",
"heldValue": 10.00,
"executedValue": 8.00,
"status": "EXECUTED",
"dltNetwork": "AlastriaTelsius",
"contractAddress": "0xAC69155Cf549078bDE41890685f4bEB1f496a527",
"operationId": "q13",
“payerWalletId": "cd496094-a77a-4e4e-bcd9-3361ff89294a",
“payeeWalletId": "66a79523-6234-4590-857b-3e745fc41c28",
"createdAt": "2019-12-17T17:38:31.112+0000",
"expiration": "2019-12-18T17:38:31.112+0000"
}
Where:
Parameter | Datatype | Description |
---|---|---|
id | string | UUID of the hold |
userId | string | UUID of the user where the hold is created |
clientId | string | UUID of the client |
issuerDltAddress | string | DLT address associated to the users's wallet that has created the hold |
payerDltAddress | string | DLT address associated to the users's wallet where the hold has been created |
payeeDltAddress | string | DLT address associated to the users's wallet receiver |
notaryDltAddress | string | DLT address that has been set as the notary of the hold. The notary can execute or cancel the hold |
heldValue | numeric | Amount of money that was put on hold with the creation of the hold |
executedValue | numeric | Amount of money that has been sent to the payee out of the hold so far |
status | string | The status can be either CREATION_REQUESTED , PENDING_DLT_CREATION , CREATED ,
CREATION_FAILED , PENDING_DLT_EXPIRATION , EXECUTION_REQUESTED ,
PENDING_DLT_EXECUTION , EXECUTED , EXECUTION_FAILED , EXECUTION_AND_KEEP_OPEN_REQUESTED ,
PENDING_DLT_EXECUTE_AND_KEPT_OPEN , EXECUTED_AND_KEPT_OPEN , EXECUTION_AND_KEPT_OPEN_FAILED ,
RELEASE_REQUESTED , PENDING_DLT_RELEASE , RELEASE_FAILED , RELEASED_BY_NOTARY ,
RELEASED_BY_PAYEE , RELEASED_ON_EXPIRATION , RENEWAL_REQUESTED ,
PENDING_DLT_RENEWAL , RENEWED or RENEWAL_FAILED |
dltNetwork | string | Blockchain network in which the hold is done |
contractAddress | string | Ethereum address of the smart contract where the hold has been created |
operationId | string | Identifier of the hold in the smart contract. It has to be unique inside its smart contract |
payerWalletId | string | UUID of the wallet where the hold has been created |
payeeWalletId | string | Payer wallet id |
createdAt | string | Timestamp of the movement creation |
expiration | Date | Date in UTC time format in which the hold is expired. When expired, the held amount is automatically made available on the origin account. You can add/substract the time zone you want from UTC. |
If you want to get the list of all the holds of a specific wallet make the following request:
GET /api/v1/public/wallets/{walletId}/holds
As a response, you will get a JSON array with the information of all the holds of that wallet.
The call can be paged. This is specially usefull when you have to retrieve a big amount of elements.
By default, the size of the page is 20 elements, and you can put a maximum size of 2000 elements. The response shows a list of resources to make the paged calls, basically you can set the page, the size, and the field you want to sort the list by.
Example:
If you want to try any of these functionalities yourself and know more about them, please go to the API catalogue.
With this functionality you can schedule payments to be executed in the future as well as set recurrent payments for your wallets.
The target of these operations can be either another wallet of your application, a favourite external bank account or a nex external bank account.
The recurrence of payments can be set with end date, with a number of repetitions or endless.
To create an scheduled operation you have to make the request shown below. All possible body parameters for all cases are explained below.
POST /api/v1/public/wallets/{walletId}/scheduled-operations
where the walletId
is the
UUID of the wallet, which will transfer the money. In our example, the whole request would be /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/scheduled-operations
.
With the following information provided as JSON:
{
"alias": "operation 1",
"concept": "recurrent payment 1",
"amount": 100.5,
"receiver": {
"type": "FAVOURITE_EXTERNAL_BANK_ACCOUNT",
"account": "79d8a4be-c934-4ffe-ad10-3982f1a30006"
},
"schedule": {
"startDate": "2020-04-23T00:00:00.000+02",
"frequency": "DAILY",
"duration": {
"type": "NUMBER_OF_REPETITIONS",
"value": "2"
}
}
}
Where:
Parameter | Required | Datatype | Description |
---|---|---|---|
alias | yes | string | Alias of the operation. The alias is unique per wallet. |
concept | no | string | Optional concept that will be included in movements related to the operation. If not provided, a default one will be set by the system. |
amount | yes | numeric | Amount of the operation. |
receiver | yes | object | Receiver information. |
schedule | yes | object | Schedule information. |
Parameter | Required | Datatype | Description |
---|---|---|---|
type | yes | string | Can be IOCASH_WALLET for a target wallet id, FAVOURITE_EXTERNAL_BANK_ACCOUNT
for a favourite external bank account id or EXTERNAL_BANK_ACCOUNT for a not saved external
bank account.
|
account | yes | string | It is a wallet UUID string if the receiver type is IOCASH_WALLET , a favourite external bank
account UUID string if the receiver type is FAVOURITE_EXTERNAL_BANK_ACCOUNT and an IBAN
number string is receiver type is EXTERNAL_BANK_ACCOUNT .
|
Parameter | Required | Datatype | Description |
---|---|---|---|
startDate | yes | string | Date and time in UTC format the scheduled operation should start. If frequency is ONCE , it
is the date in which the unique operation will be executed.
|
frequency | yes | string | Can be ONCE for unique execution in the future, DAILY for daily executions,
WEEKLY for weekly executions, MONTHLY for monthly executions and
YEARLY for yearly executions. The time of the day of the future executions is the same as
the time of the start date, for example, if you schedule a DAILY operation with start date
at 13:00, next day the operation will be executed at the same time. In addition, for a monthly
operation, if it is scheduled with a start date on the 31st of a month, it will execute on the last day
of each month.
|
duration | no | object | Duration object. Does not apply when frequency is ONCE. |
Parameter | Required | Datatype | Description |
---|---|---|---|
type | yes | string | Duration type. Can be ENDLESS if the operation does not have end date, NUMBER_OF_REPETITIONS
if you want your operation to be executed a certain number of times, or END_DATE if you
want to provide an end date for the operation.
|
value | no | string | Depends on the type. Does not apply when duration type is ENDLESS . For NUMBER_OF_REPETITIONS
duration type should be a valid positive integer number. For END_DATE should be a valid
date in UTC format greater than start date. The end date should be expressed in the format yyyy-MM-dd
without time, if expressed with time, the time will not be taken into account.
|
All types of receiver explained above can generate three type of movements:
TRANSFER_OUT
when receiver type is IOCASH_WALLET for the source wallet.TRANSFER_IN
when receiver type is IOCASH_WALLET for the target wallet.CASH_OUT
when receiver type is FAVOURITE_EXTERNAL_BANK_ACCOUNT or
EXTERNAL_BANK_ACCOUNT for the source wallet.
You can check the information of scheduled operations from our API by using the following request
GET /api/v1/public/wallets/{walletId}/scheduled-operations/{scheduledOperationId}
where the
parameter walletId
in our example would be: cd496094-a77a-4e4e-bcd9-3361ff89294a
and
the scheduledOperationId
can be for example 7f923d0b-0455-4b22-a489-67513eff2b7d
.
Therefore, the whole request would look like this: /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/scheduled-operations/7f923d0b-0455-4b22-a489-67513eff2b7d
.
As response, you will get a JSON with all the information of the requested scheduled operation.
{
"id": "7f923d0b-0455-4b22-a489-67513eff2b7d",
"alias": "operation 26",
"concept": "testing",
"amount": 0.10,
"status": "ACTIVE",
"schedule": {
"startDate": "2020-05-04T06:48:00.000+0000",
"nextDate": "2020-05-05T06:48:00.000+0000",
"frequency": "DAILY",
"duration": {
"type": "END_DATE",
"endDate": "2020-05-07",
"numberOfRepetitions": 4
}
},
"receiver": {
"type": "IOCASH_WALLET",
"account": "877bd6b7-ed92-49e2-8e59-cc814fdb1000"
},
"createdAt": "2020-05-04T06:47:19.569+0000",
"_links": {
"self": {
"href": "/api/v1/public/wallets/a611e619-16ec-4e81-b24b-bbc52cbb61ba/scheduled-operations/7f923d0b-0455-4b22-a489-67513eff2b7d"
}
}
}
Where:
Parameter | Datatype | Description |
---|---|---|
id | string | UUID of the scheduled operation. |
alias | string | Unique alias of the scheduled operation. |
concept | string | Concept of the scheduled operation. |
amount | numeric | Amount of the scheduled operation. |
status | string | Status of the scheduled operation. Can be ACTIVE , DELETED or
COMPLETED .
|
schedule | object | Schedule information of the scheduled operation. |
receiver | object | Receiver information of the scheduled operation. |
createdAt | date | Creation date of the scheduled operation. |
Parameter | Datatype | Description |
---|---|---|
type | string | Can be IOCASH_WALLET , or FAVOURITE_EXTERNAL_BANK_ACCOUNT , or EXTERNAL_BANK_ACCOUNT
for an IBAN number.
|
account | string | It is a wallet id UUID string if the receiver type is IOCASH_WALLET , a favourite external
bank account id UUID string if the receiver type is FAVOURITE_EXTERNAL_BANK_ACCOUNT and an
IBAN number string is receiver type is EXTERNAL_BANK_ACCOUNT .
|
Parameter | Datatype | Description |
---|---|---|
startDate | string | Date and time in UTC format the scheduled operation should start. If frequency is ONCE , it
is the date in which the unique operation will be executed.
|
frequency | string | Can be ONCE for unique execution in future, DAILY for daily executions, WEEKLY
for weekly executions, MONTHLY for monthly executions and YEARLY for yearly
executions.
|
duration | object | Duration object. Not filled when frequency is ONCE. |
Parameter | Datatype | Description |
---|---|---|
type | string | Duration type. Can be ENDLESS , or NUMBER_OF_REPETITIONS , or
END_DATE .
|
value | string | Depends on the type. Not filled if type is ENDLESS . For NUMBER_OF_REPETITIONS
duration type is be a valid positive integer number. For END_DATE is be a valid date in UTC
format. The end date is returned expressed in the format yyyy-MM-dd without time.
|
If you want to get the list of all the scheduled operations of a specific wallet make the following request:
GET /api/v1/public/wallets/{walletId}/scheduled-operations
As a response, you will get a JSON array with the information of all the scheduled operations of that wallet.
The call can be paged. This is specially useful when you have to retrieve a big amount of elements.
By default, the size of the page is 20 elements, and you can put a maximum size of 2000 elements. The response shows a list of resources to make the paged calls, basically you can set the page, the size, and the field you want to sort the list by.
Example:
If you want to try any of these functionalities yourself and know more about them, please go to the API catalogue.
You can check all executions of an scheduled operation. This endpoint retrieves the executions that have been done and also future executions, with a maximum number of 10.
GET /api/v1/public/wallets/{walletId}/scheduled-operations/{scheduledOperationId}/executions
where
the parameter walletId
in our example would be: cd496094-a77a-4e4e-bcd9-3361ff89294a
and the scheduledOperationId
can be for example b2462ed0-d3d7-4c8a-abc3-980fd4472876
.
Therefore, the whole request would look like this: /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/scheduled-operations/b2462ed0-d3d7-4c8a-abc3-980fd4472876/executions
.
As response, you will get a JSON with all the information of the scheduled operation executions.
The call can be paged. Only executions can be paged, as scheduled executions only retrieve 10 future executions by default. This is specially useful when you have to retrieve a big amount of elements.
By default, the size of the page is 20 elements, and you can put a maximum size of 2000 elements. The response shows a list of resources to make the paged calls, basically you can set the page, the size, and the field you want to sort the list by.
{
"_links": {
"self": {
"href": "/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/scheduled-operations/b2462ed0-d3d7-4c8a-abc3-980fd4472876/executions?page=0&size=20&sort=createdAt,desc"
},
"first": {
"href": "/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/scheduled-operations/b2462ed0-d3d7-4c8a-abc3-980fd4472876/executions?page=0&size=20&sort=createdAt,desc"
},
"last": {
"href": "/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/scheduled-operations/b2462ed0-d3d7-4c8a-abc3-980fd4472876/executions?page=0&size=20&sort=createdAt,desc"
}
},
"_embedded": {
"executions": {
"id": "c81e9548-8e3c-4a14-9ee8-fd546d6c55b0",
"status": "EXECUTED",
"date": "2020-05-04T06:48:00.394+0000",
"_links": {
"movement": {
"href": "/api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/movements/c81e9548-8e3c-4a14-9ee8-fd546d6c55b0"
}
}
},
"scheduledExecutions": [
{
"status": "SCHEDULED",
"date": "2020-05-05T06:48:00.000+0000"
},
{
"status": "SCHEDULED",
"date": "2020-05-06T06:48:00.000+0000"
},
{
"status": "SCHEDULED",
"date": "2020-05-07T06:48:00.000+0000"
}
]
},
"page": {
"size": 20,
"totalElements": 1,
"totalPages": 1,
"number": 0
}
}
Where:
Parameter | Datatype | Description |
---|---|---|
executions | list | List of executions that has been triggered. Can be in status TRIGGERED ,
EXECUTED or FAILED .
|
scheduledExecutions | list | List of future executions in status SCHEDULED . Only 10 are returned as maximum. |
Parameter | Datatype | Description |
---|---|---|
id | string | UUID id for the execution. Not filled for scheduled executions. |
status | string | Can be TRIGGERED , or EXECUTED , or FAILED , or
SCHEDULED for future executions.
|
When you delete a scheduled operation, all the associated future programmed executions will be cancelled.
DELETE /api/v1/public/wallets/{walletId}/scheduled-operations/{scheduledOperationId}
where the
parameter walletId
in our example would be: cd496094-a77a-4e4e-bcd9-3361ff89294a
and
the scheduledOperationId
can be for example b2462ed0-d3d7-4c8a-abc3-980fd4472876
.
Therefore, the whole request would look like this: /api/v1/public/wallets/cd496094-a77a-4e4e-bcd9-3361ff89294a/scheduled-operations/b2462ed0-d3d7-4c8a-abc3-980fd4472876
.
As response, you will get a JSON with the information of the deleted scheduled operation. The parameters are the same as in the Get Scheduled Operation info request.
{
"id": "7f923d0b-0455-4b22-a489-67513eff2b7d",
"alias": "operation 26",
"concept": "testing",
"amount": 0.10,
"status": "DELETED",
"schedule": {
"startDate": "2020-05-04T06:48:00.000+0000",
"nextDate": "2020-05-05T06:48:00.000+0000",
"frequency": "DAILY",
"duration": {
"type": "END_DATE",
"endDate": "2020-05-07",
"numberOfRepetitions": 4
}
},
"receiver": {
"type": "IOCASH_WALLET",
"account": "877bd6b7-ed92-49e2-8e59-cc814fdb1000"
},
"createdAt": "2020-05-04T06:47:19.569+0000",
"_links": {
"self": {
"href": "/api/v1/public/wallets/a611e619-16ec-4e81-b24b-bbc52cbb61ba/scheduled-operations/7f923d0b-0455-4b22-a489-67513eff2b7d"
}
}
}
If the wallet is not in status READY
or the scheduled operation is not in status ACTIVE
,
an error will be returned.