What Is Validation in an API? A Developer’s Guide

API validation checks whether incoming request data has the expected structure, types, formats, limits, and business meaning. Do it at a trusted server-side boundary, before application logic uses the data. Client-side checks help people fix mistakes sooner, but they can be bypassed and are not a security control.

A reliable approach is to define the accepted input, parse it strictly, enforce field and request-size limits, validate relationships and business rules, and return a useful error without exposing internal details. Validation is one layer of security; it does not replace parameterized database queries, context-aware output encoding, safe parsing, or sanitization when those are needed. See the [OWASP Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) and [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html).

What API validation checks

Validation has two connected jobs: check syntax and check semantics. Syntax asks whether a value is shaped correctly. Semantics asks whether it makes sense in context. A string can parse as a date while still representing a date the business rules do not allow.

Structure and types: Are required fields present? Are unknown fields rejected or handled according to the contract? Is a quantity an integer rather than an arbitrary string?
Format: Does a date, identifier, currency amount, or other structured value follow its documented representation?
Bounds: Are strings, arrays, numeric values, dates, and the whole request within defined limits?
Allowed values: Does a status or category match one of the exact values the endpoint accepts?
Meaning and relationships: Does an end date follow a start date? Does a requested quantity fit the documented and current business constraints?
Message rules: Is the request using a supported content type, and can the body be parsed safely?

Set each bound from product and business requirements. Avoid generic limits copied without understanding the endpoint’s purpose. Prefer explicit accepted structures and values over a denylist of suspicious strings: denylist-only filters are easy to evade and may reject legitimate input.

Where validation belongs

Validate untrusted input as early as practical in the server-side data flow, before application functions rely on it. The server is the trusted enforcement point. Browser JavaScript can be disabled or altered, and a caller can send requests directly through a script or proxy. Client validation is still useful for immediate feedback, but it cannot establish that a request is safe or authorized. OWASP ASVS 5.0 states that client-side validation “must not be relied upon as a security control.”

Server-side validation checks structure and constraints before application logic uses request data.

Keep validation rules close to the boundary and centralize repeated mechanics where practical. A schema can establish the request’s shape and declared constraints; endpoint-specific code should enforce workflow and business rules that the schema cannot express or cannot verify against current state.

Build an explicit validation contract

Before coding, write down what the endpoint accepts. For a hypothetical booking request, that might mean a JSON object with an ISO date, a supported room type, and a guest count within limits. Those are examples only; choose real rules from your own product requirements.

A well-formed value can still fail a contextual or business rule.

Specify the media type. Document accepted request content types, such as application/json, and reject unsupported types rather than guessing how to parse them.
Set request-size limits. Limit the body at the HTTP server, gateway, or framework parser. Return HTTP 413 when the body exceeds the configured limit.
Parse safely and strictly. Use a maintained parser. Treat parse errors as client errors and do not continue with partial or ambiguous data. XML needs particular care around external entities and related parser attacks.
Check shape and primitive types. Require the fields you need, distinguish strings from numbers and booleans, and decide explicitly whether extra fields are allowed.
Constrain values. Apply documented enum values, string lengths, numeric ranges, array sizes, and appropriate format rules.
Apply contextual rules. Check relationships between fields and rules that depend on account, workflow, or current server state.
Return a stable error format. Identify the field and rule the caller can fix, but do not return stack traces, SQL, internal paths, or implementation hints.

Choose an approach for the input

Input	Useful approach	Watch for
JSON or XML body	Schema validation followed by business-rule checks	A schema does not necessarily capture workflow or state-dependent rules. XML parsers need secure configuration.
Numbers and dates	Strict parsing plus explicit minimum and maximum	Do not silently coerce malformed values or assume a universal range.
Small fixed choice set	Exact allowlist of accepted values	A client dropdown does not prove the caller may select a value.
Structured text	Validate the complete value against a narrowly appropriate format	Consider Unicode and normalization; avoid a broad regex that rejects valid text.
Free-form text	Accept legitimate content, then encode for its output context	Do not reject apostrophes or angle brackets simply because they can occur in attack strings.
Uploads or serialized objects	Apply format-specific checks and strict deserialization constraints	Do not trust a filename extension as proof of file content.

