Vend data bundles via sub account (v1)

Deprecated. This endpoint is deprecated and will be removed in a future release. Use POST /v2/bill/data/{subAccountId} instead.

POST /v1/bill/data/{subAccountId}

Vend data bundles via a sub account

cURL

curl --request POST \
  --url https://api.nomba.com/v1/bill/data/{subAccountId} \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --header 'accountId: <accountid>' \
  --data '
{
  "productId": "mtn47",
  "phoneNumber": "08055441122",
  "network": "GLO",
  "merchantTxRef": "3bvwhibh38220dsjakTwvb",
  "senderName": "John Doe"
}
'

200

{
  "code": "00",
  "description": "Success",
  "data": {
    "amount": 200,
    "timeCreated": "2023-09-04T07:09:06.900Z",
    "type": "topup",
    "status": "SUCCESS",
    "productId": "mtn47",
    "plan": "3.5GB Daily Plan",
    "meta": {
      "merchantTxRef": "test1116",
      "rrn": "240626232937"
    },
    "id": "API-DATA-AAA1A-36dc6c70-5cf2-4592-93be-9bccc23df7f5"
  }
}

This endpoint is deprecated. Use Vend data bundles via sub account (v2) at POST /v2/bill/data/{subAccountId} instead.

Always requery the transaction using Fetch a single transaction on a sub account to confirm its final status before issuing a refund. Only refund if data.status is REFUND.

For a complete guide on response codes and transaction statuses, see Response Codes.

Authorizations

Authorization · string · header · required

Nomba authenticates API calls with OAuth2 HTTP bearer tokens. There are two methods of authentication; Client-Credentials method and PKCE (Proof Key for Code Exchange) method. In each of the methods, You will get an ACCESS_TOKEN. You need to use an "Authorization" HTTP header to provide your ACCESS_TOKEN. For example: Authorization: {ACCESS_TOKEN}.

Headers

accountId · string<uuid> · required

The parent accountId of the business this sub account belongs to

Example:

"890022ce-bae0-45c1-9b9d-ee7872e6ca27"

Path Parameters

subAccountId · string<uuid> · required

The sub accountId via which data bundle is to be vended

Example:

"890022ce-bae0-45c1-9b9d-ee7872e6ca27"

Body

application/json

The request payload required to vend data bundles

productId · string · required

The unique identifier of the data plan to purchase — returned as productId by the Fetch Data Plans endpoint. Required for all new integrations: it resolves to an exact plan and amount, removing any ambiguity when multiple plans on the same network share the same price.

Example:

"mtn47"

phoneNumber · string · required

Recipient phone number

Required string length: 11 - 13

Example:

"08055441122"

network · enum<string> · required

Recipient network (telco). It can also come as lowercased values e.g. glo, mtn etc.

Available options: GLO, MTN, 9MOBILE, AIRTEL

Minimum string length: 3

Example:

"GLO"

merchantTxRef · string · required

Merchant Transaction Identifier reference (Unique to merchant)

Example:

"3bvwhibh38220dsjakTwvb"

amount · number<double> · deprecated

Deprecated — do not use. amount is a legacy-only field with no guarantee of correctness: multiple plans can share the same price, so it cannot reliably identify the bundle you want. Use productId — the only supported way to select a plan.

senderName · string

A name to describe the sender of the data

Example:

"John Doe"

Response

200

application/json

OK - your request was successful.

code · string · required

Response Code

Example:

"00"

description · string · required

Response description

Example:

"Success"

data · object · required

Show child attributes