Validation Error
validation_error422
The request payload failed schema validation. The
details[]field lists exactly which fields failed and why.
What this means
We received a structurally complete request, but one or more fields failed validation against the endpoint's schema. The check runs before any business logic — no calculation engine, no database query, no external service was touched. The details[] field in the response body lists every field that failed, with enough information to fix each one programmatically.
When you'll see this
- A required field is missing from the request body.
- A field has the wrong type (string where a number was expected, etc.).
- A field's value is outside the allowed range or doesn't match a required pattern.
- A nested object is malformed in a deeper part of the request payload.
- A field's value isn't in an allowed enum set.
Learn more about how this works
Asterwise uses Pydantic for request validation. When a request fails schema, we surface every error in one response rather than failing on the first one — so you can fix all the issues in a single iteration. Each entry in details[] follows this shape:
{
"loc": ["body", "birth", "lat"],
"msg": "Input should be greater than or equal to -90",
"type": "greater_than_equal",
"input": -91.5
}
Field meanings:
loc— array path to the offending field, starting from request part (body,query,path).msg— human-readable description of what's wrong.type— machine-readable Pydantic error type. Stable identifier you can switch on.input— the value that failed (when not redacted for sensitive fields).
The most common gotcha: details[] is always present and always a list, but it might be empty if validation failed at a non-field level (e.g. invalid JSON). Code defensively for both shapes.
Example response
{
"success": false,
"error": "validation_error",
"message": "The request couldn't be processed. See the 'details' field for specific field-level issues.",
"details": [
{
"loc": [
"body",
"birth",
"lat"
],
"msg": "Field required",
"type": "missing",
"input": {}
}
],
"retry_after": null,
"doc_url": "https://docs.asterwise.com/reference/errors/validation_error",
"request_id": "req_01HXYZABCDEFGH",
"timestamp": "2026-05-25T12:34:56Z"
}
- Look at the
details[]field in the response body. - For each entry, find the field at the path indicated by
locand check themsgfor what's wrong. - Fix the offending values and retry. If
details[]had three entries, you should expect three fewer errors on the next attempt.
Parse details[] and surface field-level errors to your UI. Don't just show "validation error" — the whole point of returning structured field errors is to make per-field error messages possible.
Python:
Production handler
- Python
- TypeScript
import httpx
from typing import Any
class ValidationFailedError(Exception):
def __init__(self, details: list[dict[str, Any]]):
self.details = details
msg = "; ".join(
f"{'.'.join(str(p) for p in d['loc'])}: {d['msg']}"
for d in details
)
super().__init__(msg)
def call_asterwise(url, headers, payload):
response = httpx.post(url, headers=headers, json=payload, timeout=30)
if response.status_code == 422:
body = response.json()
if body.get("error") == "validation_error":
raise ValidationFailedError(body.get("details", []))
response.raise_for_status()
return response.json()
interface ValidationDetail {
loc: (string | number)[];
msg: string;
type: string;
input?: unknown;
}
class ValidationFailedError extends Error {
constructor(public details: ValidationDetail[]) {
const msg = details
.map((d) => `${d.loc.join(".")}: ${d.msg}`)
.join("; ");
super(msg);
}
}
async function callAsterwise(url: string, headers: HeadersInit, payload: unknown) {
const response = await fetch(url, {
method: "POST",
headers,
body: JSON.stringify(payload),
});
if (response.status === 422) {
const body = await response.json();
if (body.error === "validation_error") {
throw new ValidationFailedError(body.details ?? []);
}
}
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return response.json();
}
Avoid this error by
- Validate user input on your side before constructing API requests. Most validation errors are catchable in your UI before they cross the wire.
- Use our SDK types if you're in Python or TypeScript — they encode the schemas and catch many of these errors at compile or type-check time.
- For typed languages, mirror our schemas in your data classes rather than constructing dicts by hand.
- When you see this in production logs, check whether the failure is a single bug or a pattern. A pattern usually means an upstream system is sending malformed data.