Amazon Import — Query Relaxation and Zero-Result Augmentation Exploration

When SearchItems returns zero matches for a user’s query, we have a choice about whether to do anything about it inside the BFF and, if so, which augmentation source to draw on and how to surface the result. This document is a pure exploration of that option space: it catalogues the available families of fallback, surveys the 2025–2026 provider landscape, and lists the integration patterns we could pick from. It captures no decisions — the chosen design for PDEV-457 lives in spec-analysis.md, and the deferred LLM-suggestion feature is parked in PDEV-569. Future revisits can replay the trade-offs here without redoing the survey.

Families of fallback

There are two qualitatively different ways to augment a failed search, plus a hybrid that uses an LLM only as a query reformulator.

Family A — Stay within Amazon

Cheapest, predictable, where every mature ecommerce-search vendor starts.

Option	Behaviour	Cost
A1. Query relaxation	If the first `SearchItems` returns zero, retry up to N times dropping one constraint at a time: `searchIndex` → `browseNodeId` → `deliveryFlags` → rarest keyword. Stop at first non-empty result.	+0–N extra Amazon S2S calls; same TPS/TPD pool.
A2. Typed-field reroute	If the first call sent everything as `Keywords`, retry with the same tokens routed into Amazon’s typed fields (`Title`, `Brand`). Sometimes finds a hit a generic keyword search misses.	+1 Amazon call.

These don’t need any external dependency; they’re done with the SDK we already have. They are the natural first step of any zero-result strategy.

Family B — Outside Amazon (public web search / LLM-search)

Useful when the user’s product is genuinely not on Amazon, or when the query is so far off that no amount of Amazon-side relaxation will help. The 2025–2026 landscape shifted hard:

Microsoft Bing Search APIs were retired on 2025-08-11. All sub-APIs (Web, Image, News, Custom, Autosuggest, Spell-Check, Entity, Visual, Local Business) are dark. Migration path (Azure AI Foundry) is a platform commitment, not a drop-in swap.
Google Custom Search JSON API is closed to new signups in 2025; existing customers have until 2027-01-01 to migrate to Vertex AI Search.

What is left:

Provider	Type	Pricing (2026 snapshot)	Notes
Brave Search API	Web search (independent index)	$5 / 1k requests; no free tier as of late 2025	Closest Bing replacement. Storage rights gated by plan tier. Real, independent index — not a Google scraper. Rate-limit headers exposed.
Tavily Search API	AI-search for agents (search + answer synthesis + citations)	~$0.008 / query Researcher; 1000 free / month	Designed for LLM agents — returns ranked, filtered, RAG-ready snippets. Acquired by Nebius in Feb 2026; vendor health worth monitoring.
Perplexity Sonar API	Search-augmented LLM	Per-token pricing	Returns answers with citations; can be prompted to suggest alternative search terms.
SerpAPI / Serper / Bright Data	Google-SERP proxies	~$0.0003–$0.001 / query at scale	Cheapest per call but TOS grey area (scraping Google SERPs). Large, stable vendors.
Firecrawl Search	Search + LLM-ready page extraction	Per-page	Search hit + content scrape in one call. Heavier than we need just to suggest a query.
OpenAI / Anthropic Claude API	LLM, no built-in web	Per-token	When used for query reformulation only, the LLM never hits the web — it leans on training data to propose alternative phrasings. See Family C.

Bing and Google CSE are not viable as new dependencies in 2026.

Family C — Hybrid (LLM as query-reformulator)

Worth calling out separately because it’s the cheapest “AI” option and stays inside Amazon’s product graph:

Send the failed query to an LLM with a prompt asking for 3–5 alternative phrasings that might find similar products on Amazon.
Either re-run SearchItems with each suggestion until one yields hits, or expose the suggestions to the caller and let the caller decide.
One LLM round-trip; typically a few tenths of a cent on a small model.
All resulting matches still come from Amazon — no DTO-shape headaches, no provenance ambiguity, no compliance concerns about who is allowed to display what.

This is materially different from Family B: B searches the web and might return non-Amazon URLs that would have to be mapped back to ASINs; C just rewrites the user’s query and re-uses Amazon.

Integration patterns

Independent of which augmentation source is chosen, there are five plausible ways to wire it into the route contract.

Pattern	Caller experience	Latency on empty	Predictability	Notes
I1. Silent server-side fallback	Caller sees a populated `items` array; no idea the search was augmented.	Worst — every empty hit pays the extra round-trip(s).	Low — caller cannot reason about why these results appeared.	Cheapest UX delta, highest hidden cost. Only safe for Family A (relaxation): data still comes from Amazon.
I2. Request-level opt-in flag	Caller adds e.g. `augmentation: "off" \| "suggestions" \| ...`.	Only when caller asks for it.	High.	Lets cheap callers stay cheap; lets agentic callers spend extra budget when warranted. Slight contract bloat.
I3. Follow-up pointer in the response	Empty `items` plus a `followUp: { kind, route, query, ... }` block telling the caller how to retry.	Zero — server does not augment at all.	Highest.	Caller drives the second call. Most “REST-ish”; ideal for an agent caller that wants to reason between steps.
I4. Suggestions inline	Empty `items` plus `suggestions: string[]` (alternative queries generated server-side).	One LLM round-trip on empty.	Medium.	Caller decides whether to re-search. Cheaper than I1 in steady state, more useful than pure I3.
I5. Dedicated `/api/amazon/refine` route	Caller hits `/search`; on empty, separately hits `/refine`.	Zero from `/search`; full augmentation latency on `/refine`.	Highest — two clean contracts.	Adds a third route; only worth it if augmentation grows into something rich (multi-provider, ranking, etc.).

Adjacent ideas

Options that fall outside the three families above but that a future revisit might want to weigh:

Spelling correction as a dedicated relaxation step — Amazon’s own spell suggestions show up on the response under SearchRefinements.otherRefinements. The current BFF drops refinements at the boundary; surfacing them would be an alternative to (or supplement of) Family C reformulation.
Synonym expansion via a static dictionary (e.g. WordNet) or an LLM-built map. Lighter-weight than full Family C reformulation and not subject to model-cost variance.
Suggestion re-search as a separate route (/api/amazon/refine) that takes a single suggestion string and returns its SearchItems result. Only worth considering if an agentic caller pattern demands it; mentioned for completeness.