When handing an image to an AI provider, send the actual bytes from our side. Never hand it one of our own proxy URLs to go fetch — that is a timeout and a token burn waiting to happen.
Doozer serves business photos through its own image proxy (?e=photo) — caching, CDN-offload, session-less for performance. So when we need an AI provider to look at a photo (vision for color extraction, content, a header), the obvious thing is to hand the provider that photo's URL. We already have a nice stable URL for every image. Just pass it.
That is the trap.
Handing a provider our ?e=photo URL means the provider's servers now make a round trip back into our infrastructure to fetch the image before they can process it. That adds a second, slower hop we do not control; if our proxy is cold, busy, or the image must be fetched-and-cached on demand, the provider's request can hang until it times out. And a vision call that times out often still bills for the attempt. So the "convenient" URL turns one clean operation into a fragile cross-network dependency that can both fail and cost.
Fetch the image bytes on our side and inline them into the provider request (base64 / multipart, whatever the provider takes). One hop, fully under our control, no loopback into our own proxy. The provider gets exactly the bytes, immediately.
A related tell from the same area: expected-stale photo failures log to a file, not the error_logs DB table, because a predictable miss is not an incident and high-volume logging bloats that table.
The insight is spotting the accidental loopback: our own URL, handed outward, becomes an inbound request we then have to serve under someone else's timeout. It looks like reuse ("we already have a URL!") and it is actually a hidden dependency cycle. Send the thing itself, not a pointer back to yourself.