Skip to main content
AnySport’s error code system is deliberately kept minimal, with just a handful of HTTP status codes, each corresponding to a fundamentally different category of problem. Understanding the underlying distinction between these categories will help you design more robust client-side retry and error-handling logic.
This type of error means your request parameters don’t satisfy the endpoint’s requirements — for example, a conditionally required parameter was omitted (e.g. querying /matches by league_id without including season), a parameter has the wrong type, or a pagination parameter is out of its valid range.Recommendation: Don’t retry the same request — retrying will only produce the same error. Instead, correct the parameters based on error.message or the endpoint’s parameter table in the documentation, then send the request again. This type of error should typically be caught and eliminated during development/integration testing.
Commonly seen with detail-type endpoints, such as a match that doesn’t yet have lineup data (/lineups) or hasn’t started yet and therefore has no situation data (/matches/{match_id}/situation). This doesn’t mean your request was incorrect — the resource simply doesn’t exist at this point in time.Recommendation: Handle it at the business logic level as “no data available yet” (e.g. showing “Lineup not available” on the frontend), rather than reporting it as a system error. For time-sensitive resources (such as lineups close to kickoff), consider retrying later.
An unexpected error occurred while the server was processing the request, unrelated to your request content.Recommendation: This is the only error type where automatic retry is recommended, using an exponential backoff strategy (e.g. 1s → 2s → 4s, with a retry limit). If the error persists after retrying, contact support and include the traceId of the failed request (see Response Format).
For the complete structure of failure responses (success / error.code / error.message), see Response Format.