Adobe Target AB Activity REST API does not round-trip additional metric configuration used by the UI

These are the docs that I used: https://developer.adobe.com/target/administer/admin-api/#tag/Activities/operation/updateActivity_3

Hi ​@BENE,

The Target Admin API and the Target UI essentially speak two different "dialects" of the same logic. You are seeing this mismatch because the public REST API (v3) is designed to handle the functional delivery of a test, whereas the UI stores extra "presentation" data to make the Goals & Settings wizard look pretty.

Here is why the 404/Invalid Property error is happening and how to fix it:

1. The successCriteria Field is Internal-Only

The property you found in the browser debugger (successCriteria) belongs to the Private UI API.

• The Problem: The Public REST API does not recognize this field. When you try to PUT it, the API gateway rejects it because it’s not in the official schema.

• The Consequence: This is why your round-trip "breaks." You are pulling a simplified model and trying to push back a complex one that the API doesn't support.

2. How the API Defines Metric Types

In the public REST model, a metric’s "type" (Conversion, Engagement, Revenue) is inferred from the presence of specific properties rather than a single label.

When your GET call returned "mboxes": [], it stripped the "Conversion" logic. If you PUT that same empty array back, the UI has no data to map to, so it displays the metric as unconfigured or "broken."

3. The Solution: "Hydrate" the Metrics

To successfully round-trip an activity without breaking the UI, you must manually populate the functional fields that the UI uses to "guess" the metric type.

Instead of sending successCriteria, send a fully-formed metrics object:

JSON

"metrics": [
  {
    "metricLocalId": 1027,
    "name": "Purchases from Specific Users",
    "mboxes": ["your_mbox_name"], // MUST NOT BE EMPTY
    "unit": "count" // Tells Target to treat it as a conversion count
  }
]

4. Is the Admin API "Incomplete"?

To answer your question directly: Yes. The public Admin API is not currently a "perfect mirror" of the UI.

• The Intent: The API is designed for Activity Management (activating, renaming, scheduling).

• The Gap: Deep Goals & Settings parity—specifically the metadata that tracks how a metric was selected (e.g., the "Viewed an mbox" dropdown state)—is not fully exposed in the public v3 schema.

Would it be possible to improve the Adobe Target API documentation and close some of the current gaps in API coverage?

For example, in the activity update API, some fields are either missing or insufficiently described. A concrete case is the unit field, which does not appear to be documented properly here:

• https://developer.adobe.com/target/administer/admin-api/#tag/Activities/operation/updateActivity_3
• https://github.com/AdobeDocs/target-developers/blob/main/src/admin-api.json

This makes the API difficult to use reliably, because implementation ends up depending on trial and error rather than on a clear contract.

I was able to work around some of these issues myself and submitted a few documentation improvements here:

https://developer.adobe.com/target/administer/admin-api/#tag/Activities/operation/updateActivity_3
https://github.com/AdobeDocs/target-developers/blob/main/src/admin-api.json

But there still seem to be broader gaps that would be very valuable to address, for example:
 

This is especially important now that more teams are using AI/LLM-assisted tooling for implementation and operations. Those workflows depend heavily on APIs being well-documented, predictable, and fully supported. When fields are undocumented or behavior does not round-trip cleanly between API and UI, automation becomes fragile very quickly.

So from my perspective, the request is not only for better docs, but for stronger overall API support as a product investment. 

Is there any roadmap or planned work in this area?

Hey ​@BENE ,

I’ve been digging deeper into the InvalidProperty.Json error you received for the unit field. It turns out I steered you slightly wrong earlier by including that property, and I want to clarify why that happened so we can fix the automation.

The Adobe Target Admin API behaves inconsistently: it is 'Asymmetric.' When you perform a GET, the API outputs internal metadata like unit and successCriteria to give you context. However, the PUT validator is strictly mapped to a sanitized OpenAPI schema that doesn't actually include those fields.

Essentially, the API hands you a key in the GET that it won't let you use to unlock the door in the PUT.

The Fix: To get the PUT call to succeed and satisfy the validator, we need to strip out all 'Read-Only' metadata that isn't part of the official public contract.

1. Remove unit: count — Target doesn't need this label; it automatically infers that the metric is a 'Count' because of the mbox_shown event in your mboxes array.

2. Remove system fields: Strip modifiedAt, createdAt, and modifiedByName.

3. Ensure 'Hydrated' Mboxes: As long as the mboxes array contains a valid name and successEvent, the UI will correctly reconstruct the 'Goals & Settings' view on the next load.

By removing these 'Radioactive' fields that the gateway rejects, your payload will pass validation while maintaining full functional integrity in the Target UI.

The core of the mismatch between the Adobe Target Admin API and the Target UI lies in the fact that the API gateway uses a strict OpenAPI (Swagger) schema for validation, while the UI relies on extra internal "metadata" to render its Goal & Settings wizard.

To successfully round-trip an activity without a 400 Bad Request or a "broken" UI, you must follow a "Clean & Hydrate" strategy.

The Solution: Sanitized JSON Payload

You must strip out all fields that the Public API considers "Read-Only" or "Internal," and ensure the functional triggers (mboxes) are explicitly defined.

JSON

{
  "name": "Updated Activity Name",
  "state": "saved",
  "priority": 0,
  "options": [
    {
      "optionLocalId": 0,
      "name": "Default Content",
      "offerId": 0
    }
  ],
  "metrics": [
    {
      "metricLocalId": 3,
      "name": "ADDITIONAL GOAL 1",
      "mboxes": [
        {
          "name": "pageview_home",
          "successEvent": "mbox_shown"
        }
      ],
      "clickTrackSelectors": []
    },
    {
      "metricLocalId": 32767,
      "name": "MY PRIMARY GOAL",
      "mboxes": [
        {
          "name": "target-global-mbox",
          "successEvent": "mbox_shown"
        }
      ],
      "clickTrackSelectors": []
    }
  ],
  "reportingSource": "target"
}

Technical Root Cause & Fixes

1. Remove "Radioactive" Fields (The 400 Error)

The API gateway rejects fields that aren't in the official public contract. Before performing a PUT, you must delete the following from your JSON:

• unit

• successCriteria

• conversion (at the metric level)

• createdAt / modifiedAt / modifiedByName

2. Functional Inference (The UI Logic)

You do not need to tell the API that a metric is a "Count" or "Revenue" type. Target infers the unit and success criteria based on the successEvent inside the mboxes array:

• mbox_shown $\rightarrow$ UI automatically renders as Conversion (Count).

• order_total $\rightarrow$ UI automatically renders as Revenue.

3. Mbox Hydration (Fixing the Broken UI)

The reason the UI state appears incomplete after a REST push is usually because the mboxes array was empty or missing. For the UI to "reconstruct" the Goals & Settings view, it requires a functional trigger. By providing the name and successEvent in the mboxes array, the UI has the necessary "hook" to display the configuration correctly.