top of page
RafaleMTA - EN

2. API RESTful / JSON

 

Les APIs d'injection de messages transactionnels (SMTP API) et de mailing-list (Campaign API) reposent sur le même protocole, et partagent de nombreux formats de donnée et les objets JSON, dont la description détaillée est fournie en section 6 (Objects).

2.1. Protocole

L’API RESTful est accessible via l’url :


https//:<server address>/api


L’authentification s’effectue via le header HTTP : 


Authorization : <apikey> 
 

Le champ <apikey> se configure dans le compte utilisateur déclaré sur le serveur.
 

Par commodité, il est également possible de transmettre l’ <apikey> dans l’url, sous forme d’un paramètre de la requête :


https//:<server address>/api/<obj>?apikey=<apikey>
 

La plupart des méthodes GET retourne des tableaux d’objets (statistiques, rapports, logs…) dont le format de sortie peut être défini par le paramètre <format> de la requête :
 

https//:<server address>/api/<obj>?format=<csv/htm/xml/json>
 

  • Le format CSV est le plus compact car le nom des champs n’apparait qu’une seule fois en en-tête du tableau.

  • Le format HTM fournit une interface minimaliste pour consulter via un navigateur les principales tables et paramètres du système.

  • Le format XML permet d’importer directement les tables dans les systèmes compatibles nativement avec ce format (ex : « flux de données XML » depuis Excel).

  • Enfin, le format JSON est adapté à la récupération de faibles volumes données structurées.

 

​Les données associées aux méthodes POST et PUT doivent être exclusivement formattées en JSON.

Exemples d’utilisation avec Curl :
 

curl -X POST "https://<server address>/api/campaigns" \

     -H "Authorization: <apikey>" \

     -H "Content-Type: application/json" \

     -d "ordre de routage au format JSON"
 

Le système fournit en réponse un code de statut HTTP et, le cas échéant, des données complémentaires, formattées en JSON, sous la forme d’un objet "stamp", qui contient à minima un champ de date de traitement de la requête, un code d’erreur numérique et une description du code d’erreur.
 

Transaction type :

<method> api/<objet>?<options> HTTP/1.1
Authorization: <apikey>
Content-Type: application/json
Content-Lenght: <taille des données JSON ci-dessous>


{
   …
}

-----------------------------------------------------------------------------------------------
HTTP/1.1 <code d’erreur HTTP>
Content-Type: application/json
Content-Lenght: <taille des données JSON ci-dessous>


{
"stamp" :  {
    "date"        : <date de prise en compte YYMMDDhhmmss>,
    "err"         : <code d’erreur, 0=OK>,
    "msg"         : <description du code d’erreur>
    }
}

ou le paramètre <code d’erreur HTTP> peut prendre les valeurs suivantes : 

HTTP Status Code

Description

201 Created

Objet créé avec succès

250 OK

Requête traitée avec succès

204 No Content

Requête traitée avec succès

401 Unauthorized

Accès à la ressource non autorisé (droits <apikey>)

403 Forbidden

Accès à l’objet non autorisé (droits )

400 Bad request

Format de la requête invalide

404 Not found

Ressource / objet inexistant

2.2. Données

 

Les sections suivantes décrivent le format des données à fournir en entrée au système : body texte, html ou AMP, liste des destinataires, et nomenclature des champs de fusion et champs spéciaux.

 

2.2.1. Templates texte / html / AMP

Les contenus des bodys texte, html et AMP peuvent être soit directement encaspulés dans l’ordre de routage sous forme littérale (cf ex ci-dessus), encodés nativement en "utf-8", soit être stockés dans des fichiers externes (en ce cas, spécifier leur encodage dans le champ "charset" dans l’ordre de routage), avec un chemin d’accès précédé du caractère ‘@’ et relatif au répertoire du compte utilisateur. Nb : la description du format AMP est publiée sur https://amp.dev/.

2.2.2. Charsets

Les champs "charset" décrivent le jeu de caractère dans lequel sont entrées les valeurs, et sont donc nécessaires pour un encodage correct des messages email, qu’il s’agisse des entêtes ou des templates.


Lorsque le système fusionne les templates avec les champs de la liste de destinataires, il effectue automatiquement la conversion des jeux de caractères entre les données.


Par exemple, si le template est au format UTF-8 et la liste de destinataires en iso-8859, le système convertira les accents des champs de la liste de destinataires en UTF-8 avant de les fusionner avec le body html.

2.2.3. Liste de destinataires

