Ticketing Extension Overview
4 min
\<font color="#78b5c7">\</font> topic type concept purpose legacy ticketing api overview, differences, and hashing requirements audience api integrators and client developers applies to legacy ticketing clients implementing via api does not apply to universal apis, any other industry, or ticketing clients who opt for a non api integration the universal ticketing api extends the universal api shared transaction model with event, venue, and ticket information ticketing transactions combine a shared transaction foundation with event specific structures that describe what is being purchased and when it will be used ticketing extension model the universal ticketing api adds event information ticket information agency information insurance information activity information \<font color="#386b84"> note \</font> see ticketing complete request structure docid\ ez7ptxvlenb0wbiohk2s for the full path what makes ticketing different ticketing commonly relies on event identity and timing (event id, type, name, start time) venue context (venue identifiers and related address references) seat/ticket details (section, row, number of seats, contiguous seat blocks) these fields provide important context about what is being purchased and when it will be used hashing requirements the ticketing api follows the platform hashing rules fields designated as hash required must be hashed before submission, including giftcardnumber hashedpassword see hashing requirements docid\ yughwvl8eon7vcgswpcd3 (constraint) and accertify hash algorithm docid\ rkik1lb6euuwsz3sxpce (reference) field reference ticketing pre authorization risk score docid\ yzbk7ukmu85wigj8w2u4c ticketing post authorization risk score docid\ sn4xium5fpqh5pvok1ajl ticketing authorization update docid\ gtmychbku76ha5ym udhq ticketing fulfillment update docid\ jmysvr8pu vrj2mmyqrak ticketing chargeback update docid 8vquuivuaecwvvjv7fov0