Azure Functions Bindings
Bindings are a way to connect an Azure Function to other services without writing connection code. Instead of manually writing code to open a database connection, read a file, or send a message to a queue, bindings handle all of that automatically.
Think of a binding as a ready-made pipe that connects the function to another service. Data flows in through input bindings and flows out through output bindings.
The Binding Concept – Analogy
┌──────────────────────────────────────────────────────────────┐ │ BINDING ANALOGY │ │ │ │ Without Bindings: │ │ Function → Write 30 lines of code → Connect to Storage │ │ → Authenticate → Read file → Handle errors │ │ │ │ With Bindings: │ │ function.json → "Read from blob storage" │ │ Azure → Connects, authenticates, reads, delivers │ │ Function → Receives ready data as a parameter │ │ │ │ Binding = Pre-built connector. Zero manual plumbing. │ └──────────────────────────────────────────────────────────────┘
Types of Bindings
| Type | Direction | What It Does |
|---|---|---|
| Trigger Binding | IN (starts function) | Fires the function when the event occurs |
| Input Binding | IN (reads data) | Reads data from a service while the function runs |
| Output Binding | OUT (writes data) | Writes data to a service when the function finishes |
Binding Data Flow Diagram
┌──────────────────────────────────────────────────────────────┐ │ BINDING DATA FLOW │ │ │ │ ┌────────────────┐ │ │ │ HTTP Request │──── Trigger Binding ────►┐ │ │ └────────────────┘ │ │ │ │ │ │ ┌────────────────┐ ▼ │ │ │ Cosmos DB │──── Input Binding ────► FUNCTION │ │ │ (read user) │ │ │ │ └────────────────┘ │ │ │ │ │ │ ┌────────────────┐ │ │ │ │ Storage Queue │◄─── Output Binding ─────┘ │ │ │ (send message)│ │ │ └────────────────┘ │ │ │ │ One function. One trigger. One input. One output. │ │ All configured in function.json, no manual connection code. │ └──────────────────────────────────────────────────────────────┘
Common Binding Types
| Service | Can Be Trigger | Can Be Input | Can Be Output |
|---|---|---|---|
| HTTP | Yes | No | Yes |
| Azure Blob Storage | Yes | Yes | Yes |
| Azure Queue Storage | Yes | No | Yes |
| Azure Cosmos DB | Yes | Yes | Yes |
| Azure Service Bus | Yes | No | Yes |
| Timer | Yes | No | No |
| Azure Table Storage | No | Yes | Yes |
| SendGrid (Email) | No | No | Yes |
| Twilio (SMS) | No | No | Yes |
| SignalR | No | Yes | Yes |
Example 1 – HTTP Trigger + Queue Output Binding
This function receives an HTTP request and puts a message on a storage queue — no queue SDK code required.
function.json
{
"bindings": [
{
"type": "httpTrigger",
"direction": "in",
"name": "req",
"authLevel": "anonymous",
"methods": ["post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
},
{
"type": "queue",
"direction": "out",
"name": "outputQueueItem",
"queueName": "orders",
"connection": "AzureWebJobsStorage"
}
]
}
index.js
module.exports = async function (context, req) {
const order = req.body;
// Azure automatically sends this to the "orders" queue
context.bindings.outputQueueItem = JSON.stringify(order);
context.res = {
status: 200,
body: "Order placed successfully!"
};
};
What Happened
| Step | What Happened |
|---|---|
| 1 | HTTP POST request arrived with order data in the body |
| 2 | Function read the body from req.body |
| 3 | Function assigned the data to context.bindings.outputQueueItem |
| 4 | Azure automatically placed the message on the "orders" queue |
| 5 | Function returned HTTP 200 response |
Example 2 – HTTP Trigger + Cosmos DB Input Binding
This function receives an HTTP request with a user ID, reads the user record from Cosmos DB using an input binding, and returns the user data.
function.json
{
"bindings": [
{
"type": "httpTrigger",
"direction": "in",
"name": "req",
"authLevel": "anonymous",
"methods": ["get"]
},
{
"type": "http",
"direction": "out",
"name": "res"
},
{
"type": "cosmosDB",
"direction": "in",
"name": "userRecord",
"databaseName": "MyDatabase",
"collectionName": "Users",
"id": "{Query.userId}",
"connectionStringSetting": "CosmosDBConnection"
}
]
}
index.js
module.exports = async function (context, req, userRecord) {
if (!userRecord) {
context.res = { status: 404, body: "User not found" };
return;
}
context.res = {
status: 200,
body: userRecord
};
};
Notice that userRecord arrives as a ready-to-use JavaScript object. No database SDK code, no connection string handling, no query writing — Azure's binding did all of that automatically.
The direction Property
┌──────────────────────────────────────────┐ │ BINDING DIRECTION │ │ │ │ direction: "in" │ │ └── Data flows INTO the function │ │ └── Used for: trigger, input binding │ │ │ │ direction: "out" │ │ └── Data flows OUT of the function │ │ └── Used for: output binding │ └──────────────────────────────────────────┘
Bindings vs Manual Code
| Approach | Lines of Code | Error Handling | Maintenance |
|---|---|---|---|
| Manual Queue SDK | ~15–20 lines | Manual | SDK version updates needed |
| Output Binding | 1 line | Azure handles it | Azure manages the SDK |
Key Points
- Bindings eliminate boilerplate connection code
- A function can have multiple input and output bindings
- A function can have only one trigger
- Bindings are declared in
function.jsonand accessed viacontext.bindings - Connection strings for bindings are stored in
local.settings.jsonlocally and in App Settings in Azure
