--- title: "Direct HTTP Connector" slug: "direct-http-connector" updated: 2026-09-18T17:08:35Z published: 2026-09-18T17:08:36Z canonical: "learn.servitly.com/direct-http-connector" --- > ## Documentation Index > Fetch the complete documentation index at: https://learn.servitly.com/llms.txt > Use this file to discover all available pages before exploring further. # Direct HTTP Connector The HTTP IoT connector service is designed to facilitate communication between IoT-enabled devices and web servers using the HTTP (Hypertext Transfer Protocol) protocol. It acts as a bridge between IoT devices, which typically generate data or perform actions in the physical world, and cloud-based applications, where the data can be processed, analyzed, and transformed into valuable information. In order to use this connector, you have to enable and configure the [HTTP Connector](/docs/http-connector) plugin. For more details about how to configure the HTTP Connector in your DPS, you can refer to these articles: - [IoT Connector](/docs/iot-connector) configured on the whole environment. - [HTTP Connector Mapping](/docs/http-connector-mapping) on a single customer, location, or thing. ## Servitly HTTP Endpoints According to the environment type and cloud provider, you should use the correct HTTP endpoint. #### AWS | Environment Type | Region | URL | Port | | --- | --- | --- | --- | | Sandbox | Europe (Ireland) | https://data-sandbox.servitly.com | 443 | | Production | Europe (Ireland) | https://data.servitly.com | 443 | | Production | Asia/Pacific (Hong Kong) | https://data-ap.servitly.com | 443 | #### AZURE | Environment Type | Region | URL | Port | | --- | --- | --- | --- | | Develop | Europe (Frankfurt) | https://data-az-dev.servitly.com | 443 | | Staging | Europe (Frankfurt) | https://data-az-stag.servitly.com | 443 | | Production | Europe (Frankfurt) | https://data-az.servitly.com | 443 | ## Sending IoT Data To send IoT data, the remote product or the IoT Platform must perform a POST to the following HTTP endpoint: ```http POST https:///data?assetId=&path= Authorization Basic { "ts": 1689064634000, "data": {   "foo": "bar",   "baz": 123 } } ``` Where placeholders are: - *BASE_URL*: the HTTP connector base URL according to the target environment. - *MAPPING_ASSET_ID*: the Asset ID that has been specified in the mapping panel for a thing - *MAPPING_ASSET_PATH*: the message path, which is the concatenation of the path specified in the thing's mapping panel and the path specified in the metric mapping panel ```http / ``` - *AUTHORIZATION*: the basic authorization header that uses the username and password specified on the thing, location, or customer, or inherited from the tenant's default connector. The HTTP Connector uses the [Standard Payload Format](https://learn.servitly.com/v1/docs/standard-payload-format) for incoming messages. Check out the [Send IoT Data](https://learn.servitly.com/apidocs/send-iot-data) reference for more details. ## Sending multiple IoT data points in a single request Optionally, you can also send multiple messages in the same request; this can be done by adding an array in the payload. Each entry in the array must respect the [Standard Payload Format](https://learn.servitly.com/v1/docs/standard-payload-format). ```http POST https:///data?assetId=test-123&path=data Authorization Basic [ {"ts": 1689064634000, "data": {"temperature": 25.5}}, {"ts": 1689066434000, "data": {"temperature": 25.3}}, {"ts": 1689068234000, "data": {"temperature": 25.3}} ] ``` Instead of using JSON format, the HTTP connector also supports sending data in CSV format. ```excel POST https:///data?assetId=&path= Authorization Basic TIMESTAMP,foo,baz 1689064634000,bar,123 1689065756000,xyz,456 ``` The *TIMESTAMP* column must contain UTC values (long) in ascending order. This can help reduce the number of bytes sent over a mobile connection. ## GZIP Request Compression Optionally, to reduce the network traffic, you can send requests using GZIP compression. It is enough to add the following header to the request and compress the payload according to the GZIP protocol. ```http Content-Encoding: application/gzip ``` Note that to have an advantage in using GZIP compression, at least 5 measures must be added in the payload. ## Creating Work Sessions The manual work session creation can also be triggered by the HTTP connector. In cases where the machine has a limited connection (e.g., GSM), it is possible to take advantage of this function to create a work session to be saved directly to the work session history along with the relative measure data, all in one API call. ```http POST https:///data/workSessions?assetId=&path= Authorization Basic payload { "name": "DRILLING", "title": "Pile 001", "description": "Location 1234345, depth: -220m", "csvHeaderRow": 6 } file 10101010101 ``` The request must be a MULTIPART request containing: - *payload*: the JSON document providing the information of the Work Session being created. This includes the *name* of the Work Session Definition along with the *title* and *description* of the Work Session instance. Optionally, you can provide the `csvHeaderRow`, which represents the CSV row index (1-based) where the dataset is located (e.g., *TIMESTAMP,metric-1,metric-2*). - *file*: the CSV file containing all the measure data related to the Work Session. This file can also be a ZIP file containing a single CSV file. ## How to send remote updates HTTP connector communication can also be bidirectional (from cloud to thing), as long as the platform you're using exposes APIs to be invoked to send updates to remote products. In the [HTTP Connector](https://help.servitly.com/hc/en-us/articles/11672982135453) plugin, you can configure the method, URL endpoint, request parameters, and headers. For any update made on the cloud side (command execution, configuration parameter update, firmware update), the Servitly standard JSON message is forwarded to the external endpoint as-is, in addition to the topic field providing the update target (e.g., /). ```http { "topic": "lamp-123/change-status", "data": {   "powerOn": true } } ``` Any payload transformation will have to be handled by the external system, or by interposing an AWS Lambda or Azure function callable via HTTP. ## Request Rate Limits The HTTP connector endpoint can be invoked by using the same rate limit as the publishing rate limit of the thing. Connected products can publish data at a limited rate. For more details, refer to the [Publishing Rate Limit](/docs/publishing-rate-limit) article. For instance, given a limit of *3600 measures/hour* at the single thing level, you have a total of *3600 requests/hour* that can be performed. The rate limiter uses a refill policy allowing you to perform *60 requests/minute*, with an overdraft of 120 requests for a few minutes. The overdraft lets a client make a limited number of calls exceeding the average refill rate before being throttled. In case you get the 429 response, you can inspect the `Retry-After` header to know how much time, in seconds, you have to wait before performing another request. Be careful, as including multiple messages in the same request consumes a separate request for each message.