Runthrough of the devices API agian, as we near release

Author: addshore

devices/api/glossary.md

@@ -2,12 +2,6 @@
 outline: deep
 ---
 
-::: danger ⚠️ Not yet public
-The Device API currently in development and is not yet accessible on production devices.
-
-These pages can be seen as a view of what is to come later this year.
-:::
-
 # Glossary
 
 | Term               | Description                                                             |

devices/api/headers.md

@@ -6,12 +6,6 @@ outline: [1,3]
 import GenerateConsts from '../../components/GenerateConsts.vue'
 </script>
 
-::: danger ⚠️ Not yet public
-The Device API currently in development and is not yet accessible on production devices.
-
-These pages can be seen as a view of what is to come later this year.
-:::
-
 # Headers
 
 These header field types are reserved across all message types.

devices/api/index.md

@@ -6,21 +6,15 @@ outline: deep
 import ProtocolBytes from '../../components/ProtocolBytes.vue';
 </script>
 
-::: danger ⚠️ Not yet public
-The Device API currently in development and is not yet accessible on production devices.
-
-These pages can be seen as a view of what is to come later this year.
-:::
-
 # Device API
 
 The device API makes use of the Lightbug communication protocol, also known as the V3 protocol, which is a byte oriented protocol used for device communication.
 
-The protocol builds on top of existing Lightbug Protocols, and is designed to be:
- - Efficient to read, build
- - Lightweight to store and transmit
+The protocol builds on top of existing Lightbug protocols, and is designed to be:
  - Easy to use and understand
- - Usable in a variety of settings, without complex dependencies
+ - Efficient to read and build
+ - Lightweight to store and transmit
+ - Usable in a variety of settings, without complex or bloated dependencies
 
 ## API Access
 
@@ -30,7 +24,7 @@ Typically, it can be accessed via UART, I2C, or a UDP network connection.
 
 For access details, please [contact our support team](https://lightbug.io/contact/).
 
-Or you can get started with Toit quickly using the Lightbug provided SDK.
+Or you can [get started with Toit quickly](/devices/api/sdks/toit/) using the Lightbug provided SDK.
 
 ## Example Message
 

devices/api/messages/index.md

@@ -3,34 +3,32 @@ import GenerateConsts from '../../../components/GenerateConsts.vue'
 import ProtocolBytes from '../../../components/ProtocolBytes.vue'
 </script>
 
-::: danger ⚠️ Not yet public
-The Device API currently in development and is not yet accessible on production devices.
-
-These pages can be seen as a view of what is to come later this year.
-:::
-
 # Messages
 
-Messages often make use of a few common header fields, and you can expect to see these in most messages types:
+Messages often make use of a few common [header fields](/devices/api/headers), and you can expect to see these in most messages types:
 
 ## Requests
 
-Requests may or may not require a method.
+Requests may or may not require a [MH 5: Method](./../headers#_5-method) header field, such as `GET`, `DO`, `SET` or `SUBSCRIBE`.
+
+This is decided by the individual message type, and if required, should be included in the header.
+
 
-This is decided by the individual message type, and if required is set in the header field [5: Method](./../headers#_5-method).
 
 ## Responses
 
-You should receive a response to every valid and expected message.
+You should receive a response to every valid and expected message when the recipient is able to process the request.
 
-When a message ID is provided in the request, any direct response should include the initiating message ID in the header [3: Response Message ID](./../headers#_3-response-message-id).
+When a message ID is provided in the request, any direct response should include the initiating message ID in the header [MH 3: Response Message ID](./../headers#_3-response-message-id).
 
-Responses can come in the form of a basic [5: ACK](./5-ack) or as the same message type as the request.
+Responses can come in the form of a basic [MT 5: ACK](./5-ack) or as the same message type as the request.
 
-Responses should contain a [4: Response Status](./../headers#_4-response-status) in the header, where 0 is OK, and anything higher indicates a warning or error.
+Responses should contain a [MH 4: Response Status](./../headers#_4-response-status) in the header, where 0 and below are various OK responses, and anything higher than 0 indicates a warning or error.
 
 ## Types
 
 Per the specification, message types are represented by a single `uint16` value.
 
-Values of `60,000` to `61,000` are currently reserved for custom use. Feel free to implement your own messages within this range.
+Values of `60,000` to `61,000` are currently reserved for custom use.
+
+Feel free to implement your own messages within this range.

devices/api/sdks/toit/index.md

@@ -7,3 +7,5 @@
 Lightbug provides a [Toit package](https://pkg.toit.io/package/github.com%2Flightbug-io%2Ftoit-lightbug) that includes a set of bindings to Lightbug devices and the [Lightbug device API](./../../).
 
 Together, these tools allow you to quickly develop and deploy applications on Lightbug devices using Toit.
+
+Once developed, Toit firmware can be build without the jaguar development tooling enabled, and sent to Lightbug devices over the air for update.