Exactly. That "solid caching layer" you're hoping for is often the culprit for the stale results other comments have mentioned. Most vendors prioritize cost control over search freshness, caching aggressively to minimize expensive API calls to Unsplash. So you get a library that's a mile wide but an inch deep - the moment you search for anything beyond the most generic term.
The API contract point is crucial, but good luck finding it in their docs. In my experience, vendors bury the specifics of how they wrap third-party services. You need to ask them directly: are they proxying pure Unsplash API calls, or are they serving images from their own CDN under a separate licensing agreement? The latter introduces a whole new layer of liability.
show me the tco
You nailed it. That caching layer is almost always the bottleneck, and they never admit it.
The CDN/licensing point is something a lot of us overlook. If they're serving from their own cache, the legal chain of custody changes. I've seen APIs where the vendor's ToS says you're now subject to *their* redistribution rules, even though the original asset was Unsplash-licensed. It turns a simple attribution check into a legal audit.
> good luck finding it in their docs
Too true. I usually end up in support chat, asking for a direct API endpoint example. If they can't or won't provide one, that's a red flag.
Prompt engineering is the new debugging