Graph cloud-communications answer returns HTTP 400 "The input was not valid." for ALL incoming Teams calls to our calling bot - even from the official Microsoft.Graph.Communications SDK

The next action is to open a Microsoft support case for the Graph Cloud Communications/Teams calling backend and request investigation of the bot’s calling registration, because no public self-service command is documented for resetting an APS/calling-store agent record.

What can be concluded

• The documented answer operation accepts acceptedModalities and mediaConfig, requires application permission Calls.JoinGroupCall.All, and additionally requires Calls.AccessMedia.All only for application-hosted media. A successful request returns 202 Accepted; the answer must arrive within 15 seconds for a regular call.^1^
• serviceHostedMediaConfig is a supported media configuration, and preFetchMedia is optional.^2^
• Teams Developer CLI supports migrating bot registration between Teams and Azure, but its public documentation does not describe an APS reset, calling-store repair, or this failure mode.^3^
• There is no cited Microsoft bulletin establishing that teams app bot migrate corrupts calling registration or that empty-code HTTP 400 responses are a recognized migration defect. The temporal association is therefore useful evidence for support, but not an established root cause.

Your tests already eliminate the useful client-side branches: the documented payload, official communications SDK, token roles, timing, correlation headers, webhook processing, and resource/service-principal recreation all produce the same result. Repeating those operations is unlikely to add diagnostic value.

One remaining configuration check

Inspect the currently installed Teams app package, not only the source manifest, and verify that its bot entry has:

{
  "bots": [{
    "botId": "<same Microsoft app ID used for Graph authentication>",
    "supportsCalling": true,
    "supportsVideo": false
  }]
}

Teams calling bots require supportsCalling, the Teams calling channel, Graph application permissions with admin consent, and the calling webhook configuration.^4^

If the installed package already has the same app ID and supportsCalling: true, do not recreate or migrate it again. That leaves no documented tenant-side repair that would reset an internal calling agent record.

Also note that chatInfo and meetingInfo can appear in an incoming group-call notification; they are not documented as fields that must be copied into the answer request body. The required answer-body fields are acceptedModalities and mediaConfig.^1^

Escalation package

Open the case from the affected tenant’s Microsoft 365 or Azure support channel and classify it under Microsoft Graph → Cloud Communications / Teams calling bot. Ask for escalation to the service team that owns calling-bot registration and APS routing.

Attach:

1. UTC timestamps for at least two failed calls.
2. Call IDs and notification resource URLs.
3. Graph response headers:
   • request-id
   • client-request-id
   • date
4. Sanitized raw request and response, including the exact URL and body.
5. Token claims relevant to diagnosis: aud, appid/azp, tid, and roles; omit the token itself.
6. Incoming, established, and terminated notifications for the same call.
7. The installed Teams manifest and the Azure Teams-channel configuration.
8. CLI version, migration command output, and the migration timestamp.
9. A before/after timeline showing that calling worked before migration and failed afterward, if logs establish that.
10. The control test showing a different app ID receives 7503, while the affected app reaches a different validation path and receives the empty-code 400.

Microsoft’s Graph debugging guidance specifically recommends logging a unique client-request-id and preserving the response request-id and date, because these values are needed for support correlation.^5^

Use a direct request in the case attachment to avoid SDK abstraction:

POST https://graph.microsoft.com/v1.0/communications/calls/{call-id}/answer
Authorization: Bearer <redacted>
Content-Type: application/json
client-request-id: <unique-guid>

{
  "acceptedModalities": ["audio"],
  "mediaConfig": {
    "@odata.type": "#microsoft.graph.serviceHostedMediaConfig"
  }
}

Request that support verify:

• The app ID’s Teams calling-agent registration and routing state.
• Whether both pre- and post-migration registrations exist.
• Whether the notification-side agent and Graph answer authorization-side agent resolve to the same registration.
• Whether the registration can be repaired or removed and reprovisioned internally.
• Whether the failure correlates with a regional APS partition or active service incident.

Before submitting, check tenant Service health and Message center for an active Teams or Microsoft Graph incident; those interfaces expose current and historical health for subscribed Microsoft services.^6^

Avoid posting tenant IDs, app IDs, call IDs, tokens, or unredacted traces publicly; provide them only through the private support case.

References

1. call: answer - Microsoft Graph v1.0 | Microsoft Learn
2. serviceHostedMediaConfig resource type
3. Teams developer CLI
4. Register calls and meetings bot for Microsoft Teams
5. How to debug Microsoft Graph API calls
6. Access service health and communications in Microsoft Graph