Technical details

Overview

Zalando RESTful API and Event Guidelines are followed.

For exact details of each endpoint please see >> OpenAPI specs <<.

---

🚗🚀 Order flow

---

🆕 Order Creation

1. Data preparation

First you need tell client parameters of his exchange, for this purpose you need 🌍 GET /price.

Also we recommend using our crypto address validator, if client supplies one 🌍 GET /btc-address-validation/{address}.

2. Order create

After validating input data order creation endpoint is called.

According to your implementation call one of the public GET endpoints (if done in browser):

• 🌍 GET /order/create/buy
• 🌍 GET /order/create/sell
• 🌍 GET /order/create/deposit

Or if done at backend, rather use one of private POST methods:

• 🔒 POST /order/create/buy
• 🔒 POST /order/create/sell
• 🔒 POST /order/create/deposit

If above action is successful, client is notified by email about order creation.

---

Following cases are not required to have implemented - if you are providing only order creation and any other cases of flow go through our fallback website.

About most cases bellow is client informed via email and provided with corresponding URLs to solve their situation.

Each case solution consists of two or more API calls in set order. Generally GET confirms right condition and provides information. POST sends resolution of case.

---

🪤 Verification

Client can be prompted to prove his identity in one or more steps. About each step is informed in separated email.

1.a Verify Identity

There is base information about person: name address, personal documents and phone number, etc...

1. 🔒 GET /order/{id}/verify-identity - indicates case validity (and supplies needed information)
2. 🔒 POST /order/{id}/verify-identity - resolves case

1.b Anti Money Laundering

This step is required with bigger orders and takes place after Identity verification.

Please notice AML endpoints are separate for each country.

Czech Republic:

1. 🔒 GET /order/{id}/aml-cz - indicates case validity (and supplies needed information)
2. 🔒 POST /order/{id}/aml-cz - resolves case

2. Verify Phone

Phone verification is more complex, since we need to send SMS code on demand.

SMS endpoints can be omitted if client refuses.

1. 🔒 GET /order/{id}/verify-phone - indicates case validity (and supplies needed information)
2. 🔒 GET /order/{id}/verify-phone-sms - indicates if SMS code is already sent or not
3. 🔒 POST /order/{id}/verify-phone-sms - request sending SMS code to client
4. 🔒 POST /order/{id}/verify-phone - resolves case

---

🐖 Deposit

When client wants use his deposited funds, this case takes place. Please notice workflow is very similar to Verify Phone.

1. 🔒 GET /order/{id}/deposit - indicates case validity (and supplies needed information)
2. 🔒 GET /order/{id}/deposit-sms - indicates if SMS code is already sent or not
3. 🔒 POST /order/{id}/deposit-sms - request sending SMS code to client
4. 🔒 POST /order/{id}/deposit - resolves case

---

✏️ Change

In case input funds or exchange rate expires client is prompted to decide if they accept changed conditions.

1. 🔒 GET /order/{id}/change - indicates case validity (and supplies needed information)
2. 🔒 POST /order/{id}/change - resolves case

---

🪃 Return

In case we decide about cancellation of SELL order, we need information to whee to return crypto funds.

1. 🔒 GET /order/{id}/return - indicates case validity (and supplies needed information)
2. 🔒 POST /order/{id}/return - resolves case