Changelog

A record of notable GoTab API changes, additions, and deprecations.

This page tracks notable changes to the GoTab API. Breaking changes and deprecations are always called out explicitly.

API Changelog

Versioned history of changes to the GoTab REST API. We use Semantic Versioning:

Major (X.0.0) — Breaking changes: removed endpoints, renamed/removed response fields, schema changes
Minor (x.Y.0) — New endpoints, new response fields, non-breaking additions
Patch (x.y.Z) — Bug fixes, no new routes or response fields

Loyalty API — email_marketing_opt_in on the ENROLL event’s customer_data object. Always a boolean, reflecting the guest’s marketing consent toggle on the enrollment form. The toggle defaults to on, so true is the common case; a guest who turns it off produces false and should not be enrolled in marketing email
Loyalty API — documented the ENROLL event: how to request the enrollment form (respond to INQUIRE with a 404 and the message ENROLL_CUSTOMER), the customer_data payload and field formats, and the expected success and failure responses
Tab pass spend limits — GET /loc/{location}/tabs/passes/{x_pass_id} now returns spend_limit (amount in cents and an enforce mode of pre or post) and spent on the tab_pass object. spent is the sum of the pass’s non-pending, non-voided orders, so PENDING and VOIDED orders are excluded. spend_limit is null when no limit is set. Requires the tab_pass_spend_limits feature flag on the location
Tab pass spend limits — POST /loc/{location}/tabs/passes/{x_pass_id}/items enforces the limit and returns a 400 with the alert This pass has reached its spend limit. when an order would violate it. pre blocks the order that would push spent over the limit; post allows that order and blocks the next one. Only orders placed through this endpoint count toward a pass’s spent — orders added through the regular add-items endpoint are not attributed to the pass. See Tab Pass Spend Limits

POST /loc/subscribe — subscribes one or more locations to the integration associated with the bearer token. Intended for integrator-driven location mapping: after an end user selects locations in the integrator’s UI, post the chosen location_uuids. The integration is resolved from the token, and the token’s user must have access to every requested location — if any location fails the access check, no locations are subscribed
Loyalty API — customers can now be looked up by name or phone number. The lookup still resolves to a phone number as the lookup value
Loyalty API — customer_handles array on the INQUIRE event when the name/phone lookup type is used, containing all phone numbers and emails on file for the customer

POST /loc/{location}/tabs/{tab_uuid}/refund — refunds are issued against a single payment on the tab. paymentId is optional when the tab has exactly one refundable payment. Provide either amount (in cents) for an open refund or items for an itemized refund, but not both; each items entry requires an itemId and a positive integer quantity, with an optional reason. The top-level reason defaults to "Refund"

Webhook event: OPTION_GROUP_UPDATED — fired whenever an option group is created or updated at a location

Bulk product create/update endpoints now accept accountingStreamId. API-driven product creation can explicitly associate products with an accounting stream, resolving an issue where OPEN products defaulted to “Open Items”

Verification API — POST /v2/verification/challenge and GET /v2/verification/verify
GoTab Wallet — JWT payment_session_token on payment sessions