In a script function directory, there should be a companion function.json file that contains the configuration metadata for the function. A function can only have a single trigger binding, and can have multiple input/output bindings. Below are examples for each of the trigger types. The JSON schema is at http://json.schemastore.org/function.

HttpTrigger Example:

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "route": "orders",
      "authLevel": "anonymous"
    },
    {
      "type": "http",
      "direction": "out"
    }
  ]
}

WebHook Example:

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "webHookType": "github"
    },
    {
      "type": "http",
      "direction": "out"
    }
  ]
}

QueueTrigger Example:

{
  "bindings": [
    {
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "samples-workitems"
    }
  ]
}

BlobTrigger Example:

{
  "bindings": [
    {
      "type": "blobTrigger",
      "direction": "in",
      "path": "samples-workitems"
    }
  ]
}

TimerTrigger Example:

{
  "bindings": [
    {
      "type": "timerTrigger",
      "direction": "in",
      "schedule": "*/15 * * * * *"
    }
  ]
}

ServiceBusTrigger Example (Queue):

{
  "bindings": [
    {
      "type": "serviceBusTrigger",
      "direction": "in",
      "queueName": "testqueue"
    }
  ]
}

ServiceBusTrigger Example (Topic):

{
  "bindings": [
    {
      "type": "serviceBusTrigger",
      "direction": "in",
      "topicName": "testtopic",
      "subscriptionName": "testsubscription"
    }
  ]
}

ManualTrigger Example (Can only be run by invoking via WebHost admin API):

{
  "bindings": [
    {
      "type": "manualTrigger",
      "direction": "in"
    }
  ]
}

Function bindings can get pretty sophisticated. In addition to trigger input bindings, they can also declare non-trigger input bindings which can be used to read objects from storage and make them available to script. They can also declare output bindings that can write result objects to storage.

Here's a canonical example for a function that receives a queue message, reads an input blob, processes that blob and writes the result to another blob:

{
  "bindings": [
    {
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "image-resize"
    },
    {
      "type": "blob",
      "name": "original",
      "direction": "in",
      "path": "images-original/{name}"
    },
    {
      "type": "blob",
      "name": "resized",
      "direction": "out",
      "path": "images-resized/{name}"
    }
  ]
}

For all bindings, the type value must be one of the supported binding types (e.g. "queue", "queueTrigger", "blob", "blobTrigger", "table", etc.). The name value defines the identifier that the script will use to write to the binding. The direction must be one of the supported binding directions ("in", "out" or "inout"), The remaining properties are binding type specific. For a blob binding there is a path property, for a queue binding a queueName property, etc.

In addition to binding level config, there is also function level config that can be specified. For example, here is a timer function that uses the disabled and scriptFile properties:

{
  "disabled": true,
  "scriptFile": "test.js",
  "bindings": [
    {
      "type": "timerTrigger",
      "direction": "in",
      "schedule": "0 0 */5 * * *"
    }
  ]
}

When marked as disabled, a function will not run. A timer function will not fire, a queue function will not trigger on new queue messages, etc. When scriptFile is specified a function uses that file as the function entry point

Learn

Azure Functions Basics

Advanced Concepts

Dotnet Functions

Java Functions

Node.js Functions

Python Functions

Host API's

Bindings

V2 Runtime

Contribute

Functions host

Language workers

Get Help

Other