Get started
From no access to a signed call against sandbox, a complete order and your first webhook, in five steps.
This section takes you from no access to a working integration against sandbox: credentials, a signed request, a first call, a complete order and a verified webhook. If you have not read the plain-language Overview yet, it is a good ten minutes before this one.
The OnLink API moves money into and out of Kenya on behalf of your platform:
shillings in on a Kenyan rail, conversion between shillings and USDT, and
payout to a destination you registered. It is an HMAC-signed HTTP API; every
route lives under /v1.
What you need
- Sandbox credentials — a key id (
pk_followed by 24 hex characters) and a signing secret, carrying the scopes your integration needs. Step 1 below is how you get them, and Products and scopes explains what a scope grant does. - A way to compute HMAC-SHA256. Every request is signed. There is no bearer token and no OAuth flow.
- An HTTPS endpoint to receive webhooks. You can start without one and poll instead, but the webhook is the real completion signal.
- Somewhere durable to store two identifiers — our
orderIdand your ownpartnerReference— before you move any funds. There is no list-orders endpoint, so an id you never recorded cannot be looked up later.
The five steps
Get sandbox credentials.
Ask for sandbox access through the request form or by emailing info@onlink.africa, and tell us what you are building — credentials are issued to a named integration. The reply carries your key id, your signing secret and the base URL. Store the secret in a secrets manager; it never travels in a request. See API credentials for how to hold and rotate it.
Sign a request.
Four headers and one HMAC over five newline-joined fields. Authentication has the exact recipe and a worked example whose signature you can check your own code against before you send anything.
Make your first call.
A signed GET /v1/health, then a real quote from POST /v1/quotes, in curl,
Node and Python. Your first call walks through
both and points out the three things in a quote response you must decide about
now rather than later.
Run a complete flow.
Quote, create, move the funds, receive the terminal webhook. Sell USDT, receive KES is the flow most teams start with; Buy USDT with KES is the other direction.
Receive and verify your first webhook.
Give us an HTTPS endpoint, trigger an event, and verify the signature with the recipe in Verifying signatures. The Sandbox page explains how to reach each terminal state there, including the one that needs nothing from us.
Two things that save you an afternoon
Both exist, both are supported, and neither is obvious:
- The Postman collection — 22 requests covering every operation, with a pre-request script that signs each one for you. Import it together with the sandbox environment, fill in your key id and secret, and you can exercise the API before writing any code.
- The reference signer — a dependency-free Node file implementing the signing scheme, with its own self-test vectors. Copy it into your backend or read it and port it. It is asserted against the guard that verifies your requests, so it cannot drift from what the service actually checks.
Before you design anything
Read asynchronous settlement. Creating an order does not complete it, and an integration built as though it does is the one mistake that has to be un-built rather than patched.
Environment
https://sandbox.onlink.africaSandbox is where you integrate and certify. Production access is enabled per partner — talk to us when your integration is ready.