top of page
RafaleMTA - FR

2. API RESTful / JSON

 

The APIs for injecting transactional messages (SMTP API) and mailing-list (Campaign API) are based on the same protocol, and share many data formats and JSON objects, the detailed description of which is provided in section 6 (Objects).

2.1. Protocol

 

The RESTful API is accessible via the url:


https//:<server address>/api


Authentication is done via the HTTP header: 


Authorization : <apikey> 
 

The <apikey> field is configured in the user account declared on the server.

For convenience, it is also possible to pass the <apikey> in the url, as a parameter of the request:


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

Most GET methods return arrays of objects (statistics, reports, logs, etc.) whose output format can be defined by the <format> parameter of the request:

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

  • The CSV format is the most compact because the field names appear only once in the header of the table.

  • The HTM format provides a minimalist interface for consulting the main tables and parameters of the system via a browser.

  • The XML format allows tables to be directly imported into systems natively compatible with this format (e.g. "XML data stream" from Excel).

  • Finally, the JSON format is suitable for retrieving small volumes of structured data.

 

​Data associated with POST and PUT methods must be formatted exclusively in JSON.

Examples of use with Curl:

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

     -H "Authorization: <apikey>" \

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

     -d "ordre de routage au format JSON"
 

In response, the system provides an HTTP status code and, if applicable, additional data, formatted in JSON, in the form of a "stamp" object, which contains at least a field for the date the request was processed, a numeric error code and a description of the error code.

Typical rransaction:

<method> api/<objet>?<options> HTTP/1.1
Authorization: <apikey>
Content-Type: application/json
Content-Lenght: <JSON data size below>


{
   …
}

-----------------------------------------------------------------------------------------------
HTTP/1.1 <code d’erreur HTTP>
Content-Type: application/json
Content-Lenght: <JSON data size below>


{
"stamp" :  {
    "date"        : <processing date YYMMDDhhmmss>,
    "err"         : <error code, 0=OK>,
    "msg"         : <error description>
    }
}

where the <HTTP error code> parameter can take the following values:

HTTP Status Code

Description

201 Created

Object created successfully

250 OK

Request processed successfully

204 No Content

Request processed successfully

401 Unauthorized

Unauthorized resource access (<apikey> rights)

403 Forbidden

Unauthorized object access (rights)

400 Bad request

Invalid request format

404 Not found

Resource / object does not exist

2.2. Datas

The following sections describe the format of the data to be provided as input to the system: body text, html or AMP, list of recipients, and nomenclature of merging fields and special fields.

 

2.2.1. Text / html / AMP templates

The contents of the text, html and AMP bodies can either be directly encapsulated in the routing order in literal form (cf ex above), encoded natively in "utf-8", or be stored in external files (in this case, specify their encoding in the "charset" field in the routing order), with an access path preceded by the '@' character and relative to the directory of the user account. Nb: the description of the AMP format is published on https://amp.dev/.

2.2.2. Charsets

The "charset" fields describe the character set in which the values are provided, and are therefore necessary for a correct encoding of email messages, whether headers or templates.

 

When the system merges templates with recipient list fields, it automatically performs character set conversion between the data.

 

For example, if the template is in UTF-8 format and the recipient list in iso-8859, the system will convert the accents of the recipient list fields to UTF-8 before merging them with the body html.

2.2.3. Recipient's list

Recipient lists used for mailing lists must be in .CSV format.

  • The name of the fields must be indicated on the first line of the file, with the special characters as separator ’ ;’, ‘,’ ‘<tab>’, ‘|’.

  • The system automatically detects the separator used

  • Fields and values can optionally be double-quoted

  • Fields starting with the letters 'RF' are prohibited because they are reserved by the system

  • The "EMAIL" field must be defined and contain the recipient's email address

  • The CSV file can contain a maximum of 250 fields

  • The length of a field name is limited to 24 characters, in the range 'A'-'Z', '0-9' and the dash character ‘-‘.

  • The data size of a field is limited to 1000 characters

  • Field names are case insensitive

  • The total length of a line is limited to 4000 characters

  • File encoding must be specified in routing order (par défaut, "utf-8"", cf "list" : "charset") 

 

Example:

name;forname;email;company;custid

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

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

NB : if no list of recipients is specified in the routing order, the system builds a list of recipients from the fields 'to:' 'cc: and 'bcc:' of the headers, with the fields 'EMAIL' and ' NAME' as specified by members "addr" et "name".

2.2.4. Merging fields

Message header fields (e.g. ‘Subject:’), body text, html or AMP bodies, can be personalized with any field in the list of recipients, using the following syntax: $$[record]nom_du_champ$$.

 

The system additionally provides two special merge fields:


$$[link]mirror$$: created a link to a mirror page automatically generated by the system from the body html, repersonalized and with tracked links, exactly identical to the email sent.


$$[link]unsub$$ : created a link to the unsubscribe page indicated in the "tracking" section, which makes it possible to differentiate the click in the statistics.

 

Example of custom header:


"header" : {
  "subject" : "$$[record]forname$$, a special offer for you" },…

 

Example of custom html body:

"htmbody" : {
"path": "Hello $$[record]forname$$,
To confirm your registration, please <a href="http://mycompany.com/register?id=$$[record]custid$$"> click here</a>
To view this message in your browser,
<a href="$$[link]mirror$$">click here</a>
To stop receiving messages from us, you can
<a href="$$[link]unsub$$">unsubscribe</a>" },…

2.2.5. Dates

 

Special merge fields allow the date and time to be represented in multiple ways, in multiple languages, local time zone or 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

 

Examples:


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

bottom of page