Authentification
Conserver les clés côté serveur. Respecter les portées du client et éviter tout secret dans les applications mobiles ou scripts publics.
DOCUMENTATION DÉVELOPPEUR · SENEGAL-FIRSTUne infrastructure télécom.
Une infrastructure télécom.
Des contrats API explicites.
Commencez par Messaging A2P, puis intégrez Verify, Number Intelligence, Protect et Connect selon les autorisations et les contrats de chaque service. Les exemples ci-dessous décrivent les interfaces codées, pas une disponibilité commerciale garantie.
CATALOGUE API
Produits & disponibilité
Une fondation codée ne donne pas automatiquement le droit de traiter du trafic réel. Chaque famille possède son propre périmètre d'accès.
Messaging A2P
Contrat CoreSoumission, recherche par identifiant, devis de route et idempotence.
Voir le périmètre →Verify / OTP
Service distinctAPI Verify documentée ; disponibilité conditionnée aux routes autorisées.
Voir le périmètre →Connect / eSIM
Intégration contrôléeCatalogue et orchestration ; paiement et provisionnement commercial non qualifiés.
Voir le périmètre →Number Intelligence
Contrat séparéAccès selon identité, politique et fournisseur de données.
Voir le périmètre →Protect
Contrat séparéContrôles antifraude et signaux de confiance soumis aux sources autorisées.
Voir le périmètre →SMPP Wholesale
Accès restreintInterconnexion opérateur/agrégateur après habilitation et qualification.
Voir le périmètre →01 / API MESSAGING
Envoyer un message
Contrat canonique du Core : api/openapi.yaml. Le prix provient de la grille client côté serveur, jamais du montant transmis par l'appelant.
POST
/v1/messagesContrat définicurl -X POST "$SIGNALGRID_API/v1/messages" \
-H "X-API-Key: $SIGNALGRID_API_KEY" \
-H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{
"destination":"22177XXXXXXX",
"sender_id":"SIGNALGRID",
"body":"Votre code est 482901",
"mcc":"608",
"mnc":"01",
"traffic_type":"otp"
}'Lire le statut d'un message
GET
/v1/messages/{id}curl "$SIGNALGRID_API/v1/messages/$MESSAGE_ID" \
-H "X-API-Key: $SIGNALGRID_API_KEY"Réponses essentielles
- 202
- Message accepté (ou relecture idempotente)
- 402
- Solde prépayé insuffisant
- 403
- Refus de politique sender / KYB
- 429
- Quota tenant atteint
La liste complète des messages par tenant n'est pas encore disponible dans le contrat Messaging public. L'historique de la Console reste donc explicitement en démonstration.
02 / VERIFY
Vérification OTP
Service API distinct avec démarrage, validation du code et consultation d'un identifiant. Ne supposez pas que son URL ou ses droits soient ceux de Messaging.
POST
/v1/verify/startPOST
/v1/verify/checkGET
/v1/verify/{id}# Service Verify distinct — URL et droits propres au service
curl -X POST "$SIGNALGRID_VERIFY_API/v1/verify/start" \
-H "X-API-Key: $SIGNALGRID_VERIFY_KEY" \
-H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{"destination":"22177XXXXXXX","sender_id":"SIGNALGRID"}'L'exécution commerciale exige des routes OTP autorisées et un fournisseur opérationnel. Les fonctions Verify+ à signaux de confiance restent limitées si aucune source approuvée n'est disponible.
03 / CONNECT
eSIM & connectivité
Le catalogue et l'orchestration existent côté service Connect. Le checkout et la livraison d'un profil eSIM ne doivent pas être présentés comme actifs avant paiement confirmé côté serveur, achat fournisseur et installation sécurisée.
GET
/v1/connect/plansPOST
/v1/connect/ordersGET
/v1/connect/orders/{id}Ces routes appartiennent au service Connect et peuvent exiger un contexte client signé, distinct de la clé Messaging. Les intégrations fournisseurs et PSP sont des conditions de mise en service.
SÉCURITÉ & EXPLOITATION
Construire sans contourner les contrôles
Idempotence
Fournir une clé unique et stable par opération logique. En cas d'incertitude, vérifier le statut avant de relancer.
Disponibilité
Les statuts de démonstration ne sont pas des résultats réseau. Valider les autorisations, les DLR et les coûts fournisseurs avant le trafic réel.