Errors

Every error from the API looks the same, whichever endpoint you called and whatever went wrong. That means you can write one error handler for your whole integration. This page covers what’s in an error, which field your code should rely on, and what to include when you contact support.

Every non-2xx response uses the same envelope, including the ones generated at
the edge. No path returns HTML or a bare string.

{
  "error": {
    "type": "invalid_request",
    "code": "member_age_requirement",
    "message": "Members must meet the age requirement for this community.",
    "param": "date_of_birth",
    "doc_url": "https://developer.community.com/errors#member_age_requirement",
    "request_id": "req_8f4e2a1b-3c5d-4e6f-9a0b-1c2d3e4f5a6b"
  }
}

What to branch on

Branch on code. It is the stable machine reason and is never renamed or
repurposed once documented.

type is the coarse family and is a closed set: invalid_request,
not_found, conflict, rate_limited, internal. New codes are added over
time, so when you meet a code you do not recognise, fall back to its type.

message is one human sentence and is not the thing to parse.

request_id

Always present, and the same value appears in the response header, our edge
logs and the audit record. Quote it in a support ticket and it threads the
whole trace.