Ressources
Spécification OpenAPI
La description de l’API lisible par une machine, servie en direct par l’API elle-même.
La spécification est servie sans authentification, à dessein. Un intégrateur lit le contrat avant d’avoir une clé, et la verrouiller est précisément la friction qui fait perdre l’intégration.
La récupérer
Le document est en OpenAPI 3.1.0, renvoyé sans enveloppe à la racine parce que c’est ce qu’attendent tous les outils.
Les réponses sont cachables pendant cinq minutes. Récupérez-la dans votre build plutôt qu’à chaque démarrage de l’application.
Générer un client
N’importe quel générateur OpenAPI la consommera. Traitez le code généré comme un point de départ : le générateur ne peut exprimer ni le contrat d’idempotence, ni la vérification de signature, ni le fait qu’un 202 peut porter des destinataires rejetés.
Extensions SMSend
Le document porte trois extensions propriétaires contenant des détails de contrat pour lesquels OpenAPI n’a pas de champ standard :
- Chaque code d’erreur avec son statut HTTP et son caractère réessayable ou non — le même tableau que le guide des erreurs, sous forme lisible par une machine.
- La spécification de signature, le contrat d’ordre, la politique de livraison et de reprise, et la liste des événements.
- La version actuelle et les versions prises en charge, la politique de dépréciation, et ce qui compte ou non comme changement cassant.
En cas de désaccord entre les deux, croyez ce site
Les schémas générés sont moins complets que les réponses réelles de l’API : plusieurs objets renvoient des champs que la spécification ne liste pas, et les points de terminaison de gestion des webhooks ne portent aucun schéma de requête ni de réponse. Rien de ce qui est documenté ici n’est absent de l’API, mais l’inverse n’est pas vrai — utilisez donc la spécification pour l’outillage et cette référence pour le contrat.