Build a data bundle selector from the API catalogue
Help customers choose a Nigerian data bundle by network, size, duration and current product cost without confusing labels or silently substituting a plan.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
Two plans can both say '1 GB' and still be different purchases. Validity, network and product terms matter to the customer. The safest selector preserves the exact chosen product instead of reconstructing an order later from a label and a phone number.
Build choices from returned attributes
Read /products/dataplans?network=MTN to discover MTN products, substituting another supported network when appropriate. Follow pagination until you have the records needed for your selector. An empty first result is not evidence that a guessed product ID will work.
Use the returned product ID as the option's identity. Display bundle_size, duration, network and the package label when available. A nullable bundle_type is an unknown value; do not convert it into a marketing promise about how the bundle is delivered.
| Selector field | Handling rule |
|---|---|
| Product ID | Keep the returned string unchanged |
| Network | Preserve it with the selection and confirm it with the customer |
| Bundle size | Display the returned value without inventing a unit conversion |
| Duration | Show the actual returned validity wording |
| Bundle type | Allow an unknown value and avoid unsupported filter assumptions |
| Price | Calculate the retail total from current cost and your pricing rules |
Keep filters honest
Only send query parameters supported by the endpoint you are calling. A returned field does not automatically exist as a server-side filter. If your interface filters records locally, make that filtering operate on a complete, relevant dataset and preserve the same server query across pagination.
Do not match a purchase by 'the cheapest plan with this size' after the customer has confirmed a particular plan. Costs and available products can change between browsing and payment. If the selected product is unavailable, show the customer a new choice and obtain confirmation.
Confirm the network separately
Ask the customer to confirm the network for the number being recharged. Formatting a Nigerian phone number is not proof of its current network. Your purchase's network value must agree with the product you selected, and the number should be checked through your normal recipient confirmation flow.
Treat airtime and data as separate choices. An unavailable data plan is not permission to send airtime instead. That changes what the customer bought and can leave your API customer responsible for an unwanted charge.
Preserve the receipt
Save the selected product label, size, validity, confirmed retail total and stable external reference with the order. A later catalogue refresh should improve new choices without changing what an earlier customer sees on their receipt.
Before launch, test two similarly named plans, a missing bundle type, more than one catalogue page and an unavailable product after confirmation. A useful selector makes those differences visible before the customer pays.