Create HTTP-Triggered Azure Functions (2026)

Azure Functions can be triggered by HTTP requests, allowing you to build serverless APIs and webhooks.

Let’s see one in action. Imagine you have a simple HTTP-triggered function that doubles a number passed in the query string.

// Function.json
{
  "scriptFile": "index.js",
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ]
}

// Index.js
module.exports = async function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');

    const numberToDouble = (req.query.number || (req.body && req.body.number));

    if (numberToDouble) {
        const doubledNumber = parseInt(numberToDouble) * 2;
        context.res = {
            // status: 200, /* Defaults to 200 */
            body: `The doubled number is: ${doubledNumber}`
        };
    } else {
        context.res = {
            status: 400,
            body: "Please pass a number on the query string or in the request body"
        };
    }
};

If you deploy this function and send a GET request to its URL with ?number=5 in the query string, the response body will be "The doubled number is: 10". A POST request with a JSON body {"number": 7} would yield "The doubled number is: 14".

This setup solves the problem of needing to provision and manage servers for simple web services. You write your code, and Azure handles the infrastructure, scaling it up or down automatically based on demand. The httpTrigger binding tells Azure Functions to listen for incoming HTTP requests. The methods array specifies which HTTP verbs the function will respond to. The authLevel property controls how the function is secured; function means you need a function-specific API key. The http output binding is what allows the function to send a response back to the caller.

The core of the mental model is that your function code runs in response to an event – in this case, an HTTP request. Azure Functions is an event-driven compute service. When a request arrives at the function’s endpoint, the Azure Functions host invokes your code. The req object contains all the details of the incoming HTTP request, including headers, query parameters, and the request body. Your function then processes this information and sets the context.res object to define the HTTP response that will be sent back to the client.

When you specify methods: ["get", "post"], your function is configured to handle both GET and POST requests. For GET requests, parameters are typically found in req.query. For POST requests, they are usually in req.body, especially if the Content-Type is application/json. The || operator in (req.query.number || (req.body && req.body.number)) is a common pattern to check for the parameter in both locations.

A common misconception is that HTTP-triggered functions are just simple web servers. While they can be used for that, their power lies in their integration with other Azure services. For example, an HTTP-triggered function could be the entry point for a workflow that writes data to a Cosmos DB, sends a message to a Service Bus queue, or triggers another Azure Function. The HTTP trigger is just the start of a potential chain reaction, not necessarily the end of the interaction.

The next concept to explore is handling different response types and status codes, as well as more advanced routing within HTTP-triggered functions.