In order to optimize logs storage we will remove some parameters from a generic log message. Parameters list are below:
event_origin - parameters origin_id and origin_type allow you to restore it
event_text - textual representation of event_code

Changes will be applied at march 30th.

adsa installed today. The internal log subsystem has also been reorganized to reduce the log selection delay.
If you notice incorrect log behavior, please contact us.

We introduced slight non-blocking change to the tokens configuration.

First of all we added created field which shows their creation time. For all existing tokens for which we do not know the time they were created, we specified last accessed time as creation time.

Second - we do not update expire field anymore automatically for tokens with ttl specified. We just softly calculate validity state for the token by using both explicitly specified expire field and dynamically calculated created/accessed + ttl fields.

For more information about time control please refer to the knowledge base.

omol We are deferring the final update to 12 October 2020

Some REST API methods like PUT gw/devices or GET gw/devices/messages, etc., multiplied the API call count by the number of items affected. Thus, we tried to protect the platform from overload.
But this method was not obvious to platform consumers, so we decided to simplify it - now any REST API call increases the total counter by 1.

You can now set "x-flespi-app" header in all your REST API requests to specify any application details you may need. The content of this header (truncated to 64 characters length) is saved in corresponding platform logs messages.

A new feature has been added to the Subaccount's Limits API. You can specify how long the item will be blocked.

We implemented REST API to access billing information: https://flespi.io/docs/#/platform/billing
Now via API it is possible to:

• access to current commercial client billing configuration;
• change email recipients for billing messages;
• activate/deactivate auto charging using default Credit Card and control data stored in the payment provider (Stripe);
• download all issued invoices in PDF and JSON (meta-data) formats;

We will soon provide UI in https://flespi.io panel that utilizes that API. This announcement is for such users that want to automate flespi invoicing process non-standard way.

shal

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

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

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

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.

We moved webhooks from experimental to production-grade platform entity and applied initially published restrictions.

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.

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
      }
    }
  ]
}

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}