Ordering a photo shoot through the API could not say which product it was for. On an account holding more than one, the product was decided by sort order — the oldest described photo won. That is invisible in the response and correct often enough to look deliberate, so an integration working across several products had no way to be sure which one it had just paid to generate.
The call now takes a productId, and it is the same product id the rest of this surface hands out, so a value read from one call works in its neighbour. A product that is not on the account is refused with a reason rather than quietly falling back to a resolved one. Naming none keeps the previous behaviour.
Every answer now says what it resolved. A source block reports the product, the photo, and how each was arrived at — including on a call that only asks whether the account is ready and orders nothing.
Repeating the call no longer risks a second charge. Until now, a repeat after a finished order behaved as if nothing had happened and ordered again. Where photos from the previous order are still waiting for your review, the call is now refused and nothing is spent; sending it again with confirmReorder orders as before. Orders that failed or were cancelled still let a repeat through untouched, which is what makes a retry after a genuine failure safe.
Two further refusals close cases that used to end in a charge with nothing to show for it: a call that would rename a product on an account where nothing has been described yet and more than one product exists, and a call resolving to a product whose analysis failed. Both refuse ahead of the write, and both are scoped to the product in question — the account's other products still order normally.