Skip to main content

Invalid Request Body

Reference · Errors

invalid_request_body422

Validation · Sign-in, email confirmation, account deletion and restore, horoscopes, time zone lookup, and request bodies that arrive too slowly

The request body is missing, empty, or not valid JSON. Check the content and Content-Type header.

What this means​

The endpoint expected a request body, and what we received either wasn't there, was empty, or couldn't be parsed as JSON. This check runs before field-level validation — if the body can't be parsed at all, we can't tell you which fields are wrong because there are no fields yet. Fix the body first; then field validation can run.

When you'll see this​

  • A POST or PUT request was sent without a body at all.
  • The request body was empty (an empty string or whitespace).
  • The body is JSON-shaped but has a syntax error (missing comma, unmatched bracket).
  • The Content-Type header wasn't application/json and the body was sent as form data instead.
  • A typo in the JSON serialization produced invalid output (e.g. "key":} instead of "key": "value").
  • The body arrived too slowly: the whole body must arrive within 30 seconds of the request starting.
  • An email confirmation or account restore link has expired or was already used.
  • The account deletion code is wrong or has expired (codes last 10 minutes and five tries).
Learn more about how this works

We require Content-Type: application/json and a syntactically valid JSON body on endpoints that take a body. If either condition fails, the request is rejected at the parsing layer before any schema-level validation. The details[] field in the response may contain hints about which part of the body failed to parse, when those hints are available.

The most common gotcha: this error often masquerades as a field validation error because devs assume "the field is missing." But the difference matters — a missing field returns validation_error, while a body that can't be parsed at all returns invalid_request_body. If you're seeing this, the issue is one level lower than fields.

Example response​

{
  "success": false,
  "error": "invalid_request_body",
  "message": "Request body is missing or malformed.",
  "details": [],
  "retry_after": null,
  "doc_url": "https://docs.asterwise.com/reference/errors/invalid_request_body/",
  "request_id": "req_01HXYZABCDEFGH",
  "timestamp": "2026-05-25T12:34:56Z"
}
NEW TO APIS?
Quick fix
  1. Verify the request body is non-empty and valid JSON. Test it in any JSON validator if unsure.
  2. Verify the Content-Type header is set to application/json.
  3. If you're constructing the body string manually, switch to JSON.stringify() or equivalent — manual JSON construction is the leading cause of this error.
PRODUCTION ENGINEER
Recovery pattern

This is almost always a client-side bug. Surface during integration testing, not in steady-state production code.

Python:

Production handler​

import httpx
import json

def call_asterwise(url, headers, payload):
    # httpx handles JSON serialization and Content-Type automatically
    response = httpx.post(url, headers=headers, json=payload, timeout=30)
    if response.status_code == 422:
        body = response.json()
        if body.get("error") == "invalid_request_body":
            raise ValueError(
                "Request body couldn't be parsed. "
                "Check JSON validity and Content-Type."
            )
    response.raise_for_status()
    return response.json()

Avoid this error by​

  • Always use your language's standard JSON serializer (JSON.stringify, json.dumps, etc.) rather than constructing JSON strings manually.
  • Always send Content-Type: application/json explicitly. Don't rely on defaults — some HTTP clients fall back to form-encoded bodies in surprising cases.
  • For form-driven UIs, never pass form data directly to the API. Build a JSON payload from form values first.
  • In integration tests, include a "what if the body is empty" case so this error class is caught before production.