API Unspam.

Lancez depuis votre propre code les mêmes contrôles que le tableau de bord : tests antispam, inbox placement, aperçus clients et tests automatiques récurrents. 29 endpoints dans 6 domaines, un token bearer, du JSON en entrée et en sortie.

POST /ext/v2/spam-check Document OpenAPI

curl -X POST https://api.unspam.email/ext/v2/spam-check \
  -H "Authorization: Bearer $UNSPAM_TOKEN"

# renvoie l’id du test et l’adresse d’envoi
{
  "id": "2Bl8rzTFN6VV",
  "inbox_address": "test-xyz@check.unspam.email"
}

# envoyez votre e-mail à cette adresse, puis lisez le résultat
curl https://api.unspam.email/ext/v2/spam-check/2Bl8rzTFN6VV \
  -H "Authorization: Bearer $UNSPAM_TOKEN"

# réponse (200)
{
  "score": 8.4,
  "spf": "pass",
  "dkim": "pass",
  "dmarc": "pass"
}

Ce que couvre l’API.

29 endpoints dans 6 groupes, présentés comme l’API les groupe elle-même. La référence complète, avec chaque paramètre et chaque code de réponse, est le document OpenAPI.

Client Previews

4 appels

GET /client-preview-devices
GET /client-previews
POST /client-previews
GET /client-previews/{id}

Inbox Placement

4 appels

GET /inbox-placement
POST /inbox-placement
GET /inbox-placement/mailboxes
GET /inbox-placement/{id}

Automatic Testing: Senders

6 appels

GET /scheduled-test-senders
POST /scheduled-test-senders
GET /scheduled-test-senders/{id}
PUT /scheduled-test-senders/{id}
DELETE /scheduled-test-senders/{id}
POST /scheduled-test-senders/{id}/test-connection

Automatic Testing: Tests

9 appels

GET /scheduled-tests
POST /scheduled-tests
GET /scheduled-tests/{id}
PUT /scheduled-tests/{id}
PATCH /scheduled-tests/{id}
DELETE /scheduled-tests/{id}
POST /scheduled-tests/{id}/dispatch-now
GET /scheduled-tests/{id}/runs
GET /scheduled-tests/{id}/runs/{runId}

Spam Check

5 appels

GET /spam-check
POST /spam-check
GET /spam-check/{id}
GET /spam-check/{id}/heatmap
GET /spam-check/{id}/screenshots

Account

1 appel

GET /status

Ce que vous pouvez construire avec.

Testez avant de livrer

Lancez un test antispam depuis une étape de déploiement ou un job de CI, envoyez le message que votre application envoie vraiment et lisez le score avant que la campagne ne parte.

Tests de boîte de réception récurrents

Connectez un expéditeur une fois et laissez les tests programmés tourner à leur propre cadence, pour que l’inbox placement soit vérifié selon un calendrier et pas seulement quand quelqu’un y pense.

Aperçus dans de vrais clients

Demandez des aperçus clients sur un test déjà lancé et recevez une entrée par appareil, chacune capturée dans un vrai client et non simulée depuis le code.

Des résultats en JSON

Scores, résultats d’authentification, heatmaps et captures reviennent en JSON, et arrivent donc dans votre propre tableau de bord ou vos propres alertes.

Où elle s’intègre.

Tout ce qui parle déjà HTTP peut lancer ces contrôles. Voici où l’API trouve le plus souvent sa place, et les équipes qui en tirent le plus.

Applications et pipelines où elle se branche.

Pipelines de CI et de déploiement

Lancez un test antispam comme étape de build et faites échouer le déploiement quand le score chute : une modification de template ne peut plus vous faire perdre la boîte de réception en silence.

Votre stack d’envoi

Le test reçoit un vrai message par votre vrai canal : SES, Postmark, SendGrid, Mailgun ou votre propre SMTP, peu importe ce qui envoie déjà vos emails.

Tableaux de bord internes

Les scores, le placement et les résultats d’authentification reviennent en JSON, donc ils arrivent dans le tableau de bord que votre équipe consulte déjà.

Alertes et astreinte

Interrogez les tests programmés depuis un cron et alertez la personne d’astreinte quand le placement chute, avant que le taux d’ouverture ne suive.

Produits qui envoient des emails

Intégrez les contrôles dans votre propre produit avec le plan White Label : un outil de création d’emails ou une plateforme d’agence peut proposer le test antispam sous sa propre marque.

Assistants IA

Via MCP, les mêmes tâches deviennent des outils qu’un assistant peut appeler, donc un contrôle peut se lancer au milieu d’une conversation, sans une ligne de code client à écrire.

Qui en tire le plus.

