Open Food Facts answers a missing barcode with 200, not 404

A missing product returns 200, not 404

GET /api/v2/product/737628064502.json, queried live this session, returned 200 with status: 1 and status_verbose: "product found". The body carried a real record for a Thai peanut noodle kit, brands Simply Asia and Thai Kitchen.

GET /api/v2/product/00000000000000.json, queried live this session, also returned 200. The body read status: 0 and status_verbose: "no code or invalid code". A missing barcode and a found one share the same HTTP status.

A client that checks only the status code cannot tell a real product from a miss. It has to read status in the body on every call.

The server rewrites your barcode before it looks anything up

The all-zero query above went in as a 14-digit code, 00000000000000. The response came back with code: "00000000", eight digits. The server shortened it before it even ran the lookup.

GET /api/v2/product/12345.json, queried live this session, returned code: "00012345": the server padded a 5-digit input up to 8 digits. That padded code matched a real, short barcode already logged in the database. The padding is deliberate, and it changes which product a short code resolves to.

A client that stores or compares the barcode it sent, rather than the code field the server returns, will mismatch its own records against Open Food Facts.

Ask for only the fields you need

GET /api/v2/product/737628064502.json with no fields parameter, queried live this session, returned a 36,607-byte body: the full product record, with every nutrient, tag, and image reference the entry holds.

The same request with fields=product_name,brands appended, queried live this session, returned 212 bytes carrying only those two fields.

A client that fetches many products in a loop and never sets fields downloads the full record every time, even when the page only shows a name and a brand.