404 и 500 на postback: как быстро понять, где ломается цепочка

404 и 500 на postback: как быстро понять, где ломается цепочка

Первое правило — не искать ошибку только в трекере. 404 почти всегда означает, что запрос ушёл не туда: битый URL, лишний слэш, неверный токен, перепутанный метод. 500 — уже проблема на стороне приёмника: упал обработчик, не прошла валидация, не хватило ресурсов или сломалась логика ответа.

Чтобы отловить 404, проверьте цепочку по шагам: endpoint, query-параметры, кодировку, обязательные поля. Сравните запрос из интеграции с ручным запросом через браузер, curl или Postman. Если 404 появляется только на части офферов, ищите расхождение в шаблоне postback — часто один макрос подставляется пустым, и путь становится некорректным.

500 ловится логами. Нужны timestamp, полный URL, headers, body, IP отправителя и ответ сервера. Если сервис ваш — смотрите exception stack, таймауты и ошибки БД. Если сервис партнёрский — сначала проверьте, не шлёте ли вы слишком длинные значения, дубли или пустые поля, которые ломают обработку.

Хорошая привычка — сделать отдельный тестовый endpoint, который отвечает 200 и пишет всё в лог, а затем сравнить его поведение с боевым. Так быстрее видно, ошибка в маршруте, в параметрах или в самой бизнес-логике. Если chain рвётся, чинить надо не «в целом postback», а конкретный участок.