SignalR Service trigger binding for Azure Functions
Use the SignalR trigger binding to respond to messages sent from Azure SignalR Service. When function is triggered, messages passed to the function is parsed as a json object.
In SignalR Service serverless mode, SignalR Service uses the Upstream feature to send messages from client to Function App. And Function App uses SignalR Service trigger binding to handle these messages. The general architecture is shown below:
For information on setup and configuration details, see the overview.
Example
A C# function can be created by using one of the following C# modes:
- In-process class library: Compiled C# function that runs in the same process as the Functions runtime.
- Isolated worker process class library: Compiled C# function that runs in a worker process that's isolated from the runtime. Isolated worker process is required to support C# functions running on LTS and non-LTS versions .NET and the .NET Framework.
- C# script: Used primarily when you create C# functions in the Azure portal.
Important
Support will end for the in-process model on November 10, 2026. We highly recommend that you migrate your apps to the isolated worker model for full support.
The following sample shows a C# function that receives a message event from clients and logs the message content.
// Copyright (c) .NET Foundation. All rights reserved.
// Licensed under the MIT License. See License.txt in the project root for license information.
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
namespace Extensions.SignalR
{
public static class SignalRTriggerFunctions
{
// <snippet_on_connected>
[Function(nameof(OnConnected))]
public static void OnConnected(
[SignalRTrigger("chat", "connections", "connected", ConnectionStringSetting = "SignalRConnection")]
SignalRInvocationContext invocationContext, FunctionContext functionContext)
{
var logger = functionContext.GetLogger(nameof(OnConnected));
logger.LogInformation("Connection {connectionId} is connected", invocationContext.ConnectionId);
}
// </snippet_on_connected>
// <snippet_on_disconnected>
[Function(nameof(OnDisconnected))]
public static void OnDisconnected(
[SignalRTrigger("chat", "connections", "disconnected", ConnectionStringSetting = "SignalRConnection")]
SignalRInvocationContext invocationContext, FunctionContext functionContext)
{
var logger = functionContext.GetLogger(nameof(OnDisconnected));
logger.LogInformation("Connection {connectionId} is disconnected. Error: {error}", invocationContext.ConnectionId, invocationContext.Error);
}
// </snippet_on_disconnected>
// <snippet_on_message>
[Function(nameof(OnClientMessage))]
public static void OnClientMessage(
[SignalRTrigger("Hub", "messages", "sendMessage", "content", ConnectionStringSetting = "SignalRConnection")]
SignalRInvocationContext invocationContext, string content, FunctionContext functionContext)
{
var logger = functionContext.GetLogger(nameof(OnClientMessage));
logger.LogInformation("Connection {connectionId} sent a message. Message content: {content}", invocationContext.ConnectionId, content);
}
// </snippet_on_message>
}
}
Important
Class based model of SignalR Service bindings in C# isolated worker doesn't optimize how you write SignalR triggers due to the limitation of C# worker model. For more information about class based model, see Class based model.
SignalR trigger isn't currently supported for Java.
Here's binding data in the function.json file:
{
"type": "signalRTrigger",
"name": "invocation",
"hubName": "hubName1",
"category": "messages",
"event": "SendMessage",
"parameterNames": [
"message"
],
"direction": "in"
}
app.generic("function1",
{
trigger: { "type": "signalRTrigger", "name": "invocation", "direction": "in", "hubName": "hubName1", "event": "SendMessage", "category": "messages" },
handler: (triggerInput, context) => {
context.log(`Receive ${context.Arguments[0]} from ${triggerInput.ConnectionId}.`)
}
})
Complete PowerShell examples are pending.
Here's the Python code:
import logging
import json
import azure.functions as func
def main(invocation) -> None:
invocation_json = json.loads(invocation)
logging.info("Receive {0} from {1}".format(invocation_json['Arguments'][0], invocation_json['ConnectionId']))
Attributes
Both in-process and isolated worker process C# libraries use the SignalRTrigger
attribute to define the function. C# script instead uses a function.json configuration file.
The following table explains the properties of the SignalRTrigger
attribute.
Attribute property | Description |
---|---|
HubName | This value must be set to the name of the SignalR hub for the function to be triggered. |
Category | This value must be set as the category of messages for the function to be triggered. The category can be one of the following values:
|
Event | This value must be set as the event of messages for the function to be triggered. For messages category, event is the target in invocation message that clients send. For connections category, only connected and disconnected is used. |
ParameterNames | (Optional) A list of names that binds to the parameters. |
ConnectionStringSetting | The name of the app setting that contains the SignalR Service connection string, which defaults to AzureSignalRConnectionString . |
Annotations
There isn't currently a supported Java annotation for a SignalR trigger.
Configuration
The following table explains the binding configuration properties that you set in the function.json file.
function.json property | Description |
---|---|
type | Must be set to SignalRTrigger . |
direction | Must be set to in . |
name | Variable name used in function code for trigger invocation context object. |
hubName | This value must be set to the name of the SignalR hub for the function to be triggered. |
category | This value must be set as the category of messages for the function to be triggered. The category can be one of the following values:
|
event | This value must be set as the event of messages for the function to be triggered. For messages category, event is the target in invocation message that clients send. For connections category, only connected and disconnected is used. |
parameterNames | (Optional) A list of names that binds to the parameters. |
connectionStringSetting | The name of the app setting that contains the SignalR Service connection string, which defaults to AzureSignalRConnectionString . |
See the Example section for complete examples.
Usage
Payloads
The trigger input type is declared as either InvocationContext
or a custom type. If you choose InvocationContext
, you get full access to the request content. For a custom type, the runtime tries to parse the JSON request body to set the object properties.
InvocationContext
InvocationContext
contains all the content in the message sent from a SignalR service, which includes the following properties:
Property | Description |
---|---|
Arguments | Available for messages category. Contains arguments in invocation message |
Error | Available for disconnected event. It can be Empty if the connection closed with no error, or it contains the error messages. |
Hub | The hub name that the message belongs to. |
Category | The category of the message. |
Event | The event of the message. |
ConnectionId | The connection ID of the client that sends the message. |
UserId | The user identity of the client that sends the message. |
Headers | The headers of the request. |
Query | The query of the request when clients connect to the service. |
Claims | The claims of the client. |
Using ParameterNames
The property ParameterNames
in SignalRTrigger
lets you bind arguments of invocation messages to the parameters of functions. You can use the name you defined as part of binding expressions in other binding or as parameters in your code. That gives you a more convenient way to access arguments of InvocationContext
.
Say you have a JavaScript SignalR client trying to invoke method broadcast
in Azure Function with two arguments message1
, message2
.
await connection.invoke("broadcast", message1, message2);
After you set parameterNames
, the names you defined correspond to the arguments sent on the client side.
[SignalRTrigger(parameterNames: new string[] {"arg1, arg2"})]
Then, the arg1
contains the content of message1
, and arg2
contains the content of message2
.
ParameterNames
considerations
For the parameter binding, the order matters. If you're using ParameterNames
, the order in ParameterNames
matches the order of the arguments you invoke in the client. If you're using attribute [SignalRParameter]
in C#, the order of arguments in Azure Function methods matches the order of arguments in clients.
ParameterNames
and attribute [SignalRParameter]
cannot be used at the same time, or you'll get an exception.
SignalR Service integration
SignalR Service needs a URL to access Function App when you're using SignalR Service trigger binding. The URL should be configured in Upstream Settings on the SignalR Service side.
When using SignalR Service trigger, the URL can be simple and formatted as follows:
<Function_App_URL>/runtime/webhooks/signalr?code=<API_KEY>
The Function_App_URL
can be found on Function App's Overview page and the API_KEY
is generated by Azure Function. You can get the API_KEY
from signalr_extension
in the App keys blade of Function App.
If you want to use more than one Function App together with one SignalR Service, upstream can also support complex routing rules. Find more details at Upstream settings.
Step-by-step sample
You can follow the sample in GitHub to deploy a chat room on Function App with SignalR Service trigger binding and upstream feature: Bidirectional chat room sample