• Edited

In order to standardize tokens and oauth REST API services together with other platform entities we moved them to a different REST API path.
Old: /platform/customer/tokens and /platform/customer/oauth
New: /platform/tokens and /platform/oauth

Syntax and call parameters remained the same, just "/customer" part was removed from the API call path.

Old REST API methods will be available until May 15, 2023. On March 1, 2023 we will mark them as deprecated and they will be highlighted in the platform logs with warnings about deprecated method usage on each API call. We will also detect and personally contact all flespi users that will use old REST API methods after April 1, 2023 to ensure their smooth operations.

MQTT tokens and oauth state topics also changed to reflect updated paths:
Old: flespi/state/platform/customer/tokens and flespi/state/platform/customer/oauth
New: flespi/state/platform/tokens and flespi/state/platform/oauth

Both topic paths are synchronously updated now and old topics will be maintained until May 15, 2023.

Please update your software accordingly until May 15, 2023. If you have any question do not hesitate to contact us in flespi chat.

3 months later

shal

The methods /platform/customer/tokens and /platform/customer/oauth have been removed as they were deprecated.

13 days later

We started to publish the unique idents received by the channel to its retained MQTT storage. The topic is flespi/state/gw/channels/+/idents/+

2 months later

We introduced certain limits for traffic generated by CDNs which may lead to temporary suspension of particular CDN operation. And we activated webhooks limits as was initially published (were not active during experimental period).
You may find latest restrictions per each tariff by this link: https://flespi.com/en/docs/restrictions

10 days later

When an account hits certain limitations, we no longer block the entire account. Instead, we block specific active tokens that have exceeded the limit. For example, if your API token starts consuming too many requests or generating excessive traffic, it will be temporarily blocked for a certain period of time. However, all of your other systems will continue to function as usual. Additionally, you will still be able to log in to the panel to check logs and perform other tasks.

When you perform an HTTP request using a blocked token, you will receive an HTTP error 429: Too Many Requests.

12 days later
2 months later

REST API selectors syntax has been enhanced with expressions. Now it is possible to perform rather complex selection operation for PUT/GET/DELETE operations.

To specify expression with REST selector please use brackets: {expression}.

To select devices from 2 accounts specified by cid you may use this selector: GET /gw/devices/{cid=123 || cid==456}

To find devices that are located within 100 km from point with latitude 54.72 and longitude 25.26 you may use the following selector: GET /gw/devices/{(now()-telemetry.timestamp < 3600) && distance(telemetry.position.latitude, telemetry.position.longitude, 54.72, 25.26) < 100}
The actual request should be urlencoded:
curl -X GET --header 'Authorization: FlespiToken XXX' 'https://flespi.io/gw/devices/%7Bnow()-telemetry.timestamp%20%3C%203600%20%26%26%20distance(telemetry.position.latitude%2C%20telemetry.position.longitude%2C%2054.72%2C%2025.26)%20%3C%20100%7D'

To select devices by multiple idents use the following syntax: GET /gw/devices/{configuration.ident == "123456" || configuration.ident == "54321"}

