V2 Changelog

Suggest Edits

Breaking Changes when moving to V2 from V1

  • Authentication is no longer Basic, but token retrieval is more accessible to retrieve without requiring LRSConnect or the iOS TT application. See Authentication
  • "stateStarted" property in active order responses has changed to "stateChanged" in order to avoid confusion with the actual state "started" and the same property with viewing an order history's "started" timestamp.
  • "count" property for list responses is now outputting as an integer instead of a string.
  • "statistics" body from V1 moved into it's own enclosed object to keep consistent. (See Statistics)
  • HTTP WebHook /register is now a POST method instead of a GET method. The corresponding query parameter (http_client) now must be defined in the POST data in JSON format.
  • (Only in WebSocket when moving from HTTP) "ORDER_MODIFIED" notifications originally included newly created orders, but now newly created orders will have a notification type of "ORDER_CREATED". As a result, existing integrators who used HTTP should expect to handle this new notification type while switching to WebSockets.
  • (Only in WebSocket when moving from HTTP) "ACTIVE_ORDERS" notification is also presented once upon connecting to WebSocket. It is recommended to be handled so that making another call GET /api/v2/activeorders can be avoided.

New Additions

With v2.0, it is possible to integrate with Table Tracker Gateway without requiring the iOS Table Tracker application. Previously, a third party could manage orders, but a iOS TT app was required for setup in order to access API as well as enable activation with LRSConnect, if desired.

In addition to managing orders as in v1, new endpoints are added for additional functionality or debugging:

  • Viewing repeaters, enable pairing of new repeaters, and disable pairing.
  • Viewing trackers that are connected with gateway and sending Zigbee events.
  • Gateway settings to change timezone, default values, and zigbee channel.
  • List of capabilities to check what hardware features are enabled or if there is any potential problem.
  • API token management. See Authentication.
  • A WebSocket webhook was added which is now recommended to receive order notifications. Like with any TCP socket, the client connecting to the gateway can know if a connection is severed and able to handle it appropriately unlike an HTTP webhook which is only one-way.
  • Every generic or error response will have a returnCode to identify by. It is recommended to check for this returnCode to make sure the proper behavior is expected.

Updated less than a minute ago