v1 - User Endpoints Only

Getting Started


Deposits Layers
A. Deposits Core
B. Platform services
C. Banks/FI/Credit Unions/Business Aggregators
D. Open market


Life can be complex, everyone knows it. We believe money doesn’t have to be. As a result, we have built a single platform that serves as a marketplace for all things money and is the complete solution to several financial needs within the American workspace. We provide a suite of services specially designed for the American business and workforce.
Our services can be used by various financial institutions, businesses, employers, developers, and brokers alike. With us, you can build your bank, run KYC, accept payments, store value, send funds, offer p2p transfers, and do so much more.

Getting Started

The Deposits API is built around a standard REST architecture, uses predictable, resource-oriented URLs, and all data are returned in JSON format. Requests are made with HTTP methods and HTTP response codes indicate the success or failure of those requests.

API Architecture And Resource Structure

The Deposits Platform has various resources and features, but is majorly centered around five resources. Virtually all the others are connected in one way or another with the resources mentioned here.
  • KYC&KYB (KySync product)
  • Payment collection
  • Transfers
  • Topups
  • Payouts
The Deposits API architecture is laid out in various levels as described below.
A tenant is an organization or institution built on the Deposits API or making use of the Deposits API to offer finance-related products and services to other entities
An entity is a single unique object who is able to carry out transactions on the Deposits platform. On deposits, we have two types of entities - individual and business
An individual is a type of entity that is a person. An individual will go through KYC.
A business is an entity that is a registered organization. A business will go through KYB
A user represents an end-user accessing the Deposits Platform API via your application, be it a mobile app, web app, desktop app, etc.


For ease of development, we have provided two environments from which you can access and interact with our APIs depending on how far along you are in the development stage. When you interact with our APIs, your use of the live or test keys would determine what environment you're working in.

Live Environment

The base URL for the Live Environment is

Staging Environment

The base URL for the Staging Environment is


Our suite of API endpoints allows you to build fintech applications for your users. You're able to create wallets, issue cards to your customers, and so much more. Deposits makes use of designated public and private keys to authenticate requests and perform actions.
To get these authentication keys, you have to create an account or log into your existing console to retrieve your keys. You can access the console here.
For security reasons, we recommend that in public-facing scenarios, such as building your SDKs on ours or using any of the Deposits SDKs, you utilise the Public Key rather than the Private Key.
It is important to keep your API key private because it provides direct access to your account. Your API (private) key should not be disclosed on public platforms and should be kept safe at all times.
Console dashboard

Console Staging Environment

You can access the console in the staging environment here
We will always be available to help if you are having trouble setting this up.

Status Codes

Status codes are part of a response that can be received while interacting with the Deposits API. There are two main status codes that can be gotten while interacting with our APIs:
  • 200 OK
  • 400 Bad Request

200 - OK

A 200 response looks like this:
"status": "success",
"message": "Account created successful.",
"data": {...}
It is however important to note that a 200 OK response can also look like this
"status": "error",
"message": "user client not found.",
This requires you to check the credentials you put in and ensure they are correct.

400 - Bad Request

A 400 bad request means the request was not successful and was possibly a fault from our end. A 400 bad request response can be similar to this:
"status": "warning",
"message": "An error occured please contact our support team"
A response body contains three parts:
  • Status - could be ‘success’, ‘warning’, or ‘error’ depending on what request was made and the state of the request.
  • Message - this provides more information or context as to what the request has found or achieved.
  • Data - could be null, object or array.

Rate Limiting

The maximum amount of API calls you can make from a single client in a minute is 200. If your use case requires more than 200 calls in a minute, please reach out to us.