For a better understanding of the API’s use, we proposed below a summary of the data structure with which Experticket works. To facilitate understanding, we will work with the fictitious examples of the PTM Theme Park and the PAC Water Park. ## **Transaction** A Transaction is equivalent to a purchase or purchase attempt. A transaction can be composed of one or several products (those the customer has decided to buy), but which must all belong to the same Provider. In other words, a transaction must involve only the products of a single Provider. If the customer wants to buy products from two Providers, there will be two transactions. ## **Provider** A Provider encompasses a set of defined products. Its objective is solely that of setting a simple hierarchical order. In our example we present two providers: PTM and PAC. ## **ProductBase** A ProductBase (or product category) is a simple classifier/grouper of products. Later on we will see, for instance, that it is not required for creating a transaction (it's enough with the provider and the list of products with their tickets). But on the other hand, it is very useful for defining common properties for a set of products, e.g. a "description". We will look at the different uses of the ProductBase throughout the document. For simplicity, our example has only one ProductBase in each Provider, which we refer to as "tickets", and which will not have a description. To facilitate the concept’s understanding a little further, we envision a ProductBase referred to as "tickets" (with products "adult tickets" and "children’s tickets"), and another ProductBase referred to as "offers" (with products "adult offers" and "children’s offers"). ## **Product** A Product is the basic commercial element of sale. In PTM, for example, there will be 4 products: "Adult Ticket", "Children’s Ticket", "3x2 Ticket (two adults and a child)" and "3D animated movie". In PAC, for example, there will be 4 products: "Adult Ticket", "Children’s Ticket", "Senior Ticket" and "2x1 Children’s Ticket". ## **Ticket** A ticket is the smallest unit of sale. A product may have one ticket, several, or none. A ticket can be part of one or several products. Continuing with the proposed example: - PTM (provider): - "Adult Ticket" product composed of a single ticket ("Adult Ticket"). - "Children’s Ticket" product composed of a single ticket ("Children's Ticket"). - "3x2 Ticket" product composed of three tickets ("Adult Ticket", "Adult Ticket" and "Children's Ticket"). - 3D animated movie composed of a single ticket ("3D Ticket"). - PAC (provider): - "Adult Ticket" product composed of a single ticket ("Adult Ticket"). - "Children's Ticket" product composed of a single ticket ("Children's Ticket"). - "Senior Ticket" product composed of a single ticket ("Senior Ticket"). - "2x1 Children's Ticket" product composed of two tickets ("Children's Ticket" and "Children's Ticket"). In the example, each product is composed of tickets. In addition, some of these tickets are part of several products. E.g. in the case of provider PTM, "Adult Ticket" ticket is part of products "Adult Ticket" and "3x2 Ticket", the latter which includes two adult tickets. > **Important note:** a product may not contain tickets. In this case the customer will receive a "bonus", which doesn't carry a bar code, and which should be exchanged at the destination. ## **Session** A session is defined by date, time, content, and (optionally) available capacity. A product may have one session, several, or none. Here are some examples: - "3D animated movie" product (follows with our example in provider PTM): composed of two single sessions of 1 January 2001 at 10:00 a.m. and at 4:00 p.m. - "3D Movie Room": composed of three sessions per day for every day of the year (i.e. 3x365 = 1,095 sessions), from 1 January 2000 to 31 December 2000, showing: "Travels with Dinosaurs" at 10:00 a.m., "Looking Deeply into the Universe" at 12:00 a.m., and "The Volcano of Volcanoes" at 1:30 p.m. - "Tunnel Guide" product: composed of 10 daily sessions (each lasting half an hour starting at 10:00 a.m.) every weekend, thirty weeks per year (10x2x30 = 600 sessions). - "Water park adult ticket" product: composed of two sessions, one in the morning (9:00 a.m.) and one in the afternoon (4:00 p.m.) for 90 days of the summer (2x90 = 180 sessions). > **Important note:** a product may not contain a session, i.e. its tickets will not have an associated use time but rather simply be bound to the schedule of the destination. ## Hierarchical scheme To conclude, we present a hierarchical scheme below: - 1 Transaction - 1 Provider - N ProductBase - N Products - N Tickets - N Sessions ## **Communication Interface** The communication channel will be that of a REST API, i.e. HTTP calls to a Uniform Resource Locator (URL), with an HTTP Verb (POST, GET, DELETE…) and a request body. ### **Content Negotiation** We can choose whether to work with XML or JSON depending on the REQUEST HEADER "Accept" and/or "Content-Type" we send. E.g. for XML we will send an "application/xml" and for JSON we will send an "application/json". If we ignore the REQUEST HEADER, by default it will return a JSON. Remember that "Accept" is used for requests and "Content-Type" for responses. If you prefeer XML, you can download the XSDs from your partner administration panel, section "Communication Interface".

Versori has established itself as the third generation of Integration Platform as a Service (iPaaS). Versori builds custom integrations for its customers using an intuitive visual user interface.

Versori’s connector engine means there is no dependency on an existing library of apps, all you need to start is the documentation of the app or system you want to integrate to.