Click Airtime

Response Codes

Complete reference of status codes and error codes returned by the Click Airtime V1 API.

Version 1 API (v1.4) — This API is in maintenance mode. New integrations should use the Version 2 API which provides structured error codes with descriptive messages.

Response Structure

The top-up endpoint (POST /adp) returns a code field that indicates the result:

{
  "message": "Descriptive message",
  "statusCode": 200,
  "code": 1,
  "data": { ... }
}
FieldTypeDescription
messagestringHuman-readable description of the result
statusCodenumberHTTP status code
codenumberNumeric response code (1 for success, other values indicate specific errors)
dataobjectResponse payload (present on success)

HTTP Status Codes

Status CodeDescription
200Request processed successfully (check code field for top-up results)
400Bad request — missing or invalid parameters
401Unauthorized — invalid or missing authentication credentials
403Forbidden — business logic failure (insufficient balance, invalid number, etc.)
404Not found — requested resource does not exist
500Internal server error — unexpected error on our side
503Service unavailable — the service is temporarily offline

Note that the V1 API may return non-200 status codes for business logic errors on the top-up endpoint. Always check both the HTTP status code and the code field in the response body.

Top-up Response Codes

The following response codes may be returned by the POST /adp endpoint:

CodeMessageDescriptionResolution
1Top-up successful! Airtime has been successfully topped upSuccess
5The airtime top-up operation has failedGeneral top-up failure (operator declined for a reason we don't have a specific code for)Check the transaction via GET /adp/transactions; retry if appropriate
10The operation is pending and being processedTransaction is in flight; will reach a terminal state shortlyPoll GET /adp/transactions?extRefId=... for the final state
20Request declined due to low balanceInsufficient account balanceTop up your account balance in the dashboard
30Recipient's number is invalidPhone number format is invalid, destination is not supported, OR the operator rejected the subscriber (not active / not KYC-verified for the requested service)Verify the phone number is in international format (e.g., 263719545499); for bundles, confirm the recipient is KYC-verified with the operator
50Repeat recharge to this number within 1 minute is blocked by this providerThe operator blocked a duplicate recharge to the same number within their anti-duplicate window (typically 1 minute)Wait a minute and retry, or change the amount
90External reference ID already existsThe extRefId was already used in a previous transactionUse a unique extRefId for each new transaction
150Specified amount is invalidThe amount sent does not match what the operator expects for the requested productIf sending a productId, omit amount (the bundle's preset price is used). Re-pull GET /adp/products if your cached catalogue may be stale
190Customer account not locatedYour account could not be foundVerify your API credentials
200Customer has not been configured to use this service providerNo service configuration for this destinationContact support to enable the destination
210Service provider product not foundThe productId you sent does not exist (or has been discontinued by the operator)Re-pull GET /adp/products for the current catalogue
218The carrier associated with the MSISDN doesn't correspond to the chosen packageThe productId is for a different network than the recipient's MSISDNUse a productId from the recipient's network, or use open-range airtime (omit productId)
221Data bundle purchase failedBundle subscription rejected by the operatorCheck the response state; if the recipient is on a non-eligible plan or your catalogue is stale, re-pull GET /adp/products
222MSISDN verification failedUnable to verify the recipient's phone numberVerify the phone number and try again
227Amount is below the minimum allowed recharge amountTop-up amount is too smallCheck the minimum amount for the destination network
228Amount exceeds the maximum allowed recharge amountTop-up amount is too largeReduce the amount or split into multiple transactions
231Invalid Source AmountThe calculated source amount is below the minimum thresholdIncrease the top-up amount
232Airtime Request is being processedReturned when processingMode: "ASYNC" is used; the request was queued and will be processed in the backgroundPoll GET /adp/transactions?extRefId=... for the final state
234This recharge route is temporarily unavailableThe network provider is experiencing issuesRetry after a few minutes
235Transaction not foundNo transaction matches the lookup criteriaVerify the extRefId / transaction_Id / msisdn you queried

Balance Error Messages

The following error messages may be returned by the GET /adp/balances endpoints:

MessageDescriptionResolution
Account not foundThe specified account_id does not exist or is not accessibleVerify the account ID from GET /adp/balances
Invalid or missing authentication credentialsAuth headers are missing or incorrectCheck X-Click-Airtime-Email and X-Click-Airtime-Token headers

Transaction Error Messages

The following error messages may be returned by the GET /adp/transactions endpoint:

MessageDescriptionResolution
At least one search parameter is requiredNo query parameters were providedInclude transaction_Id, msisdn, or extRefId in the query string
No transactions foundNo transactions match the search criteriaVerify the phone number or external reference ID
Invalid or missing authentication credentialsAuth headers are missing or incorrectCheck X-Click-Airtime-Email and X-Click-Airtime-Token headers

Best Practices

  1. Always check the code field — For top-up requests, the code field tells you the specific result. A value of 1 means success; any other value indicates a specific error.

  2. Handle timeouts gracefully — If you receive a timeout error on a top-up request, query GET /adp/transactions?extRefId=YOUR_REF before retrying to avoid duplicate transactions.

  3. Use unique extRefId values — Generate a unique reference for every transaction attempt. This prevents duplicate deliveries if your retry logic is triggered.

  4. Implement exponential backoff — When you receive a 503 response, wait progressively longer between retries (e.g., 1s, 2s, 4s, 8s).

  5. Log all responses — Store the full response body for every API call to assist with debugging and reconciliation.