Overview

IWannaTicket allows event promoters to sell tickets online through the website or through the programmatic RESTful API.

Format

Only JSON is supported. It is still a requirement to explicitly state the content type required.

For GET requests this is done through appending a ".json" suffix to the URL or through appropriately setting the "Content-Type" and "Accepts" headers.

For requests other than GET the headers must be set.

Access and versioning

Versioning is performed through prepending a version number, as a path, to the API. The current version is v2. Accessing this version is then https://api.iwannaticket.com.au/v2/...

If you are developing against the IWannaTicket test system, "UAT", you should use the following URLs:

UAT uses a fake payment processor so you can do test transactions.

  • Good card: 4111 1111 1111 1111
  • Bad card: 4111 1111 1111 1103

Authentication and security

All API access is conducted over SSL.

To authenticate a request the user’s username and password are to be included as HTTP Basic-Auth (http://www.ietf.org/rfc/rfc1945.txt s10.2).

Entity Model

  • An IWannaTicket Account has Users, Venues, and Events.
  • A Venue has one or more Venue Sections.
  • A Venue Section is generally a geographical region of a Venue for which capacity restrictions and ticket types may be applied.
  • An Event is related to exactly one Venue.
  • An Event has one or more Event Dates (occurrences of an Event).
  • An Event Date has one or more Ticket Types.
  • A Ticket Type is a type of ticket (Adult, Child, Gold, Silver, etc) belonging to a Venue Section that may be purchased.
  • Customers reserve Admissions in a Payment. An Admission (ticket) is a right to enter an Event on an Event Date for a particular Ticket Type.
  • A Payment (also known as a Sale) is the basic element of commerce in the system. A payment corresponds to one transaction for one or more Admissions to one Event.
  • Master Tickets are prototype Ticket Types which can be used to allow multiple Ticket Types to be changed in one operation. An Event has zero or more Master Tickets.
  • Additional Fields are questions asked of the ticket buyer during purchase, or of guests after tickets are sold. An Event has zero or more Additional Fields.
  • Event Groups are groups of events.
  • Festival Discounts are discounts which span multiple events (usually, an event group). Festival discounts are attached to an account.
  • Multipacks are special discounts which may span multiple events. Multipacks are attached to an account.

Non-Entity Objects

  • An Event Date Group is a string tag applied to one or more Event Dates.
  • A Venue Configuration is a subset of Venue Sections, implemented as a tag on the Venue Sections included in the configuration. This is intended to cover cases where a venue has a ballroom which can be divided into two conference rooms - the configuration prevents tickets being sold for the ballroom and the conference rooms for the same event.
  • Ticket Types for an Event must be located in a Venue Section included in the Venue Configuration for the Event.
  • A Cart is a set of Sales in progress. The cart is identified by a "multi-sale key".

Fulfilment process

This details the process of creating an event through to allocations being purchased and admitted.

Creating an event

  1. A promoter creates an event, its event dates, and their ticket types.
  2. The promoter publishes the event with IWannaTicket.

Purchasing tickets

  1. A punter selects an event and event date to purchase tickets for.
  2. A punter first reserves their tickets through the ticket purchase component.
  3. With a successful reservation the punter completes their details and elects to purchase.
  4. The sale is fulfilled through the merchant facility and the punter is sent their tickets.

Admitting tickets (Admission)

  1. The API is contacted to admit an Admission.
  2. The Admission is marked as admitted and further requests to admit it will be denied.

Ticket QR Code.

All IWannaTicket tickets have either an A or B type QR code.

A-type

The original code employed and is simply the admission ID in plaintext. This is sent to the relevant call and the admission procedure is followed.

B-type

This is a UUID associated with each admission. This is simply provided to the relevant call where the server looks up the corresponding ID and then the admission procedure is followed.

Example of reserving through the API

  1. Reserve 
    POST /reservation/
{
    "event": 123,
    "tickets": [
        {"ticketType": 234, "quantity": 1}
    ]
}
  2. Lock 
    POST /reservation/ABCDEF/lock
{
    "FIRST_NAME": "Foo",
    "LAST_NAME": "Bar",
    "EMAIL": "foo@bar.com",
    "PHONE": "0432574700",
    "OPT_IN": "true"
}
  3. Pay 
    POST /reservation/ABCDEF/payment
{
    "amounts": {
        "CASH": 123.45
    }
}