Im Maileon Help-Center finden Sie umfassende Dokumentationen zu unserem System.
Beliebte Suchanfragen: Importe | Rest-API | Integrationen | SMS
Frequently Asked Questions
General
Why is my data sometimes not saved in Maileon?
Often such problems are based on a wrong document encoding. Example: the first name “Maik” will probably not cause problems but “Dörthe” might, if not UTF-8 encoded. In this case Maileon cannot interpret the special char “ö” correctly, so make sure that all data transmitted to Maileon is UTF-8 encoded.
Why do the method getContact and updateContact require a checksum and where do I get that from?
The API methods getContact and updateContact use the fields “id” and “checksum” to enhance the confidentiality of the user’s data.
A personalized mailing may contain links to view and/or change a user’s profile. When the user clicks on one of those links, they are forwarded to a page where they can view or update personal data. The getContacts and updateContacts methods provide the same functionality over the API. In cases where the request comes directly from user interaction, the checksum is used to guarantee that the user cannot simply replace his own ID with another user’s ID and view or change that user’s profile, as shown in Figure 1. To ensure this, Maileon generates a checksum in addition to the numeric ID and provides this checksum as credentials in the personalized mailing’s links. In order to view or update contact details, a valid checksum must be provided as a security token.
For third party systems where the call does not come from a manipulatable user request, the recommended way to update a single contact is either the
– updateContact method/ with flag “ignore_checksum” set to true (will be available with next release),
– createContact method/ with the flag “UPDATE” or
– synchronizeContacts with a single contact in the list.
Example with checksum
The designer of a mailing creates the mailing and uses the Maileon UI to add a link where the recipients (contacts) can view and update their contact profile data, see Figure 1. Maileon will then create a placeholder which will be replaced at the time of sending with personalized data, in this case the ID of the contact and the internally generated checksum, see Figure 2.
If the user contact reads the newsletter and clicks the profile update link, the ID and checksum are forwarded to Maileon which redirects to the actual profile update landing page, see Figure 3. The landing page now uses the ID and checksum to request the contact data from the Maileon API. The API checks if the checksum matches the expected (internal) checksum of the contact with the given ID and will only return the contact data if they match (Figure 3). If the contact decides to change their data, the profile update page will handle this by sending the data, the ID and the checksum to the API which again checks the ID and checksum and only stores the data if the given credentials match, see Figure 4.
If an evil contact would manipulate the data sent by the profile update page, e.g. change the contact ID to get data of another contact, the API will not return any data as the checksum no longer matches the expected checksum for the new contact with the manipulated ID.
Hypothetical Example without Checksum
If Maileon did not employ the checksum method, the scenario of an evil user would change a bit. The creation of the newsletter looks the same for this scenario, compare Figure 1. However, at sending time no internal checksum is added to the link of the profile update landing page as depicted in Figure 5. This would allow an evil user to manipulate the data of the link to simulate a different user ID, see IDX in Figure 6. The landing page would then load the contact data of the contact with ID IDX, as there is no further authentication check. Obviously the evil contact can then update the contact data in the same way, using only the manipulated ID IDX, see Figure 7. Because Maileon does employ the checksum method, this exploit is impossible in Maileon.
Transactions
How are empty values or null handeled?
Empty values and null values are stripped from the data model when saved.
"content": { "firstname": "", "lastname": "Mustermann" }
In the above example the empty value for ‘firstname’ will not be saved in Maileon and expressions to print the value like [[TRANSACTION|firstname]] will fail as no data is available for ‘firstname’, even if aparently submitted. In this case an empty fallback value must be specified: [[TRANSACTION|firstname|]]
I have a possibly empty variable and a fallback value in the template but still get personalization errors. Why?
The documentation about transaction types explains that attributes can be grouped in some kind of sub object, e.g.:
"content": { "customer": { "firstname": "Max", "lastname": "Mustermann" } }
In this case the values can be printed using [[TRANSACTION|customer.firstname|]]. If ‘firstname’ is empty and ‘lastname’ is set, this will work, as ‘firstname’ is stripped from the model and thus, the object ‘customer’ still contains ‘lastname’. However, if an object is empty, it will be stripped and if ‘customer’ does not hold any data,in this case lastname is empty, too, the expression [[TRANSACTION|customer.firstname|]] will search for a variable ‘customer’ and throw an error as customer is not available and the fallback is designed for the last check (‘for firstname’) only. So make sure to either have a dummy value if this case can possibly happen (some static value that will never be printed) or use more sophisticated checks to investigate if all objects are available. Just contact us if you wish details on this topic.
When I use use account placeholders, why aren’t they updated when I change them?
When using account placeholders like [[ACCOUNT|…]] in transaction mails there is a cache of 1 hour lifetime or 25 minutes, if no mail is triggered in between. If an account variable is changed, it might take up to one hour until the changes are visible in the transaction mails.