API партнёрок ломается не на auth, а на мелких quirks в схеме и ответах

API партнёрок ломается не на auth, а на мелких quirks в схеме и ответах

При интеграции сначала проверь не методы, а контракт. У партнёрок часто расходятся названия полей в docs и в ответе: id вместо offer_id, payout в string вместо number, status как text, а не enum. Если парсить «в лоб», ошибка вылезает не в тесте, а на боевом постбэке.

Типовые места поломки:
— пагинация: limit/offset и page/next_cursor смешаны в одном API;
— timezone: дата в UTC, фильтр ожидает локальное время;
— знаки в статусах: approved, approve, confirmed могут значить одно и то же;
— деньги: копейки, целые, строка с точкой, строка с запятой;
— дубли: один и тот же lead прилетает повторно, нужен idempotency key.

Нормальный слой интеграции делает три вещи: нормализует поля в свой internal schema, сохраняет сырой payload для дебага и не доверяет пустым значениям. Если поле optional, не подставляй дефолт молча: лучше отдельно логировать null, empty string и missing key. Это сильно помогает, когда партнёрка меняет сериализацию без объявления.

Ещё одна ловушка — rate limit и ретраи. Если API отдаёт 429 или временный 5xx, повторяй запрос с backoff, но не пересоздавай конверсию без проверки внешнего id. Иначе дубли пойдут в трекинг, а потом в reconciliation.

Вывод простой: интеграция с партнёркой должна переживать грязный JSON, повторные ответы и кривые статусы. Делай адаптер, а не прямой парсинг в бизнес-логику.