Где какой идентификатор
| Данные | Метод | Чем указан товар |
|---|---|---|
| Карточки | /v3/product/info/list | id (product_id), offer_id; SKU - в stocks.stocks[].sku |
| Отправления FBO и FBS | /v3/posting/fbo/list, /v4/posting/fbs/list | products[].sku, products[].offer_id |
| Начисления | /v1/finance/accrual/by-day | posting.products[].sku |
| Отзывы | /v1/review/list | sku |
| Отчет о выкупе | /v1/finance/products/buyout | sku, offer_id |
Как найти SKU карточки
- В ответе
/v3/product/info/listSKU лежит вstocks.stocks[]: у каждого элемента естьskuиsourceсо значениемfboилиfbs. Так SKU есть даже у товара без единого заказа (проверено 10.08.2026). - У старых карточек два SKU, для FBO и для FBS. После перехода Ozon на единый SKU они обычно совпадают, но сопоставляйте по обоим.
- Верхнеуровневое поле
sources[].sourceдля этого не подходит: там коды вродеsds, а не fbo и fbs. - Товар без остатков, которому Ozon еще не выдал SKU, в ответе SKU не имеет: его начисления сопоставятся позже.
Регистр offer_id
Ozon считает артикулы, которые отличаются только регистром букв, разными товарами. Большинство баз данных по умолчанию сравнивают текст без учета регистра (в MySQL это коллации _ci), и тогда заказы двух разных товаров склеиваются, а отчеты по ним удваиваются или обнуляются.
- Храните offer_id в колонке с бинарным сравнением (в MySQL -
utf8mb4_bin) или сравнивайте какCAST(a AS BINARY) = CAST(b AS BINARY). - Группировки по offer_id (
GROUP BY,DISTINCT) тоже должны учитывать регистр. - Поиск по артикулу для пользователя можно оставить без учета регистра: это поиск, а не сопоставление.
