Can I send a POST to a private server directly from the board?


Hi! I just got my new Dash Pro and I’m wondering if there’s a way to send data from the board directly to my server (Without using the Cloud).


Hi, we don’t have that yet, but it’s on the firmware roadmap. You can send stuff through our cloud webhooks feature pretty easily though. There’s a lot of examples on the forum for that stuff.


Hi Reuben,

Jumping on the train a little late… Any progress on that new functionality? I am putting together a digital twin platform and the ability to stream data from a Hologram connected device to any third-party server is a must-have for me.




I doubt Hologram is working on this anymore and I wouldn’t expect an update to their Dash / Dash Pro code base as those products are discontinued. As Reuben mentioned before, there are a lot of examples of similar functionality online and its not very difficult (I send data directly to 3rd party servers on my custom hardware).

Its pretty difficult for Hologram or anyone to provide a generic “send data to any third-party” as so much depends on what the 3rd party wants.

  • Does it need HTTP headers if so which? any encryption? access keys?
  • Is data encoded (ie base64) or supporting raw binary?
  • Are there special control characters or tags?
  • Is there any expected response from the server or set of responses (Http codes, custom messages, etc)?

All of these question would require different behavior on the senders device in order to interface with the third-party’s system.

To me I think of it more that Hologram provides authentication to use a data pipe pretty much anywhere in the world. The ability to stream data from a … connected device to any third-party server is what YOU will provide with your product, and what makes your product more than a simcard and off the shelf cell module. Hologram gets you 1/2 way there with their cloud messaging / data router but if you want to bypass Hologram’s system that does most of the heavy lifting for you then I would expect you to need to write your own code.


Hi Andrew,

Thanks for taking the time to answer this. I was afraid such an answer would come up and kind of anticipated it. IoT is still a big mess when it comes to communication protocols and I wish more unification would come faster. OPC UA seems to be headed in that direction…

I am willing (forced) to compromise here which is OK. Say I have a basic scenario like:

  • 1 sensor board with N sensors
  • 1 Hologram Nova USB modem + SIM card

What would you recommend as a cellular network API to communicate with a server? I am trying to assess my options and make a decision about which way to go.

Best regards,



I think hologram’s cloud messaging/routing is a good middle ground. ~500 bytes overhead per message to do DNS lookup and TCP handshake + a few characters for the device id and key. At the end of the day its basically just passing JSON over websocket so nothing crazy. Once data is in Hologram’s cloud it is much easier to send it anywhere you want via many protocols and without paying a bandwidth penalty. Basically you can use hologram to convert from unencrypted JSON to PUT to an S3 bucket or send to Amazon’s or Microsoft’s IoT endpoints for you.

It is a great way to get started and build out your full product. Then once you have a working setup and a few prototypes you can decide where further optimization is needed. I think many people (myself included) worry too much about bandwidth / the cellular communication side of their product and not look at other costs / optimizations / issues in the whole product scope (regulatory certification being the elephant everyone ignores for many products).

For example I have a sensor product that goes [Custom Hardware] --> [Hologram Cloud via Embedded API] --> [AWS API Gateway] --> [AWS Lambda Functions] --> [Relational Database]

I am smart with how I compress and buffer data on the sensor board to make up for the message overhead and overall I found no reason for me to invest the time in setting up my own endpoints to receive messages on this.


Hi Andrew,

Thanks again for sharing your perspective, very helpful. I just glanced through the Hologram C++ and Python SDKs and got the essentials I needed. Even though I was reluctant with having an extra intercessor between my devices and my database server, the added benefits Hologram Cloud brings make it a viable middle ground as you said (especially the remote monitoring/control features).

One last question just to confirm my understanding of how it all works. Once I have a Hologram-connected device through a Nova modem, I can freely use any third-party API to stream data to a remote server right? This post seems to confirm it: Sending to Azure.

Thanks again,



Yes a Nova with the default configuration will basically act like a WiFi card telling the OS “I am a network port you can access the internet through me”. So if that is the only network port connected to your device all internet traffic will route through the Nova. This makes it very easy to get started as it (mostly) “just works”.

BUT be careful- as I said above, it acts like a normal network port. If your OS wants to download a 50MB automatic update guess what, that is going over the Nova and you’ll pay $20 for it (50MB * $0.40/MB). A similar thing to be careful about is how your 3rd party server communicates. If it is using a REST API requiring HTTPS you can expect ~5-7kB overhead per message. This is tiny for devices connected through WiFi but can be expensive over cellular. For example if your product is a temperature sensor and you want to send the temperature every 10 minutes, you will have ~22MB/month in overhead alone.

There are ways to inhibit background tasks like the OS updates or other network traffic from using the Nova (I’m not sure how but have seen it on the forum) and carefully selecting which 3rd party server you use and how you send data could help with that overhead. This again is where the using Hologram’s API is helpful, their embedded API has much lower overhead and is designed for cellular connections.

Good luck!