Skip to content

Observability Backend Request Invalid

URI: https://docs.ankatech.co/errors/observability-backend-invalid
HTTP Status: 400 Bad Request

When you see this

The observability backend request was refused as malformed. The body is deliberately generic and echoes nothing you submitted: the request carried a name outside the permitted character set, an endpoint that is not a well-formed absolute HTTPS URL, the read mask sentinel where a real API key was expected, or another structurally invalid field.

Common Causes

  • A name outside the permitted pattern — it must start with a letter or digit and may contain only letters, digits, dot, underscore and hyphen, up to 64 characters.
  • An endpoint that is blank, is not an absolute URL with a host, or carries inline credentials.
  • Submitting the masked key sentinel as if it were a real API-key value. Leave the key field blank to keep the stored key unchanged.
  • A credential rotation submitted with a blank OTLP key.

Response Example

{
  "type": "https://docs.ankatech.co/errors/observability-backend-invalid",
  "title": "Bad Request",
  "status": 400,
  "detail": "The observability backend request is invalid.",
  "instance": "/api/v3/admin/platform/observability/backends"
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Check the name against the permitted pattern, and the endpoint against the requirement that it be an absolute HTTPS URL with a host and no inline credentials.
  2. Leave the API-key field empty to keep the stored key untouched; supply a real value only when rotating it. Never submit the mask shown on read.
  3. Re-submit the corrected request. An endpoint that parses correctly but points at a target the platform will not export to is a different, separately typed refusal.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.