The Tix ticketing system is used in combination with a website from the venue. This article describes the possibilities and best approach to integrate the venue website and Tix.
There are multiple methods to do this, from simple manual links to an fully automated setup.
Manual links
It is possible to use direct links to the production, event or subscription sales pages and place these in your website by hand. Of Course this depends on the cms how this is done.
Some examples:
Link to a production:
https://tix.theaterexample.com/nl/buyingflow/tickets/1290/
Link to an event in this production
https://tix.theaterexample.com/nl/buyingflow/tickets/1290/18417/
Link to an subscription:
https://tix.se/sv/oslo/buyingflow/subscription/15/
The first two examples show a Tix setup on the subdomain of the venue. The last one the Tix domain.
These links can be found in the Box Office sales screens in Tix and also on the Internet tab of the event edit screens
Automated setup
The website database holds the events or subscriptions with all information that the venue wants to publish on their website. There can be a calendar page, a page per production.
A common approach is to have a setup that does the following:
- The website periodically imports all future events into their database with help of the Tix Event API This ensures that the event information from Tix is present in the website database
- The more information is used the better, at least the PurchaseURL's, OnlineSaleStart,OnlineSaleEnd and SaleStatus are needed.
- The cms is used to add more information, videos, reviews etc to the event groups (productions) or to individual events.
- The website publishes the event. From now it is visible to the visitors. A [buy tickets] button is shown with the Purchase url when the current date is between OnlineSaleStart and OnlineSaleEnd
When the user clicks on [buy tickets] the Tix flow is opened in the same browser window. The user can buy tickets.
A reasonable interval for the import in step 1 depends on the situation. Once every hour is reasonable.
Webhook
It seems a bit of a waste to do the import very often, when most of the time nothing has changed. But on the other hand, you don't want to wait 2 hours for a change to come online. This is when you can use the webhook.
Tix can call a url on your website, the webhook url, every time in Tix a change to an event has been made. As a response to the webhook request your website can start an import job.
There is no information in the webhook on what event has been changed.
User login status and basket information
Important: Due to security restrictions of the safari browser, your Tix instance needs to be on a subdomain of your venue website. e.g. tix.venuewebsite.se
It is possible to show on the venue website that a user if logged in Tix and if he has a basket. Also the basket contents can be shown on the website.
This is achieved by sharing session data from Tix to the website. The website then uses this data to show it in the design they want.
The sharing works by opening an iframe to the tix website with the integration url on the correct “skin”.
This iframe can be hidden on the venue webpage. The event/postmessage framework is used to communicate between the opener page and the iframe.
The post messaging is limited by the “skin” where you can set which websites are able to post messages and receive them. (see Skin settings) Multiple domains can be configured to allow development and staging servers of the venue site to use the same skin as the production website.
The url of the Integration TIX (itix) file is defined as:
{skin url}/{language}/itix
example:
https://tix.theateraandeparade.nl/nl/itix
This url has to be requested in an iframe .
A working example can be seen at this example site: http://venuepoint.is/isess/
The postMessage 'GetSession' should be issued to the iframe.
An EventListener is used to act on the return message with the session information. The simple javascript in the example site can help to understand this.
Example of the json structure of the postmessage response shows the order and the user.
{
"order": {
"items": [{
"type": "Ticket",
"name": "An evening with Q on stage",
"details": "13-3-2022 20:00:00",
"price": 12.0000
},
{
"type": "Ticket",
"name": "An evening with Q on stage",
"details": "13-3-2022 20:00:00",
"price": 12.0000
}
],
"expires": 896.0954898,
"url": "https://tix.theaterexample.nl/nl/buyingflow/purchase/"
},
"user": {
"id": 35,
"name": "James Bond",
"email": "JamesBond@Example.com",
"tags": [{
"id": 7,
"name": "Premium",
"abbr": "PP"
}]
},
"profile": "https://tix.theaterexample.nl/nl/profile/"
}
In the above example we have a user with an ongoing order.
Details of the object sent are as follows;
| order | Object that is null if no order is currently in the user session |
| order->items | A list of all items in the order |
| order->items->type | Type of item can be Ticket, Subscription,GiftCard, Product. Note that Subscription is a ticket that is part of a subscription package. |
| order->items->name | Name of the item these are different for each type: Ticket => Name of event, Subscription => Name of subscription package, GiftCard => Name of gift card or group, Product => Name of product |
| order->items->details | Details for each type: Ticket => Event’s start date, Subscription => Event’s name and start date, GiftCard => Amount of the gift card formatted as an invariant string “0.00”, Product => No details on products |
| order->items->price | Price of the item as an invariant decimal 0.00 |
| order->expires | Decimal seconds and milliseconds until the order expires. |
| order->url | A url that takes you to the purchase page for the order (usually same for all since the order is already in the session) |
| user | Object is null if user is not logged in on this session |
| user->name | Full name of the logged in user (can be empty) |
| user->email | Email of the logged in user |
| user->tags | A list of “Tags” that the user has access to, these can be matched with “tags” on events to give special access to the logged in user |
| user->tags->id | Id of the tag |
| user->tags->name | Name of the tag |
| user->tags->abbr | Abbreviation of the tag, this is not guaranteed to be unique it can be chosen by the client |
| profile | A url that takes you to the login page if you are not logged in, but to the profile page if you are logged in. |
Note: delivery fees are not in the session information.
Personalised information
With the session information the website is able to show personalised information to the customers.
For example if a VIP customer is logged in he can see his VIP prices, normal customers don't see these. Or you can show the [buy tickets] button earlier to your members, now they can buy before the general public can.
The method used here is tix event API containing all the normal sales dates and prices, but also the possible benefits the customers with certain customer tags can utilize.
And example of an object list of benefits;
{
"Benefits": [{
"CustomerTag": {
"CustomerTagId": 8,
"Name": "Student",
"Abbreviation": "ST"
},
"Prices": [{
"TicketType": "Student",
"Translations": [],
"Prices": [{
"PriceZone": "1",
"Price": 8.5
}]
}]
},
{
"CustomerTag": {
"CustomerTagId": 16,
"Name": "Friend",
"Abbreviation": "FR"
},
"OnlineSaleStart": "2021-06-10T13:00:00",
"OnlineSaleStartUTCUnix": 1620039600,
"Prices": [{
"TicketType": "Friends",
"Translations": [],
"Prices": [{
"PriceZone": "1",
"Price": 5
}]
}]
}
]
}
Here you can see that Customers with the tag Student get to buy tickets for TicketType Student for a price of 8.5
For customers who are "Friend" there is an alternative, earlier, OnlineSaleStart and also an extra TicketType.
All the benefit data should be stored in the database of the website, so they are available to use in the web front-end.
A possible approach to use this data
The webpage loads with the prices visible in the template, and the "Benefits" prices are in hidden elements. Then when the website gets a user object in the session information from Tix. The user->tags->id can be used to display the benefit prices, the ones with the corresponding CustomerTagId
The same goes for the buy tickets button. The default information is used to display the initial state of the button. But when the user has a CustomerTag Id that matches a benefit with an earlier date, the button state can be evaluated using that date.
Example of what normal, or not logged-in users see and what friends see sometime on Jun 10th after 13:00.
|
Default info / state |
Friends benefit had an different date |
|
"OnlineSaleStart": "2021-06-26T13:00:00" |
"OnlineSaleStart": "2021-06-10T13:00:00" |
 |
 |
