Zamawiając sesję zdjęciową przez API, nie dało się powiedzieć, którego produktu dotyczy. Na koncie z więcej niż jednym produktem decydowało sortowanie — wygrywało najstarsze opisane zdjęcie. W odpowiedzi nie było tego widać, a wynik wystarczająco często wychodził poprawny, żeby wyglądać na zamierzony, więc integracja pracująca na kilku produktach nie miała jak się upewnić, za wygenerowanie którego właśnie zapłaciła.
Wywołanie przyjmuje teraz productId — i jest to ten sam identyfikator produktu, który wydaje reszta tej powierzchni, więc wartość odczytana z jednego wywołania działa w sąsiednim. Produkt spoza konta zostaje odrzucony z podaniem powodu, zamiast po cichu ustąpić miejsca produktowi wybranemu automatycznie. Niepodanie żadnego zachowuje dotychczasowe zachowanie.
Każda odpowiedź mówi teraz, co zostało ustalone. Blok source podaje produkt, zdjęcie i sposób, w jaki każde z nich zostało wybrane — również przy wywołaniu, które tylko pyta o gotowość konta i niczego nie zamawia.
Powtórzenie wywołania nie grozi już drugą opłatą. Do tej pory powtórka po zakończonym zamówieniu zachowywała się tak, jakby nic wcześniej nie zaszło, i zamawiała ponownie. Jeśli zdjęcia z poprzedniego zamówienia wciąż czekają na Twoją ocenę, wywołanie jest teraz odrzucane i nic nie zostaje wydane; wysłane jeszcze raz z confirmReorder zamawia tak jak wcześniej. Zamówienia nieudane i anulowane nadal przepuszczają powtórkę bez zmian — i to właśnie sprawia, że ponowienie po prawdziwej awarii jest bezpieczne.
Dwie kolejne odmowy zamykają przypadki, które wcześniej kończyły się opłatą bez żadnego rezultatu: wywołanie, które zmieniłoby nazwę produktu na koncie, gdzie nic jeszcze nie zostało opisane, a produktów jest więcej niż jeden, oraz wywołanie trafiające na produkt, którego analiza się nie powiodła. Obie odmawiają przed zapisem i obie dotyczą wyłącznie danego produktu — pozostałe produkty konta zamawiają normalnie.