REST API · v1

Un seul token. Tous les endpoints.

Une HTTP API claire et orientée ressources pour vos campagnes, listes, abonnés, automatisations, sending servers et la facturation client. Authentifiez-vous avec un seul token, interrogez en JSON, livrez en quelques minutes. La même API qu'utilisent les plugins est la même API qu'utilisent les clients externes — aucun endpoint de seconde zone.

Ce que vous pouvez construire

Frontend SaaS Application mobile Synchronisation CRM Déclencheurs d'automatisation Tableaux de bord revendeur
REQUEST POST /api/v1/campaigns HEADERS Authorization: Bearer ACELLE_TOKEN Content-Type: application/json BODY { "list_uid": "a3b9..." "name": "Welcome" "subject": "Hi friend" "from_name": "Acme" "from_email": "hi@..." "track_open": true "html": "<h1>…" } HTTPS your.acelle.com RESPONSE 200 OK { "campaign": { "uid": "abc123" "name": "Welcome" "subject": "Hi friend" "status": "ready" "track_open": true "created_at": "2026-05-06T…" "links": { "self": "/api/v1…" } } }

POURQUOI CETTE API

Aucune surprise. Aucun endpoint de seconde zone.
La même API qu'utilisent vos plugins.

Authentification par token

Chaque requête transporte un unique bearer token. Généré par utilisateur depuis Profil → API token. Transmis via l'en-tête Authorization: Bearer ou la query string ?api_token=. Révocable et rotatif à tout moment.

Orientée ressources

Chaque concept est une ressource avec des verbes prévisibles. GET /lists retourne la collection, POST /lists en crée une, PATCH /lists/:uid met à jour, DELETE /lists/:uid supprime. Les sous-ressources s'imbriquent naturellement : /lists/:uid/subscribers.

La même qu'utilisent les plugins

Il n'y a pas de séparation interne / externe. Les endpoints sollicités par l'UI de AcelleMail, ceux que votre plugin étend et ceux que lit votre client externe — sont identiques. Voir le plugin SDK →

Endpoint auto-hébergé

L'URL de base est votre propre serveur — https://your-acelle.example.com/api/v1/. Pas de proxy fournisseur, pas de rate limit partagé, pas de frais par requête. Le débit est celui de votre matériel.

DÉMARRAGE RAPIDE

De zéro à la première réponse en quatre étapes.

Chaque installation AcelleMail héberge sa propre API à /api/v1/. Remplacez your-acelle.example.com par le nom d'hôte de votre installation.

STEP 1

Générer un token

Connectez-vous à votre installation AcelleMail. Ouvrez le menu de votre profil et cliquez sur API token. Copiez la valeur — elle est unique par utilisateur et liée aux permissions de ce dernier.

# In your shell:
$ export ACELLE_TOKEN=paste-your-token-here
$ export ACELLE_BASE=https://your-acelle.example.com
STEP 2

Vérifier le token

Appelez /me. Si le token est valide, vous récupérez votre enregistrement utilisateur. Sinon, vous obtenez un 401 — vérifiez le token et l'URL de base.

$ curl $ACELLE_BASE/api/v1/me \
    -H "Authorization: Bearer $ACELLE_TOKEN"

{ "id": 1, "email": "you@…", "uid": "…" }
STEP 3

Créer une liste

Les ressources se créent avec POST. Les champs requis dans le body d'une mailing list sont name, from_email, from_name, subject, plus un bloc de contact.

$ curl -X POST $ACELLE_BASE/api/v1/lists \
    -H "Authorization: Bearer $ACELLE_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "name":       "Newsletter",
      "from_name":  "Acme",
      "from_email": "hi@acme.com",
      "subject":    "Welcome"
    }'
STEP 4

Ajouter un abonné

Utilisez l'UID de la liste obtenue à l'étape 3. Les champs personnalisés se passent en paramètres en majuscules (FIRST_NAME, LAST_NAME, …) en concordance avec la configuration des champs de votre liste.

$ curl -X POST $ACELLE_BASE/api/v1/subscribers \
    -H "Authorization: Bearer $ACELLE_TOKEN" \
    -d list_uid=$LIST_UID \
    -d EMAIL=alice@example.com \
    -d FIRST_NAME=Alice \
    -d tag=newsletter,beta

RESSOURCES

Huit ressources. Plus de quarante endpoints. Tous les verbes que vous attendez.

Tous les endpoints ci-dessous sont namespacés sous /api/v1/ et exigent une authentification token auth:api sauf mention contraire. Les actions de cycle de vie (run, pause, resume) sont exposées en sous-routes POST. Les téléchargements de logs streament le CSV sous-jacent.

Authentification

