API Connection Interface

Automatic synchronisation of data

During the Maileon integration the first step is to define how to manage the data – how will you import your contacts and how many places will be stored. In every case we recommend complete integration which means that subcribers’/unsubscribers’ data and these mutations/changings will be synchronised automatically. It happens through an API (Application Programming Interface).



Unlike other newsletter sender software Maileon uses a central database to store contacts. It allows to manage the user responses in a central location whether the newsletter was sent to different contact lists or not. Due to the system’s principle of operation an email address clearly identifies a user. This may cause a problem in the event of integrating a site where an email address with a primary key cannot be required.

We provide a solution to store an email address repeatedly connected to different users. In this case it may occur that a user recieves the newsletter twice to the same address (because the database stores the email address twice).

Mailing Lists

Since Maileon put the contact database and user behavior tracking forward it follows a different logic structuring the mailing lists. Every single mailing list’s base is a contact filter. A contact filter is a list of contacts which comply with the given set of conditions. A condition takes account of previous responses, personal data and the details of how it was imported into the system.
In other newsletter sender softwares artificial lists also available in Maileon. Let us see the following example:
There are several Newsletter Categories:

  • Novelties
  • Special Offers
  • Manufacturer Products

If it is possible to sign up to all the three mailing list(s) at the same time then you (will) have to create three contact fields with a primary key in Maileon:

  • Newsletter about Novelties
  • Newsletter about Special Offers
  • Newsletter about Manufacturer Products

In this case a contact filter (and a mailing list) which contains the contacts with Newsletter about Novelties/Newsletter about Special Offers/Newsletter about Manufacturer Products with a YES value at primary contact field can be made.
Related links:

http://dev.maileon.com/api/rest-api-1-0/contacts/create-custom-field/Feliratkozás/leiratkozás/felhasználói adatok szinkronizációja/

Maileon is the primary database

In the first case when a user subscribes to a mailing list it creates a contact in the Maileon database and from this point Maileon stores and manages the user’s preferences and also provides an opportunity to unsubscribe.

Maileon provides to edit the users’ data easily which are stored in the database thus users can modify their data and the newsletter related preferences with ease as well. If the user authentication is solved on the impelentation site (eg .: the user is logged in), then it can be used as usual for retrieve and modify user information.

Maileon provides the placement of profile modifying links in sent emails. These links are contains every single users individiual „contactid” and „checksum” GET parameters allowing the individual identification even if the user is not logged in (or not even registered) on the implementing page.

The implementing page is the primary database

In the second case, the main location of data is in the implementing page’s database; at this point it will be kept in sync with the database system Maileon. You must provide a subscribe / unsubscribe page on the implementing site.

Comment: in this case the Maileon database has to synchronise back the unsubscribers, because Maileon required to provide certain unsubscribe options (treatment of response letters, list-unsubscribe, etc..).


Transaction API provides an opportunity in the given Maileon account to send individual letters for active users. Generally, these letters will be sent out due to the effect on the contact’s typical lifestyle event (eg.: confirm order, password reset, etc.). After loading the transaction event the right mail will be sent immediately. A transaction “event” does not necessarily have to be accompanied by the dispatch logic of Maileon, that this API allows the user’s behavior communication towards to the Maileon system.

Transaction object specifies the details of the user-induced event. A transaction object contains the following:

  • The contact-reference identifies the user in the Maileon system; This is usually the e-mail address or a defined external ID on the interface.
  • The content of this transaction is a JSON document that describes the attribution of transaction event
  • The transaction type specifies a particular type of transaction’s exact parameters.
  • Maileon manages the content of the transaction as a set of attributes.
  • The transaction type determines the type of attributes that are allowed for a certain kind of transaction; Maileon validates each and every transaction based on a “template”.


Maileon provides the AddressCheck function as an extra service. The Email AddressCheck analyses the email address entered regarding syntax, domain and mail server existence as well as bounce risk, and typing errors:

  • The email address is syntactically correct (according to the rules of RFC or in some cases other particular provider)
  • Existing email address (
  • Existing domain (if not, suggested list about similar domains)
  • Risk of bounces
  • Risk of Spamtrap
  • Risk of disposable address

Address check is an independent system from Maileon. Although accessing the API and identification of the account made differently than in Maileon but the logic and structure is similar.