Free tools

HTTP 422 Unprocessable Content

The server understood the content type but the fields are invalid. Free reference, no signup.

422 Unprocessable Content

MeaningThe server understood the content type but the fields are invalid.
WhenJSON parsed, and validation failed.
CausesA missing channel or title, a bad email, or a value outside the allowed set. Trigv returns 422 for invalid event fields.
FixRead the errors object and correct the fields.
RetryDo not retry the same body.
Alert?Usually no. Alert if a job that used to pass validation starts getting 422.

Runs in your browser. Nothing you enter is stored.

Most 422s are not an incident

Alert if a job that used to pass validation starts getting 422.

curl -sS -X POST https://api.trigv.com/v1/events \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer $TRIGV_API_KEY" \
  -d '{"channel":"ops","title":"HTTP 422","level":"warning"}'

How to use it

  1. Read what 422 means before changing a retry loop.
  2. Check the common causes against the response body and the server log.
  3. Follow the retry note. Retrying a 400 with the same body will fail again.
  4. Alert only in the cases the verdict describes.

About this tool

HTTP 422 Unprocessable Content means The server understood the content type but the fields are invalid. Servers send it when JSON parsed, and validation failed.

Common causes: A missing channel or title, a bad email, or a value outside the allowed set. Trigv returns 422 for invalid event fields. The practical fix is: Read the errors object and correct the fields.

Retry: Do not retry the same body.

Alert on it? Usually no. Alert if a job that used to pass validation starts getting 422.

Trigv is a push for the moment a status starts mattering, not a log of every response. If the code is one you should hear about, the snippet posts a single event with level error or warning. The status page itself does not call your API.

Questions

What is HTTP 422?

The server understood the content type but the fields are invalid.

Should the client retry?

Do not retry the same body.

Should I alert on it?

Usually no. Alert if a job that used to pass validation starts getting 422.

How is this different from reading the spec?

The page adds a plain retry note and an alert verdict for people running the service, not only for people parsing the response.