# Get Protocol Research ###### tags: `Get Protocol` ## Overview ![](https://i.imgur.com/rYVu2jJ.png) ## Actions * The Ticket Engine API has been designed to accept a stream of actions, where each action is an operation that you wish to carry out on the protocol. * Offering a stream endpoint allows integrators on the protocol to forward mixed batches of action requests to the Ticket Engine API and these will be processed in the order they are received. ### Events * There are two actions types available for interacting with events; **newEvent** and **updateEvent**, both of which require an eventId. * This event ID will not be propagated to the blockchain and is only used as a reference ID for Ticket Engine to use for subsequest requests. * **newEvent** will queue a transaction to create a new smart contract on the blockchain. * **updateEvent** will update the event's metadata on-chain. ### Ticket Lifecycle ![](https://i.imgur.com/CayMr73.png) There are a number of ticket actions available to change the state of a ticket on-chain: * **soldTicket** will create an NFT ticket within the event contract created as part of newEvent. * **resoldTicket** will log a secondary sale event on the ticket. * **scannedTicket** will issue a non-finalising scan event on a ticket. A scan can happen an unlimited amount of times and should be used for multi-day or multi-gate events. * **checkedInTicket** is a scan event that finalises the state of the ticket. For a single-gated event a check-in event should be used instead of a scan. Upon check-in the NFT is ready to be claimed into a user's wallet. * **invalidatedTicket** will also finalise the ticket's lifecycle although this will not enable claiming. To be used for event invalidations & cancellations. * **claimedTicket** to claim to a user's wallet. Updating metadata does not affect blockchain storage: * **updateTicket** will change the NFT Content URI, which is the media file used on NFT marketplaces and wallets.