Access Processing Rules via API

Wow.  This is really distressing.  The introduction of AEP Web SDK makes this a really hot issue since we will have to send everything via XDM key value pairs which become context variables on the beacon that gets sent to the AA collection server.  Processing rules suddenly become super-important for the purpose of mapping from these (xdm) context variables into AA events, props, and evars.   I have to assume that if the functionality was once in the 1.4 API but now gone from the 1.4 and 2.x API's that we will soon be seeing this functionality exposed elsewhere (in another API).  If you need an alpha/beta tester, please get in touch with me as I have an urgent need for this.

@jacob-dddev  Which part of my answer is incorrect?

Hi @brian_kent_watson , you mentioned that "API support is not available in API 1.4..."

It is available it's just not very useful and requires inconvenient text parsing. Outside groups have had to compensate for this poorly written API.

@jacob-dddev  We appear to be using the term "support" and "available" slightly differently. API access for processing rules is not officially supported in any version of the Analytics APIs (1.3/1.4/2.0). The version of GetProcessingRules that some have used in the past is an internal Adobe API that was unintentionally exposed a few years back but never officially documented or released, thus it's not supported nor officially available. The undocumented and internal GetProcessingRules endpoint is subject to change at any time, including breaking changes, or complete elimination, without advance notice. Some enterprising folks have figured out how to make calls to it but they are doing so at their own risk.

I didn't dismiss the RSiteCatalyst package but simply stated the fact that it is not an Adobe-authored, sold, or supported package. As an Adobe representative, I can't speak authoritatively about RSiteCatalyst or its future as it's an open-source package supported by a community of users.

Regards,

BKW

Hi @jantzen_b , given that Idea of v2.0 processing rules API is still a very current and requested feature, it doesn't seem appropriate to archive yet. Perhaps once the feature has been added?

@jacob-dddev - We ran an auto archive job a few days ago and a few items were archived by mistake. We've changed the status back to new. I'll have the relevant product manager review this idea.

+1

Something I'd like to see

In the data collection roadmap, there is an item labeled "XDM Mapper on the Edge".  This item sits at the top of the list for Q4.  See https://experienceleaguecommunities.adobe.com/t5/adobe-experience-platform-launch/data-collection-roadmap/ba-p/401733

It's tough to connect the dots, but it is my understanding that this functionality will (among other things) allow us to:

• Map from XDM fields into AA props, eVars, events, list vars, and built-ins (pageName, channel, purchaseID, transactionID, state, zip, etc). 
• Construct complex product strings from XDM including PS Merch eVars, and product scoped events.
• Manage mapping rules in a UI
• Manage mapping rules via API

Once this functionality is in place, there will be no need for processing rules in implementations that use AEP Web SDK (or AEP Mobile SDK ("v5"+)).  Of course, this doesn't address the needs of folks still sending beacons directly from the client to AA collection servers, but it's a big step toward helping them make the migration to XDM. 

@thebenrobb - Can you validate this answer?

It is very unfortunate (to put it nicely) that after all these years (decades), Adobe still do not have an API solution for bigger scale operations.

I manage Adobe implementations across 4 different Orgs and Adobe do not have a solution to for me to use one account as Template and copy over Processing Rules to all other reports suites on different accounts.

This forces me to manual task that takes time and are very prone to errors. Hard to believe how/why Adobe don't have a solution for this in 2025!!

Kind of suggests that for large scale operations, we are better off building our own Analytics solution instead.