# Типы ошибок

**303 SEE\_OTHER** - запрос необходимо повторить, но направить в другой центр обработки данных.

**400 BAD\_REQUEST** - запрос содержит ошибки. В случае, если запрос был создан с помощью формы и содержит данные, сгенерированные пользователем, пользователь должен быть уведомлен о том, что данные необходимо исправить перед повторением запроса.

**401 UNAUTHORIZED** - была предпринята несанкционированная попытка использования функционала, доступного только авторизованным пользователям.

**403 FORBIDDEN** - нарушение конфиденциальности. Например, попытка написать сообщение тому, кто занес текущего пользователя в черный список.

**404 NOT\_FOUND** - попытка вызвать несуществующий объект, например метод.

**406 NOT\_ACCEPTABLE** - аналогично 400 BAD\_REQUEST, но приложение должно отображать ошибку пользователю немного иначе. Не отображайте пользователю никаких видимых ошибок при получении конструктора rpc\_error: вместо этого дождитесь обновления updateServiceNotification и обработайте его как обычно. По сути, всплывающее обновление updateServiceNotification будет отправлено независимо (т.е. НЕ как конструктор Updates внутри rpc\_result, а как обычное обновление) сразу после отправки 406 rpc\_error: обновление будет содержать фактическое локализованное сообщение об ошибке, которое будет показано пользователю во всплывающем окне пользовательского интерфейса.

Исключением является ошибка AUTH\_KEY\_DUPLICATED, которая отправляется только в том случае, если какой-либо из немедиа DC обнаруживает, что авторизованный сеанс отправляет запросы параллельно из двух отдельных TCP-подключений с одного и того же или разных IP-адресов. Обратите внимание, что параллельные подключения по-прежнему разрешены и фактически рекомендуются для медиа-DC. Также обратите внимание, что под сеансом мы подразумеваем сеанс с авторизацией, идентифицированный конструктором авторизации, извлекаемый с помощью account.getAuthorizations, а не сеанс MTProto.

Если клиент получает ошибку AUTH\_KEY\_DUPLICATED, сеанс уже был аннулирован сервером, и пользователь должен сгенерировать новый ключ авторизации и войти снова.

**420 FLOOD** - это сообщение об ошибке, генерируемое серверами Telegram, когда он обнаруживает, что приложение отправляет слишком много запросов в течение короткого периода времени. Telegram имеет ограничение на количество запросов, которые можно отправить в течение определенного периода времени, и если этот лимит будет превышен, серверы ответят этим сообщением об ошибке. Более подробно можете узнать об ограничениях в официальном боте Telegram [@SpamBot ](https://telegram.me/SpamBot)

**500 INTERNAL** - во время обработки запроса произошла внутренняя ошибка сервера; например, произошел сбой при доступе к базе данных или файловому хранилищу.

Если клиент получает ошибку 500 или вы считаете, что эта ошибка не должна была возникнуть, соберите как можно больше информации о запросе и ошибке и отправьте ее разработчикам.

**Другие коды ошибок -** если сервер возвращает ошибку с кодом, отличным от перечисленных выше, это может считаться ошибкой 500 и рассматриваться как внутренняя ошибка сервера.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.leadsender.ru/rukovodstvo-polzovatelei-leadsender/nachalo-raboty-c-telegram/otpravka-soobshenii/tipy-oshibok.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.