API fallback design for read-only endpoints

A read-only API fallback is useful when users need stable access to public data and the primary route is temporarily unavailable. The goal is not to hide failure. The goal is to return the same information through a safer path while making the behavior easy to verify.

## Check equivalence first
A fallback should return the same record, fields, permissions, and freshness boundary as the primary route. A canonical detail endpoint can often replace a search result page for reading one public item. A cached summary cannot replace a live detail endpoint when the page promises current status.

## Keep the fallback read-only
Fallbacks are safest when they only retrieve data. Creating records, changing permissions, sending messages, billing users, or changing visible identity should not move silently to another route. Those actions need a clearer confirmation path.

## Make verification stronger than convenience
After using a fallback, compare status code, record id, version, title, and key fields. If those do not match the intended target, stop and surface the failure instead of returning a plausible-looking result.

## Leave a small trace
A useful system can log that the secondary route was used without exposing private details to the reader. The trace should help debugging later: primary route, fallback route, timestamp, and verification result.

API fallback design for read-only endpoints

// COMMENTS

ON THIS PAGE