What it means

PreVOP reached the upstream VOP provider but the provider's response was unusable — either a 5xx status, a non-parseable body, or the TCP / TLS connection did not complete. This is the catch-all for "upstream misbehaved" and is usually transient.

When you'll see it

• The upstream provider returned any non-2xx HTTP status that PreVOP did not map to a more specific error (FORMAT_ERROR, CLIENT_INVALID, etc.).
• The upstream response body could not be parsed as the expected JSON schema.
• The TLS handshake with the upstream failed — expired certificate, wrong CA, cipher mismatch.
• The TCP connection was reset mid-response, or DNS resolution for the upstream failed.
• An upstream planned or unplanned outage is in effect; alseda typically detects and announces these.

Example response

HTTP/1.1 502 Bad Gateway
Content-Type: application/problem+json
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-Rejected-By-Provider: false

{
  "type":    "https://errors.prod.prevop.alseda.eu/errors/upstream-unavailable",
  "code":    "UPSTREAM_UNAVAILABLE",
  "title":   "Upstream provider unavailable",
  "status":  502
}

How to fix

1. Retry the request with a fresh X-Request-ID. Most UPSTREAM_UNAVAILABLE responses are transient and the retry succeeds.
2. Back off on sustained failures — if several retries in a row return 502, pause and try again in 30–60 seconds; do not hammer.
3. If failures persist for several minutes, assume an upstream outage and check any alseda status channel you have access to.
4. Contact alseda with the X-Request-ID of a failing call so we can correlate the failure with our upstream logs.

Related

• Customer API Contract §4.4 — UPSTREAM_UNAVAILABLE example + retry guidance
• See also: UPSTREAM_TIMEOUT — same general class of failure, but specifically when the upstream did not respond in time.