Adobe Experience Platform AEP API

Introducing Python SDK for AEP

Hello everyone,
This article is the start of series that I am very hyped for. Most of you know my work on the different API for Adobe Analytics, Launch, Audience Manager.
During the (infamous) year 2020, I spent a lot of time developing the Adobe Experience Platform Python module (aepp).
This is now the unofficial python wrapper for AEP.

I spoke very seldomly of that module as Platform was not really mainstream in 2020 but 2021 may start to be the year for it and I believe this will be super useful for a lot of persons.

AEP API First Approach & Feedbacks

There are 2 main reasons that I am so excited to promot the module and I see good values for it.

AEP is API-first

The same way than Launch is API first, AEP has this API-first approach as well when it comes to its infrastructure. Therefore, it makes a lot of sense to look at the API in order to understand the full capabilities of AEP.

In contrary to Adobe Analytics or Audience Manager where the API comes “on-top” of the infrastructure to request data, the API for AEP is basically how it is built. You are just another consumer of the data, without the UI.
It can be more painful because the heavy lifting is not done for you (big respect to the front-end team here) but it is so much more flexible and more importantly, you really understand what is happening.

Again, the same way that when you look at the Launch API, you start to understand how everything is working together, you can do the same with AEP. However, this time, the scale is 100 times more.
There are so many components for AEP that you cannot really talk about an AEP API. You can talk about the different API components:

  • Query Service
  • Schema
  • Identity
  • etc…

Each component is own by a different team and I am sure Adobe would not want that to be a problem (or at least an obvious one) but you can clearly see these different teams, facing different challenges and use-cases, creating this API. There are these subtle changes on how the method are handled and the type of response it gives back.
These differences will probably fade away but I think it is good to understand that all pieces are quite independant and an issue or a feature of AEP means probably a lot more work from different teams that you would expect (it is good as long as it is not hindering the usage of the API).

So as long as I would be super happy that you use my python module to work with AEP, the most important thing is that you understand either my module or the API itself. It would prove to be a very valuable time-spent in your future work with AEP.

Already approved

The second reason why I am excited to share that module with you is that for this module (aepp), it has been tested and used internally at Adobe before its “public release”. Nothing official of course, I am still not a developer and not paid for that kind of product, however colleagues used it for their use-cases and the feedbacks have been really good.

In all honesty, it is still in a version 0.1.X so a lot of improvement can still be done. We can definitely do a lot more and better in the future, especially because not all of the use-cases has been added but it is encouraging to see that it already can help AEP consultants.

This project is so massive that I am definitely looking forward for people participating on the development of the use-cases and advanced functionalities that this type of module can provide.

Current scope for aepp

aepp already has a quite a massive support for the AEP API. In version 0.1.0, the exposed methods are submodules so you will need to import the submodule you want to work with.

The different endpoints that have been integrated so far are:

  • Query Service
  • Schema
  • Data Access
  • DULE
  • Sandboxes
  • Identity
  • Catalog
  • Segmentation
  • Access Control
  • Sensei
  • Privacy Service
  • Data Ingestion
  • Mapping Service
  • Datasets
  • Ingestion

There isn’t documentation for all of them in Github yet and there may be some missing endpoints support where it is a bit tricky to do. Especially the sensei one where it request a JAR file to upload. I am in no position to test and realize this endpoint at the moment.

Nevertheless, I am sure that the current supported endpoints and the documentation will be useful for a lot of people.

For example, you can realize Schedule Query with Adobe Experience Platform, unlucky for you, you don’t have this option in the UI at the moment.
With this module, you can realize a Schedule query in Jupyter notebook via 6 lines of code. 3 of which are kind of identical than the ones you do for the other modules I developed so you won’t be too frighten.


The same way that I developed a repo in pypi for Adobe Analytics API and Launch API, you can download and install the module directly through a pip command:

pip install aepp

Please consider to upgrade regularly as it will be develop quite heavily in the next months.

pip install aepp --upgrade

Usage of the module

As explained above, you will need to know which module you want to use in order to use the aepp module. The module on itself won’t give you much methods.
Most of the useful endpoints resources are hosted behind a sub module. Each submodule have at least a class that you can instantiate after providing the configuration JSON or a configure method to the main module.

For schema endpoints per example you will need to realize the following:

import aepp
from aepp import schema

## alternatively
aepp.configure(org_id= "",
tech_id = "",
secret = "mySecret",
client_id = "myClientId",
private_key = "myStringPrivateKey",
sandbox ="prod")

# this will instantiate the connection to the schema endpoint and methods.
mySchema = schema.Schema()

## Example of methods


You can have more information in the get-started documentation.

Possible Future of aepp

As much as I would like to do every type of project that AEP can offer, this is not very realistic. Therefore, there will always be some blind spots that I will not see for this module.

The same way that some people pushed for the Virtual ReportSuite component editor with my adobe analytics API wrapper (aanalytics2), I would count on you to help develop or request new features that are not yet there.

More importantly.
Is this module tested ? Yes, through me and some consultants on the field.
Is this module stable ? Maybe. I will try to not do any major break in the architecture but this is still version 0.1.0.
Is this module bulletproof yet ? Definitely not ! It is version 0.1.0 so a lot of debugging in scenarios I couldn’t test will probably occurs but counting on you to give me feedback on that.

Because this is free work (literally), I cannot ensure any SLA on deliverable of new features or bug fixes but I always try to do it in a reasonable time length (see aanalytics2 and launchpy supports).
I am also quite happy if direct Pull Requests (PR) are made as I can review them faster.

So this is the wrap up on my first communication on this module.
I hope to post future videos and article about AEP and proving how you can make the most of AEP with the API.

Leave a Reply

Your email address will not be published. Required fields are marked *