Managing Adobe Tags data elements through the API

When you need this

A migration between properties (or a company consolidation) needs every data element rebuilt in the destination - doing that by hand, field by field, in the UI is where implementations quietly introduce typos in a custom-code data element that nobody notices until a report goes wrong weeks later. The API turns that into a scripted, diffable export/import.

It's also the practical tool for a structural audit: pulling every data element's type and settings in one call to find, say, every custom-code data element that references a global variable which no longer exists on the page.

How to work with it correctly

1. List before you write. Start with a read-only pull of every data element in the property to build an inventory and confirm naming conventions before any create or update call touches production configuration.

GET https://reactor.adobe.io/properties/{PROPERTY_ID}/data_elements
Headers: Authorization: Bearer {TOKEN}, x-api-key: {CLIENT_ID}, x-gw-ims-org-id: {ORG_ID}

POST https://reactor.adobe.io/properties/{PROPERTY_ID}/data_elements
Body (JSON:API):
{
  "data": {
    "attributes": {
      "name": "de - page - template type",
      "delegate_descriptor_id": "core::dataElements::javascript-variable",
      "settings": "{\"path\":\"digitalData.page.templateType\"}"
    },
    "type": "data_elements"
  }
}

2. Match the delegate descriptor to the extension that owns the type. Each data element type - JavaScript Variable, Custom Code, a Web SDK-provided type, or one from a third-party extension - has its own delegate_descriptor_id and settings schema. Pulling one existing example of the type you need from the UI first, via the API, is the fastest way to get the settings JSON shape right before writing your own.

3. Create in the Development library, never directly against Production. API writes land in the property's working (Development) library the same as UI edits - they still have to go through the same build and publish flow before they take effect on real pages, which is what makes a scripted bulk change safe to review before it ships.

4. Script the diff, not just the write. Before a bulk update, generate a before/after diff of the settings JSON for every affected data element and have a second person review it - a scripted change that touches forty data elements at once is exactly the kind of edit that benefits from a second set of eyes, since it bypasses the one-at-a-time friction that normally catches mistakes.

How to verify it worked

• A follow-up GET on the created or updated data element returns the exact settings you posted - confirming the write landed as intended, not just that the API returned a success status.
• The data element appears correctly in the Tags UI's Development library, with the right type icon and settings shown in its edit view - the API and the UI are two views of the same object, and they should always agree.
• After a build and staging publish, the AEP Debugger resolves the data element to the expected value on a real page - proving the API-created object actually works, not just that it saved.

Illustrative, not a measured result: a team consolidating three regional properties into one might script the data-element migration for all three, cutting weeks of manual re-creation down to a review-and-run script.

Delegate descriptor IDs and settings schemas are extension-specific and change with extension versions - verify the exact shape against Adobe's current Tags API documentation before scripting a bulk write.

FAQ

Does creating a data element through the API publish it automatically?

No - an API-created data element lands in the Development library exactly like one created in the UI, and still needs a build and a publish through the normal environment flow (Development to Staging to Production) before it affects live pages.

Can the API move a data element between properties directly?

Not as a single operation - there's no cross-property move endpoint. The practical pattern is reading the source data element's full configuration and creating a matching object in the destination property, which is exactly the kind of repetitive task worth scripting rather than doing by hand.