What is the OnLink API?

The OnLink API lets a business move money into and out of Kenya without becoming a bank integrator or a crypto desk. You connect once. From then on your systems can take shillings in on a Kenyan rail and pay them out to M-PESA or a bank account. They can convert between shillings and USDT at a rate we quote, or collect US dollars from contributors in the US and then convert those dollars to shillings or pay them out as dollars.

Think of it as a currency desk your software can call. You do not visit it; you send it an instruction, and it reports back when the job is done.

The problem it solves

A business that earns in shillings and spends in USDT, or the other way round, has to do four hard things to move between them:

• Price the conversion off a live rate, and honour that rate long enough to act on it.
• Take funds in on one side — a bank transfer or an M-PESA payment in Kenya, or a USDT transfer on-chain.
• Pay funds out on the other side, to the right place, exactly once.
• Screen every movement and keep the records that come with moving money.

Each of those is its own project. OnLink does all four behind one API, with one counterparty, so your team builds the product on top rather than the plumbing underneath.

Money in, and money out

Your partner account holds balances with us — shillings, on the USDT product USDT, and on the collections product US dollars. Everything you do either fills a balance, empties one, or converts between them.

Buying and selling USDT work the same way in both directions: lock a rate, create an order, and wait for us to settle it. The order is paid for from a balance you already hold, so there is no payment to chase. Paying out works the same way too: you give the instruction, someone you nominated confirms it with a one-time code, and we tell you when the rail settles it. Converting US dollars to shillings is simpler still: one request, no code, because both accounts are yours, and a webhook when it has settled. How it works walks through both in plain language.

Shillings arriving on a Kenyan rail top up your balance; they are not tied to any one order. If you need to know which of your own users sent a payment, the rail's own reference, the amount and the time are your handles. Receive money in Kenya explains how to design for that, and how to raise an M-PESA prompt yourself instead.

USD collections are a separate product, and they cover the whole journey. You open a collection and hand your contributor US deposit details. The deposit is then paid into your USD account, net of fee, and a webhook tells you when it lands. From there you decide what happens to the dollars, and when: convert them to shillings in your KES account and pay those out on any Kenyan rail, or pay them out as US dollars to a USD bank account. Nothing is converted unless you ask for it. Collect in the US, pay out in Kenya walks through it end to end.

Who it is for

The API is built for businesses that already hold a relationship with the people whose money is moving:

• Remittance operators bringing value into Kenya and paying it out locally.
• Exchanges and wallet apps giving their customers a way in and out of shillings.
• Treasury teams at companies with revenue in one currency and costs in the other.
• Platforms paying suppliers or contractors in Kenya from a USDT balance.
• Products collecting from many payers, in shillings in Kenya or in US dollars from the US, where the roll of who paid what is yours to keep.

Use cases describes each of these in more detail.

It is not a retail product. OnLink does not offer a stablecoin wallet or a self-serve trade to individuals in Kenya through this API, and your end customers never interact with OnLink directly. They interact with you.

What you build, and what we do

Your users are yours. We never see them, so identifying and verifying them is your responsibility, under your own registrations. You decide who can transact on your platform, you keep the records your regime requires, and you tell your customers what happens to their money and how long it takes.

We price and execute the movement of value between the two currencies. We screen each movement and its counterparties, we pay out on the rails, and we tell you the outcome — as a status you can read and as a message we send to you. When we cannot complete a movement, we say so rather than guess.

Who does what sets out that line in full.

Where the money can go

Nothing about a destination is decided at the moment of a payment. The proceeds of a sell can only land in one of your own OnLink KES accounts. Addresses that can receive USDT are registered through the API and then confirmed, so a mistyped address is caught before any value moves. And every transfer or USDT send you instruct waits for a one-time code sent to a person you nominated — by default not to your integration — before anything moves. Unless your account receives confirmation codes by webhook, a leaked credential on its own therefore cannot send your money anywhere you have not already approved. If it does receive them by webhook, one backend holding both your API secret and your webhook endpoint holds both factors, so compromising it can move money with nobody reading out a code. The same is true of an account OnLink has enabled confirmation waiving for, where in production an API key with an IP allowlist needs no code.

Where you start

Everything begins in sandbox, a full copy of the service where no real value moves. Your engineers integrate and test there, including receiving real signed webhooks. When the integration is ready, production access is enabled for your account, and nothing changes in the code except the address it talks to and the credentials it uses.

Next

• How it works — the life of an order and of a payout, step by step.
• Use cases — what different kinds of business build on this.
• Glossary — every term, defined once.
• Get started — when you are ready to hand this to an engineer.