Amusement Extension Overview
4 min
\<font color="#b6c7cb">\</font> topic type concept purpose legacy theme parks api overview, differences, and hashing requirements audience api integrators and client developers applies to legacy theme parks clients implementing via api does not apply to universal apis, any other industry, or theme parks clients who opt for a non api integration the universal amusement api extends the universal api shared transaction model for admissions, attractions, events, and ticket package purchases amusement extension model the universal amusement api adds ticket package information event information ticket information agency information insurance information activity information \<font color="#386b84"> note \</font> see amusement complete request structure docid 4lxgczaunhr5o13jvecar for the full path what makes theme parks different theme parks transactions often rely on venue context (park/venue identifiers) ticket counts and pricing (number of tickets, total ticket price, ticket currency) package context (package id/class/description) per ticket guest context (guest name, age classification, ticket class, annual pass flags) these structures allow admissions and package purchases to be evaluated with the right contextual signals hashing requirements the amusement 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 amusement park pre authorization risk score docid\ elqrfrtv7xjgomfenfqhe amusement park post authorization risk score docid\ xaus4uaghi4dr9xqwulvi amusement park authorization update docid\ kgwhbf7zvyv6nookp3w3h amusement park fulfillment update docid 4svwdycmsvoc5qezduyoz amusement park chargeback update docid\ wunluogy4ovni3k1frcpz