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, an endpoint outside the endpoint character rule, an API key containing $ or a control character, 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.
  • An endpoint holding anything but the ASCII characters RFC 3986 permits, a , or a $, or a [ ] outside an IPv6 host. The endpoint is written into the collector configuration as it is, and the collector's supervisor refuses the whole configuration for such a character. Percent-encode any other character of the path, and write an internationalized host in its ASCII form. A request that the request schema already refuses for this reason answers 400 with the validation type instead.
  • An API key containing $ or a control character (a line break, a tab, a NUL, a Unicode line or paragraph separator). The collector reads ${...} as a reference to a file, an environment variable or a URL, so no value it carries may contain $. A request that the request schema already refuses for this reason answers 400 with the validation type instead.
  • 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. The API key may not contain $ or a control character; vendor keys (hex, base64, Api-Token …, Bearer …) never do. A Dynatrace key must be a dt0c01. access token or a dt0s16. platform token, or carry the Api-Token or Bearer scheme (Dynatrace setup*). The endpoint uses only the ASCII characters RFC 3986 permits, with no , or $ and [ ] only around an IPv6 host (percent-encode any other character of the path, and write an internationalized host in its ASCII form).
  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.

* restricted content — see higher-tier documentation