Adaptive Card Execute Action Fails with 500 Error When Calling Third-Party API

Hello Rahil Faldu ,
This is a recently surfaced breaking issue affecting Declarative Agents using Action.Execute → Plugin (API) invocation in Microsoft 365 Copilot. The error (HTTP 500, "Execute action failed: Error calling plugin") occurs even though the same payload worked previously, and the third-party API is never reached. This indicates the failure happens inside the Copilot Execute → Plugin broker layer before the API call is sent.

The root cause is a recent backend change (Copilot Orchestrator Service ≥ 1.0.0337x) that now enforces a Plugin Invocation Trust Context for Adaptive Card Action.Execute calls. Previously, tokens were injected silently, but now the platform validates a trust chain (User → Agent → Plugin). If this context is missing or mismatched, the invocation fails with HTTP 500.

This particularly impacts Adaptive Card Execute actions because they originate from the Teams client rather than an agent or LLM tool call. To fix the issue, the Action.Execute must include the msteams.invoke binding, and the Declarative Agent manifest must include supportsUserContext: true in the plugin runtime configuration. Without these updates, the trust chain is incomplete and the broker blocks the request.

To confirm, check DevTools → Network → invoke for PluginInvocationFailed and verify that your backend API receives no requests. After applying the fix, republish the agent, reinstall the app, and clear Teams cache, as Execute payloads may be cached client-side.

HTTP 500 indicates that the service processing the Adaptive Card action is failing, not the card itself. For Adaptive Cards using Action.Execute or Action.Http, the platform expects the backend endpoint (bot, plugin, or API façade) to successfully process the request and return a valid response payload.

From the provided details:

• The card shows a generic "Something went wrong. Please try again." message.
• The trace text shows Execute action failed: Error calling plugin and HTTP 500.

This matches the documented behavior where:

• A successful execution must return HTTP 200.
• Failures are surfaced when the backend returns 4xx/5xx or an invalid payload.

To troubleshoot:

1. Check the third‑party API and plugin endpoint
   • Confirm the endpoint used by the Execute Action still accepts the request (method, URL, headers, and body) and is reachable.
   • Call the same endpoint outside Copilot (for example with Postman) using the same payload to see if it returns 500 there as well.
   • If the API recently changed (schema, auth, rate limits), update the plugin or backend accordingly.
2. Verify HTTP contract for Adaptive Card actions
   • For Action.Http / Action.Execute, the backend must:
     • Accept the request (typically POST) and process the card input values.
     • Return HTTP 200 on success.
     • For Outlook-style Action.Http, if execution fails, return HTTP 4xx and optionally include an error header (CARD-ACTION-STATUS) whose value is shown to the user.
   • If the backend is returning 500, fix the server‑side exception so it returns 200 with a valid response body, or a 4xx with a clear error.
3. Validate the response schema for Action.Execute
   • When using the universal action model, the backend must return one of the supported content types and status codes (for example, 200 with application/vnd.microsoft.card.adaptive or application/vnd.microsoft.activity.message).
   • If the plugin returns an unsupported content type or malformed JSON, the client can surface a generic failure even if the status code is 200.
4. Inspect recent changes
   • Because this worked until yesterday, compare:
     • Any recent changes to the plugin code, deployment, or configuration.
     • Any changes to authentication (tokens, keys, scopes) used to call the third‑party API.
     • Any changes to the Adaptive Card payload (new inputs, changed IDs, or action definitions) that might cause the backend to fail when parsing.
5. Harden error handling
   • Wrap the plugin’s call to the third‑party API in try/catch and log the full exception.
   • Map known API errors to appropriate HTTP 4xx responses with clear messages so that the card can show a more specific error instead of a generic 500.

Once the backend consistently returns a valid 200 response with the expected schema (or a controlled 4xx with a clear message), the Execute Action should stop failing and the Adaptive Card will either update or display the returned message as designed.

References:

• Designing Outlook Actionable Message cards with the Adaptive Card format
• Universal Action Model