Airtime API or supplier portal? How to choose

A portal can be the easier choice if an operator can process the busiest day’s orders, handle failures and close out the account. An API makes more sense when repeat work takes enough staff time to pay for the build and someone can run it afterwards. Compare both routes with the same set of orders.

By Freepaid · Published 3 November 2026

Compare the actual workload

List monthly orders, peak bursts, product changes and percentage of exceptions. An API adds development, credential management, monitoring and support. A portal shifts work to an operator and requires access review, maker-checker approval and repeatable records. Compare time spent on both paths over a representative month.

A weekly order file may take one portal upload and a second person’s approval. If staff type hundreds of different orders into a form every day, time that work before you price the build. Include fixing invalid numbers and tracking down pending orders.

Use the busiest day as well as the monthly average. Ask whether the portal can accept your largest batch and what rate limit the API applies. Check what happens when one order in that batch needs attention.

Five checks before you choose

1. Describe the demand. Record orders per week, busiest day, products, average batch size and exceptions. Use four recent representative weeks if records exist. Separate routine work from seasonal spikes.

2. Cost the portal route. Time the operator’s preparation, approval, submission, status checks, correction and closeout. For example, 12 batches taking 25 minutes each require five hours of direct handling monthly, before exception work.

3. Cost the API route. Obtain a build estimate and include security review, deployment, monitoring, maintenance, supplier change testing and support coverage. Divide the one-off build estimate over the business period used for comparison, and show it separately from recurring cost.

4. Compare failure ownership. For an invalid recipient, a portal may show an operator a rejection while an API requires your application to present a usable error and prevent accidental resubmission. For a timeout, both routes need a status check against the original reference.

5. Agree what counts as a pass. Ask staff, finance and engineering what they need to approve, track and reconcile orders. A portal can handle sizeable volumes if those steps are quick. An API still has ongoing costs when volume is low. Keep the sample and assumptions with the decision and revisit it when volume, staffing or products change.

Compare the two routes over the same period

Say an operator spends 12 hours a month on the portal at an internal rate of R180 an hour. That’s R25,920 over 12 months. An API build costs an estimated R30,000 plus four hours of monthly work at the same rate, for a first-year total of R38,640. The API costs R12,720 more in that example before either supplier's fees. Check the busiest weeks and what support will cost in year two before you decide.

Record costs on the same basis. Separate a one-off integration estimate from recurring operating costs. List supplier fees only when confirmed, and treat unpriced work as an open item. If the business expects faster fulfilment, define the time window that matters and measure it in both trials. Finance needs the costs and the observable business outcome to decide.

Once you know what you’re buying, read the documentation for that product. Freepaid’s SOAP API, SIMcloud’s airtime API and AllNetAirtime’s voucher API each handle orders and status checks differently. Freepaid airtime API · SIMcloud airtime API · AllNetAirtime API documentation

Record the decision and a review date

Show setup work separately from what the portal or API will cost to run each month. Ask the portal administrator and engineering to demonstrate the same orders, volume and approval rules, including an order with an uncertain result. Keep the observed handling time, estimate date and any unanswered supplier questions with your decision.

Write down who owns the system, funding and reconciliation. Attach a sample run from each route, the cost assumptions and the process for exceptions. If you choose the portal, say what volume or change in controls would prompt a review. If you choose the API, name who covers it when staff are away or the supplier is doing maintenance.

Give staff a short guide for the route you chose and name who handles escalations.

Review annually.

Match the work to the product before choosing the interface

If you use SMS to tell someone about an airtime reward, keep separate records for the text and the reward. A successful message tells support who got the notice. The order or voucher record tells them what happened to the reward.

More in this series

• Prepaid API supplier RFP template for South African buyers
• Scope a prepaid integration before you estimate the build
• What finance needs from a prepaid integration
• Test prepaid order failures before going live
• Compare an airtime product catalogue across two suppliers
• What to monitor when a supplier handles prepaid fulfilment
• Plan a prepaid API migration with a pilot cohort
• Give support teams the right prepaid order evidence
• Review an API reseller partner before sharing access
• Wholesale airtime buying guide for South African businesses
• Reconcile prepaid airtime purchases at month-end

Browse all Freepaid prepaid business guides