Problem type:
https://docs.nordicfinancialnews.com/problems/semantic-unavailable503 when a search using mode=semantic cannot be completed. Two things can cause it:
- Your query could not be turned into an embedding, because the upstream call failed or did not finish inside its 3 second timeout.
- The query embedded, but the vector search itself was cancelled for running past the database’s 15 second statement timeout. A broad filter over a large candidate set can reach it.
mode=semantic can return this. Keyword search is unaffected and stays available throughout.
Example response
detail names the embedding in both cases, so it does not tell you which of the two you hit. You do not need to know in order to recover: the handling is the same either way.
Response headers
Why you get an error instead of keyword results
When semantic matching is unavailable, the API could quietly rank your results with keyword search instead. It deliberately does not. A silent fallback would return a differently ranked page under an identical request shape, with nothing in the response to say which ranking you received. That is difficult to detect and worse to debug, particularly for an agent that cannot tell the two apart. Failing explicitly means a200 from a mode=semantic request always contains a genuine semantic result.
Choosing keyword ranking is therefore yours to make, not something the API does on your behalf.
How to fix it
Wait the number of seconds inRetry-After and retry the same request. This condition is usually brief.
Python
mode=semantic and use keyword search until it recovers. Make that switch explicit in your own code so you always know which ranking produced the results you are holding.
Retrying safely
Successful query embeddings are cached for one hour, keyed on the query text after case folding and trimming, and shared across every surface. A query embedded within the last hour is normally served from that cache, so a retry of it does not re-embed. That removes one of the two causes, not both. The vector search still runs on every request, cache hit or not, so a repeat can still be cancelled and return this same error. A timed-out or failed embedding is not written to that cache, so a retry after an embedding failure genuinely re-attempts the call rather than replaying a stored failure. Each attempt draws on your semantic search allowance, including the ones that end in this error. The allowance is checked before the query is embedded, so a503 costs you a call and so does every retry of it. Retry on Retry-After rather than in a tight loop, or you can turn one outage into a 429 on top of it.
Related
- Error handling for the full problem type list
- Rate limit exceeded for the
429returned when you exceed a request limit