Alarm Ingestion API HTTP 202 returns application/json with a plain text body

Products

DX SaaS DX OI SaaS DX Operational Intelligence DX Operational Observability

Issue/Introduction

When integrating an external source with the DX Operational Observability Alarm Ingestion API (POST /jarvis/v2/ingestion), a successful ingestion returns HTTP 202 Accepted with the response header Content-Type:

application/json;charset=UTF-8

But the response body is the plain text string "Accepted Payload", which is not valid JSON.

Consumers that automatically parse the response based on the declared Content-Type, for example the Azure Logic Apps built in HTTP action or other strict clients that deserialize based on the declared Content-Type, fail to parse the body and report the successful call as a failure.

A typical symptom in Azure Logic Apps is a BadRequest error:

"HTTP request failed: the content was not a valid JSON... Unexpected character encountered while parsing value: A".

Note that the alarm is ingested successfully; only the response handling on the client side fails.

Environment

DX Operational Observability (SaaS), Alarm Ingestion API.

Cause

On the successful ingestion (HTTP 202) path, the API sets Content-Type: application/json;charset=UTF-8 but returns the plain text body "Accepted Payload".

Because the declared Content-Type states JSON while the body is not valid JSON, strict consumers that parse the body based on the declared Content-Type fail, even though the request succeeded.
The response also carries x-content-type-options: nosniff, which confirms that the declared content type should be trusted rather than guessed; this is an observed header on the 202 response, not the mechanism that drives client parsing. On error paths (for example 401), the endpoint returns a matching JSON body, so the mismatch is specific to the 202 success path.

Resolution

This is resolved in the DX Operational Observability 26.8.2 SaaS release.

The fix ships in that release and reaches tenants according to the regional SaaS update schedule, so it may not yet be live in every region. Confirm your tenant's current version with Broadcom Support, and rely on the interim workaround below until 26.8.2 is deployed to your tenant.

Until your tenant is updated, use one of the following workarounds on the consumer side to treat the 202 as success independently of body parsing. These checks treat only HTTP 202 as success, so genuine errors still surface.

Azure Logic Apps | Option A (configuration only): Place the HTTP action inside a Scope, which is a container that lets the flow continue past the failed action. Add a guard action after the Scope and, on that guard action, enable "Configure run after" for all four states (is successful, has failed, is skipped, has timed out) so it always runs.
Then add a Condition that validates success on the status code instead of the body using the expression @equals(outputs('HTTP')?['statusCode'], 202), and replace 'HTTP' with the actual name of your HTTP action. Confirm in the run history that the 202 status code is exposed on the failed HTTP action; if the status code is not exposed there, use Option B instead. The Scope can be omitted if you set "Configure run after" directly on the action that follows the HTTP action.

Azure Logic Apps | Option B (most robust): Make the call from an Azure Function that reads the response body as raw text (no JSON parsing) and returns a clean object such as {"statusCode":202,"accepted":true} to the Logic App, then branch on that.

Other consumers: treat any 2xx status as success and avoid failing outright on response body deserialization for this endpoint.

Additional Information

The correct token type for this endpoint is the APM Gateway Tenant token (Authorization: Bearer <tenant token>). Independently reproduced via Postman (status 202 Accepted; body "Accepted Payload" shown in the JSON viewer) and via Azure Logic Apps (HTTP action failure as quoted above).

Alarm Ingestion API: Alarm Ingestion Api