Http POST from card in Microsoft Teams

Question

We are trying to create an approval workflow using Teams, Flow, and Assembla and are running into a bit of trouble.

We have a few of the pieces successfully setup however we are unable to initiate a POST action from a card in Teams.

In teams we can successfully create a card using the incoming webhook connector with this result.

This is created with the following JSON body from a POST action in Flow

{
    "@@type": "MessageCard",
    "@@context": "http://schema.org/extensions",
    "summary": "This is the summary property",
    "themeColor": "f46b42",
    "sections": [
        {
            "startGroup": true,
            "title": "**Pending Review**",
            "activityTitle": "Ticket Title",
            "activitySubtitle": "Requested by: ",
            "facts": [
                { "name": "Date submitted:", "value": "06/27/2017, 2:44 PM" },
                { "name": "Details:",
                "value": "This ticket is ready for review." }
            ]
        },
        {
            "potentialAction": [
                {

                    "@@type": "HttpPOST",
                    "name": "Approve",
                    "target": "ANOTHER-POST-URL-IS-HERE"
                },
                {


                    "@@type": "HttpPOST",
                    "name": "Deny",
                    "target": "ANOTHER-POST-URL-IS-HERE"
                }
            ]
        }
    ]
}

We have another Flow url as the target for both buttons on the card. To test this url we are able to successfully post via POSTMAN and continue the approval workflow.

When clicking the button on the Team card the Flow at the post url is in no way notified at all. No run on Flow is triggered. In teams a very generic "There was a problem submitting your changes. Try again in a minute." error is displayed.

After researching I ran across the connectors.md file on the Microsoft Teams github page and noticed this lovely part of the documentation

It seems odd to me that right below them mentioning that POST actions may not be supported the documentation goes on in length to show examples of using POST and ActionCard actions in a card on teams.

So my question is this, is there any way to get an HttpPOST action to work from a custom card in Teams to a Microsoft Flow POST URL?

Thanks!

Update:

Upon further testing we have determined that HttpPOST actions work with just about any post url we can come up with except Microsoft Flow Request URLs. They are exceptionally long urls so maybe that has something to do with it?

Here's an example Flow request url.

https://prod-43.westus.logic.azure.com:443/workflows/f86b928acd3d4ecab849f677974f7816/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=ZBxr5GFKQhMp4JXWGmec_L6aqgcaqvCOKUWOf2li-xQ

When running teams in a web browser we are able to see the request first posts to a api.teams.skype.com url and returns a generic "ProviderError". Other non-flow urls also do the same but return success.

Answer 1

This was a head-scratcher for us - as you surmised, this should have worked. The Teams, Flow, and Outlook teams troubleshooted this today and found out what was going on.

The URL you are posting to, https://prod-43.westus.logic.azure.com[...] has an embedded bearer token (the value of the sig parameter in the URL). When you POST to that URL via CURL, Fiddler, Postman, etc. it works because that token is present.

However, when you click on a HttpPOST button in an actionable message, Outlook adds its own JWT token in the HTTP header, meaning that the HTTP POST has both a sig= bearer token in the URL and a JWT token in the HTTP header. Flow detects this and rejects the HTTP POST as invalid (while we don't currently support JWT tokens, we plan to, and treat this case as invalid to maintain forward compatibility).

This use case will work in the future. In the meantime, one workaround to try would be to have the actionable message buttons POST to your endpoints, e.g. https://yoursite.com/accept and https://yoursite.com/deny (validating the JWT as much as you like) and have these endpoints POST to Flow directly without the JWT.

Please let us know if that works.

BTW, the text you found is a documentation bug that has since been fixed:

Sorry for the confusion.