# Device connection and status **URL:** \ **Category:** Forum\ **Tags:** device-connectivity, cumulocity\ **Created:** [August 1, 2023, 6:52am UTC](https://community.cumulocity.com/t/device-connection-and-status/7549 "2023-08-01T06:52:37Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Reuben\_Miller2](https://dub1.discourse-cdn.com/flex005/user_avatar/community.cumulocity.com/reuben_miller2/32/317_2.png) [@Reuben\_Miller2](https://community.cumulocity.com/u/Reuben_Miller2)\ **Post date:** [August 1, 2023, 7:20am UTC](https://community.cumulocity.com/t/device-connection-and-status/7549/2 "2023-08-01T07:20:27Z")
One of the reasons could be because the client which is generating the data has the HTTP header set `X-Cumulocity-Application-Key` (which is the default if you’re using the Cumulocity IoT Java or Angular SDKs). There is a [Concept](https://cumulocity.com/guides/microservice-sdk/concept/) page which mentions some details about this, below is a snippet from the references docs. > Furthermore, most of the HTTP requests which are sent by microservices must contain the HTTP header `X-Cumulocity-Application-Key` . The header indicates that an action is performed by an application. When the header is missing Cumulocity IoT assumes that the HTTP request is originated by an IoT device. Therefore, a request without `X-Cumulocity-Application-Key` affects for example, the device availability state, or the billing data. Long story short, if you remove the `X-Cumulocity-Application-Key` HTTP header from the REST API calls which are generating data which should count towards the device monitoring (though inventory updates don’t generally affect it, except for an empty PUT). **Note** I inferred that you are using a microservice to generate the data has the screenshot showed that the device owner follows the pattern `service_xxxx`. --- _[View the full topic](https://community.cumulocity.com/t/device-connection-and-status/7549)._