L'API SMM Africa est un point de terminaison unique basé sur des actions pour les workflows de catalogue, de solde, de commande, de statut, de réapprovisionnement et d'annulation. Elle accepte les champs JSON, codés en URL et les données de formulaires en plusieurs parties uniquement par champ, de sorte que les panneaux de revendeurs courants peuvent s'intégrer sans adaptateur.
L'API ne supprime pas le fournisseur. variabilité ou les responsabilités du revendeur. Une intégration solide conserve un instantané du service actuel, mappe chaque client à l'ID de commande SMM Africa, préserve l'objectif et la quantité soumis, et présente avec précision le statut et l'éligibilité au remboursement ou au rechargement.
Point de terminaison et authentification
Envoyez une demande HTTPS POST à https://smm.africa/api/v3 avec JSON, application/x-www-form-urlencoded, ou sur le terrain multipart/form-data. Authentifiez-vous avec Authorization: Bearer YOUR_API_KEY ou le champ key standard. Les champs codés en URL sont recommandés pour les panneaux de revendeurs courants.
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" Gardez la clé sur le serveur. Ne l'envoyez pas dans un navigateur JavaScript, un ensemble mobile, un référentiel public, des journaux visibles par le client, des événements d'analyse ou des captures d'écran. Faites-le pivoter à partir des contrôles de sécurité du compte s'il a pu être exposé.
Les six actions documentées
- services : renvoie le catalogue de services actuel.
- solde : renvoie le solde et la devise du portefeuille partagé.
- ajouter : soumet une commande pour un ID de service, une cible et une quantité actuels.
- statut : renvoie les champs opérationnels pour un identifiant de commande SMM Africa.
- recharge : demande un examen de recharge pour une commande éligible.
- annulation : demande l'annulation d'une commande éligible.
Les six actions utilisent le même point de terminaison. L' action valeur décide de la forme de la requête et de la réponse.
Récupérer les services avant d'exposer un catalogue
Le services décrit l'identifiant, le nom, le type, la catégorie, le tarif, le minimum, le maximum et les indicateurs de recharge et d'annulation d'un service. Le contrat v3 utilise USD indépendamment de la devise affichée sur le site. Lisez chaque type de service : les tarifs standard à la quantité sont calculés pour 1 000, tandis que les forfaits suivent d'autres règles. Les identifiants, prix, limites, noms et indicateurs peuvent changer ; ne les inscrivez pas dans le code comme des caractéristiques permanentes.
Un revendeur peut mettre en cache la réponse pour des raisons de convivialité, mais doit enregistrer la date à laquelle elle a été récupérée et l'actualiser avant d'accepter une commande. Si le catalogue destiné aux clients modifie un nom ou un prix, conservez l'ID de service SMM Africa d'origine et les détails affichés lors de la passation de la commande.
Passer une commande avec l'action d'ajout
Pour un service de type Default, le champ add l'action nécessite service, linket quantity. Les autres types de services utilisent les champs documentés correspondants. Le champ facultatif runs et interval s'appliquent uniquement aux services d'alimentation goutte à goutte compatibles. Validez l'objectif par rapport à la note de service en direct et conservez la quantité entre le minimum et le maximum actuels.
{ "action": "add", "service": 1234, "link": "https://instagram.com/your-profile", "quantity": 500
} Une réponse réussie renvoie une order valeur. Stockez cet identifiant immédiatement avec la référence client, l'instantané du service, la cible, la quantité soumise, les frais attendus et l'horodatage. Le revendeur est propriétaire de ce mappage ; l'API ne peut pas déduire quel client final ou quelle facture appartient à la commande.
Représenter le statut avec précision
Le status l'action accepte l'ID de commande SMM Africa. La réponse documentée peut inclure les frais, le nombre de départs, l'état de la commande, les restes et la devise. Les étiquettes de statut possibles incluent En attente, En cours, En cours de traitement, Partielle, Terminée et Annulée.
Utilisez ces champs pour afficher la progression de la commande dans un portail client. Séparez les rapports de campagne et utilisez les analyses de la plateforme sociale pour la portée, l'engagement et la réponse de l'audience.
Le rechargement et l'annulation sont des demandes, pas des promesses
Le refill et cancel les actions utilisent toutes deux un identifiant de commande. Un indicateur de service actuel peut indiquer si une action est exposée, mais l'éligibilité finale dépend toujours du service, de l'état de la commande, du moment, de la réponse du fournisseur et de la politique publiée.
Ne promettez pas à un client que chaque livraison sera réapprovisionnée ou que chaque commande soumise peut être annulée. Conservez la liste d'origine, les horodatages de commande et la réponse afin que l'assistance dispose des preuves nécessaires à l'examen.
Gestion des erreurs et interrogation
- 400 : inspectez la demande et les champs obligatoires.
- 400, erreur d'authentification : arrêtez et examinez la clé ; ne réessayez pas continuellement les informations d'identification invalides.
- 429 : respectez l'en-tête
Retry-Afteret reculez. - 500 : enregistrer un enregistrement de corrélation expurgé et réessayer de manière prudente plutôt que de créer des commandes en double.
N'enregistrez jamais le jeton Bearer complet. Si une erreur réseau se produit après l'envoi add, vérifiez si la commande a été créée avant de soumettre à nouveau la même demande client.
Une séquence d'intégration plus sûre
- Lisez la référence de l'API humaine et Document OpenAPI.
- Testez l'authentification avec
balanceet inspectez la réponse actuelleservices. - Passez une petite commande manuelle pour l'ID de service exact et le type de cible que vous envisagez de faire exposer.
- Observez l'état des commandes, la variabilité du calendrier et tout comportement de recharge ou d'annulation.
- Créez le client côté serveur, l'instantané de service, le mappage des commandes, les journaux rédigés et la gestion des limites de débit.
- Expliquez la livraison, la plate-forme, la rétention, l'option de support et les limites des résultats dans votre propre client. termes.
Résultat
Une API de panneau SMM peut faciliter l'exploitation d'un flux de travail testé. Utilisez la documentation actuelle, conservez l'ID de service et l'ID de commande, sécurisez la clé et présentez l'état de la commande avec précision aux clients.
Un échange complet pour une commande standard
Les valeurs ci-dessous sont des exemples de remplacement, pas des identifiants de service, identifiants de connexion, prix ou résultats de commande réels. Récupérez d'abord les services et choisissez un service Default compatible. Tous les montants v3 utilisent USD ; la devise d'affichage du site ne modifie pas ce contrat.
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
}
Exemple de réponse réussie :
{ "order": "example-order-id", "charged": 1.25 }
Conservez l'identifiant de commande renvoyé, puis demandez son statut :
POST https://smm.africa/api/v3
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json { "action": "status", "order": "example-order-id" }
Vérifiez l'état, le solde, le coût, la date de mise à jour et la fraîcheur. Un état obsolète correspond à des informations mises en cache et non à une vérification récente du fournisseur ; un horodatage d'actualisation manquant ne doit pas être présenté comme une vérification récente. Utilisez la la référence OpenAPI pour les structures de réponse complètes et les cas d'erreur.
Gérer une expiration sans double débit
Attribuez une clé d'idempotence opaque à chaque commande logique et conservez sa requête exacte. Si cette commande expire, réutilisez la même clé et les mêmes données pendant la période de répétition documentée. Ne créez pas une nouvelle clé simplement pour contourner un conflit. Les réponses add actuelles peuvent être rejouées pendant 24 heures ; après ce délai, rapprochez la commande d'origine avant toute nouvelle tentative. Les clients standard peuvent utiliser le champ de formulaire idempotency_key au lieu d'un en-tête.
Une réponse de l'API ou un enregistrement local confirme l'état du traitement, pas la rétention, la qualité de l'audience ou les résultats commerciaux. Ne placez jamais de clés dans le code côté navigateur, les captures d'écran ou les outils d'analyse.
Différences entre types de services et erreurs
Une commande par défaut utilise un lien et une quantité. Un forfait utilise un lien sans quantité. Les commentaires personnalisés calculent la quantité à partir des lignes de commentaire, et les abonnements ont leurs propres champs. Récupérez le type depuis le catalogue et suivez la documentation API en vigueur plutôt que d'envoyer tous les champs pour chaque service.
Les échecs d'authentification et de validation peuvent renvoyer HTTP 400 avec un message d'erreur ; les types de contenu non acceptés utilisent 415, les comptes suspendus 423 et les limites de débit 429 avec Retry-After. Ne répétez pas une requête rejetée sans la modifier. Patientez après une limitation de débit et rapprochez les envois incertains avant de réessayer après une erreur serveur ou réseau.