KDA API Logo
API Docs
Services

Overview

Explore the KDA API services.

Service endpoints (purchases, verifications, plans) require an API key with the services scope. Profile-scoped keys will receive a 403 Forbidden when attempting to access these endpoints.

How Our Services Work

Every VTU service follows the same two-step workflow:

Fetch Available Plans

Send a GET request to the service's /plans endpoint to retrieve the list of available products with their kds-* plan IDs and pricing. Pass ?id=<planId> to fetch a single plan, or ?type=<class> (Data/TV) to filter by plan class.

GET /api/services/{service}/plans
GET /api/services/{service}/plans?id=kds-*-* 

Make a Purchase

Send a POST request to the service endpoint with the chosen planId, the target identifier (phone number, meter number, etc.), and an idempotencyKey.

POST /api/services/{service}

Response Format

All successful purchase responses return this top-level envelope with a data object that varies per service type:

{
  "success": true,
  "message": "Data purchase successful!",
  "transactionId": "KDS-DAT-YRGH1BZA-SN",
  "data": {
    "amount": 1000,
    "label": "2GB",
    "planId": "kds-data-001",
    "provider": "MTN",
    "number": "08031234567",
    "status": "SUCCESS",
    "description": "Data purchase successful!",
    "transactionId": "KDS-DAT-YRGH1BZA-SN",
    "createdAt": "2025-01-01T12:00:00.000Z",
    "validity": "30 Days",
    "category": "SME",
    "type": "DATA",
    "idempotencyKey": "your-idempotency-key"
  }
}

transactionId is your internal KDA reference. The data object always includes amount, provider, status, description, transactionId, createdAt, type, and idempotencyKey, plus additional fields depending on the service type.

Service-Specific Fields

The data object is dynamically composed per service type. Below are the extra fields returned beyond the common set:

Prop

Type