URL¶
POST https://w3s.webmoney.com/json/V1/GetMessages.ashx
Заголовки¶
Тело запроса (JSON)¶
{
"reqn": 123456,
"msgid": 0,
"maxid": 0,
"datestart": "2025-09-01T00:00:00",
"datefinish": "2025-10-02T23:59:59"
}
| Поле |
Тип |
Описание |
| reqn |
long |
Номер запроса (идемпотентность/трейсинг), не обязательный. |
| msgid |
long |
id сообщения (0 — не учитывать). |
| maxid |
long |
Верхняя граница id сообщений (0 — не учитывать). |
| datestart |
DateTime |
Начало периода (ISO 8601: YYYY-MM-DDThh:mm:ss). |
| datefinish |
DateTime |
Конец периода (ISO 8601: YYYY-MM-DDThh:mm:ss). |
Пример успешного ответа¶
Ответ формируется потоково: сначала мета и массив messages, затем финальные поля retval/retdesc.
{
"reqn": 123456,
"messages": [
{
"id": 1010246826,
"corrwmid": "111122223333",
"subj": "wmk:link-button=Подробнее",
"msg": "Предлагаю выполнить задачу ...",
"dir": 2,
"sentdate": "2025-09-02T12:00:43"
}
],
"retval": 0,
"retdesc": "OK"
}
Пример ошибки (частичные данные уже отданы)¶
Если ошибка произошла после начала выдачи массива messages, ответ завершается флагом ошибки.
{
"reqn": 123456,
"messages": [
{ "id": 1, "corrwmid": "123", "subj": null, "msg": "..." }
],
"retval": -2,
"retdesc": "Partial data followed by error: <описание>"
}
Пример ошибки (до начала вывода, HTTP 400)¶
{
"reqn": 123456,
"retval": -3,
"retdesc": "Request processing error: <описание>"
}
Пример ошибки авторизации (HTTP 401)¶
{
"retval": 401,
"retdesc": "Authorization error: <описание>"
}
Возможные коды возврата¶
| Код |
Описание |
| 0 |
OK |
| 401 |
Ошибка авторизации (невалидный/отсутствующий JWT) |
| 405 |
Метод не разрешён (поддерживается только POST) |
| -2 |
Данные отданы частично, затем произошла ошибка |
| -3 |
Ошибка обработки запроса до начала выдачи данных |
Примечания¶
- Клиентам необходимо полагаться на
retval/retdesc для определения успешности операции,
даже если HTTP-статус — 200.
Режим проверки без выполнения операции (dry-run)Режим проверки без выполнения операции (dry-run)
Эндпоинт поддерживает режим, в котором запрос проходит полную проверку токена и валидацию тела, но реальная операция не выполняется — ничего
не записывается в БД, никакие WMID/кошельки/сообщения не затрагиваются.
Удобно использовать, чтобы заранее убедиться, что у токена есть нужные
права и что тело запроса корректно по формату.
Включается одним из способов (любой на выбор):
- HTTP-заголовок `X-Dry-Run: 1`
- query-параметр `?dryrun=1` в URL
Допустимые значения для включения: `1`, `true`, `yes` (регистр не важен).
Любое другое значение или отсутствие параметра — режим выключен.
Что проверяется в dry-run¶
- подпись JWT, срок действия и факт отсутствия отзыва;
- наличие в токене права, требуемого этим эндпоинтом;
- соответствие полей тела ограничениям (длины, форматы, обязательность,
совпадение `purse`/`wmid` с токеном — то же, что и в боевом режиме).
Что НЕ происходит в dry-run¶
- не вызываются методы Keeper'а / XML-интерфейсы WebMoney;
- не создаются и не отменяются счета, не выполняются переводы,
- не отправляются сообщения, не выбираются истории операций;
- не генерируются `wmtranid`, `wminvid`, `id` сообщений и т.п.
Пример успешного ответа в dry-run (JSON)¶
{
"reqn": 1730486400000,
"retval": 0,
"retdesc": "OK (dry-run)",
"dryrun": true
}
Поле dryrun: true — признак того, что запрос завершился без выполнения
реальной операции. Поля с данными конкретной операции (invoice, operation,
message, purses и т.п.) в этом режиме не возвращаются.
Ошибки в dry-run¶
Любые ошибки авторизации (401) и валидации тела (400) возвращаются как
в обычном режиме — dry-run их не подавляет. Это и есть смысл режима:
получить тот же результат, что в бою, но без побочных эффектов.
Если нужна только проверка токена (без привязки к телу конкретного
вызова), используйте отдельный эндпоинт POST /V1/Introspect.ashx —
он возвращает {"active": true/false, "scope": "...", "exp": ..., ...}
по схеме RFC 7662 OAuth 2.0 Token Introspection.