Errors

Every non-2xx response body is a Problem Details document (RFC 9457, supersedes RFC 7807), Content-Type: application/problem+json:

{
  "type": "https://data.placepoint.no/problems/validation",
  "title": "Your request didn't validate.",
  "status": 400,
  "detail": "The request body contains one or more validation errors.",
  "instance": "urn:uuid:123e4567-e89b-12d3-a456-426655440000",
  "code": "VALIDATION_FAILED",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736"
}

• type: a URL identifying the problem class.
• title: short, human-readable, fixed per type.
• status: the HTTP status as a number.
• detail: what went wrong in this specific request.
• instance: the request path or a urn:uuid: correlating to logs.
• code: a stable machine code, SCREAMING_SNAKE_CASE.
• traceId: quote this to support when asking for help.

The response types in the spec

Every operation's error responses come from a shared set:

Response	Status	Meaning
BadRequest	400	The request body or a parameter failed validation.
Unauthorized	401	The bearer token is missing, expired or invalid.
Forbidden	403	The token lacks the scope this operation needs.
NotFound	404	No such resource in the served registers. A resource that exists but belongs to another tenant answers 404, not 403, so callers cannot probe for existence.
TooManyRequests	429	Rate limit or daily quota exceeded; see Rate limits and quotas.
InternalError	500	Something failed on our side; quote traceId to support.

The one exception: POST /auth/token

The token endpoint is OAuth, not the resource API, so a failed grant follows RFC 6749 Section 5.2 instead of Problem Details: application/json with error and error_description, not type/title/code.

{
  "error": "invalid_client",
  "error_description": "Unknown client_id or invalid client_secret."
}

See Authentication for the full token flow.