Les listes de destinataires utilisées pour les mailing lists doivent être au format .CSV.

 

  • Le nom des champs doit être indiqué sur la première ligne du fichier, avec comme séparateur les caractères spéciaux ’ ;’, ‘,’ ‘<tab>’, ‘|’.

  • Le système détecte automatiquement le séparateur utilisé

  • Les champs et les valeurs peuvent optionnellement être double-quotés

  • Les champs commençants par les lettres ‘RF’ sont interdits car réservés par le système

  • Le champ « EMAIL » doit être défini et contenir l’adresse email du destinataire

  • Le fichier CSV peut contenir au maximum 250 champs

  • La longueur du nom d’un champ est limitée à 24 caractères, dans la plage ‘A’-’Z’, ‘0-9’ et le caractère tiret ‘-‘.

  • La taille des données d’un champ est limitée à 1000 caractères

  • Les noms des champs sont insensibles à la case

  • La longueur totale d’une ligne est limitée à 4000 caractères

  • L’encodage du fichier doit être précisé dans l’ordre de routage (par défaut, "utf-8"", cf "list" : "charset") 

 

Exemple :

 

name;forname;email;company;custid

Smith;John;john.smith@smithcompany.com;thesmithcompany;12345

Andersen;Thomas;t.ansersen@neocompany.com;neocomp;67890

NB : si aucune liste de destinataire n'est précisée dans l'ordre de routage, le système construit une liste de destinataires à partir des champs ‘to:’ ‘cc: et ‘bcc:’ des entêtes, avec les champs ‘EMAIL’ et ‘NAME’ tels que spécifiés par les membres "addr" et "name".

2.2.4. Champs de fusion

Les champs d’entêtes des messages (ex : ‘Subject:’), les corps des bodys texte, html ou AMP, peuvent être personnalisés avec n’importe quel champ de la liste des destinataires, à l’aide de la syntaxe suivante : $$[record]nom_du_champ$$.


Le système fournit en outre deux champs de fusion spéciaux :


$$[link]mirror$$ : créé un lien vers une page miroir générée automatiquement par le système à partir du body html, repersonnalisée et avec liens trackés, exactement à l’identique de l’email envoyé


$$[link]unsub$$ : créé un lien vers la page de désinscription indiquée dans la section "tracking", ce qui permet de différencier le click dans les statistiques.


Exemple de header personnalisé :


"header" : {
  "subject" : "$$[record]forname$$, votre offre personnalisée" },…

 

Exemple de body html personnalisé :
 

"htmbody" : {
"path": "Bonjour $$[record]forname$$,
Pour confirmer votre inscription, veuillez <a href="http://mycompany.com/register?id=$$[record]custid$$"> cliquez ici</a>
Pour visualiser ce message dans votre navigateur,
<a href="$$[link]mirror$$">cliquez ici</a>
Pour ne plus recevoir de message de notre part, vous pouvez
<a href="$$[link]unsub$$">vous désinscrire</a>" },…

 

2.2.5. Dates

Les champs de fusions spéciaux permettent la représentation de la date et l’heure de multiples façons, dans plusieurs langues, en fuseau horaire local ou GMT :


$$[XXXdateYYY]FMT,def$$
XXX    ‘gmt’, def=‘local’
YYY    ‘fr’, ‘be’, ‘us’, ‘uk’, ‘esp’, ‘deu’, ‘ita’, def=current country
FMT
%a Abbreviated weekday name
%A Full weekday name
%b Abbreviated month name
%B Full month name
%c Date and time representation appropriate for locale (%m/%/%y %H:%M:%S)
%C Long Date and time representation appropriate for locale
%d Day of month as decimal number (01 – 31)
%H Hour in 24-hour format (00 – 23)
%I Hour in 12-hour format (01 – 12)
%j Day of year as decimal number (001 – 366)
%m Month as decimal number (01 – 12)
%M Minute as decimal number (00 – 59)
%p Current locale's A.M./P.M. indicator for 12-hour clock
%S Second as decimal number (00 – 59)
%w Weekday as decimal number (0 – 6; Sunday is 0)
%x Date representation for current locale
%X Time representation for current locale
%y Year without century, as decimal number (00 – 99)
%Y Year with century, as decimal number
%Z Either the time-zone name or time zone abbreviation, depending on registry settings; no characters if time zone is unknown
%e Date and time representation for email header (RFC 822).
%g Local / GMT difference. For example: " +0200"
def    default [section]key

 

Exemples :


$$[date]%e$$          =>    Thu, 20 Jun 2010 14:27:12 +0200
$$[datefr]%c$$        =>    20/06/10 16:27:12
$$[gmtdatefr]%A, %c$$ =>    Dimanche, 20/06/10 16:27:12

bottom of page