# Websocket Structure The websocket messages have a defined structure that must be followed when both sending and recieving a message from a unit/server. A message has two components, a header with some meta data and the payload, with the contents of the message. All keys in this structure are camelcase. ### Header \[object\] The header of the message contains 7 fields as follows:
**Field** | **Type** | **Structure** | **Purpose** | **Example** |
fromID | string | First letter of 'type' \_ 'timestamp of device initialisation' \_ version | the ID of the origional sender of the message | S\_1707151018347\_1.0.9 |
timestamp | number | unixtimestamp | The millisecond unix timestamp of when the message was sent | 1707160733725 |
version | string | version.major.minor | Semantic version of the API version in use | 1.0.9 |
type | string | Capitalised string | The type of the sender, to help identify what the prupose of the device is | Server/Browser |
active | boolean | true/false | To determine if the origonal sending device is still online on the network. The message could be a relayed then cached message | true/false |
messageID | number | unixtimestamp | The ID of the origional message, this is typically the unixtimestamp at the time of sending, but could be any number. For detecting message duplication | 1707160733725 |
recipients | array | \[fromID, fromID\] | An array of IDs that have been confirmed to have received this message. This is used in mesh networks to ensure messages don't get stuck in loops. Can also be used to track the path of a message through the network | \[S\_1707184718392\_1.0.9, B\_1707174713595\_1.0.8\] |