Adobe I/O

The developer platform for integrating Adobe products and services - clearly explained

Adobe I/O

With AEM as a Cloud Service (AEMaaCS), Adobe launched a cloud-native AEM last year. Along with it, Adobe built a platform to run a wide variety of cloud-based integrations for Adobe services. However, Adobe I/O is more than just an API hub or a runtime environment for services, and a discussion of Adobe I/O in the context of AEM as a cloud service seems essential. This article is intended to provide some insight into Adobe I/O.

An overview

As soon as you start reading up on Adobe I/O, you're confronted with a whole host of "buzzwords."

Adobe I/O Buzzwords

I will now first try to classify these terms below to get a better overview.

The platform

Adobe I/O is designed to be a platform for developers and system integrators around the products and services offered by Adobe. The Adobe I/O platform offers the following areas at entry:

Adobe Developer Console - Workspace Overview Website

The platform is presented via the website This is also the first point of contact for anyone who wants to get involved with the platform. On the site itself, you can find a wide variety of documentation about the services and interfaces offered. Another extensive component is the so-called Code Labs, where you can find detailed tutorials for various application scenarios, see

Adobe Developer Console

On this web page you will find the entry point to the so-called Adobe Developer Console. Using the Adobe Developer Console, you can create your own integration projects with the help of templates. When using these templates, different so-called workspaces are created directly. In one of the workspaces, the services that are required for the development of an application or integration of Adobe services are bundled. Classically, workspaces are created for "Stage" and "Production". But you can also create your own workspaces for development. In addition to using templates, you can also start from scratch and create your own workspaces.

Überblick über die Adobe I/O Plattform

Access management is also located at the workspace level. All services and APIs bundled in this way share the same access data per workspace, usually JSON Web Token (JWT) authentication. This reduces the integration effort, especially when connecting different APIs. The templates also integrate the Adobe I/O Runtime as a central component in the workspaces. Additional services and APIs have to be clicked together via the Developer Console in the browser.

Adobe I/O - Add an API

Adobe I/O API Gateway

Adobe I/O acts as an API hub for the various services and APIs offered in the Adobe cosmos. If you add a service to one of the workspaces mentioned above, you will find that the catalog of available APIs now includes a whole range of very different applications. The spectrum is now enormous and ranges from a user management API, which can be used to access user information, to AI-based services, such as the Photoshop API for cropping images.

This is also where Adobe's various solutions are made interconnectable. For example, the catalog of services offered also includes APIs from Adobe Analytics, Adobe Campaign, or Adobe Target. Of course, it is not enough to "click" the services together. There is still a need for an integration in which, for example, the various APIs are addressed. Such an integration is developed and encapsulated in the Adobe I/O environment in a so-called Firefly Application.

App Builder (formerly project "Firefly")

With App Builder, Adobe has created a development and runtime environment integrations around Adobe I/O can be quickly and purposefully implemented and operated. integrations can be implemented and operated quickly and efficiently. Here we are talking about a developer activity, because at this point we are leaving the path of simply clicking together.

But let's start from the beginning: Project Firefly was the label under which Adobe has combined various components. In the future, the the whole thing under the name App Builder. The following parts fall under it:


  • Adobe I/O Runtime
  • Adobe I/O Events
  • Adobe I/O CLI
  • Adobe SDK
App Builder (ehemals Project Firefly)

Adobe I/O Runtime

The Adobe I/O Runtime is the central component and quasi the runtime environment that Adobe provides so that the developed integrations can be operated. Using so-called "serverless functions" can be used to extend or interconnect the Adobe Experience Platform and its services. services can be extended or interconnected.

The Adobe I/O Runtime is based on Apache OpenWhisk and Node.js. OpenWhisk is an open source, serverless platform that can execute functions in response to events. in response to specific events. OpenWhisk, or the Adobe I/O runtime manages the infrastructure, servers, and scaling using Docker containers. As a result, you don't have to worry about scaling issues during development and can focus on solving the problem. focus on solving the problem.


As the platform is based on Node.js, development mostly takes place in JavaScript. The platform supports a programming model in which application code is encapsulated in functions. These functions are called OpenWhisk Actions. These functions are mostly triggered by triggers (e.g. events) or HTTP requests. For example, you can develop a function that uses JavaScript and a corresponding client library to call Adobe's Photoshop API. The whole thing can then be used to generate renditions from AEM via HTTP requests, for example. The advantage of this approach is obvious: The individual functions are encapsulated and are automatically scaled via the Adobe I/O Runtime (Function-as-a-Service). The load is thus distributed from the AEM system to the Adobe I/O Runtime.

In addition to these actions, web applications can also be deployed and operated via the Adobe I/O Runtime. Adobe uses specially developed React components for this purpose, which are based on Adobe's design system. The web interfaces developed in this way can then be used, for example, to test the actions mentioned above. In general, many different use cases can be mapped here. However, the extent to which it makes sense to run a web application via Adobe I/O Runtime must be evaluated on a case-by-case basis. This makes the most sense for applications that function as a web front end for the "Serverless Functions".

Adobe I/O Events

Another component of the platform is Adobe I/O Events. Adobe I/O Events is integrated with Adobe I/O Runtime and allows you to respond to events from the Experience Platform. For example, it is possible to respond to a deployment in Cloud Manager from AEM as a Cloud Service. One can register for these events via a webhook. This can then be used to generate automatic build notifications for Microsoft Teams, for example. Adobe currently offers a range of events that can be acted upon. If you want to learn more about the specific events, you should be able to find them here:!adobedocs/adobeio-events/master/using/

Adobe I/O Events

To speed up development, Adobe offers a whole range of ready-developed libraries in addition to the platform. All these libraries are NPM modules and can be easily integrated into the application.

Below is a list of the most interesting libraries in my opinion:


  • Adobe / aio-lib-state
    API for the Cloud/State Storage


  • Adobe / aio-lib-files

Abstraction of cloud storage to a file system-like API


  • Adobe / aio-lib-photoshop-api
    SDK for Photoshop API of Adobe


  • Adobe / aio-sdk

Module containing all major Adobe I/O SDKs


  • Adobe / aio-lib-cloudmanager
    SDK for the Cloud Manager API


  • Adobe / aio-lib-events
    SDK for the Adobe I/O Events API


Adobe is working to develop and publish more libraries. These are then published open source on GitHub. We have observed recently that Adobe is following this path more and more. Even the documentation and all tutorials are now open sourced.

Adobe I/O CLI

Of course, no development goes without a Command Line Interface (CLI). Adobe has a tool with the Adobe I/O CLI, which is a central tool of the development and supports the development in many aspects: For example, the functions developed can be compiled, deployed and tested using the Adobe I/O CLI. Likewise, project initialization takes place via the command line. The command line interface can be extended via plug-ins. Adobe offers a number of plug-ins that can be used, for example, to automate a number of things in the Cloud Manager environment, such as triggering builds or updating environments. So the CLI plays a role not only in the development of apps and servless functions; it is generally used in dealing with Adobe's cloud services.


In summary, Adobe has created Adobe I/O, a useful cloud-based extension of the Experience Platform around AEM. It is foreseeable that many customizations that used to reside directly in the AEM environment will now be mapped through Adobe I/O and its associated platform. The advantages are obvious: The architecture is scalable, service-oriented, and individual extensions can be encapsulated in microservices. The platform also makes it much easier to connect the individual services and APIs of the Experience Cloud.