Tous les endpoints authentifiés acceptent le token via l'en-tête Authorization: Bearer (préférable) ou le paramètre de query ?api_token= (legacy). Utilisez POST /user/login pour échanger email/password contre un nouveau token depuis un client programmatique.

POST/user/loginÉchangez email + password contre un token API. Endpoint public.
GET/meRetourne l’enregistrement de l'utilisateur authentifié. À utiliser pour vérifier un token.
POST/login-tokenGénère une URL de login à usage unique sur laquelle l'utilisateur peut cliquer pour atterrir authentifié.

Lists

Les mailing lists sont le conteneur principal des abonnés. Chaque liste embarque une identité d'expéditeur par défaut, des champs personnalisés ainsi que des paramètres de double opt-in / email de bienvenue. Les champs personnalisés s'ajoutent via la sous-route add-field.

GET/listsIndex paginé des listes appartenant à l'utilisateur du token.
POST/listsCrée une nouvelle liste. Requis : name, from_email, from_name, subject + bloc contact.
GET/lists/:uidRécupère une seule liste avec ses champs et ses statistiques.
PATCH/lists/:uidMet à jour les métadonnées, l'identité d'expéditeur ou les paramètres d'opt-in de la liste.
POST/lists/:uid/add-fieldAjoute un champ personnalisé. Le type est text, number ou datetime.
DELETE/lists/:uidSupprime définitivement une liste et tous ses abonnés.

Subscribers

Les abonnés appartiennent à une liste et portent des valeurs de champs personnalisés, des tags et un historique d'ouvertures/clics. Le statut est l'un de subscribed, unsubscribed ou unconfirmed. Les opérations sur les tags sont additives et idempotentes.

GET/subscribers?list_uid=…Index paginé. Filtrez avec open=yes|no, click=yes|no.
POST/subscribersCréation. Requis : list_uid, EMAIL. Champs personnalisés en paramètres majuscules.
GET/subscribers/:idRécupère un seul abonné par id ou email.
GET/subscribers/email/:emailTrouve toutes les listes qui contiennent un abonné avec cet email.
PATCH/subscribers/:idMet à jour les champs, tags ou statut.
POST/subscribers/:id/add-tagAjoute des tags séparés par des virgules.
POST/subscribers/:id/remove-tagRetire des tags séparés par des virgules.
PATCH/lists/:list_uid/subscribers/:id/subscribeMarque comme subscribed.
PATCH/lists/:list_uid/subscribers/:id/unsubscribeMarque comme unsubscribed.
PATCH/lists/:list_uid/subscribers/email/:email/unsubscribeDésabonne par email lorsque vous n’avez pas l'id.
DELETE/subscribers/:idSuppression dure depuis la liste.

Campaigns

Les campagnes sont l'unité d'envoi. Créez-en une avec du contenu HTML + des flags de tracking, faites-la transiter par run / pause / resume, puis téléchargez en CSV les logs de tracking, d'ouverture, de clic, de bounce, de feedback et de désinscription.

