Support Issue: Custom Connector Connection Stuck

(1) Share

Report

Posted on by SS-14071457-0

Hi all,

I've got a custom connector using API Key auth (not OAuth) that's showing a connection status of suspended_for_consent, which doesn't make sense since there's no consent flow involved with API Key auth. Hoping someone has hit this before.

Setup:

Environment: Sandbox (EU region)
Connector: custom REST connector, imported via Swagger 2.0 spec
Auth type: API Key, header parameter Authorization
Target API: Intercom REST API, expects Authorization: Bearer <token>
Consuming app: Copilot Studio (added as a Tool)

The problem:

The connection shows a green checkmark and looks fine in the "Create or pick a connection" dialog in Copilot Studio. But:

Triggering the tool from Copilot Studio's test chat returns a 404.
Checking the connection object directly shows:
```
 
```
json

{ "status": "suspended_for_consent" } this error only shows when testing the tool in new copilot studio
As a control test, I went to the same connector's Test tab in Power Apps, ran the exact same operation with the exact same connection, and got a clean 200 OK with valid data back.

So the same connection works when tested directly, but fails and shows a consent-suspended state only when invoked through Copilot Studio.

What I've already ruled out:

Auth type is definitely API Key, not OAuth 2.0 (checked the connector's Security tab).
No DLP policies exist in this environment at all (checked in admin.powerplatform.microsoft.com → Security → Data and privacy → Data policy — it says "No policies created").
Connection selected in Copilot Studio matches the one that works in the Test tab (same display name, green checkmark).
Deleted and fully recreated the connector + connection multiple times — issue persists.
Also cleaned up leftover Dataverse AI Plugin Operation (msdynaip_...) records from an earlier unrelated connector I deleted, in case that was corrupting state — didn't resolve it either.

Questions:

Has anyone seen suspended_for_consent on a connection that uses API Key auth (no OAuth involved at all)?
Is there a way to force-clear/resume a suspended connection outside the normal UI (PowerShell, etc.)?
Any idea why Copilot Studio and the connector's own Test tab would behave differently using what looks like the same connection object?

Any pointers appreciated — happy to share more screenshots/logs if useful.

Categories:

Calling actions from Copilot Studio

I have the same question (0)

All responses (2)

Answers (0)

Sort by

Suggested answer

Haque 4,004 Super User 2026 Season 2 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @SS-14071457-0,

It is almost always due to strict schema rules required by Copilot's Orchestrator. While Power Apps and Power Automate can handle lazy configurations (like dynamic or empty schemas), Copilot Studio demands precise OpenAPI parameters to understand how and when to invoke the tool. Though it is bit different but a close reason is there - a thread is developed here.

PA and Power Apps may handle API Key auth connectors smoothly without consent prompts. Copilot Studio, however, sometimes enforces OAuth-like consent flows or flags connections as suspended_for_consent even for API Key auth connectors, due to internal validation or token refresh expectations. So, Copilot Studio enforces stricter consent or token validation rules compared to Power Automate or Power Apps.

A suspended_for_consent state occurs in Copilot Studio and Power Platform connectors when runtime scope enforcement or channel security policies (particularly in Microsoft Teams) flag an agent identity or connector action as lacking explicit pre-authorized execution consent, even if the underlying connection uses a static API key.

A clue how consent works is here <cite> Step 7: Verify if the prompt paramter is passed </cite> | it is just a clue.

What can be done:

Let's try re-creating the connection in Copilot Studio explicitly, even if it shows green in the picker. Sometimes re-authentication clears the suspended state. Test the connector in Power Automate or Power Apps again to confirm it works there, then re-import or update the connector in Copilot Studio. If possible, switch to OAuth 2.0 authentication for the connector, as Copilot Studio handles OAuth flows more reliably.

Two important notes to prevent humna errors:

1. Please check the connector's base URL, path and headers in the Swagger spec - to make sure they match API signature exacly.

2. Confirm the Auth head is correclty set as Bearer <token> and the token is valid.

Also, let's not forget to use the Power Platform Admin Center to check connection health and error logs.

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!

Was this reply helpful? Yes No
Suggested answer

MParikh 529 Super User 2026 Season 2 on at

Like
a
(0)

Report
Copy link

Link copied!
HI

suspended_for_consent is a Power Platform connection lifecycle state, not an OAuth-only one. Copilot Studio wraps every connector connection in a consent and authorization model at the agent level, independent of your connector's auth type. Your Power Apps Test tab calls the connector directly with your maker credentials against the connection at the API layer. Copilot Studio calls through the agent's connection reference, which enforces consent and channel authentication. Same connection at the API layer, different invocation path and different gate. The green checkmark in the pick dialog confirms the API-layer connection is valid. The checkmark does not confirm the agent's connection reference is consented. While the reference sits in suspended_for_consent, the runtime never authorizes the call, and the platform surfaces a 404-style failure before reaching Intercom. So the 404 is a symptom of the suspended reference, not an Intercom routing problem. Your clean 200 in the Test tab proves the host and path are correct.

One more piece. Recreating the connector does not rebind the agent. The agent keeps its old connection reference. Your cleanup of the msdynaip_ AI Plugin Operation records points at that same plugin and reference layer, so a stale or orphaned reference is a strong candidate here.

Steps to work through:

Open the agent's Connection Settings, not the pick dialog. In the agent, go to Settings, then Connection Settings. This page lists the connections your agent uses and lets you view, edit, or disconnect them. Disconnect the tool's connection there and reconnect. Microsoft Learn

Remove the tool from the agent, then re-add it. This forces a fresh connection reference and a fresh consent, which recreating the connector alone will not do.

Check the tool's authentication mode. By default the connection uses user credentials, so each user of the agent gets asked to enter credentials for the service when they use the tool. If you want your maker connection used at runtime instead, configure the agent for an authenticated channel and set the tool accordingly. Microsoft Learn

Trigger the consent card directly. Run the tool in the test chat and complete any "let's get you connected" or "open connection manager" prompt. Completing that action is what moves the reference out of the suspended state.

Confirm environment and identity alignment. The connection must live in the same Sandbox EU environment as the agent, under the identity the agent runs as. A connection made under a different user or environment stays unconsented for the agent.

Confirm premium licensing on the runtime identity. Custom connectors are premium. The Test tab passes under your maker license, but the agent's runtime identity needs its own premium entitlement, or the connection stays unusable through Copilot Studio.

On question 2, there is no supported "resume" verb for a suspended connection. The Microsoft.PowerApps.Administration.PowerShell module lists and removes connections, so you use PowerShell to find and delete stale ones, then reconsent through Connection Settings. The path is remove and reconsent, not resume.

Watch item once consent is fixed. Your API key parameter is the Authorization header, and the platform connector runtime uses Authorization for its own token. The Test tab injects differently, which is likely why the direct test passes today. If Intercom calls start failing auth after the consent state clears, rename the API key parameter to a non-Authorization header and set the Authorization: Bearer <token> value through a connector policy instead. That removes the collision.

Start in the agent's Connection Settings and re-add the tool. Rebinding the reference and forcing a fresh consent is where the suspended state actually lives.

References

https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-connections

https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-connectors

Thank you!

Proud to be a Super User!

🏷️ Need more help?

✅ Don't forget to Accept as Solution if this guidance worked for you.

❤️Your Like motivates me to keep helping

Was this reply helpful? Yes No