How SeaLink handles upstream disruption

Model APIs can degrade for reasons outside a customer's control: provider incidents, regional capacity, temporary auth failures, or maintenance windows. A production gateway should make those failures visible and keep the customer contract simple. SeaLink's public behavior is intentionally narrow: consistent errors, request IDs for support, status pages, and response headers that show when routing changed.

SeaLink routes customer traffic through a gateway layer that can stop sending new requests to unhealthy upstream paths. Customers keep using the same SeaLink API key and model ID; the operational change stays behind the API. The public contract is the API behavior: consistent errors, request IDs for support, and visible headers when a fallback is used.

When an upstream path is unavailable, SeaLink can route to a comparable model from a different upstream. /docs/error-codes documents customer-visible failure behavior. Customers see a 502 only if every eligible path also fails. This can change model behavior, so SeaLink surfaces the substitution via X-SeaLink-Fallback: true on the response. Customers who care can detect it and decide what to do — retry, accept the answer, or surface the degradation to their own users.

Two reasons. First, you'll find out anyway when something goes wrong; better to have read about it in advance than to debug it during an outage. The X-SeaLink-Fallback header and /docs/error-codes are part of the same contract — what you can expect, what you can detect, what you can do about it. Second, some applications need a stricter single-provider contract, custom uptime terms, or dedicated operational controls. SeaLink is the right choice when you want one API, clear fallback behavior, and visible degradation signals.