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.

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…