APIs for datastream timestamp

Dear Blynk team,

I am writing to you regarding our project in which we are using the Blynk platform and have subscribed to the Plus plan to meet our project requirements. We are pleased to report that all 13 of our edge devices are seamlessly sending data to the Blynk platform without any issues.

As part of our project, each device is transmitting three parameters to the server, namely the flow rate, total volume, and solenoid status, as shown in the attached image.

We have an additional server hosted on AWS, and we are looking to retrieve the above-mentioned parameters of three specific devices from the Blynk platform using the API links available on the console. While we are able to obtain the values of the DataStreams through these links, we have been unable to find a way to retrieve the instance or timestamp (highlighted in red) at which these values were obtained.

I would appreciate it if you could kindly advise me on how I can obtain the timestamp along with the DataStream value. If there is any documentation or API available to address this, please let me know.

Thank you for your prompt attention to this matter. I look forward to hearing from you soon.

You can use the Export Data API then parse the JSON result for the value and the timestamp…


but you’re limited to doing thusi a maximum of 10 times per day (24 hour period)…



1 Like

Thank you @PeteKnight , for your prompt response. Actually we are going to hit the API request after every 10 mins. So, looks like there is no way we can fetch (timestamp) the data continuously.

I was hoping there must be a way as blynk is quite popular platform.

I guess there are work-arounds. One would be to use the Blynk RTC functionality to get the server time (and adjust it to your TZ if needed) then write this - probably as a string - to a virtual pin when you upload your other data. It can then be retrieved in the same was as any other virtual pin data via the REST API

Alternatively you could install Node-Red on the AWS server and that would be triggered whenever new data was received from the Blynk device and you could timestamp it that way. This is an approach I use with data that comes from an electronic scale that wakes-up around every 4 hours and sends a reading then goes back to sleep. The timestamp tells me the dast time the weight was updated.


Thank you @PeteKnight, for the solutions. The second one looks more promising. We will try second solution and will see whether everything works properly. I will update you on the same.

Thank you once again really appreciate it.

I’d say that the first solution is simpler and easier to implement, but using Node-Red opens-up so many other possibilities that it’s worth exploring.


@Chintoo hello. Currently, There are 2 ways:

  1. Use get device report APi as Pete mentioned
  2. Use webhook, so when the value comes you send it right away to the AWS

We’ll later add an option to get timestamp as well.

Thank you @Dmitriy, for mentioning webhook approach for implementation. We will consider that too. I am not sure whether this approach can trigger the process on the AWS like the way node red dose. I will update whatever solution we implement.

Thank you once again @Dmitriy & @PeteKnight for your support.

Dear @Dmitriy and @PeteKnight,

I hope this message finds you well. I would greatly appreciate your attention regarding an important matter and a potential solution.

As previously mentioned, we are currently dealing with 13 edge IoT devices, each sending 3 parameters (loaded in a single data frame) to Blynk at a frequency of 1 minute. These parameters consist of flow rate, volume of water, and solenoid status. For reference, please consult the attached image.

Following your suggestion, we have successfully utilized webhooks to send data to AWS, as we encountered limitations with HTTP requests. The implementation has been flawless so far.

However, we are now faced with the challenge of retrieving each individual parameter from Blynk on AWS, which requires the creation of separate webhooks. With 13 devices and 3 parameters per device, we find ourselves in need of creating a total of 39 webhooks. Unfortunately, the plan (plus plan) we are currently subscribed to only supports a maximum of 10 webhook creations, as stated in Blynk’s documentation. Despite managing to create 20 webhooks initially, we subsequently received the following notification:

Given that we require 39 webhooks, and our current plan only supports 10, upgrading to the pro plan seems like the logical solution, as it offers 40 webhooks according to the information provided in Blynk’s documentation. However, we have encountered conflicting information on the same page, where it states the webhook limit for the pro plan is 20.

We are currently facing a time-sensitive situation, as we have completed the development of the entire system (hardware, firmware, and cloud), with a project delivery deadline just a few days away. Unfortunately, the webhook limit issue has presented itself as a significant obstacle.

Hence, I kindly request your assistance in providing a potential solution and clarification regarding the webhook limit. If there is any possibility of resolving this issue within our current plan or if upgrading to the pro plan will indeed provide the desired resolution, we would greatly appreciate your guidance.

Thank you in advance for your kind attention to this matter. We eagerly await your response.

Is there any reason why you don’t push the data to the AWS server directly, via an HTTPclient from each device, rather than via the Blynk Webhook?
Presumably this approach would require less reconfiguration of the AWS side.

I’m not clear how using the Blynk Webhook has solved the timestamp issue that you originally flagged-up, but I assume that you’re time stamping the data based on AWS server time when the inbound Webhook data arrives?


Thank you @PeteKnight for your prompt response.

Yes the reason is,

  1. Initially, we considered utilizing Blynk for visualization. However, due to the specific customization requirements of our esteemed client, it is not feasible to achieve those customizations within the Blynk platform. Therefore, we have devised a solution where we retrieve the data from Blynk and transmit it to AWS for further processing.
  2. Unfortunately, we are unable to physically access the deployed devices to modify their firmware. As these devices are programmed to send data exclusively to Blynk, our most practical solution is to extract the data directly from Blynk and subsequently transmit it to AWS. It’s worth noting that during the second phase of this project, we plan to establish a direct data transfer from the devices to AWS.

Regarding your point, @PeteKnight , you are absolutely correct. At present, the timestamp is not a concern. However, we have encountered certain limitations on the webhook associated with the current plan we are utilizing.

That’s the reason we had to reach out to you for a clarity about the plan and offered webhooks.

I wasn’t suggesting that you stop using Blynk, simply that you send the data directly to AWS via an HTTP client on the devices instead of the Blynk Webhook, as well as to Blynk.

You’ve previously said…

I took “edge” to mean that you were using Blynk’s Edgent functionality. If this is the case then the firmware can be updated remotely via Blynk.Air.
If you aren’t using Edgent then what does the “edge” reference relate to?
I think it’s a very risky strategy to have no OTA functionality written-in to the firmware for the devices.

Is this a commercial solution for a business client?


We have not incorporated FOTA feature in our device and neither we have a need to do so. The application is pretty simple. Read the 3 sensor and send the raw data to blynk.

@PeteKnight by edge I mean the device deployed on the field.

Could you please answer this comment, it will help us to make a decision.

Further, while exploring the webhook we noticed that there is a provision for custom JSON response. So, I would like to know if there is any possibility to get multiple DataStream via the JSON response.

@Dmitriy could you please look into it. We are stuck and need further support. Looking forward to your response to make right decision.