GET/campaignsIndex paginé. Passez per_page, page.
POST/campaignsCréation. Requis : list_uid, name, subject, from_*, html.
GET/campaigns/:uidRécupère une seule campagne avec ses statistiques.
PATCH/campaigns/:uidMet à jour le contenu, l'objet ou les flags de tracking.
POST/campaigns/:uid/runMet la campagne en queue pour délivrance.
POST/campaigns/:uid/pauseMet en pause une campagne en cours.
POST/campaigns/:uid/resumeReprend une campagne en pause.
GET/campaigns/:uid/tracking-log/downloadStreame le CSV de tracking.
GET/campaigns/:uid/{open,click,bounce,feedback,unsubscribe}-log/downloadStreame le CSV par événement (une route par type d'événement).
DELETE/campaigns/:uidSupprime une campagne (uniquement lorsqu'elle n'est pas en cours).

Automations

Les automatisations sont des flux visuels de déclencheurs, conditions et actions. L'API expose la vue de lecture plus deux façons de déclencher des flux depuis des systèmes externes : execute pour exécuter une automatisation entière, ou api/call pour déclencher un nœud "API call" en milieu de flux.

GET/automationsIndex des automatisations possédées par l'utilisateur du token.
POST/automations/:uid/executeDéclenche une automatisation pour un abonné. Utile pour les flux transactionnels.
POST/automations/:uid/api/callDéclenche un nœud trigger "API call" en milieu de flux avec un payload personnalisé.

Sending servers

Les sending servers sont les transports configurables (SMTP, Amazon SES, SendGrid, Mailgun, Postmark, drivers personnalisés issus de plugins). Gérez-les par programmation lors du provisioning de nouveaux tenants ou lors de la rotation de credentials.

GET/sending_serversIndex des sending servers configurés.
POST/sending_serversCrée un nouveau sending server. Configuration spécifique au driver sous settings.
GET/sending_servers/:uidRécupère un seul sending server.
PATCH/sending_servers/:uidMet à jour les paramètres ou fait tourner les credentials.
DELETE/sending_servers/:uidSupprime un sending server (les campagnes qui le référencent doivent d'abord être re-routées).

Ajouter un nouveau transport (Postal MTA, HTTP API personnalisée, …) passe par un Hook REGISTRY — livrez-le sous forme de plugin plutôt que de patcher le core.

Customers ADMIN

Les endpoints customers sont réservés aux tokens admin. Utilisez-les pour provisionner des comptes tenants, gérer des abonnements, changer de plan ou générer des URLs de login à usage unique pour le support / l'impersonation.

GET/customersIndex paginé de tous les customers.
POST/customersCrée un nouveau customer + compte utilisateur.
GET/customers/by-email/:emailRecherche un customer par email.
PATCH/customers/:uidMet à jour le profil, le contact ou le quota du customer.
PATCH/customers/:uid/{enable,disable}Suspend ou réactive l'accès sans supprimer les données.
POST/customers/:uid/change-plan/:plan_uidBascule un customer sur un plan différent (charges, prorata, renouvellement d'abonnement).
POST/customers/:uid/assign-plan/:plan_uidAssigne un plan sans flux de facturation (override admin).
POST/customers/:uid/subscription/updateMet à jour les paramètres d’un abonnement actif.
POST/login-tokenGénère une URL de login à usage unique pour le customer ciblé.

Subscriptions ADMIN

Les subscriptions lient un customer à un plan + une cadence de facturation. Utilisez ces endpoints pour intégrer des systèmes de facturation externes ou auditer le revenu récurrent.

GET/subscriptionsIndex de toutes les subscriptions actives.
POST/subscriptionsCrée un enregistrement subscription (typiquement déclenché par le webhook de votre passerelle).
GET/subscriptions/:uidRécupère une seule subscription avec son historique de renouvellement.
PATCH/subscriptions/:uidAjuste le quota, la cadence ou la date de fin.

Files

Uploadez des images et autres assets pour les utiliser dans le contenu de vos campagnes. L'endpoint accepte du multipart/form-data et retourne une URL publique référençable dans le corps HTML.

POST/file/uploadUpload un fichier. Retourne { "url": "..." }.

Plugins & mises à jour ADMIN

Installez des plugins par programmation depuis une URL de téléchargement, exécutez des mises à jour core distantes via un flux de requêtes en deux étapes (pour que l'étape 2 atterrisse sur un worker PHP frais), ou rafraîchissez la licence. Utile pour les opérateurs de flotte qui gèrent de nombreux tenants AcelleMail.

POST/plugins/installInstalle un plugin depuis une URL de téléchargement.
POST/upgrade/runDémarre une mise à jour core distante (téléchargement + extraction).
POST/upgrade/run-fileApplique une seule étape de migration.
POST/upgrade/finalizeFinalise une mise à jour. Doit être appelée comme une requête fraîche après run.
POST/license/refreshRafraîchit les infos de licence CodeCanyon (miroir d'Admin → License).

WEBHOOKS

Poussez les événements, plutôt que de les poller.

AcelleMail fournit deux surfaces de webhooks. Les webhooks de cycle de vie se déclenchent sur les transitions customer + subscription + automation et sont configurés globalement. Les pings de tracking par destinataire se déclenchent sur les ouvertures / clics / désinscriptions et sont configurés par campagne. Les deux retentent en cas d'échec avec un backoff exponentiel.

Webhooks de cycle de vie

Transitions customer + subscription

Configurés une fois dans Admin → Settings → Webhooks. Chaque webhook est un nom + un événement + une configuration HTTP sortante (URL, méthode, headers, body template). Six événements sont livrés en core :

new_customerparams : customer_id
new_subscriptioncustomer_id, plan_id
change_plancustomer_id, old_plan_id, new_plan_id
cancel_subscriptioncustomer_id, plan_id
terminate_subscriptioncustomer_id, plan_id
automation_webhookautomation_id (se déclenche depuis les nœuds API call)

La politique de retry est par webhook : retry_times configurable (par défaut 2) et retry_after_seconds (par défaut 900). Les délivrances en échec sont loguées, retentées et remontées dans le log de webhooks de l'admin.

Les plugins peuvent enregistrer des événements supplémentaires via le pattern Hook EVENT — acelle/ai, par exemple, déclenche ai_task_completed depuis ses listeners personnalisés.

Tracking par destinataire

Ouvertures, clics, désinscriptions

Configurés par campagne ou par template email sous Tracking → Webhooks. Trois types d'événements se déclenchent au fil des interactions du destinataire avec le message :

openle destinataire a ouvert l'email (pixel de tracking)
clickle destinataire a cliqué sur un lien tracké
unsubscribele destinataire a cliqué sur le lien de désinscription

Chaque ping porte l'uid de la campagne, l'email de l'abonné et l'URL du clic (pour les événements click). Configurez autant de tracking webhooks que nécessaire par campagne — utile pour un miroir parallèle vers analytics + CRM + data warehouse.

Les événements de niveau sending server (bounce, complaint, delivery) transitent par la stack interne de listeners App\SendingServers\Webhooks\* — remontés dans les endpoints de logs de campagne plutôt qu'en webhooks sortants. Télécharger les CSV de logs →

Exemple : payload new_subscription

POST /your-webhook-url
Content-Type: application/json
X-AcelleMail-Event: new_subscription
X-AcelleMail-Signature: sha256=…

{
  "event":       "new_subscription",
  "customer_id": 1234,
  "plan_id":     "extended-monthly",
  "fired_at":    "2026-05-06T12:34:56Z"
}

Exemple : payload de tracking click

POST /your-webhook-url
Content-Type: application/json
X-AcelleMail-Event: click

{
  "event":         "click",
  "campaign_uid":  "abc123",
  "subscriber":    "alice@example.com",
  "url":           "https://acme.com/promo",
  "clicked_at":    "2026-05-06T12:34:56Z"
}

RÉPONSES & ERREURS

Du JSON prévisible. Des codes de statut conventionnels.

Chaque réponse réussie est du JSON. Chaque réponse en échec est du JSON, avec un message de haut niveau et une map errors pour les échecs de validation. Les codes de statut suivent la convention REST — vous pouvez brancher votre client sur le code seul.

Code Quand vous le verrez
200 OKLecture ou mise à jour réussie.
201 CreatedCréation réussie.
401 UnauthorizedToken manquant ou invalide.
403 ForbiddenToken valide, mais la ressource ne vous appartient pas / pas admin.
404 Not FoundL'UID n'existe pas.
422 UnprocessableErreur de validation. Consultez la map errors dans le body.
500 ServerBug côté serveur. Consultez storage/logs/laravel.log.

Erreur de validation (422)

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{
  "message": "The given data was invalid.",
  "errors": {
    "from_email": [
      "The from_email field is required."
    ],
    "subject": [
      "The subject must be at most 998 characters."
    ]
  }
}

Échec d'authentification (401)

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{ "message": "Unauthenticated." }

Pagination

Les endpoints d'index acceptent per_page (par défaut 10–25 selon la ressource) et page. Les réponses incluent la forme standard du paginator Laravel : data[], links, meta.current_page, meta.total.

Rate limits

Le rate limiting est à votre main — définissez-le sur votre installation Laravel via RouteServiceProvider. Les builds standards ne posent aucun throttle API, puisque vous tapez sur votre propre serveur. Ajoutez throttle:60,1 si vous en voulez un.

Versioning

La version majeure actuelle est v1. Les nouveaux endpoints sont ajoutés librement ; les changements cassants sur les endpoints existants seraient livrés en v2 aux côtés de v1. Épinglez votre client à /api/v1/ et vous êtes stable.

CLIENTS

Tout client HTTP. Aucun SDK propriétaire.

Il n'y a pas de SDK AcelleMail à installer. L'API parle JSON sur HTTP — piochez dans le client que votre stack possède déjà. Voici trois des plus courants en pratique :

curl · one-liners

curl $ACELLE_BASE/api/v1/lists \
  -H "Authorization: Bearer $ACELLE_TOKEN" \
  | jq '.data[].name'

Client HTTP Laravel

$resp = Http::withToken($token)
    ->baseUrl($base.'/api/v1')
    ->post('/subscribers', [
        'list_uid' => $listUid,
        'EMAIL'    => $email,
    ]);

return $resp->json();

fetch côté navigateur / Node

const r = await fetch(
  `${base}/api/v1/campaigns/${uid}/run`,
  {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${token}`,
    },
  }
);
const data = await r.json();

Vous construisez un SDK open source ? Écrivez-nous — nous le lierons depuis cette page.

RÉFÉRENCE CANONIQUE

La référence API complète et exécutable.

Chaque paramètre. Chaque forme de retour. Chaque exemple curl fonctionnel. Hébergée sur l'installation de démo canonique — le même code que celui que fait tourner votre installation.

api.acellemail.com

Remplacez api.acellemail.com par le nom d'hôte de votre propre installation lors des appels.

COMMENCER À CONSTRUIRE

Faites tourner AcelleMail. Récupérez un token. Faites un appel.

Licence en achat unique. Sources complètes. Endpoint auto-hébergé. L'API est incluse — pas de module additionnel, pas de plan de tarification.

Obtenir AcelleMail — $80 Plugin SDK →