Teams error 403 InvalidBotApiHost: InvalidBotApiHost - wrong cloud endpoint (GCC)

Your bot called the public Bot API host for a conversation that lives in a Government Community Cloud (GCC) tenant. The status table documents InvalidBotApiHost with the message "Invalid agent api host. For GCC tenants, call https://smba.infra.gcc.teams.microsoft.com." and - uniquely among the 403s - a retry path: "Update the service URL for the conversation to https://smba.infra.gcc.teams.microsoft.com and retry the request."

Microsoft 365 government clouds are separate service boundaries with their own Bot API hosts. The proactive-messaging guide lists them: public https://smba.trafficmanager.net/teams/, GCC https://smba.infra.gcc.teams.microsoft.com/teams, GCC High https://smba.infra.gov.teams.microsoft.us/teams, DoD https://smba.infra.dod.teams.microsoft.us/teams. The correct behavior is to use the serviceUrl from each incoming activity rather than a hardcoded host - hardcoding the public host is exactly how multi-cloud bots hit this error the day a GCC customer installs them.

The symptom pattern is distinctive: the same code path works for every commercial customer and fails only for one tenant, because the conversation IDs themselves give no hint of which cloud minted them. If your logs show this 403 clustered on a single organization, you are looking at a cloud-boundary problem, not a permissions one.

{
  "error": {
    "code": "InvalidBotApiHost",
    "message": "Invalid agent api host. For GCC tenants, call https://smba.infra.gcc.teams.microsoft.com."
  }
}

Never hardcode a Bot API host. The incoming activity's serviceUrl is authoritative for replies, and stored conversation references must carry it for proactive sends - Microsoft's proactive-messaging warning says precisely this. If you operate in multiple clouds, add the cloud environment to your conversation records so a misrouted send is queryable rather than mysterious.