Créez un test de spam via REST, envoyez votre e-mail à l’adresse renvoyée et récupérez en JSON un score de 0 à 100 avec toutes les vérifications derrière.
POST crée un test et renvoie une adresse de réception unique. Envoyez-y votre véritable e-mail depuis votre infrastructure, puis récupérez le résultat par GET : c’est bien le message que votre plateforme envoie qui est noté.
Chaque test terminé renvoie le score, l’hôte de l’expéditeur, son adresse IP, le message-ID et un tableau results[] couvrant 17 types de vérification, de SPF, DKIM et DMARC aux listes noires, à SpamAssassin et aux liens brisés. Une seule lecture couvre tout le verdict.
/screenshots renvoie les rendus du test sur ordinateur, tablette et mobile, et /heatmap des cartes de focus et d’attention par IA pour ordinateur. Passez le même id de test à POST /client-previews pour afficher l’e-mail dans plus de 50 clients et appareils réels.
GET /spam-check?page=N&per_page=15 renvoie les tests en cours et terminés que vous avez créés via l’API, avec l’id, le statut, le score, les horodatages et le report_url hébergé. Affichez les anciens résultats dans votre propre tableau de bord sans relancer le test.
Un score de délivrabilité de 0 à 100, le détail des vérifications qui le produisent, et les extras visuels et IA pour vos pipelines de QA.
Le champ score est un entier de 0 à 100 qui réunit chaque signal (authentification, contenu, listes noires, en-têtes) en un seul nombre sur lequel une étape de CI peut se brancher. Les rapports Unspam lisent 90 à 100 comme excellent, 70 à 89 comme solide, 50 à 69 comme à risque et 0 à 49 comme risque élevé, et traitent un échec SPF, DKIM ou DMARC comme un risque élevé quel que soit le chiffre : branchez-vous donc aussi sur results[].
Associez-le au report_url si votre équipe a besoin du détail visuel complet : les deux champs arrivent dans la même réponse.
Le tableau results[] liste chaque vérification exécutée par le moteur : spf, dkim, dmarc, bimi, ip_blacklist, domain_blacklist, spamassassin, subject_line, html_best_practice, broken_links et d’autres. Chaque entrée a un id stable et les signaux derrière, chacun avec son propre status.
Aucun endpoint distinct pour obtenir les verdicts vérification par vérification. Un seul GET, toute l’histoire.
GET /spam-check/{id}/screenshots renvoie les URL d’images de votre e-mail sur ordinateur, tablette et mobile, avec null pour les appareils encore en cours. Ajoutez-les à vos artefacts CI ou à votre tableau de bord expéditeur sans autre traitement.
GET /spam-check/{id}/heatmap renvoie des heatmaps de focus et d’attention générées par IA pour ordinateur, chacune avec une url et un status, pour voir où vos lecteurs regarderont avant de lancer l’envoi suivant.
L’API de test de spam est asynchrone : vous créez un test, vous envoyez votre e-mail à l’adresse de réception que nous vous renvoyons, puis vous lisez le verdict.
POST /ext/v2/spam-check avec votre bearer token. La réponse 201 renvoie un id de test et une inbox_address unique.
Depuis votre pipeline transactionnel, votre plateforme marketing ou une étape de CI. Le message passe par notre moteur de test de spam, qui le retient pour l’analyser.
GET /ext/v2/spam-check/{id} passe de pending_inbox_message à spam_check_running puis à completed, avec le score, les données de l’expéditeur et results[]. Interrogez avec un back-off ou reliez-le à un worker de tâches, et arrêtez-vous aussi sur error ou outdated.
/spam-check/{id}/screenshots pour les rendus des trois appareils, /spam-check/{id}/heatmap pour les cartes de focus et d’attention par IA sur ordinateur, et POST /client-previews avec le même id de test pour afficher l’e-mail dans plus de 50 clients réels (voir l’API d’aperçu d’e-mails). Chacun puise dans son propre quota : les captures et la heatmap consomment une unité la première fois que vous les demandez, et une demande d’aperçu consomme un aperçu d’appareil par appareil rendu. Demander la heatmap avant les captures consomme aussi une unité de capture, car la heatmap est dessinée sur la capture pour ordinateur.
6 endpoints, avec le même token que le reste de l’API. Le document OpenAPI détaille chaque paramètre et code de réponse.
Document OpenAPI
/spam-check/spam-check/spam-check/{id}/spam-check/{id}/heatmap/spam-check/{id}/screenshots/statusIntégration, facturation, limites de requêtes et contenu renvoyé par l’endpoint de test de spam.
POST /ext/v2/spam-check renvoie une inbox_address ; votre plateforme d’envoi livre le véritable e-mail à cette adresse ; puis GET /ext/v2/spam-check/{id} renvoie le verdict dès que status vaut completed. Espacez les appels avec un délai exponentiel ou utilisez un worker de tâches, et arrêtez-vous aussi sur error ou outdated.GET /ext/v2/status renvoie votre e-mail et votre abonnement : nom du forfait, prix, date du prochain paiement et limites restantes (spam_checks, inbox_placements, screenshots, heatmaps, client_previews), ainsi que les indicateurs has_history, has_ai_assistant, has_api et has_mcp. Pratique pour afficher la consommation dans votre propre interface d’administration.Authorization: Bearer YOUR_API_TOKEN.L’accès à l’API est inclus dans le plan sur mesure, qui s’achète en ligne à partir d’un minimum de $5 par mois. Intégrez-le à votre propre produit et revendez-le sous votre propre marque.