Teams error 400 Bad Argument: Bad Argument - invalid request payload

The Connector understood who you are but not what you sent. Microsoft's status table documents 400 as code Bad Argument with a scenario-specific message and the developer action "Reevaluate request payload for errors. Check returned error message for details." The retry column says No: the same payload will fail the same way forever, so retrying a 400 only burns your rate-limit budget.

In Teams practice the message body is where the diagnosis lives: a malformed conversation ID, an activity missing its required type, a card attachment whose contentType does not match its content, an invalid mention entity whose mentioned.id is not actually in the conversation, or JSON that serializes a null into a required field. Because the message text varies by scenario, log the full ErrorResponse body and the X-Correlating-OperationId header rather than just the status code.

{
  "error": {
    "code": "Bad Argument",
    "message": "Invalid ChannelData property..."
  }
}

Build activities through the SDK's typed factories instead of raw dictionaries so required fields cannot be omitted silently. Validate card JSON in CI. Keep one integration test per card template you ship, run against a test tenant, so schema drift surfaces before release - the same discipline that keeps 413 payload-size failures out of production.