Also from now we encourage all our users to wrap strings in double quotes using legacy selectors as well, like: GET /gw/devices/name="asd*" instead of: /gw/devices/name=asd*. Although both formats will work.

  • Partial Fields Request: You can now specify which keys to return in order to reduce the amount of fetched JSON. For example, you can fetch only ident and phone number for selected devices:
    Request: GET /gw/devices/all?fields=id,configuration.ident,configuration.phone
    Response: {"result": [{"configuration.ident": "first", "configuration.phone": "+123"}, ...]}

  • Pagination Support: You can now use pagination to fetch a limited number of items starting from a specific position. The parameters 'limit' (X) and 'offset' (Y) are available for this purpose. To fetch not more than X items starting from position Y:
    Request: GET /gw/devices/all?limit=X&offset=Y
    Response: {"result": [{}, ...], "pagination": {"limit": X, "offset": Y, "count": Z}}
    Here, 'count' is the total number of items available.

    2 months later

    We have added a new field named metadata to all item types, allowing the attachment of custom properties to any item. These properties can be used as filters in REST API selectors.

    Device configuration example:

    REST API Request: GET /gw/devices/metadata.activated=true?fields=id,metadata
    Response:

    {
      "result": [
        {
          "id": 123,
          "metadata": {
            "Region": "EU",
            "UserId": 123,
            "activated": true
          }
        }
      ]
    }
    a month later

    We are excited to introduce a highly requested feature in today's update. Managing projects with complex architectures, numerous subaccounts, and intricate token systems can be challenging. In response to user feedback, we've now made it easier for you to temporarily suspend subaccount activities.

    Previously, achieving this required setting a completely restricted limit for the subaccount. However, with the latest update, you can now simply toggle the ON/OFF switch for the desired subaccount or token. Notably, disabling this option will recursively affect all nested subaccounts.

    REST API method to disable subaccount:
    PUT /platform/subaccounts/{subaccount-id}
    Payload: {"enabled": false}

    Similarly, to disable a token, use the following REST API call:
    PUT /platform/tokens/{token-id}
    Payload: {"enabled": false}


    2 months later

    We have lifted "experimental" restriction flag from Realm and Identity Provider entities. You can find them in "Access Management" tab in the side menu:

    Realms allow you arrange per-user token management. The most obvious application is to provide multi-user access to your flespi account.

    Identity providers represent configuration of 3rd-party identity management solutions. We support work with OAuth 2.0 and OpenID Connect identity providers. Using identity providers you can link accounts of any organization to flespi realm users.

    In the nearest future we will publish more details on how these features can be used together. If you want to try them now and encounter any questions then don't hesitate to ask in our support chat.

    2 months later

    We have removed a parameter called item_type that was used to denote the type of group members during group creation.

      2 months later

      We've added ability to specify custom subaccount for realm users. It can be done in newly added home property in REST API requests or in Token home field in user management window.

        We've added support of the following templates in realm/user token parameters ACL topics:

        • realm.home.subaccount_id
        • realm.home.limit_id
        • user.subaccount_id
        • user.home.subaccount_id
        • user.home.limit_id
          13 days later

          We've made significant improvements to the grants concept. Previously, each grant was associated with a single subaccount, requiring you to create multiple grants for multiple subaccounts. Now, you can create a single grant and assign multiple subaccounts to it. Consequently, the grant property gid is deprecated and will be removed on August 8th.

          HTTP Methods: POST, DELETE, GET

          Endpoint: platform/grants/{grant-selector}/subaccounts/{subaccounts}

          Additionally, we have added the ability to disable or enable a grant:

          HTTP Method: PUT

          Endpoint: platform/grants/{grant-selector}

          Request body:

          {
            "enabled": false
          }
            15 days later
            5 days later
            1. We have improved the responsiveness of the logging subsystem for platform items such as tokens, grants, and similar entities. Previously, these logs were stored together with REST API logs, which meant that searching for specific grant logs required sifting through a large volume of unrelated log messages. The key goal of this update was to separate the logs of different items into distinct storage locations, significantly reducing response times. Now, platform logs contain REST API logs and customer logs by default. If you want to retrieve logs for other entities, you need to specify which entity, for example:

              curl -X GET 'https://flespi.io/platform/customer/logs'
              {
               "item_type": 33,
               "count": 100,
               "reverse": true
              }

            2. Additionally, we've added support for all platform entities in the recycle bin. Newly created and later deleted items will now appear in the recycle bin. In the coming days, we will update the recycle bin to work with existing items as well.

            3. You can now restore deleted geofences from the recycle bin.

              a month later

              We’ve introduced a limit per URI component. For example, requests with a component length exceeding 64KB will be rejected with a 414 URI Too Long error code.

              A URI consists of components separated by /. For example, the request:

              GET /gw/devices/all

              consists of three components:

              • gw
              • devices
              • all
                25 days later

                We've added support of specifying web origins from which flespi tokens are allowed to be used.

                Note: allowed origins validation works only for the requests performed in the web browsers. Requests sent from backend applications aren't affected by this validation.

                You can set allowed origins in token origins field via API:

                or in Allowed origins field via flespi panel:

                Wildcard characters * and ? are supported in custom origins. Asterisk * matches to the interdomain dot-character . as well.

                It is strongly recommended always to allow access to the flespi origins for your tokens unless you want to block access to the flespi panel and all the flespi public projects. In order to allow flespi origins you need to add
                {"preset":"flespi"} object as one of the origins via API or select all flespi origins via flespi panel (see the screenshots above).

                23 days later
                • Edited

                omol
                We've added support of allowed web origins and allowed IPs in token parameters for realms and users.

                  Write a Reply...