@blues-inc/notehub-js 6.5.0-beta.60 → 6.5.0-beta.62

package/README.md

@@ -6,7 +6,7 @@ The OpenAPI definition for the Notehub.io API.
 This SDK is automatically generated by the [OpenAPI Generator](https://openapi-generator.tech) project:
 
 - API version: 1.2.0
-- Package version: 6.5.0-beta.60
+- Package version: 6.5.0-beta.62
 - Build package: org.openapitools.codegen.languages.JavascriptClientCodegen
   For more information, please visit [https://dev.blues.io/support/](https://dev.blues.io/support/)
 
@@ -112,7 +112,6 @@ var projectOrProductUID = "app:2606f411-dea6-44a0-9743-1130f57d77d8"; // {String
 var opts = {
   pageSize: 50, // {Number}
   pageNum: 1, // {Number}
-  cursor: "cursor_example", // {String} A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
   monitorUID: "monitorUID_example", // {String}
 };
 api.getAlerts(projectOrProductUID, opts).then(

package/dist/ApiClient.js

@@ -26,7 +26,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
  */
 /**
  * @module ApiClient
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 /**
  * Manages low level client-server communications, parameter marshalling, etc. There should not be any need for an
@@ -68,7 +68,7 @@ var ApiClient = /*#__PURE__*/function () {
      */
     this.defaultHeaders = {};
     if (typeof window === "undefined") {
-      this.defaultHeaders["User-Agent"] = "OpenAPI-Generator/6.5.0-beta.60/Javascript";
+      this.defaultHeaders["User-Agent"] = "OpenAPI-Generator/6.5.0-beta.62/Javascript";
     }
 
     /**

package/dist/api/AlertApi.js

@@ -28,7 +28,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Alert service.
  * @module api/AlertApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var AlertApi = exports["default"] = /*#__PURE__*/function () {
   /**
@@ -49,7 +49,6 @@ var AlertApi = exports["default"] = /*#__PURE__*/function () {
    * @param {Object} opts Optional parameters
    * @param {Number} opts.pageSize  (default to 50)
    * @param {Number} opts.pageNum  (default to 1)
-   * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
    * @param {String} opts.monitorUID
    * @return {Promise} a {@link https://www.promisejs.org/|Promise}, with an object containing data of type {@link module:model/GetAlerts200Response} and HTTP response
    */
@@ -68,7 +67,6 @@ var AlertApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         monitorUID: opts["monitorUID"]
       };
       var headerParams = {};
@@ -86,7 +84,6 @@ var AlertApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {String} opts.monitorUID
      * @return {Promise} a {@link https://www.promisejs.org/|Promise}, with data of type {@link module:model/GetAlerts200Response}
      */

package/dist/api/AuthorizationApi.js

@@ -30,7 +30,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Authorization service.
  * @module api/AuthorizationApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var AuthorizationApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/api/BillingAccountApi.js

@@ -30,7 +30,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * BillingAccount service.
  * @module api/BillingAccountApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var BillingAccountApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/api/DescriptionApi.js

@@ -29,7 +29,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Description service.
  * @module api/DescriptionApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var DescriptionApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/api/DeviceApi.js

@@ -48,7 +48,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Device service.
  * @module api/DeviceApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var DeviceApi = exports["default"] = /*#__PURE__*/function () {
   /**
@@ -1128,7 +1128,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @return {Promise} a {@link https://www.promisejs.org/|Promise}, with an object containing data of type {@link module:model/GetDevicePublicKeys200Response} and HTTP response
      */
   }, {
@@ -1145,8 +1144,7 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
       };
       var queryParams = {
         pageSize: opts["pageSize"],
-        pageNum: opts["pageNum"],
-        cursor: opts["cursor"]
+        pageNum: opts["pageNum"]
       };
       var headerParams = {};
       var formParams = {};
@@ -1163,7 +1161,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @return {Promise} a {@link https://www.promisejs.org/|Promise}, with data of type {@link module:model/GetDevicePublicKeys200Response}
      */
   }, {
@@ -1181,7 +1178,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Number} opts.startDate Start date for filtering results, specified as a Unix timestamp
      * @param {Number} opts.endDate End date for filtering results, specified as a Unix timestamp
      * @param {Boolean} opts.firstSync When true, filters results to only show first sync sessions (default to false)
@@ -1207,7 +1203,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         startDate: opts["startDate"],
         endDate: opts["endDate"],
         firstSync: opts["firstSync"]
@@ -1228,7 +1223,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Number} opts.startDate Start date for filtering results, specified as a Unix timestamp
      * @param {Number} opts.endDate End date for filtering results, specified as a Unix timestamp
      * @param {Boolean} opts.firstSync When true, filters results to only show first sync sessions (default to false)
@@ -1248,7 +1242,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {Array.<String>} opts.tag Tag filter
      * @param {Array.<String>} opts.serialNumber Serial number filter
@@ -1275,7 +1268,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         deviceUID: this.apiClient.buildCollectionParam(opts["deviceUID"], "multi"),
         tag: this.apiClient.buildCollectionParam(opts["tag"], "multi"),
         serialNumber: this.apiClient.buildCollectionParam(opts["serialNumber"], "multi"),
@@ -1301,7 +1293,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {Array.<String>} opts.tag Tag filter
      * @param {Array.<String>} opts.serialNumber Serial number filter
@@ -1328,7 +1319,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {Array.<String>} opts.tag Tag filter
      * @param {Array.<String>} opts.serialNumber Serial number filter
@@ -1359,7 +1349,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         deviceUID: this.apiClient.buildCollectionParam(opts["deviceUID"], "multi"),
         tag: this.apiClient.buildCollectionParam(opts["tag"], "multi"),
         serialNumber: this.apiClient.buildCollectionParam(opts["serialNumber"], "multi"),
@@ -1385,7 +1374,6 @@ var DeviceApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {Array.<String>} opts.tag Tag filter
      * @param {Array.<String>} opts.serialNumber Serial number filter

package/dist/api/EventApi.js

@@ -30,7 +30,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Event service.
  * @module api/EventApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var EventApi = exports["default"] = /*#__PURE__*/function () {
   /**
@@ -51,7 +51,6 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
    * @param {Object} opts Optional parameters
    * @param {Number} opts.pageSize  (default to 50)
    * @param {Number} opts.pageNum  (default to 1)
-   * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
    * @param {Array.<String>} opts.deviceUID A Device UID.
    * @param {Array.<String>} opts.sensorUID A sensor UID to filter events by, matched exactly against the event sensor field. The value may carry any prefix.
    * @param {module:model/String} opts.sortBy  (default to 'captured')
@@ -84,7 +83,6 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         deviceUID: this.apiClient.buildCollectionParam(opts["deviceUID"], "multi"),
         sensorUID: this.apiClient.buildCollectionParam(opts["sensorUID"], "multi"),
         sortBy: opts["sortBy"],
@@ -116,7 +114,6 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {Array.<String>} opts.sensorUID A sensor UID to filter events by, matched exactly against the event sensor field. The value may carry any prefix.
      * @param {module:model/String} opts.sortBy  (default to 'captured')
@@ -146,8 +143,8 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
      * Get Events of a Project by cursor
      * @param {String} projectOrProductUID
      * @param {Object} opts Optional parameters
-     * @param {Number} opts.limit How many events to return in one page. The rate limit counts requests, not events, so a bulk reader should ask for the largest page it can rather than making many small calls. Values above the maximum are rejected.  (default to 50)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
+     * @param {Number} opts.limit  (default to 50)
+     * @param {String} opts.cursor A cursor, which can be obtained from the `next_cursor` value from a previous call to this endpoint. The results set returned will include this event as its first result if the given identifier is actually the UID of an event. If this event UID is not found, the parameter is ignored and the results set is the same as if the parameter was not included.
      * @param {module:model/String} opts.sortOrder  (default to 'asc')
      * @param {Boolean} opts.systemFilesOnly
      * @param {String} opts.files
@@ -191,8 +188,8 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
      * Get Events of a Project by cursor
      * @param {String} projectOrProductUID
      * @param {Object} opts Optional parameters
-     * @param {Number} opts.limit How many events to return in one page. The rate limit counts requests, not events, so a bulk reader should ask for the largest page it can rather than making many small calls. Values above the maximum are rejected.  (default to 50)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
+     * @param {Number} opts.limit  (default to 50)
+     * @param {String} opts.cursor A cursor, which can be obtained from the `next_cursor` value from a previous call to this endpoint. The results set returned will include this event as its first result if the given identifier is actually the UID of an event. If this event UID is not found, the parameter is ignored and the results set is the same as if the parameter was not included.
      * @param {module:model/String} opts.sortOrder  (default to 'asc')
      * @param {Boolean} opts.systemFilesOnly
      * @param {String} opts.files
@@ -216,7 +213,6 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {Array.<String>} opts.sensorUID A sensor UID to filter events by, matched exactly against the event sensor field. The value may carry any prefix.
      * @param {module:model/String} opts.sortBy  (default to 'captured')
@@ -253,7 +249,6 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         deviceUID: this.apiClient.buildCollectionParam(opts["deviceUID"], "multi"),
         sensorUID: this.apiClient.buildCollectionParam(opts["sensorUID"], "multi"),
         sortBy: opts["sortBy"],
@@ -285,7 +280,6 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {Array.<String>} opts.sensorUID A sensor UID to filter events by, matched exactly against the event sensor field. The value may carry any prefix.
      * @param {module:model/String} opts.sortBy  (default to 'captured')
@@ -315,8 +309,8 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
      * @param {String} projectOrProductUID
      * @param {String} fleetUID
      * @param {Object} opts Optional parameters
-     * @param {Number} opts.limit How many events to return in one page. The rate limit counts requests, not events, so a bulk reader should ask for the largest page it can rather than making many small calls. Values above the maximum are rejected.  (default to 50)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
+     * @param {Number} opts.limit  (default to 50)
+     * @param {String} opts.cursor A cursor, which can be obtained from the `next_cursor` value from a previous call to this endpoint. The results set returned will include this event as its first result if the given identifier is actually the UID of an event. If this event UID is not found, the parameter is ignored and the results set is the same as if the parameter was not included.
      * @param {module:model/String} opts.sortOrder  (default to 'asc')
      * @param {Boolean} opts.systemFilesOnly
      * @param {String} opts.files
@@ -368,8 +362,8 @@ var EventApi = exports["default"] = /*#__PURE__*/function () {
      * @param {String} projectOrProductUID
      * @param {String} fleetUID
      * @param {Object} opts Optional parameters
-     * @param {Number} opts.limit How many events to return in one page. The rate limit counts requests, not events, so a bulk reader should ask for the largest page it can rather than making many small calls. Values above the maximum are rejected.  (default to 50)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
+     * @param {Number} opts.limit  (default to 50)
+     * @param {String} opts.cursor A cursor, which can be obtained from the `next_cursor` value from a previous call to this endpoint. The results set returned will include this event as its first result if the given identifier is actually the UID of an event. If this event UID is not found, the parameter is ignored and the results set is the same as if the parameter was not included.
      * @param {module:model/String} opts.sortOrder  (default to 'asc')
      * @param {Boolean} opts.systemFilesOnly
      * @param {String} opts.files

package/dist/api/ExternalDevicesApi.js

@@ -29,7 +29,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * ExternalDevices service.
  * @module api/ExternalDevicesApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var ExternalDevicesApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/api/JobsApi.js

@@ -36,7 +36,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Jobs service.
  * @module api/JobsApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var JobsApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/api/MonitorApi.js

@@ -29,7 +29,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Monitor service.
  * @module api/MonitorApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var MonitorApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/api/OrganizationApi.js

@@ -30,7 +30,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Organization service.
  * @module api/OrganizationApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var OrganizationApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/api/ProjectApi.js

@@ -56,7 +56,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Project service.
  * @module api/ProjectApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var ProjectApi = exports["default"] = /*#__PURE__*/function () {
   /**
@@ -1046,13 +1046,12 @@ var ProjectApi = exports["default"] = /*#__PURE__*/function () {
     }
 
     /**
-     * Get host or Notecard DFU history for all devices that match the filter criteria  When read with a `cursor`, this feed follows writes to the DEVICE record. Firmware state is held separately, so a change made through fleet or project firmware settings may not appear until something else writes that device. A consumer needing complete firmware state should periodically re-read without a cursor.
+     * Get host or Notecard DFU history for all devices that match the filter criteria
      * @param {String} projectOrProductUID
      * @param {module:model/String} firmwareType
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  On THIS endpoint the feed follows writes to the device record. Firmware state is held separately, so a change made through fleet or project firmware settings may not appear until something else writes that device. A consumer needing complete firmware state should periodically re-read without a cursor.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {module:model/String} opts.sortBy  (default to 'captured')
      * @param {module:model/String} opts.sortOrder  (default to 'asc')
      * @param {Array.<String>} opts.deviceUID A Device UID.
@@ -1086,7 +1085,6 @@ var ProjectApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         sortBy: opts["sortBy"],
         sortOrder: opts["sortOrder"],
         deviceUID: this.apiClient.buildCollectionParam(opts["deviceUID"], "multi"),
@@ -1109,13 +1107,12 @@ var ProjectApi = exports["default"] = /*#__PURE__*/function () {
     }
 
     /**
-     * Get host or Notecard DFU history for all devices that match the filter criteria  When read with a `cursor`, this feed follows writes to the DEVICE record. Firmware state is held separately, so a change made through fleet or project firmware settings may not appear until something else writes that device. A consumer needing complete firmware state should periodically re-read without a cursor.
+     * Get host or Notecard DFU history for all devices that match the filter criteria
      * @param {String} projectOrProductUID
      * @param {module:model/String} firmwareType
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  On THIS endpoint the feed follows writes to the device record. Firmware state is held separately, so a change made through fleet or project firmware settings may not appear until something else writes that device. A consumer needing complete firmware state should periodically re-read without a cursor.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {module:model/String} opts.sortBy  (default to 'captured')
      * @param {module:model/String} opts.sortOrder  (default to 'asc')
      * @param {Array.<String>} opts.deviceUID A Device UID.
@@ -1138,13 +1135,12 @@ var ProjectApi = exports["default"] = /*#__PURE__*/function () {
     }
 
     /**
-     * Get host or Notecard DFU history for all devices that match the filter criteria  When read with a `cursor`, this feed follows writes to the DEVICE record. Firmware state is held separately, so a change made through fleet or project firmware settings may not appear until something else writes that device. A consumer needing complete firmware state should periodically re-read without a cursor.
+     * Get host or Notecard DFU history for all devices that match the filter criteria
      * @param {String} projectOrProductUID
      * @param {module:model/String} firmwareType
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  On THIS endpoint the feed follows writes to the device record. Firmware state is held separately, so a change made through fleet or project firmware settings may not appear until something else writes that device. A consumer needing complete firmware state should periodically re-read without a cursor.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {module:model/String} opts.sortBy  (default to 'captured')
      * @param {module:model/String} opts.sortOrder  (default to 'asc')
      * @param {Array.<String>} opts.deviceUID A Device UID.
@@ -1178,7 +1174,6 @@ var ProjectApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         sortBy: opts["sortBy"],
         sortOrder: opts["sortOrder"],
         deviceUID: this.apiClient.buildCollectionParam(opts["deviceUID"], "multi"),
@@ -1201,13 +1196,12 @@ var ProjectApi = exports["default"] = /*#__PURE__*/function () {
     }
 
     /**
-     * Get host or Notecard DFU history for all devices that match the filter criteria  When read with a `cursor`, this feed follows writes to the DEVICE record. Firmware state is held separately, so a change made through fleet or project firmware settings may not appear until something else writes that device. A consumer needing complete firmware state should periodically re-read without a cursor.
+     * Get host or Notecard DFU history for all devices that match the filter criteria
      * @param {String} projectOrProductUID
      * @param {module:model/String} firmwareType
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  On THIS endpoint the feed follows writes to the device record. Firmware state is held separately, so a change made through fleet or project firmware settings may not appear until something else writes that device. A consumer needing complete firmware state should periodically re-read without a cursor.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {module:model/String} opts.sortBy  (default to 'captured')
      * @param {module:model/String} opts.sortOrder  (default to 'asc')
      * @param {Array.<String>} opts.deviceUID A Device UID.

package/dist/api/RouteApi.js

@@ -30,7 +30,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Route service.
  * @module api/RouteApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var RouteApi = exports["default"] = /*#__PURE__*/function () {
   /**
@@ -189,7 +189,6 @@ var RouteApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {module:model/String} opts.sortBy  (default to 'date')
      * @param {module:model/String} opts.sortOrder  (default to 'desc')
@@ -222,7 +221,6 @@ var RouteApi = exports["default"] = /*#__PURE__*/function () {
       var queryParams = {
         pageSize: opts["pageSize"],
         pageNum: opts["pageNum"],
-        cursor: opts["cursor"],
         deviceUID: this.apiClient.buildCollectionParam(opts["deviceUID"], "multi"),
         sortBy: opts["sortBy"],
         sortOrder: opts["sortOrder"],
@@ -250,7 +248,6 @@ var RouteApi = exports["default"] = /*#__PURE__*/function () {
      * @param {Object} opts Optional parameters
      * @param {Number} opts.pageSize  (default to 50)
      * @param {Number} opts.pageNum  (default to 1)
-     * @param {String} opts.cursor A cursor marking where this page begins. Obtain it from the `next_cursor_modified` value, or the `X-Next-Cursor-Modified` response header, of a previous call to the same endpoint. Start a fresh read with `cursor=0`. Treat the value as opaque: its internal form may change.  Supplying a cursor reads the collection as a CHANGE FEED rather than paging a snapshot, which means three things. Results are ordered oldest-change-first, so `pageNum` and any sort options are ignored. A record that is updated appears again, at its new position. A record that is deleted also appears, carrying `deleted: true`, which is how a caller keeping its own copy learns to drop it.  This is the efficient way to enumerate a large collection and the only way to watch it for changes. A page is a seek to a position rather than a scan of everything before it, so reading deep into a collection does not get slower the further you go. The alerts feed is the exception: it sorts on an unindexed column.  A cursor returned by this endpoint identifies an exact record, so resuming from it continues strictly after that record. The bare `cursor=0` bootstrap instead starts at or before the first record, so the very first page of a fresh read may repeat a record you have already seen if you switch to a feed from an ordinary page. Use the record's own identifier to discard duplicates.  Omitting this parameter leaves the endpoint's original paging behavior unchanged, including its response body.  Events additionally accept a legacy cursor here: the `next_cursor` value from a previous call, which is the UID of an event. That form pages in the original order and never returns deleted events.  Cursors are meaningful only within the project that issued them.
      * @param {Array.<String>} opts.deviceUID A Device UID.
      * @param {module:model/String} opts.sortBy  (default to 'date')
      * @param {module:model/String} opts.sortOrder  (default to 'desc')

package/dist/api/UsageApi.js

@@ -31,7 +31,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Usage service.
  * @module api/UsageApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var UsageApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/api/WebhookApi.js

@@ -29,7 +29,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * Webhook service.
  * @module api/WebhookApi
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var WebhookApi = exports["default"] = /*#__PURE__*/function () {
   /**

package/dist/model/AWSRoleConfig.js

@@ -29,7 +29,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * The AWSRoleConfig model module.
  * @module model/AWSRoleConfig
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var AWSRoleConfig = /*#__PURE__*/function () {
   /**

package/dist/model/AddDeviceToFleetsRequest.js

@@ -29,7 +29,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * The AddDeviceToFleetsRequest model module.
  * @module model/AddDeviceToFleetsRequest
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var AddDeviceToFleetsRequest = /*#__PURE__*/function () {
   /**

package/dist/model/Alert.js

@@ -31,7 +31,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * The Alert model module.
  * @module model/Alert
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var Alert = /*#__PURE__*/function () {
   /**

package/dist/model/AlertDataInner.js

@@ -26,7 +26,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
 /**
  * The AlertDataInner model module.
  * @module model/AlertDataInner
- * @version 6.5.0-beta.60
+ * @version 6.5.0-beta.62
  */
 var AlertDataInner = /*#__PURE__*/function () {
   /**