Agences Pilotez la délivrabilité de tous vos clients depuis un seul compte et présentez les rapports sous votre propre marque. SaaS Les réinitialisations de mot de passe, les liens magiques et les emails de facturation font partie du produit : un email que personne ne voit est un incident. E-commerce Le chiffre d’affaires des campagnes suit l’inbox placement, donc les envois du calendrier marketing se testent avant de partir. Newsletters Quand la boîte de réception est le produit, le placement est le chiffre qui paie, donc on le vérifie selon un planning. Développeurs Un token bearer, des ids à interroger et des résultats en JSON : l’intégration tient dans un après-midi, pas dans un sprint. Grands comptes Un token par intégration, chacun révocable séparément, donc un audit de sécurité peut couper l’accès d’un seul système sans toucher aux autres.

Comment fonctionne l’accès.

Un token par intégration, un petit ensemble de codes de statut et les mêmes tâches accessibles aux clients IA via MCP.

Des tokens que vous révoquez un par un

Chaque requête porte un token bearer dans l’en-tête Authorization. Les tokens sont créés dans votre compte, un par intégration, et en révoquer un laisse les autres fonctionner.

Un token absent, mal formé ou révoqué répond 401. Un token valide sur un compte qui n’a pas le droit de faire cet appel répond 403, et le corps nomme le motif : un problème de facturation n’est donc jamais pris pour une intégration cassée.

Des ids que vous interrogez, pas des webhooks que vous hébergez

Un appel qui démarre un travail répond avec un id. Vous interrogez cet id jusqu’à ce que le résultat soit prêt, ce qui garde l’intégration en HTTP sortant, sans rien exposer publiquement de votre côté.

L’API utilise un petit ensemble de codes et rien en dehors. Un 422 signifie que la requête a été lue et les valeurs refusées, avec les champs nommés, donc un payload incorrect ne ressemble jamais à un compte refusé.

Les mêmes tâches via MCP

Les clients IA atteignent le même travail via MCP, en JSON-RPC 2.0 sur un seul endpoint, si bien qu’un assistant peut lancer un test antispam et lire le résultat sans que personne n’écrive de client.

MCP s’authentifie avec OAuth 2.1 et il n’y a aucun token à coller : le client déroule le flux quand vous ajoutez le serveur. Le token bearer ci-dessus ne concerne que l’API REST.

Du token au résultat en quatre étapes.

Le test antispam est le chemin le plus court dans l’API. L’inbox placement et les aperçus suivent la même forme : vous lancez quelque chose, vous prenez l’id, vous lisez le résultat.

01
Créez un token

Dans votre compte, un token par intégration, chacun révocable séparément.
02
Lancez un test

Un POST sur l’endpoint du test antispam. La réponse porte l’id du test et l’adresse à laquelle envoyer votre e-mail.
03
Envoyez l’e-mail

Depuis la plateforme avec laquelle vous envoyez vraiment, vers l’adresse renvoyée par l’API, pour que le test mesure votre configuration d’envoi réelle et non une copie.
04
Lisez le résultat

Un GET sur le test par son id donne le score et les résultats d’authentification, puis vous demandez la heatmap ou les aperçus clients sur ce même id.

Questions fréquentes sur l’API.

Offres, limites, où se trouve la référence et ce que vous dit un 403.

Quelle offre inclut l’accès à l’API ?

L’accès à l’API est inclus dans l’offre White Label. Les prix actuels sont sur la page des tarifs.

Existe-t-il une référence avec tous les paramètres ?

Oui. Le document OpenAPI est la référence, et il est généré depuis l’API elle-même : il ne peut donc pas décrire un appel auquel le service ne répond pas. Il est lié dans l’exemple de code ci-dessus.

Quelles sont les limites de requêtes ?

L’API REST ne publie aucune limite de requêtes et aucun endpoint ne documente de réponse 429. Lisez cela comme non spécifié et non comme illimité : espacez vos tentatives après des échecs répétés au lieu de supposer un budget. Le serveur MCP limite bien les requêtes par compte et répond 429 dès que vous dépassez la limite.

Que signifie un 403 ?

Le token est valide et le compte n’a pas le droit de faire cet appel. Le corps porte un motif : l’e-mail du compte n’est pas encore confirmé, le quota de l’offre pour cet appel est épuisé sur la période, ou l’offre n’inclut pas l’accès à l’API.

Un assistant IA peut-il l’utiliser ?

Oui, via MCP plutôt que REST. Le serveur MCP expose les mêmes tâches comme des outils qu’un assistant peut appeler, avec OAuth 2.1 à la place d’un token bearer.

Faut-il un accès à ma plateforme d’e-mail ?

Pas pour un test antispam ni pour un aperçu. Vous envoyez un message à une adresse que l’API vous donne, depuis ce avec quoi vous envoyez déjà, et l’API lit ce qui est arrivé. Les tests automatiques récurrents sont différents, car il faut bien que quelque chose les envoie selon un calendrier : un expéditeur est donc connecté en SMTP pour ceux-là.

Prêt à intégrer la délivrabilité à votre propre stack ?