1.11.7. Future Sandbox API


Sandbox serves the following resources:

  • Demobanks.
  • Bank accounts.
  • Subscribers.
  • Transactions.
  • Customers.
  • Reports.

The resources are subject to all CRUD operations, via by two types of users: the ‘admin’ and the customers. The admin has rights on all of them.

One of the main differences with the previous versions is the removal of the “/admin” initial component. If the administrator authenticates for one operation, then this one is of type admin: no need for a dedicated and extra URI path component.

For example, mocking transactions in the system was a typical /admin-operation, but since transactions themselves are resources and any resource is subject to CRUD operations, then mocking one becomes just a C operation on the ‘transactions’ resources. If a test case wants to simplify the authentication - by hard-coding the credentials, for example - before mocking one transaction, then it can impersonate the administrator.


POSTing to an endpoint with a trailing $id means modification of an existing resource.


Demobanks are the main containers of all the other resources. They take configuration values, like the currency for example.

GET /admin/demobanks
GET /admin/demobanks/$id
POST /admin/demobanks
POST /admin/demobanks/$id
DELETE /admin/demobanks/$id

Bank accounts.

Bank accounts collect money of customers and participate in transactions.

The $base is one demobank, in the form /demobanks/$id. That is due because a bank account must inherit some defaults from the demobank, like the currency.

GET $base/bankaccounts
GET $base/bankaccounts/$id
POST $base/bankaccounts
POST $base/bankaccounts/$id
DELETE $base/bankaccounts/$id


Subscribers are (optional) customers identities for protocols other than the native one.

A subscriber is not required to have a bank account “soon”. Therefore, it can be created, and later be linked to one bank account. For this reason, the $base should not mention one bank account.


Creating a subscriber is a time-consuming operation that goes often through slow channels, therefore it should basically never be done more than once.

GET $base/subscribers
GET $base/subscribers/$id
POST $base/subscribers
POST $base/subscribers/$id
DELETE $base/subscribers/$id


Transactions are money movements between bank accounts.

For convenience, $base could mention one bank account to let customers see their transactions without defining “history” query parameters: like $demobank/bankaccounts/$bankaccountId/transactions.

At the same time, transactions should be easy to query regardless of whose bank account they involve – for administrative reasons, for example. Hence, a “global” URI scheme like $demobank/transactions?param=XXX should be offered as well.

GET $base/transactions
GET $base/transactions/$id
POST $base/transactions
POST $base/transactions/$id
DELETE $base/transactions/$id


Customers are persons that can have one bank account. As with subscribers, $base should not mention any bank account so as to leave more flexibility to assign new bank accounts to the same customer.

GET $base/customers
GET $base/customers/$id
POST $base/customers
POST $base/customers/$id
DELETE $base/customers/$id


Reports are persistent documents witnessing transactions. A typical example is a Camt.053 statement. A report lives even after a bank account gets deleted or a customer leaves the bank, therefore $base should only mention a demobank instance.

GET $base/reports
GET $base/reports/$id
POST $base/reports
POST $base/reports/$id
DELETE $base/reports/$id