Azure HTTP Triggers

An example integration where a Data Connector forwards events to an Azure HTTP Trigger.


This example uses a Data Connector to forward the events of all devices in a project to an Azure HTTP trigger. When receiving the HTTPS POST request, our trigger will verify both the origin and content of the request using a Signature Secret, then decode the data.


The following points are assumed.

Azure Function

Depending on the runtime, parts of creating the HTTP Trigger must be done in a local environment on your machine. Ensure you have a working runtime environment for development using either the command line or Visual Studio Code.

Create a Function App

Function Apps combine several functions into a single unit for easier management and can be created in the Azure Portal by following this guide. Create a new Function App with the following configurations.

  • Runtime Stack: Python

  • Version: 3.11

  • Operating System: Linux

Click Review + create, then Create and wait for deployment. Once deployed, Go to resource.

Edit Application Settings

We will verify the incoming POST request by a signature secret, as explained in the Data Connector Advanced Configurations. In your new Function App, add a secret to your App environment by adding a new Application Setting, as explained in this guide.


  • Value: A unique password. We will use it later, so write it down.

Create an HTTP Trigger Function

Once the Function App is deployed, a new HTTP trigger function can be created. Azure has guides on creating and editing functions. Follow either.

By following one of the guides, create a new HTTP Trigger with the following configurations.

  • Authorization level: Anonymous.

Afterward, your project structure should end up looking something like this.

├── yourNewFunction
│   ├── function.json
│   └──
├── host.json
├── local.settings.json
└── requirements.txt

Modify the HTTP Trigger

Once the function has been created, the desired behavior can be programmed. The following code snippet implements a simple HTTP trigger that listens for POST requests, then validates the content and origin using the Signature Secret and Checksum verification.

In your HTTP Trigger function directory, edit the file The implementation is explained in detail on the Data Connector Receiving Events page.
import os
import hashlib

import azure.functions as func
import jwt

# Fetch environment variables.

def verify_request(body, token):
    # Decode the token using signature secret.
        payload = jwt.decode(token, SIGNATURE_SECRET, algorithms=["HS256"])
    except Exception as err:
        return False

    # Verify the request body checksum.
    m = hashlib.sha1()
    checksum = m.digest().hex()
    if payload["checksum"] != checksum:
        print('Checksum Mismatch')
        return False

    return True

def main(req: func.HttpRequest) -> func.HttpResponse:
    # Extract necessary request information.
    body = req.get_body()
    token = req.headers['x-dt-signature']

    # Validate request origin and content integrity.
    if not verify_request(body, token):
        return func.HttpResponse('Bad request', status_code=400)

    # Further processing goes here.

    return func.HttpResponse("OK", status_code=200)

Dependency Management

Dependencies must be specified and included for your HTTP Trigger to run in the cloud.

As explained here, edit requirements.txt to tell Azure which dependencies to install.



Your function should now be ready for deployment. It is considered good practice to test- and experiment with your function locally, which you can read how-to here. The following command will deploy your function to the Function App created in the beginning.

func azure functionapp publish <APP_NAME>

Once the function is deployed, the Invoke URL is displayed in the output. Copy and save it as we will need it when creating our Data Connector.

Deployment successful.
Remote build succeeded!
Syncing triggers...
Functions in msdocs-azurefunctions-qs:
    HttpExample - [httpTrigger]
THIS->  Invoke url:

Data Connector

To continuously forward the data to our newly created Cloud Function, a Data Connector with almost all default settings is sufficient. If you are unfamiliar with how Data Connectors can be created, refer to our Creating a Data Connector guide. The following configurations should be set.

  • Endpoint URL: The Invoke URL found in the previous step.

  • Signature Secret: The value of DT_SIGNATURE_SECRET environment variable set earlier.

Depending on your integration, it can also be smart to disable the event types you are not interested in. For instance, the NetworkStatusEvent is sent every Periodic Heartbeat and will by default be forwarded by the Data Connector if not explicitly unticked.

Test the Integration

If the integration was correctly implemented, the Success counter for your Data Connector should increment for each new event forwarded. This happens each Periodic Heartbeat or by touching a sensor to force a new event.

If instead the Error counter increments, a response containing a non-200 status code is returned.

  • Verify that the Data Connector endpoint URL is correct.

  • Azure provides a host of tools that can be used to monitor Azure Functions. Check the logs for any tracebacks that could explain why an error is returned.

Next steps

Your sensor data is now in the Azure environment, and you can start using it in their various services. Fortunately, Azure has some well-documented guides to get you started.

PostgreSQL Database

A database should be tailored to each specific use case. However, if you're uncertain, PostgreSQL (Postgres) is a good place to get started. The following guides will show you how to create a new Postgres database, then connect your HTTP Trigger to execute queries.

Last updated