Skip to main content
Problem type: https://docs.nordicfinancialnews.com/problems/semantic-unavailable
The API returns this problem type with HTTP 503 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.
Only requests that ask for mode=semantic can return this. Keyword search is unaffected and stays available throughout.

Example response

The 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 a 200 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 in Retry-After and retry the same request. This condition is usually brief.
Python
If it persists past a few retries, drop 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 a 503 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.
Last modified on September 8, 2026