Парсер успешно разобрал тело запроса как JSON, но валидатор обнаружил 5 нарушений требований схемы. Ниже — полный технический разбор каждой ошибки и рекомендации по исправлению.
Контактные данные администратора недоступны на этой странице.
Поле items обязательно и должно содержать хотя бы один элемент заказа. Передан пустой массив [].
Поле total ожидает числовое значение. Получена строка "540 руб". Уберите текст из значения — валюта передаётся отдельным полем.
Поле currency ожидает код по ISO-4217 (трёхбуквенный): RUB, USD, EUR. Символ ₽ не входит в допустимый набор.
Поле created ожидает дату в формате ISO-8601 с тайм-зоной. Литерал "только что" не принимается.
Поле customer_email ожидает корректный email. Значение "user.example" не содержит символа @ и домен не указан.
Поле shipping обязательно, в нём ждут хотя бы address и method. Передан пустой объект {}.
{
"items": [],
"total": "540 руб",
"currency": "₽",
"created": "только что",
"customer_email": "user.example",
"shipping": {}
}
{
"items": [{"id":"sku-001","qty":2}],
"total": 540.00,
"currency": "RUB",
"created": "2026-05-20T10:48:00Z",
"customer_email": "user@example.invalid",
"shipping": {
"address":"...",
"method":"std"
}
}
orders/v2 и пройдите по списку обязательных полей. Каждое поле должно соответствовать ожидаемому типу и формату.items и объект shipping не могут быть пустыми. При формировании заказа всегда добавляйте хотя бы один элемент и адрес доставки.@ и домен. Для тестов используйте псевдо-домен example.invalid.POST на тот же путь. Дополнительных шагов не требуется.POST, путь /api/v3/orders/create, content-length 522 байт. TLS 1.3 рукопожатие успешное.orders/v2. Поля customer_id и published прошли проверку.Нет. Код 400 — штатная часть HTTP-протокола. Сервер работает корректно и принимает решения по правилам схемы. Проблема находится в формате данных, которые отправил клиент.
Нет. Тот же запрос вернёт тот же 400 с тем же списком нарушений. Валидация — детерминированная: одинаковый вход даёт одинаковый выход.
orders/v2?Описание схемы публикуется в разделе API-документации. Эта страница содержит только разбор конкретного запроса и не заменяет полную спецификацию.
В strict-режиме парсер не пытается приводить типы автоматически. Строка "540" не превращается в число 540 — клиент обязан прислать значение нужного типа сразу.
Тело запроса показано в анонимизированном виде. Реальные значения полей не публикуются; идентификаторы и адреса заменены на условные. Конфиденциальные данные не утекают через страницы ошибок.
Контактные данные администратора недоступны на этой странице. Если задача срочная, используйте принятый в вашей среде канал связи с ответственным оператором. Обязательно укажите request-id для быстрого поиска контекста.
Сверить версию схемы: возможно, изменился контракт API. Также проверить заголовки запроса, в первую очередь content-type. Если по всем признакам запрос валиден — обратитесь к ответственному оператору с request-id.
После исправления тела запроса валидация пройдёт штатно и заказ попадёт в основную обработку. Никаких действий на стороне сервера не требуется — это исключительно вопрос формата клиентских данных.