MYAFRICA / DEVELOPERS

Build your integration.

Explore partner services, inspect request contracts and test A2P scenarios in your browser.

Development preview. The sandbox simulates responses locally. It does not send SMS, charge accounts or connect to an operator. Live API access and production availability are subject to onboarding and qualification.

Open A2P sandbox ↗Integration guide ↓

Before connecting

Choose your service. Review its operations and qualification status below.
Agree your integration scope. Sovrion Labs provisions the approved tenant, country, operator, product and client. Scope identifiers are not authorization credentials.
Obtain environment details. Your onboarding supplies the actual API origin, token endpoint, authorized scopes and certificate requirements. No live endpoint is advertised here.
Test before release. Validate authentication, idempotency, errors and asynchronous status against your provisioned integration environment. Browser simulations do not certify an integration.

Authentication, retries and response handling

Partner contracts describe OAuth 2.0 client credentials with mutual TLS. Use the operation's granted scopes and your provisioned client certificate. Keep access tokens, client secrets and private keys on your server.

Send an Idempotency-Key where required. Preserve it when retrying the same request. A changed request should use a new key. A 202 response means accepted for processing; it does not prove delivery or settlement. Read the corresponding status endpoint.

Handle 400 validation errors, 401 authentication failures, 403 scope denials, 404 missing resources, 409 conflicts, 429 rate limits and 5xx failures. The draft contracts are not a complete guarantee of every runtime error or response body.

Integration updates · 14 September 2026

These changes are undergoing qualification. Confirm the deployed version and approved integration scope with Sovrion Labs before connecting.

Advance authorization and eligibility

Advance operations require their specific granted OAuth scope: advance:read for reads, advance:eligibility for eligibility, advance:originate for origination and advance:repay for repayment requests. A read-only token must not authorize a write. Tenant and client entitlements are checked separately.

Origination requires an enabled repayment profile matching the product, plus current affordability evidence. Missing prerequisites must not trigger disbursement. Eligibility is not a commitment to lend.

Validation, retries and asynchronous results

API billing spend limits must be nonnegative decimal strings, with at most 14 whole-number digits and six decimal places. Warning thresholds are integers from 1 to 100. Evidence hashes contain 64 lowercase hexadecimal characters. Requests are subject to account authorization and further commercial controls.

Reuse a request key only for identical intent. Configuration retries must preserve the payload, schedule, change reason and maker. A received dispute or request does not mean it is resolved, approved or settled.

Message policy checks require an explicit ALLOW decision. Conditional, missing and unrecognized decisions do not authorize sending. Reconciliation amounts from different currencies must not be added into a single monetary total.

Try scope denial, policy denial and spend-limit validation in the browser sandbox ↗

A2P integration example

This server-side example illustrates message submission after onboarding. Replace every environment variable and example value with your provisioned test configuration. Use test recipients approved for your environment. The browser sandbox needs none of these credentials.

curl --request POST "$MYAFRICA_API_ORIGIN/v1/a2p/messages" \
  --cert "$CLIENT_CERT_PATH" --key "$CLIENT_KEY_PATH" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: $UNIQUE_REQUEST_KEY" \
  --data @message.json

Example message.json

{
  "countryId": "YOUR_COUNTRY_ID",
  "operatorId": "YOUR_OPERATOR_ID",
  "tenantId": "YOUR_TENANT_ID",
  "productId": "YOUR_PRODUCT_ID",
  "clientId": "YOUR_CLIENT_ID",
  "clientReference": "otp-example-0001",
  "recipient": "+12025550123",
  "senderId": "YOUR_APPROVED_SENDER",
  "content": "Your example verification code is 123456.",
  "trafficClass": "OTP"
}

After acceptance, use GET /v1/a2p/messages/{submissionId} with the returned identifier and the required countryId, operatorId, tenantId, productId and clientId query parameters. Track final delivery separately from OTP verification. Delivery receipts and OTP outcome feedback are different signals.

Partner API reference

Draft contract reference

Paths and request definitions below are extracted from partner-marked repository contracts. They are documentation, not a callable API explorer. Missing schemas and contract inconsistencies are shown explicitly; confirm the final contract during onboarding.

Loading reference…