SMM Panel API Guide: Build a Verifiable Reseller Workflow

The SMM Africa API is a single, action-based endpoint for catalog, balance, order, status, refill, and cancellation workflows. It accepts JSON, URL-encoded fields, and field-only multipart form data, so common reseller panels can integrate without an adapter.

The API does not remove supplier variability or the reseller's responsibilities. A sound integration keeps a current service snapshot, maps each client to the SMM Africa order ID, preserves the submitted target and quantity, and presents status and refund or refill eligibility accurately.

Endpoint and authentication

Send an HTTPS POST request to https://smm.africa/api/v3 with JSON, application/x-www-form-urlencoded, or field-only multipart/form-data. Authenticate with Authorization: Bearer YOUR_API_KEY or the standard key field. URL-encoded fields are recommended for common reseller panels.

curl -X POST https://smm.africa/api/v3 -H "Content-Type: application/x-www-form-urlencoded" --data-urlencode "key=YOUR_API_KEY" --data-urlencode "action=balance"

Keep the key on the server. Do not ship it in browser JavaScript, a mobile bundle, a public repository, client-visible logs, analytics events, or screenshots. Rotate it from the account security controls if it may have been exposed.

The six documented actions

• services: returns the current service catalog.
• balance: returns the shared wallet balance and currency.
• add: submits an order for a current service ID, target, and quantity.
• status: returns operational fields for one SMM Africa order ID.
• refill: requests refill review for an eligible order.
• cancel: requests cancellation for an eligible order.

All six actions use the same endpoint. The action value decides the request and response shape.

Fetch services before exposing a catalog

The services response documents a service ID, name, type, category, rate, minimum, maximum, refill flag, and cancel flag. The v3 contract uses USD independently of the website display currency. Read each service type: standard quantity rates use a per-1,000 basis, while packages have different billing rules. Service IDs, prices, limits, names, and flags can change, so do not hard-code them as permanent product facts.

A reseller can cache the response for usability, but should record when it was fetched and refresh it before accepting an order. If the client-facing catalog changes a name or price, keep the original SMM Africa service ID and the details shown when the order was placed.

Place an order with the add action

For a Default service, the add action requires service, link, and quantity. Other service types use their documented fields. Optional runs and interval fields apply only to compatible drip-feed services. Validate the target against the live service note and keep quantity between the current minimum and maximum.

{ "action": "add", "service": 1234, "link": "https://instagram.com/your-profile", "quantity": 500
}

A successful response returns an order value. Store that ID immediately with the client reference, service snapshot, target, submitted quantity, expected charge, and timestamp. The reseller owns this mapping; the API cannot infer which end customer or invoice belongs to the order.

Represent status accurately

The status action accepts the SMM Africa order ID. The documented response can include charge, start count, order status, remains, and currency. Possible status labels include Pending, In progress, Processing, Partial, Completed, and Canceled.

Use these fields to show order progress in a client portal. Keep campaign reporting separate and use the social platform's analytics for reach, engagement, and audience response.

Refill and cancellation are requests, not promises

The refill and cancel actions both use an order ID. A current service flag can indicate whether an action is exposed, but final eligibility still depends on the service, order state, timing, provider response, and published policy.

Do not promise a client that every drop will be refilled or that every submitted order can be canceled. Preserve the original listing, order timestamps, and response so support has the evidence needed for review.

Error handling and polling

• 400: inspect the request and required fields.
• 400 authentication error: stop and review the key; do not retry invalid credentials continuously.
• 429: respect the Retry-After header and back off.
• 500: log a redacted correlation record and retry conservatively rather than creating duplicate orders.

Never log the full Bearer token. If a network error occurs after sending add, check whether the order was created before submitting the same client request again.

A safer integration sequence

1. Read the human API reference and OpenAPI document.
2. Test authentication with balance and inspect the current services response.
3. Place a small manual order for the exact service ID and target type you plan to expose.
4. Observe order status, timing variability, and any refill or cancel behavior.
5. Build the server-side client, service snapshot, order mapping, redacted logs, and rate-limit handling.
6. Explain delivery, platform, retention, support option, and outcome boundaries in your own client terms.

Bottom line

An SMM panel API can make a tested workflow easier to operate. Use the current documentation, keep the service ID and order ID, secure the key, and present order status accurately to clients.

A complete standard order exchange

The values below are placeholders, not live service IDs, credentials, prices, or order results. Fetch services first and choose a compatible Default service. All v3 amounts use USD; the website's display currency does not change that contract.

POST https://smm.africa/api/v3
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
Idempotency-Key: example-client-order-001 { "action": "add", "service": 1234, "link": "https://instagram.com/your-profile", "quantity": 500
}

Illustrative successful response:

{ "order": "example-order-id", "charged": 1.25 }

Store the returned order ID, then request its status:

POST https://smm.africa/api/v3
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json { "action": "status", "order": "example-order-id" }

Inspect status, remains, charge, updated_at, and freshness. A stale status is cached information, not a fresh provider check; a missing refresh timestamp must not be presented as recent verification. Use the OpenAPI reference for complete response shapes and error cases.

Handle a timeout without a duplicate charge

Assign one opaque idempotency key to each logical order and keep its exact request. When the same order times out, reuse that key and the same inputs within the documented replay period. Do not create a new key just to bypass a conflict. Current add responses are replayable for 24 hours; after expiry, reconcile the original order before any retry. Standard clients can use the idempotency_key form field instead of a header.

An API response or local order record confirms workflow state, not retention, audience quality, or business results. Never put keys in frontend code, screenshots, or analytics.

Service-type and error differences

A Default order uses link and quantity. A Package uses link without quantity. Custom Comments derives quantity from comment lines, and subscriptions have their own fields. Fetch type from the catalog and follow the current API reference rather than sending every field for every service.

Authentication and validation failures can return HTTP 400 with an error message; unsupported content types use 415, suspended accounts 423, and rate limits 429 with Retry-After. Do not retry a rejected request unchanged. Back off after rate limits and reconcile uncertain submissions before retrying server or network errors.