canonical: https://jentic.com/apis/mtn.com/mtn

# MTN Developer API

MTN Group's developer API surfaces core mobile network capabilities - mobile money payments, messaging, customer profile lookups, and account balance - across MTN's African operating units. Fintech and consumer apps use it to take MTN Mobile Money payments, send transactional SMS to MTN subscribers, and verify customer details against the carrier of record. The seven-endpoint surface focuses on payment request, transfer, messaging send, customer lookup, and account balance read operations under a single API-key auth model.

## For AI agents

Take MTN Mobile Money payments, send SMS to MTN subscribers, and look up customer or account data across MTN's African mobile network through one API.

## Scope

Does not handle bank wire transfers, card payments, or roaming-data provisioning - use for MTN Mobile Money, carrier SMS, and customer lookups only.

## Capabilities

- Initiate an MTN Mobile Money collection from a subscriber via POST `/payments/request`
- Check the state of a payment using its referenceId via GET `/payments/{referenceId}`
- Push funds out to a recipient wallet via POST /transfer
- Send a transactional SMS to an MTN subscriber via POST `/messages/send`
- Retrieve a sent message by id via GET `/messages/{messageId}`
- Look up a customer profile by id via GET `/customers/{customerId}`
- Read the merchant or agent account balance via GET `/account/balance`

## Use cases

### Accept MTN Mobile Money at Checkout

Merchants accepting payments in markets like Ghana, Uganda, Cameroon, and Côte d'Ivoire issue a collection request to the customer's MTN Mobile Money wallet. POST `/payments/request` returns a referenceId that the merchant polls with GET `/payments/{referenceId}` until settlement. The flow replaces card payments where Mobile Money penetration exceeds card issuance.

Example prompt: Call POST `/payments/request` with the customer's MSISDN and amount, then poll GET `/payments/{referenceId}` every few seconds until the status field reads SUCCESSFUL or FAILED.

### Disbursement to Wallet Recipients

Gig platforms and microfinance products push earnings or loan disbursements to MTN Mobile Money wallets via POST /transfer. The same call structure handles agent commissions and refunds, removing the need for bank rails in markets where wallet penetration is higher than account ownership. Each transfer carries a referenceId for reconciliation.

Example prompt: Call POST /transfer with the recipient MSISDN and the disbursement amount, persist the returned referenceId, and reconcile against GET `/payments/{referenceId}` status.

### Transactional SMS to MTN Subscribers

Apps confirming payments, deliveries, or appointments send transactional SMS through POST `/messages/send` routed natively across MTN's network. The `/messages/{messageId}` read confirms delivery state for reconciliation. Native carrier routing improves deliverability for MTN-numbered subscribers compared with international SMS aggregators.

Example prompt: Send POST `/messages/send` with the subscriber's MSISDN and message body, then audit deliveries via GET `/messages/{messageId}.`

### Agent-Driven Mobile Money Reconciliation

An AI agent reconciles a day of Mobile Money settlements against the merchant's order ledger. Through Jentic the agent searches for 'check mobile money payment status', loads the schema, iterates GET `/payments/{referenceId}` for every order in the day, and flags mismatches. The merchant balance from GET `/account/balance` closes the loop on cash position.

Example prompt: Search Jentic for 'check mobile money payment status', call GET `/payments/{referenceId}` for each ledger row, and reconcile discrepancies against GET `/account/balance.`

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/payments/request` | Initiate a Mobile Money collection from a subscriber |
| GET | `/payments/{referenceId}` | Check payment status by referenceId |
| POST | `/transfer` | Send funds to a recipient wallet |
| POST | `/messages/send` | Send a transactional SMS |
| GET | `/customers/{customerId}` | Look up a customer profile |
| GET | `/account/balance` | Read merchant account balance |

## Key resources

- **Payment** — Mobile Money collection request and status lookup
- **Transfer** — Outbound disbursement to a recipient wallet
- **Messaging** — Transactional SMS send and lookup over MTN's carrier network
- **Customer** — Customer profile lookup by id
- **Account** — Merchant or agent account balance

## Why Jentic

- **Setup:** Wiring the MTN Developer API by hand means learning its X-API-Key header auth, choosing between the production and sandbox host, and threading reference ids through the Mobile Money payment flow yourself. Through Jentic you install once, import the MTN Developer API from the API Directory, store the API key once, and your agent calls it.
- **Permission scoping:** The payment and transfer targets travel in the request body, so limit the agent to the operations it needs, such as requesting a Mobile Money payment or checking its status. You choose which operations are in scope, so money-moving calls like transfer are not included unless you add them.
- **Credential handling:** Your MTN API key is stored once, encrypted, by your own Jentic One instance and injected into the X-API-Key header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'take a mobile money payment' or 'send a carrier sms', and Jentic returns the matching MTN operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Airtel Africa API** — Airtel Money offers a competing mobile money rail across many of the same African markets
- **Twilio Messaging API** — Twilio handles SMS across global carriers including African operators
- **SendGrid Mail** — SendGrid covers transactional email to complement MTN's SMS and Mobile Money

## FAQ

### What authentication does the MTN Developer API use?

The MTN Developer API uses an API key passed in the X-API-Key header on every request. Through Jentic that key is held in the encrypted vault and injected at execution, so the agent never holds the raw secret.

### Can I take a Mobile Money payment and confirm it in one workflow?

Yes. POST `/payments/request` creates the collection on the subscriber's wallet and returns a referenceId, then GET `/payments/{referenceId}` returns the settlement status. Poll until the status is SUCCESSFUL or FAILED before fulfilling the order.

### What are the rate limits for the MTN Developer API?

MTN applies environment-specific rate limits - sandbox is throttled lower than production and limits vary by operating unit (Ghana, Uganda, Cameroon, etc.). Use the sandbox base URL for testing and request a production quota uplift before launching a high-volume integration.

### How do I send a transactional SMS through Jentic?

Search Jentic for 'send a carrier sms in africa', load the `/messages/send` schema, and execute POST `/messages/send` with the MSISDN and message body. Audit delivery via GET `/messages/{messageId}` on the returned id.

### Is the MTN Developer API free?

MTN provides a sandbox tier for development at no cost. Production use is metered per channel and per operating unit - Mobile Money charges a transaction fee, SMS is charged per message, and country-specific commercial agreements apply.

### Does the API work across every MTN country?

Coverage varies by operating unit. Mobile Money endpoints are live in markets with active MTN MoMo operations including Ghana, Uganda, Cameroon, and Côte d'Ivoire, while messaging is available wherever MTN runs the network. Check developers.mtn.com for the current per-country availability matrix.

### Can I limit what my agent is allowed to do with the MTN Developer API?

Yes. Because you run Jentic One yourself, your own rules decide which MTN operations the agent may call and which credentials it uses. You can scope it to read-only or low-risk calls like requesting a Mobile Money payment with POST `/payments/request` and checking status with GET `/payments/{referenceId}`, while leaving money-moving operations such as POST /transfer out of scope unless you explicitly add them. Since payment and transfer targets travel in the request body, keeping the operation set narrow is how you control what the agent can move.