Markdown-документация API из OpenAPI или списка эндпоинтов

Подготовь единый Markdown-документ с готовой к публикации документацией API. Пиши по-русски, технически чётко и без лишних вступлений.

Входные данные
- Либо [OPENAPI ИЛИ SWAGGER ФАЙЛ В YAML/JSON].
- Либо [СПИСОК ЭНДПОИНТОВ] с методом, путём, описанием, параметрами, схемами запроса и ответа, кодами ошибок, аутентификацией и rate limits.
- Опционально: [СТИЛЬ ОФОРМЛЕНИЯ], [УРОВЕНЬ АУДИТОРИИ: junior/mid/senior], [ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ].

Если каких-то данных нет, не задавай вопросов. Используй явные маркеры TODO или REVIEW и перечисли допущения в отдельном блоке Assumptions / TODO.

Формат ответа
- Один Markdown-файл.
- H1 для названия API, H2 для крупных разделов, H3/H4 для эндпоинтов.
- В начале TOC и краткий overview.
- Таблицы параметров в Markdown с колонками: name | in | type | required | default | description | example.
- Примеры кода в fenced code blocks с языками bash, python и javascript.

Обязательные разделы
1. Название API, версия, base URL, бизнес-контекст.
2. Аутентификация с примерами, rate limits и обработка 429.
3. Для каждого эндпоинта: метод и путь, summary, описание поведения, таблица параметров, тело запроса, заголовки ответа, примеры успешного ответа и 3–5 типовых ошибок, кодовые примеры, SLA или TODO.
4. Схемы и модели: поля, типы, обязательность, примеры JSON, вложенные объекты, перечисления.
5. Коды ошибок и troubleshooting: стандартный формат ошибки, причины, быстрые проверки, retry/backoff.
6. Лучшие практики и ограничения: пагинация, фильтрация, сортировка, кеширование, idempotency, безопасное хранение токенов, ограничения по размеру и параллелизму.
7. Примеры интеграций: 2–4 сценария вызовов с ожидаемыми ответами и примечаниями по ошибкам.
8. Дополнительно, если данные есть: observability, меры безопасности, changelog.
9. Блок Assumptions / TODO.

Требования
- Не пропускай разделы даже при неполных входных данных.
- Не добавляй вымышленные факты.
- Там, где есть пробелы, честно ставь TODO вместо догадок.