Notes:
Benefits can add ticket types to the list of available ticket types. Benefits can not change the price of already available ticket types, nor can they remove ticket types.
A customer can have multiple customer tags. Each tag can have a benefit.
All beneficiary ticket types are available to such a customer, and as such should be shown to him.
When there are multiple beneficiary OnlineSaleStart dates, the first occurring OnlineSaleStart should be used.
A customer tag or benefit does not influence the OnlineSaleEnd, SoldOut or SaleStatus, they remain the same for all customers.
Skin settings
In Tix we have a skin, that is a combination of settings to be used online. Relevant for the integration in the website are the following settings.
SkinUrl
The Url this skin works on. This can be an abbreviation that is used in the url of the tix domain. e.g. exam Or a subdomain of the venue website. https://tix.exampletheatre.com. Of course this has to be a configured domain for your workgroup.
Url
Set per language. This is the URL as set on the logo in the top bar of the skin. This is also used when the customer presses “Continue shopping” in the Tix buying process.
DomainOverride
(Only available to Tix admins) If the same work group has multiple organizations then they might want to have different skins but still use the same subdomain. For example if the “main” skin uses tix.exampletheatre.com then that is set in the SkinUrl for the “main” skin. If there are other skins in the same work group that want to use the same subdomain then “tix.exampletheate.com” goes in DomainOverride, and the SkinUrl is used as a token to differentiate between the two. So the “non main” skin would have tix.exampletheatre.com in DomainOverride, then it would have something like “opera” in the SkinUrl leading to the eventual domain “https://tix.exampletheatre.com/en/opera” as the url for the “non main” skin.
HostedSkin
(Only available to Tix admins) This is set if the SkinUrl setting indicates a subdomain skin. So if the SkinUrl is set to tix.exampletheatre.com then this setting needs to be set as well.
SessionUrls
These are the protocols and domains you want to allow to use session information on. You can set multiple to give you webcompany to option use different develop / test and live servers in combination with Tix.