Prepare and get flow
In v3 thesearch controller handles prepare and execute automatically. When you call get(), the controller prepares the query if needed and retries a 425 response until results are ready.
prepare() directly to cache expensive work before calling get().
Reusing a prepared search across pages
Configurestorage when you want the results page to reuse a prepared search ID. The SDK stores the prepared ID by the canonical query and request parameters, then resolves it automatically on the next page.
prepare() before navigating so the search_id is written to storage. If navigation happens first, the request is likely cancelled and the results page prepares again, which is correct but slower. On the results page, create sdk.search({ query }) with the same request parameters and call get(). Do not read a search ID from the URL or pass one to get().
Debouncing autocomplete
For search-as-you-type, useautocomplete() and debounce the input in your framework or with createDebounce() from the SDK.
suggest() method also debounces, but new integrations should use autocomplete() with their own debounce logic.
Concurrent API calls
Callsearch.prepare() and autocomplete.get() concurrently for a fast search-as-you-type experience.
Aborting stale requests
Controllers are tied to a single request lifecycle. To abort a previous request (for example, when the shopper types a new character), dispose the old controller and create a new one.Next steps
Caching
Learn how the SDK caches requests and results.
Performance
Optimize your implementation for speed.