All requests to the Bity API should begin by creating an instance of this Order class. It's designed around the builder pattern, where methods are chained to declaratively configure the order.
Here are a few common examples to get you started!
NOTE: Even though this package does a best-effort approach to safety, it is possible to create invalid trading pairs, such as a fiat to fiat trade. In these cases, the Bity Exchange API will tell you it doesn't support this trade. The same goes for any unsupported currency codes or invalid amounts.
This is the most common usage of Order. Depending on the currency codes
the underlying available methods change. In this example,
'CHF' will cause
a FiatInput to be assigned to Order.input, and
'BTC' will cause a
CryptocurrencyOutput to be assigned to Order.output.
const order = (new Order()) .setInput('CHF', '12.00') .do((input) => input .setOwner(new Owner(...)) .setIban('...')) .setOutput('BTC') .do((output) => output .setCryptoAddress('...')); // Now use your order in a request. const preparedOrder = await order.generateObjectForOrderCreation(); preparedOrder .then(bity.createOrder) .catch(alertUserTheOrderHasErrors);
We can see here that generateObjectForOrderCreation can fail. This is because some fields may be invalid, such as a phone number, or an IBAN. This is one of many safety features we have put in to make it safe for developers to create orders with confidence. This is accomplished with Order.areAllFieldsValid().
It's common where a user would like to "pin" their exchange on its output price. This is particularly useful for cryptocurrency to fiat exchanges, when a client might want a precise amount of money for the trade to pay for something directly like their rent or some fast food.
const order = (new Order()) .setInput('BTC') .do((input) => input.setCryptoAddress('...')) .setOutput('CHF', '100.00') .do((output) => output.setOwner(new Owner(...)));
Due to the nature of floating point numbers, precision is lost when using
this format. For some people the loss of even the smallest denomination is
unacceptable. The solution is to encode all amounts as strings so precision
is kept throughout the entire process. As a developer, it's up to you how you
use these NumericalStrings. You should never
parseInt() these strings unless you are using the result to display a
warning, error, or similar message to the end-user.
In the event a developer tries to set an amount as a string, it will throw an error.
On resolve, an object (which is intentionally abstracted to be
robust against API changes) that will be sent to Bity's
On rejection, the error object.
Generated using TypeDoc