Data and airtime, as an API.
Billbytes sells Nigerian data bundles and airtime over one REST API — MTN, Airtel, Glo and 9mobile — against a prepaid naira wallet.
curl https://billbytes.ng/api/v1/ping/
{
"status": true,
"message": "pong",
"version": "v1",
"time": "2026-11-03T15:43:31+01:00",
"purchases_enabled": true,
"request_id": "req_13750612559829c5d262a5b5"
}
Buy a bundle in one POST.
The plan quoted below is active in the catalogue right now, so this is a real command against a real plan_id. Plan ids come from GET /api/v1/bundles/ and are stable.
curl -X POST https://billbytes.ng/api/v1/bundles/purchase/ \ -H "Authorization: Bearer bb_live_your_key" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{"plan_id": 70, "phone": "08031234567"}'
{
"status": true,
"transaction": {
"reference": "bb_tx_6a7b5ffa48948afd1431",
"status": "success",
"service": "data",
"network": "MTN",
"phone": "08031234567",
"amount": 297,
"currency": "NGN",
"plan": "1GB IG/TT/YT Weekly Plan",
"plan_id": 70,
"created_at": "2026-11-03T15:43:31+01:00",
"completed_at": "2026-11-03T15:43:31+01:00"
},
"request_id": "req_13750612559829c5d262a5b5"
}
A retry carrying the same Idempotency-Key returns that first result again with "replayed": true — no second purchase and no second debit. Reuse a key with different parameters and you get 409 idempotency_key_reused instead of the wrong order. An order still with the operator answers 202 and status pending; poll GET /api/v1/transactions/?reference=… or wait for the webhook rather than retrying with a fresh key.
Test keys spend nothing.
A bb_test_ key never reaches the network operator. The recipient number decides the outcome, so you can drive every branch — including the one everybody forgets — before a naira moves.
| Recipient | Transaction status | Your wallet | Webhook |
|---|---|---|---|
| 08000000001 | failed | Refunded in full | transaction.failed |
| 08000000002 | pending | Debited, order left open | none yet |
| any other number | success | Debited | transaction.success |
The sandbox answers 202 for the pending case and 200 for the other two, and it queues the same HMAC-SHA256 signed webhooks a live key would — so your delivery handler can be finished and tested before you ever fund a live key.
Four steps, all self-service.
Create an account
The same account the storefront uses. There is one wallet behind it.
Issue a key
Sandbox or live, from your developer page. The key is shown once; we keep only a peppered HMAC of it.
Fund the key's wallet
Move naira from your site wallet into the key. Purchases are prepaid and debit that balance.
POST a purchase
One call per order with an idempotency key. A signed webhook lands when it settles.
168 sellable plans across 4 networks.
The price returned by GET /api/v1/bundles/ is exactly what your wallet is debited. Quote it to your own customers and keep the difference. Prices move when the networks move theirs, so read the catalogue rather than hard-coding it.
| Network | Plans | Lowest | Highest |
|---|---|---|---|
| 9MOBILE | 15 | ₦245.00 | ₦19,584.00 |
| AIRTEL | 10 | ₦62.00 | ₦4,998.00 |
| GLO | 63 | ₦49.00 | ₦19,584.00 |
| MTN | 80 | ₦25.00 | ₦123,675.00 |
Create an account, issue a sandbox key, spend nothing.
Already have an account? Your keys, wallet and webhook secret live on the developer page. Everything else is in the documentation, and /api/v1/ is the machine-readable index.