User parameters

The <UserParameterList> contains a number of parameters the user of the API may input in order to customise various functionality of the check-in. Please contact Travelfusion, if any additional user specific parameters are required.

Parameters related to emailing of the boarding pass(es)

The Checkin API always forwards the boarding pass(es) to the emails specified in emailto and emailbcc parameters. The email body has a default style, and it contains the boarding pass(es) as attachments, usually in pdf form. Different styles may be used for the email body, so long as the user requests it from Travelfusion as well as provide the necessary email styles/templates. For example, a user may require a different email style or language for their different markets / customers.

emailto

It contains the recipient email address (comma separated if more than one address). This would typically be the main travellers' email(s).

emailbcc

Bcc email address (comma separated if more than one address) for the hidden recipients. The user of the API may need to receive all emails sent by the API to the user's end customers.

locale

For user specific email styles/templates. It would typically specify the locale of email body. Example value: "it_CH", which is 'ISO 639 alpha-2 language code' followed by underscore, followed by 'ISO 3166 alpha-2 country code'.

brand

For user specific email styles/templates. This would generally be the name of the email template to be used.

phone

For user specific email styles/templates. This would be used within the given template. This would normally be the user's contact number for the end customer to call for support; it may change as the brand or locale parameters change. It may be ignored, for example when the phone numbers are actually already specified in the given email templates.

userbookingreference

For user specific email styles/templates. This would normally contain the user's specific booking reference. The user of the API may have their own booking reference which they need to pass on into the email such as the end customer may use it when contacting for support.

Sender of the boarding pass(es) email

The default sender's email address (emailFrom) is of the Travelfusion domain (e.g. servers@travelfusion.com). The API cannot just use a sender of a different domain, because that would potentially result in Travelfusion's IPs being marked as spoofing and eventually get blacklisted.

If an API user requires a different (and potentially configurable) sender email address be used, then the user should contact Travelfusion in advance in order to discuss the requirement and arrange for appropriate setup. Generally, there is a number of options available, as follows.

Travelfusion sender, user forwards to end customer

Travelfusion is the actual sender (as in default), and the email is sent to the API user (only) who manages forwarding to all appropriate recipients, hence using the emailFrom of their choice. This is not using different sender; it merely is a simple workaround the user may wish to consider, because it seems to be a much simpler option than the others.

Include SPF record in user's DNS

The user should include an SPF record in their DNS that specifies our servers may send email on behalf of user's domain(s). In order to achieve that, the user should request the Travelfusion's email servers IPs or DNS names. After user's DNS change is effective, Travelfusion would have to verify by checking email server logs e.g. sample log:

Received-SPF: pass (google.com: domain of USER_SENDER_EMAIL designates IP_OF_TF_EMAIL_SERVER as permitted sender) client-ip=IP_OF_TF_EMAIL_SERVER;

Travelfusion is allowed access to user's email server(s)

Unlikely, but a possibility.

Independent Travelfusion domain creation

Travelfusion would create and register an independent domain on its side for email sending on user's behalf; agreed in advance with the user. This wouldn't be easy as the name would have to be different from those names user uses, plus, it would have not to exist elsewhere. Unlikely, but a possibility.