Validation facilities and schema tools can reduce duplicated code, but select maintained tools that fit your language and framework. A library does not decide the correct business limits for you. Document those limits in the API contract and keep implementation and documentation aligned.

Example: validate a JSON request in Python

This runnable standard-library example shows the boundary checks for a small JSON API. It deliberately uses illustrative rules; replace field names and bounds with the endpoint’s actual contract. It checks media type, body size, JSON shape, types, and simple rules, and returns generic client errors without a traceback.

from http.server import BaseHTTPRequestHandler, HTTPServer
import json

MAX_BODY = 16 * 1024
ALLOWED_STATUSES = {"draft", "active"}

class Handler(BaseHTTPRequestHandler):
    def send_json(self, status, payload):
        body = json.dumps(payload).encode("utf-8")
        self.send_response(status)
        self.send_header("Content-Type", "application/json; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

    def do_POST(self):
        if self.path != "/items":
            self.send_json(404, {"error": "not_found"})
            return
        media_type = self.headers.get("Content-Type", "").split(";", 1)[0].strip().lower()
        if media_type != "application/json":
            self.send_json(415, {"error": "unsupported_media_type"})
            return
        try:
            length = int(self.headers.get("Content-Length", "-1"))
        except ValueError:
            length = -1
        if length < 0:
            self.send_json(400, {"error": "invalid_content_length"})
            return
        if length > MAX_BODY:
            self.send_json(413, {"error": "request_too_large"})
            return
        raw = self.rfile.read(length)
        try:
            data = json.loads(raw)
        except (UnicodeDecodeError, json.JSONDecodeError):
            self.send_json(400, {"error": "invalid_json"})
            return
        if not isinstance(data, dict):
            self.send_json(400, {"error": "invalid_request", "field": "body"})
            return
        errors = {}
        name = data.get("name")
        status = data.get("status")
        quantity = data.get("quantity")
        if not isinstance(name, str) or not 1 <= len(name) <= 120:
            errors["name"] = "must be a string of 1 to 120 characters"
        if status not in ALLOWED_STATUSES:
            errors["status"] = "must be an allowed status"
        # bool is a subclass of int in Python, so exclude it explicitly.
        if isinstance(quantity, bool) or not isinstance(quantity, int) or not 1 <= quantity <= 100:
            errors["quantity"] = "must be an integer from 1 to 100"
        if errors:
            self.send_json(400, {"error": "validation_failed", "fields": errors})
            return
        # Apply authorization and state-dependent business rules here.
        self.send_json(201, {"ok": True})

if __name__ == "__main__":
    HTTPServer(("127.0.0.1", 8000), Handler).serve_forever()

Save as app.py and run python app.py. In another terminal, send a valid request:

curl -i http://127.0.0.1:8000/items \
  -H 'Content-Type: application/json' \
  --data '{"name":"Notebook","status":"draft","quantity":3}'

Try an invalid quantity or content type to see the corresponding error. This compact example is for explaining validation boundaries, not a production server: a deployed service also needs a production HTTP server, authentication and authorization where required, transport security, concurrency controls, and operational limits. Configure body limits in the server or gateway too; application checks after a framework has already read a huge body may be too late.

Validation errors and HTTP responses

Choose statuses consistently with your API contract. Common choices include 400 for malformed JSON or invalid request data, 413 for a body that exceeds the size limit, and 415 for an unsupported request content type. Some APIs distinguish syntactically valid but semantically invalid content with 422; consistency and documented behavior matter more than using a status callers cannot predict.

Return enough detail for a caller to correct the request, such as a field name and a concise rule. Avoid reflecting raw input without care, and do not expose stack traces or internal parsing details. Keep error shapes stable so clients can handle them. Log useful diagnostic context on the server, while taking care not to place secrets or sensitive request data in logs.

Validation is not a complete security boundary

A string that passes validation can still be dangerous when used in the wrong way later. Use parameterized queries for database access, encode output for the HTML, JavaScript, URL, or other context where it is rendered, and use safe parsers. Sanitize only when the application’s use case requires transforming content, such as allowing a limited subset of markup.

Do not use validation as a substitute for authorization. A user may send a perfectly well-formed account ID they are not allowed to access. Check permissions against the authenticated identity and resource on the server. Likewise, allowlists constrain values but do not prove that an action is permitted.

Performance, reliability, and cost

Validation usually saves downstream work by rejecting bad input before expensive processing. Keep boundary checks deterministic and bounded: cap request bodies and collection sizes before parsing or iterating deeply, avoid pathological regular expressions, and do not perform avoidable network calls as part of basic syntax checks. State-dependent checks may require database reads; make those rules explicit and consider race conditions where the rule can change between validation and the eventual write.

For reliable behavior, share schemas or contract definitions where feasible, test boundary values, and monitor validation failures by endpoint and error type. Do not silently “repair” ambiguous input in a way that changes its meaning. Prefer clear rejection over surprising coercion. Keep an eye on compatibility: tightening a rule can break older clients, so version or roll out contract changes deliberately.

Validation itself has no universal price tag. Engineering cost comes from defining and maintaining rules, selecting a parser or validation library, and handling errors consistently. Request-size caps, early rejection, and bounded rules also limit unnecessary processing. The right tradeoff depends on the input, expected traffic, and consequences of accepting an invalid value.

Common problems and fixes

Symptom	Likely cause	Fix
Malformed JSON returns a server error	Parser exceptions are not handled at the boundary	Catch parse failures and return the documented client error without a stack trace.
Valid clients get rejected after a deployment	A rule became stricter or an undocumented assumption was added	Compare the contract and implementation; make compatibility changes deliberate and document accepted values.
Oversized request exhausts memory	The body is fully buffered before enforcing a limit	Set limits at proxy, server, and parser layers; stop reading once the cap is exceeded and return 413.
“Sanitized” text breaks legitimate names	A denylist or overly broad pattern blocks ordinary punctuation or Unicode	Validate only constraints the field truly has; preserve free-form content and encode it on output.
Schema-valid request still causes a business error	Cross-field, authorization, or current-state checks were omitted	Apply contextual rules after structural validation and check permissions separately.
Unsupported body is parsed unexpectedly	Content-Type is ignored or guessed	Document accepted types and reject others with a consistent 415 response.
XML input triggers parser concerns	Unsafe parser features, including external entity handling, are enabled	Use a secure parser configuration and accept only the XML features the API requires.
Regex validation stalls on long input	A pattern has pathological backtracking or input has no length cap	Bound input first and use a simpler, well-understood pattern or parser.

Or skip the browser setup

For API work that needs a visual check of a page or a captured artifact, ScreenshotNeo offers a one-request screenshot API. It is a website screenshot API and MCP server from ScreenshotNeo; request options and details are in the API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server gives Claude, Cursor, and other MCP clients tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Create a free account and get 1,000 screenshots a month with no card.

FAQ

Should an API validate every field?

Validate every field the endpoint accepts, including optional fields when present. Define whether unknown fields are rejected or ignored, and apply field-specific rules rather than a single generic filter.

Can a schema replace validation code?

A schema can enforce structure and declared constraints. Add checks for permissions, workflow, relationships, and rules that depend on current application state.

Is a valid request safe to put in a database or HTML page?

No. Use parameterized database operations and encode output for its destination context. Validation does not neutralize every later use of a value.

Should invalid input be corrected automatically?

Only normalize when the transformation is defined and predictable, such as trimming whitespace where the contract allows it. Reject ambiguous values rather than silently changing their meaning.

Implementation checklist

Document required fields, types, formats, allowed values, and business rules.
Enforce validation on the server before application code trusts input.
Set body-size and collection limits before expensive parsing or processing.
Use safe parsers and reject unsupported content types.
Return stable, actionable errors without internal details.
Keep validation separate from authorization, safe database access, and output encoding.
Check boundary values and keep the published contract aligned with implementation.