|
| 1 | +--- |
| 2 | +title: HTTP triggers in Azure SRE Agent |
| 3 | +description: Learn how HTTP triggers in Azure SRE Agent let you invoke agent actions from CI/CD pipelines, alerting tools, and any HTTP client. |
| 4 | +author: craigshoemaker |
| 5 | +ms.author: cshoe |
| 6 | +ms.reviewer: cshoe |
| 7 | +ms.date: 03/25/2026 |
| 8 | +ms.topic: concept-article |
| 9 | +ms.service: azure-sre-agent |
| 10 | +ai-usage: ai-assisted |
| 11 | +--- |
| 12 | + |
| 13 | +# HTTP triggers in Azure SRE Agent |
| 14 | + |
| 15 | +HTTP triggers in Azure SRE Agent are webhook endpoints that external systems use to invoke your agent on demand. When a CI/CD pipeline fails, an alerting tool detects an anomaly, or any HTTP client sends a POST request, the agent receives the event context and starts working immediately. |
| 16 | + |
| 17 | +## How HTTP triggers work |
| 18 | + |
| 19 | +Each trigger is a named webhook endpoint on your agent with a unique URL. When an external system calls that URL through an HTTP POST, the agent executes the trigger's configured prompt. If the request includes a JSON body, the data becomes part of the agent's prompt so the agent has full context about the event. |
| 20 | + |
| 21 | +| Concept | Description | |
| 22 | +|---|---| |
| 23 | +| **Trigger** | A named endpoint with a prompt, an assigned agent (default or subagent), and an autonomy level (autonomous or review). | |
| 24 | +| **Trigger URL** | The unique webhook URL generated when you create a trigger. External tools call this URL. | |
| 25 | +| **JSON context** | Optional JSON body sent with the POST request. The data becomes part of the agent's prompt. | |
| 26 | +| **Execution history** | Every invocation is logged with a timestamp, thread link, and success or failure status. | |
| 27 | +| **Enable/disable** | Toggle triggers on or off without deleting them. Disabled triggers return 404. | |
| 28 | + |
| 29 | +## Invoke a trigger |
| 30 | + |
| 31 | +Call the trigger URL with an HTTP POST request: |
| 32 | + |
| 33 | +```bash |
| 34 | +curl -X POST \ |
| 35 | + https://your-agent.sre.azure.com/api/v1/httptriggers/trigger/<TRIGGER_ID> \ |
| 36 | + -H "Authorization: Bearer <ARM_TOKEN>" \ |
| 37 | + -H "Content-Type: application/json" \ |
| 38 | + -d '{ |
| 39 | + "source": "datadog", |
| 40 | + "alert_title": "High error rate on checkout-api", |
| 41 | + "severity": "critical", |
| 42 | + "service": "checkout-api", |
| 43 | + "region": "eastus2", |
| 44 | + "metric": "error_rate", |
| 45 | + "value": "8.2%", |
| 46 | + "threshold": "5%" |
| 47 | + }' |
| 48 | +``` |
| 49 | + |
| 50 | +The following table describes each part of the request: |
| 51 | + |
| 52 | +| Part | Description | |
| 53 | +|---|---| |
| 54 | +| **URL** | The trigger's unique webhook endpoint. Find it in the trigger detail view under **Trigger URL**. | |
| 55 | +| **Authorization** | An Azure ARM Bearer token. See [Authentication](#authentication). | |
| 56 | +| **Content-Type** | Must be `application/json` if you're sending a JSON body. | |
| 57 | +| **JSON body** (optional) | Any JSON data you want the agent to receive as part of its prompt. | |
| 58 | + |
| 59 | +The JSON body is optional. If you call the trigger without a body, the agent runs with just the trigger's configured prompt. With a body, the agent sees both the prompt and the data you sent. |
| 60 | + |
| 61 | +The trigger returns HTTP 202 (Accepted) immediately. The agent processes the request asynchronously. |
| 62 | + |
| 63 | +## Authentication |
| 64 | + |
| 65 | +The trigger endpoint requires an Azure ARM Bearer token in the `Authorization: Bearer <TOKEN>` header. The caller needs `Microsoft.App/agents/threads/write` permission on the agent resource. |
| 66 | + |
| 67 | +The following table describes how to obtain a token: |
| 68 | + |
| 69 | +| Method | Best for | Details | |
| 70 | +|---|---|---| |
| 71 | +| [Service principal](/entra/identity-platform/howto-create-service-principal-portal) | CI/CD pipelines, automated systems | Create an app registration, assign the role on the agent resource, and use client credentials flow to get a token. | |
| 72 | +| [Managed identity](/entra/identity/managed-identities-azure-resources/overview) | Azure-hosted services (Azure Functions, VMs, Container Apps) | No secrets to manage. The Azure resource authenticates automatically. | |
| 73 | +| Azure CLI | Testing and development | Run `az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsv`. | |
| 74 | + |
| 75 | +### Connect external tools that don't support Azure auth |
| 76 | + |
| 77 | +Tools like Datadog, Dynatrace, Jira, and Splunk send webhooks with their own auth formats, not Azure ARM tokens. To bridge the gap, use one of the following intermediaries: |
| 78 | + |
| 79 | +| Intermediary | How it works | |
| 80 | +|---|---| |
| 81 | +| [Azure Function](/azure/azure-functions/functions-bindings-http-webhook-trigger) | Receives the webhook, acquires an ARM token using its managed identity, and forwards the call to the trigger URL. | |
| 82 | +| [Logic App](/azure/logic-apps/logic-apps-overview) | No-code workflow that receives webhooks from any source and calls Azure APIs with built-in ARM authentication. | |
| 83 | +| [Azure API Management](/azure/api-management/authentication-authorization-overview) | Sits in front of the trigger URL and handles token validation and transformation via policies. | |
| 84 | + |
| 85 | +## Use cases |
| 86 | + |
| 87 | +The following examples show common scenarios for HTTP triggers. |
| 88 | + |
| 89 | +### CI/CD pipeline integration |
| 90 | + |
| 91 | +When a deployment pipeline fails, invoke the agent to analyze the failure: |
| 92 | + |
| 93 | +```bash |
| 94 | +# In your pipeline's failure handler |
| 95 | +curl -X POST "$AGENT_TRIGGER_URL" \ |
| 96 | + -H "Authorization: Bearer $ARM_TOKEN" \ |
| 97 | + -H "Content-Type: application/json" \ |
| 98 | + -d "{\"pipeline\": \"$PIPELINE_NAME\", \"run_id\": \"$RUN_ID\", \"error\": \"$ERROR_MESSAGE\"}" |
| 99 | +``` |
| 100 | + |
| 101 | +### Alert-driven investigation |
| 102 | + |
| 103 | +Connect your alerting system to trigger automated investigation when critical alerts fire. The following example shows a sample JSON payload: |
| 104 | + |
| 105 | +```json |
| 106 | +{ |
| 107 | + "alert_name": "Error rate > 5%", |
| 108 | + "severity": "P1", |
| 109 | + "service": "checkout-api", |
| 110 | + "region": "eastus2", |
| 111 | + "start_time": "2026-03-13T10:15:00Z" |
| 112 | +} |
| 113 | +``` |
| 114 | + |
| 115 | +### Deployment compliance checks |
| 116 | + |
| 117 | +After a deployment completes, trigger a compliance review: |
| 118 | + |
| 119 | +```bash |
| 120 | +curl -X POST "$AGENT_TRIGGER_URL" \ |
| 121 | + -H "Authorization: Bearer $ARM_TOKEN" \ |
| 122 | + -d '{"deployment_id": "deploy-456", "environment": "production", "changes": ["config update", "image bump"]}' |
| 123 | +``` |
| 124 | + |
| 125 | +## Scheduled tasks vs. HTTP triggers |
| 126 | + |
| 127 | +The following table compares scheduled tasks with HTTP triggers: |
| 128 | + |
| 129 | +| Scheduled tasks | HTTP triggers | |
| 130 | +|---|---| |
| 131 | +| Time-based (cron schedule) | Event-driven (on-demand) | |
| 132 | +| Runs whether or not something happened | Runs only when called | |
| 133 | +| No external input per execution | Payload data included in each invocation | |
| 134 | +| Best for recurring checks | Best for event-driven reactions | |
| 135 | + |
| 136 | +Use both together. Scheduled tasks handle proactive monitoring, and HTTP triggers handle reactive event handling. |
| 137 | + |
| 138 | +## API reference |
| 139 | + |
| 140 | +The following table lists the available HTTP trigger endpoints: |
| 141 | + |
| 142 | +| Endpoint | Method | Description | |
| 143 | +|---|---|---| |
| 144 | +| `/api/v1/httptriggers` | GET | List all triggers | |
| 145 | +| `/api/v1/httptriggers/create` | POST | Create a new trigger | |
| 146 | +| `/api/v1/httptriggers/{id}` | GET | Get trigger details | |
| 147 | +| `/api/v1/httptriggers/{id}` | PUT | Update trigger properties | |
| 148 | +| `/api/v1/httptriggers/{id}` | DELETE | Delete a trigger | |
| 149 | +| `/api/v1/httptriggers/{id}/enable` | POST | Enable a trigger | |
| 150 | +| `/api/v1/httptriggers/{id}/disable` | POST | Disable a trigger | |
| 151 | +| `/api/v1/httptriggers/{id}/execute` | POST | Run trigger manually | |
| 152 | +| `/api/v1/httptriggers/{id}/executions` | GET | Get execution history | |
| 153 | +| `/api/v1/httptriggers/trigger/{id}` | POST | External webhook endpoint | |
| 154 | + |
| 155 | +## Troubleshooting |
| 156 | + |
| 157 | +**Trigger returns 404** |
| 158 | + |
| 159 | +- Verify the trigger is **enabled**. Disabled triggers return 404. |
| 160 | +- Check that the trigger ID in the URL is correct. |
| 161 | + |
| 162 | +**401 Unauthorized** |
| 163 | + |
| 164 | +- The token audience must match the SRE Agent app ID, not `https://management.azure.com`. |
| 165 | +- To get a token for testing, run: `az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsv`. |
| 166 | + |
| 167 | +**Trigger executes but agent doesn't act** |
| 168 | + |
| 169 | +- Check the agent prompt. An empty prompt might not produce useful output. |
| 170 | +- Verify the chosen subagent has the tools needed for the task. |
| 171 | +- Check execution history for error details. |
| 172 | + |
| 173 | +## Limits |
| 174 | + |
| 175 | +| Resource | Limit | |
| 176 | +|---|---| |
| 177 | +| Triggers per agent | No hard limit | |
| 178 | +| Max turns per execution | 250 turns | |
| 179 | +| Authentication | Bearer token required for each trigger URL | |
| 180 | + |
| 181 | +## Related content |
| 182 | + |
| 183 | +- [Create and test an HTTP trigger](create-http-trigger.md) |
| 184 | +- [Scheduled tasks](scheduled-tasks.md) |
| 185 | +- [Workflow automation](workflow-automation.md) |
| 186 | +- [Workflow automation](workflow-automation.md)—multi-step automated workflows that HTTP triggers can start |
0 commit comments