Telegram error 400: Bad Request: group chat was upgraded to a supergroup chat

You addressed a basic group by its old chat ID, but that group has since been converted to a supergroup and received a new ID. Telegram tells you this explicitly and, uniquely among Bot API errors, includes the replacement ID in parameters.migrate_to_chat_id. The old ID will never work again.

Basic groups are upgraded when an admin enables certain features, when the member limit is exceeded, or when a member triggers a conversion. Your bot receives a service message at the time (migrate_to_chat_id on a Message in the old chat and migrate_from_chat_id in the new one), but bots that only store IDs at onboarding and never look at later updates miss it. The API documents that the new identifier can exceed 32 bits (at most 52 significant bits), so it must be stored in a 64-bit integer or string.

Several libraries convert this error into a dedicated exception that carries the new ID: python-telegram-bot raises telegram.error.ChatMigrated with a new_chat_id attribute, and aiogram v3 raises aiogram.exceptions.TelegramMigrateToChat with migrate_to_chat_id. In Telegraf and grammY, read err.response.parameters.migrate_to_chat_id / err.parameters.migrate_to_chat_id; in node-telegram-bot-api it is at error.response.body.parameters.migrate_to_chat_id. The handling pattern is the same everywhere:

# python-telegram-bot
try:
    await bot.send_message(chat_id, text)
except ChatMigrated as e:
    store.update_chat_id(chat_id, e.new_chat_id)
    await bot.send_message(e.new_chat_id, text)

// grammY / Telegraf
try { await bot.api.sendMessage(chatId, text); }
catch (err) {
  const newId = err.parameters?.migrate_to_chat_id;
  if (newId) { await store.updateChatId(chatId, newId);
               await bot.api.sendMessage(newId, text); }
  else throw err;
}

Supergroup IDs start with -100; a stored ID that is negative but does not begin with -100 is a basic group and a candidate for this error.

{"ok":false,"error_code":400,"description":"Bad Request: group chat was upgraded to a supergroup chat","parameters":{"migrate_to_chat_id":-1001234567890}}

Always inspect the parameters object on errors, not just description; this is the one case where the fix is handed to you. Store chat IDs as mutable records keyed by an internal ID so a migration is a single update rather than a data repair. The same parameters object carries retry_after on 429 responses, so a shared error decoder pays off twice. If the old ID keeps failing after migration handling, you will see chat not found instead.