BUILD YOUR INTEGRATION

One endpoint. Your own access.

Connect with a dedicated API key, use your permitted product codes, and vend through the existing account API with your limits applied.

Try the integration/autobiz_vending_index.php

01 / GET CONNECTED

Quick start

Ask the account owner to activate the one-time paid add-on and create your access point with the products and limits you need.
Obtain the API key securely from the owner. Your portal username and password are separate and cannot authorize API requests.
Send a JSON POST to the shared endpoint with Authorization: Bearer YOUR_ACCESS_POINT_KEY and Content-Type: application/json.
Call get_available_services for your permitted product codes. Confirm each code’s price and required fields with the owner before purchasing.
Use a unique user_reference per purchase. Keep the same reference and identical payload when retrying that purchase.

Existing shared-endpoint integrations keep the same endpoint and familiar payload. Replace the API key and use an assigned catalogue product code. Use ap:mtn_vtu, ap_mtn_vtu, or the original mtn_vtu. The access-point prefix is stripped before normal product routing. Assigned products must be local catalogue codes; remote OneConnect product codes are not supported.

02 / API REFERENCE

Requests

Action	Payload fields	Result
`get_available_services`	None	The normal API catalogue response, filtered to permitted product rows.
`balance`	None	The normal account balance response. Owner must enable balance visibility.
`status`	`user_reference` (or `order_id`, containing the same client reference)	Actual transaction state, scoped to this access point.
`vend`	`product_code`, `user_reference`, recipient fields; `amount` and `quantity` where applicable	The normal vending response, unchanged.

Purchase fields

Use phone_number for airtime/data or the contact phone for utilities. Add meter_number for electricity or smartcard_number for TV. Supply amount for variable-price products, in the wallet’s major currency units. quantity defaults to 1. Optional name is supported. Product validation and pricing remain those of the shared API.

References must be 5–100 characters: letters, digits, underscore, hyphen, colon or vertical bar. Reusing a reference with different purchase details is rejected. A retry must not generate a fresh reference.

{
  "action": "vend",
  "product_code": "ap:YOUR_ASSIGNED_PRODUCT_CODE",
  "phone_number": "RECIPIENT_PHONE",
  "quantity": 1,
  "user_reference": "integration-order-00001"
}

03 / HANDLE THE RESULT

The same API response

Access points return the existing account API response without changing its fields, status codes, delivery status, or provider result. Your integration should handle it exactly as it handles the owner’s API response.

Check access

The key identifies the owner and access point. Product permissions and limits apply before recording the transaction.

Normal vending

Existing pricing, wallet preferences, routing, provider processing, and callbacks continue. History labels the actor as the access point.

Normal result

No access-point-specific success acknowledgment or waiting mode is applied. Existing platform processing settings determine the result.

Use a stable user_reference. An identical retry checks the recorded transaction through the normal status handler; it does not debit again. To check status, send order_id with the returned recharge ID or your original reference. Only transactions belonging to this access point can be queried.

A timeout does not prove failure. Check the original reference before retrying; never generate a new reference merely because a response was delayed. Pending responses retain their normal meaning.

04 / OPERATE SAFELY

Limits and security

Purchases use the owner’s existing pricing, wallet preferences and vending flow. Product permissions, limits, expiry and request rate limits remain enforced. Money caps track money-wallet charges; non-cash wallet usage is controlled by transaction-count and quantity caps.
Daily and monthly limits follow the configured access-point timezone. Check remaining allowances and transaction history in the read-only portal.
The owner’s API IP allowlist applies to normal API requests. The secure browser tester can bypass this check only with a valid portal session and the matching API key. All other permissions and limits still apply.
Keep production keys on your backend, outside source control, URLs, analytics, and logs. Do not embed them in a public website or mobile app.
Only owners manage access. Administrator changes require the owner’s approval code. Ask the owner to rotate a compromised key; portal passwords and MFA do not replace API keys.
Use the documented shared API actions and purchase fields. Normal wallet choices, callbacks and async options are preserved; caller-supplied owner IDs, actor labels, worker flags and internal bypass controls are never trusted.

Troubleshooting

Not permitted: check product assignment, balance permission, account IP allowlist and whether the access point is active. Limit reached: inspect portal allowances and ask the owner to adjust them. Reference conflict: restore the original purchase details. Pending or unknown: check status, never assume failure. Feature unavailable: ask the owner to verify the feature flag and paid entitlement.

PERMITTED CATALOGUE

Your products

This tab automatically loads the products permitted for your signed-in access point. No API key is needed.

05 / TRY IT HERE

Live integration tester

Portal tests use a session-protected handler and the same access-point vending runtime. This is a production endpoint, not a sandbox. No request is sent until you press Send request.

Tests use your portal session, are audited, and are limited to 10 requests per minute. If sign-in is required, a login form opens here without clearing your request.

View request example

The example always uses a placeholder key. Replace it only in a trusted server environment.

Response

Ready. No request sent.

Your response will appear here.