Takes in an optional JSON PromotionRequest body and performs a promotion operation defined by the specified Toast-Transaction-Type.

• PROMOTION_VERIFY: Verifies whether a given promotion code is applicable to a check. Confirms that the promotion code is available for use, the check meets the criteria of the promotion, and that no other, conflicting promotions or discounts are applied.
  
  Each unique PROMOTION_VERIFY request has a unique GUID. Providers can cache a response based on a Toast-Transaction-GUID.
  
  If the request is valid (it is properly formatted and the promotion code can be applied), then the API returns a corresponding PromotionObject that is applicable to the check provided in the PromotionRequest. This PromotionObject contains the proper state of the promotion, including the amount to take off the check (as calculated by the provider), the name of the promotion, and the appliedDate. It is recommended that the provider use the appliedDate provided by the VerifyPromotionRequest.
  
  This operation must be idempotent, such that the same request must always get the same response (barring any separate apply/void requests). The provider should reserve a promotion code based on a PROMOTION_VERIFY response, and may wish to use a composite key of (check.guid, restaurant-external-guid). Providers should use the Toast-Transaction-GUID to prevent replayed requests from reserving the promotion more than once. Additionally, the Toast-Transaction-GUID acts as an identifier for the promotion in future requests.
  
  The average response time for a promotion verify request should be 500ms, with the maximum response time being 2s.
  
  
• PROMOTION_REVALIDATE: Revalidates all AppliedPromotions provided on an RevalidatePromotionsRequest (in the promotionsToActOn field). This should check that all promotions in that field are still applicable to the provided check, and represent the correct amount. The promotions in promotionsToActOn are not APPLIED.
  
  If the PROMOTION_REVALIDATE request is valid (it is properly formatted and the promotion code can be applied), then the API returns a 200 response with a list of all AppliedPromotion objects from promotionsToActOn with up-to-date values. If the total discount of a promotion is different than what was provided, the corresponding AppliedPromotion response should have this new value.
  The promotions that are not included in `promotionsToActOn` are immutable because they have been APPLIED, and can no longer be removed from the check.
  
  If there are any promotions that are invalid, the API returns a 400 response with an `ErrorResponse` object. The `ErrorResponse` should contain all invalid promotions. Toast will resend a request to the revalidate endpoint after removing all invalidated promotions.
  
  This operation must be idempotent, such that the same request must always get the same response (barring any separate apply/void requests). If promotions are locked, their unlocking time should be refreshed upon this request. If promotion locks have expired, they should acquire a new lock.
  
  The average response time for a revalidate request should be 500ms, with the maximum response time being 2s.
  
  
• PROMOTION_APPLY: Redeems all AppliedPromotions provided on an ApplyPromotionsRequest (in the promotionsToActOn field). If the redemption is successful, the API commits the transaction and returns a 200 response.
  
  Each unique PROMOTION_APPLY request will have a unique GUID, which will be referenced later to verify the state of a promotion code or to void a previously applied promotion code. If the request contains a Toast-Transaction-GUID that has already been committed or voided for a different check GUID, the API provider must return a 400 response with the appropriate ErrorResponse object. If there are any issues applying promotions, the API provider must return a 400 response, and we will revalidate our existing promotions.
  
  If the request is valid (it is properly formatted and the promotion code can be applied), then the API returns a list of AppliedPromotion objects that are applicable to the check provided in the PromotionRequest. Each AppliedPromotion object contains the proper state of the promotion, including the amount to be taken off the check (as calculated by the provider).
  
  This operation must be considered idempotent for multiple requests with the same Toast-Transaction-GUID and the same check GUID, for a 24 hour period (that is, it should apply once and only once).
  
  The average response time for an apply promotion request should be 500ms, with the maximum response time being 2s.
  
  
• PROMOTION_STATUS: Responds with the PromotionObject or ErrorResponse that is associated with the provided Toast-Transaction-GUID, as well as the status of the redemption ("VERIFIED", "VOIDED", or "APPLIED"). If the transaction GUID is not associated with a promotion that was VERIFIED, the response code is 400.
  
  The average response time for a promotion status request should be 500ms, with the maximum response time being 2s.
  
  
• PROMOTION_VOID: Voids supplied promotions from a VoidPromotionsRequest (in the appliedPromotions field). This endpoint is called when the entire check is voided, or the promotion is removed from the check. This endpoint is called on promotions that are verified as well as committed. If called on a non-committed promotion AND there is a lock placed on the promotion, the lock should be lifted, allowing another user to potentially use the promotion code. If the promotions have already been voided, then nothing should change for those.
  
  This call must be idempotent for multiple requests with the same Toast-Transaction-GUID. The Toast-Transaction-GUID may be used to cache a response, and to prevent a replay attack.
  
  The average response time for a promotion void request should be 500ms, with the maximum response time being 2s.