Interactive example
Teams Workflow request lab
Switch between the captured request and expected test response. All identifiers are synthetic.
- Content-Type
- application/json
- User-Agent
- integration-test/1.0
- X-Event-Id
- evt_deploy_0182
{
"type": "message",
"attachments": [
{
"contentType": "application/vnd.microsoft.card.adaptive",
"contentUrl": null,
"content": {
"$schema": "https://adaptivecards.io/schemas/adaptive-card.json",
"type": "AdaptiveCard",
"version": "1.2",
"body": [
{ "type": "TextBlock", "text": "Deployment completed", "weight": "Bolder" },
{ "type": "FactSet", "facts": [
{ "title": "Service", "value": "checkout-api" },
{ "title": "Environment", "value": "staging" }
] }
]
}
}
]
}Configured response
200 OK
Content-Type: application/json
{"status":"accepted","target":"teams-workflow-test"}Synthetic data only. Never paste production tokens, signing secrets, personal data, or payment information into a public test endpoint.
One-click test setup
Creates a temporary bucket and applies this guide's expected response. You can inspect and delete it from the dashboard.
Test the Contract Before the Secret Teams URL
A Teams Workflow webhook URL is a secret destination, not a request inspector. When a payload fails, the sender often exposes only a status code while the malformed envelope remains hidden inside application logs. A temporary WebhookTest.net bucket gives you a controlled boundary where the exact method, headers, query values, and raw JSON are visible.
Keep the real Workflow URL out of screenshots, source control, tickets, and shared test fixtures. Start with a synthetic deployment event, deliver it to the temporary endpoint, and compare the capture with Microsoft’s documented schema. Move to the Teams URL only after the request is correct.
Build the Adaptive Card Envelope
Microsoft’s Teams webhook trigger accepts POST requests and documents an Adaptive Card envelope whose top-level type is message. The attachments array contains objects with contentType application/vnd.microsoft.card.adaptive, a null contentUrl, and an Adaptive Card content object.
The example on this page uses version 1.2 and contains only synthetic service and environment values. Real payloads can include additional card elements, but begin with a small envelope so a missing bracket, incorrect content type, or misplaced body field is easy to identify.
- Send POST with Content-Type application/json
- Keep type set to message at the top level
- Use application/vnd.microsoft.card.adaptive for each card attachment
- Keep production URLs, tokens, and customer data out of the test payload
Inspect Headers and Correlation Values
Content-Type is the required transport signal. The additional X-Event-Id in the lab is a deliberate application-level correlation header, not a Microsoft requirement. Adding a stable synthetic event identifier makes it easier to connect the sender log, captured request, and retry attempt without exposing a real credential.
Inspect the captured raw body before relying on a parsed preview. Serialization bugs can change numbers into strings, omit null fields, or send a nested JSON value as an escaped string. The raw request is the evidence that Teams will actually receive.
Expected Response and Failure Cases
The one-click endpoint created by this guide responds with 200 and a small JSON acknowledgement. That verifies that the sender records a successful HTTP exchange. The response is a WebhookTest.net test contract; Microsoft controls the response returned by the real Workflow URL.
If nothing arrives, confirm that the application uses the newly created webhook URL and permits outbound HTTPS. If a request arrives with an empty body, inspect serialization and the outgoing Content-Type. If Teams later rejects a request that passed this capture test, compare the card version and supported elements with the current Microsoft documentation.
- 404 usually means the sender retained an old or incomplete destination URL
- 400 points to malformed JSON or an envelope that does not match the receiver contract
- A timeout can cause duplicate delivery even if the first request reached the receiver
- A successful capture proves transport shape, not that every Teams card element is supported
Move the Verified Request to Teams
After the synthetic request looks correct, replace only the destination URL with the Teams Workflow callback URL. Preserve the method, headers, and body generated by the same code path. This isolates destination behavior from request-construction behavior.
Delete the temporary bucket after the test. Treat both the random bucket URL and the Teams callback URL as bearer capabilities, and never reuse the synthetic test endpoint as a production message processor.
Common questions
Frequently asked questions
- Can WebhookTest.net send a message into Microsoft Teams?
- This guide uses WebhookTest.net as a safe inspection boundary before the real Teams Workflow URL. Send the same synthetic JSON to the temporary endpoint first, inspect it, then point your integration at the secret Teams URL after the contract is correct.
- Should I create a legacy Microsoft 365 connector?
- Microsoft documents Microsoft 365 Connectors as nearing deprecation and recommends the Workflows app with the When a Teams webhook request is received trigger for new webhook automations.
- Which HTTP method and content type should the test use?
- Use POST with Content-Type application/json. The Teams webhook trigger does not support GET, and Adaptive Card messages use a message envelope with an attachments array.
Primary sources
Official references
Try it with a real request
Turn the guide into a test.
Open a temporary endpoint, send your payload, and inspect exactly what arrived.
Open the tester