To write an extension for Launch, we need to make sure your Adobe Experience Cloud Organization is set up properly, and that developers on your team have the correct permissions. Your extension project (extension package) should be ready for uploading to our system, and of course you’ll need to be familiar with the Launch user interface. In this guide we’ll walk through all the steps and link to all the resources you need to start your own extension project.

Getting Started Guide - Table Of Contents


In order to author extensions for Launch, your company will need to join our Exchange Partner program. If you’re not an Exchange Partner now, it’s easy to join here. Simply register for the program and request access to Launch. You can also request access to other Adobe Experience Cloud products like Adobe Analytics, Adobe Audience Manager, or the Adobe Advertising Cloud. Learn more about the Exchange Partner program here.

If your company is already an Exchange Partner, but you don’t have access to Launch, you can request access by emailing

If your company is an Adobe Partner in another program, like the Solution Partner Program, or the Global Alliance Program, you still need to join the Exchange Partner Program at the link above. The Exchange Partner agreement contains the terms for authoring Launch extensions.

Create a Listing in the Exchange Partner Portal

After your extension is completed, you should create a listing for it in the Exchange Partner Portal. To create an application listing please login to the Partner Portal. Once logged in click on the Application Listing button next to your name. Then click on create listing and follow through the screens. Before you start, it will help to read the App Submission Guideline to learn how to submit the most powerful listing. One question asked often is on the Featured Image included in the Application Listing, this is an image that should stand alone to promote your brand and product. This logo is what shows when you or someone else shares your Exchange listing in social media or messengers, so you want to ensure it represents your brand and product well.

Once submitted, the Adobe Exchange team will review the application and will either approve the application, or respond with comments about changes. This process is detailed in the App Submission Instructions.

If you don’t have a login to the site, make sure that your email is registered for the Exchange program by following the instructions in the Program Registration Guide. Even if your company is registered, each user still has to associate their email with the partner account for the company. For questions on this process, email


We have a number of resources available to help you write extensions. If you’re not familiar with the Launch user interface, please review this Youtube playlist for the Introduction to Launch, by Adobe. The user help docs have more detail on the user interface. And for extension authors, we also have an Introduction to Extensions Youtube playlist to get you started after you’re comfortable with the user interface.

Example extensions

There are a few extensions on Github you can review or use as a starters for your own extension projects:

Slack Workspace

There is a community workspace in Slack where extension authors can support each other. You can request access at Please note: while there are members of the Launch team in this Slack workspace, it is a community resource not sponsored by or moderated by Adobe.

Admin Console Set Up

We have a non-production environment for you to use with your extension development project. This environment can be accessed at To set up your team members with access and the appropriate credentials, you need to take some steps in the Adobe Administration Console first.

Choose Your Organization

The steps included here should get you sorted, but if you need more information, check out the Administration User Guide.

Your Adobe Experience Cloud organization administrator should sign in to the Admin Console at The first screen is the Overview:

Some of you may have access to more than one Organization. In order to add the Launch product to the correct Org, click the name of the Organization you see in the upper right corner of the screen, then choose the one where you want to use Launch:

Create a Product Profile

Choose the “Products” link at the top, and “LAUNCH, BY ADOBE” on the left. If you do not have the Launch Product listed, please contact your account team to have it added to your organization, or email

The screenshot above shows one existing Profile for Launch, you may not have one yet. To create one, click the blue “New Profile” link. On the Create a New Profile screen, just add a Profile Name (Adobe Launch, for example), and an optional Description, then click Done:

Now that we have the Product Profile in our Organization, let’s add our users.

Assign Users to the Product Profile

Notice that the Product Profile shows zero for Entitled Users and Admins. Click the name of the Product Profile you created (Adobe Launch, or whatever you chose):

Let’s add an Admin first. Click the Admins tab, then click the blue Add Admin link:

That link brings up a screen where you can search for existing users, or add new users as Admins of this Product Profile:

Click save and add any other Admin users you want to administer this Launch Product Profile.

Click on the Users tab, then you can add users by clicking the blue Add User link:

Just like we did with the Admins, we can search for existing Adobe ID users by email, or add new ones as Users of this Adobe Launch Product Profile:

Click the blue Save link when you add the user. When you have all the users you need in this Product Profile, we’ll add Permissions for them. Click the Permisions tab:

On the Permissions screen you’ll see PROPERTIES and RIGHTS, click on RIGHTS:

To author extensions, you and your team need rights for extensions, develop, and environments at a minimum. You can also assign all rights to the people in this Product Profile if you prefer. You can create additional Product Profiles with more limited rights later if you like, but for now click the rights you want, or “+ Add all” and then the blue “Save” link:

At this point, we chose the appropriate Organization, created a Product Profile, and added Users and Admins to the Product Profile. We also assigned Permissions to the Users in the Product Profile.

This completes the required set up in the Administration Console!

Sign in to Adobe Launch

Confirm Provisioning

After your company is provisioned with access to Launch, and your users are set up as described above, you should be able to access the Launch production environment. If you know you’ve been provisioned for Launch, and you’ve gone through the Admin Console steps above, but you still can’t sign in to Launch, please email for support.

For now, access to our non-production integration environment has to be granted manually. After your company is provisioned with access to Launch in production (, and your users are set up, please email your Experience Cloud Org ID to and request integration environment access. How do I find my Org ID? contains the simple steps you’ll need.

Access the Integration Environment

The users we set up in the above steps should now be able to access the integration environment for Adobe Launch at Again, if you have multiple Experience Cloud Organizations with Adobe, you’ll need to select the Organization where you added the Product Profile in the first step above:

Once you select the correct Organization (if necessary), you can create a Property with full access to the live system. Create Rules, upload Extensions, create Data Elements - everything you need to work with Launch and test your extension. The Help Docs for Launch are available publicly for your reference.

User IDs for Extension Developers

Granting permissions to upload Extensions into the integration environment is not something available in the Adobe Admin Console, it’s a right we have to grant on the back end for now. In order to provision your teams to upload your extension packages, we need the User ID for each person you want to have this right. Or, simply send us the Technical Account ID from your I/O integration:

Find a UserID

Sign in to Launch at with your Adobe ID. Then open the Developer Tools Console in your browser and type userData.imsUserID and copy this value. Please send the name(s), email address(es), and these UserID(s) for anyone you want to have upload rights to us at We’ll grant those people the right to upload extensions for your project.


In Chrome, typing copy(userData.imsUserID); in the console will copy this value to the clipboard for you:

Your Organization Administrator can also get the Adobe ID for users by going to the admin console:

  1. Click Users in the menu tabs
  2. Click a user
  3. Click “view profile”
  4. In the URL, eg: the D987654321@AdobeID part is the Adobe ID.

You can also get to that page by clicking on a user in the Product Profile.

Creating Your Extension Package

In addition to the Resources section above, here are some additional helpful resources to get your started:

Once your team is satisfied with the performance of your extension and the results they see in the Sandbox tool, you should be ready to create an extension package and upload it to the integration environment. Before that, please be sure to validate that any required fields or settings are present. For example, reviewing your extension manifest, your extension configuration, your views, and your library modules (at a minimum) would be good practice. One specific example is to verify your logo file exists: Add an "iconPath": "example.svg", line to your extension.json file and include that logo image file in your project. This is the relative path to the icon that will be displayed for the extension within Launch. It should not begin with a slash. It must reference an SVG file with a .svg extension. The SVG should appear normally when rendered square and may be scaled by our user interface. See How to Scale SVG for more details.

The Extension Package

The extension package you upload to our system is nothing more than a .zip file of your project. reactor-packager is a command-line utility for packaging a Launch extension into a zip file. While using this utility is not required, it is highly recommended. It will validate your extension and make an effort to exclude anything from the zip file not necessary for the extension to run properly.

Uploading & Patching Extensions

Uploading and patching extension packages in our integration environment is currently done with cURL commands from a terminal window or command prompt to access the API. If you prefer, you can use a free tool like Postman or other REST or API applications or browser extensions to interact with the API. If you prefer to write your own application or tool to use the Adobe I/O integration, you are free to use any language and/or framework you choose.


Documentation for the API is available at These docs are being actively updated and are subject to change. As a convenience, we provide the most relevant notes below to help you get started.


Please note: As of this writing, API access is preliminary and may be changing prior to production release. We will do our best to keep developers up to date, but please delay other itegrations with our APIs until we reach 1.0 in production with public API access later this year.

Adobe I/O Integration

Before you can work with the API to upload or patch your extension package, you need to create an integration through Adobe I/O. We’ll create a JSON Web Token (JWT) and we’ll use it in the Adobe I/O console to create a bearer token. This bearer token will be used in your API calls to upload or patch your extension packages.

For programmatic access, here’s a good reference from the I/O team on how to generate a JWT and exchange it for an access token:

Create a New I/O Integration

You can purchase key pairs or generate your own self signed keys. If you want to create your own keys, follow these steps in your terminal:

mkdir keys
cd keys
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout reactor_integration_test_private.key -out reactor_integration_test_public.crt

We recommend naming your keys for easy reference later, and to store them in a folder. If you create multiple integrations, then you can easily identify and manage which keys go with which integration.

Openssl asks for some information that will be incorporated into the keys:

Country Name (2 letter code:  // Example: US
State or Province Name:  // Example: California
Locality Name (eg, city):  // Example: Santa Monica
Organization Name (eg, company):  // Example: Grunions Incorporated
Organizational Unit Name (eg, section):  // Example: Engineering
Common Name (e.g. server FQDN or YOUR name):  // Example: Jane Doe
Email Address:  // Example:

After you input your information, open the current directory and you should see your .key and .crt files, with the name you used in the openssl command above. Here’s an example:

Adobe I/O Console and Your Bearer Token
  • Go to and sign in with your Adobe ID.
  • Click the blue “New Integration” button
  • Select “Access an API”, then click “Continue”
  • Select “New integration”, then click “Continue”
  • Select the Adobe service to integrate with: select “Launch, by Adobe” and click “Continue”
  • On the “Create a new integration” screen, enter a Name and Description. Drag & drop your xxxx_public.crt file onto the “Public keys certificates” drop zone. At the bottom of the screen, under “Launch, by Adobe Configuration”, select “Admin” as the role and click the blue button:

  • You should see the “Integration created” screen that says “Your integration has been created. Click “Continue to integration details”
  • On the “Overview” screen of the integration, you should copy and note the information for your integration.

  • Click on the “Services” tab. You should see “Launch, by Adobe” in the “Configured Services” section at the top. Hover your mouse over the “Launch, by Adobe” icon and click on “Config” if you need to change Role permissions.
  • Click on “JWT” at the top. The Adobe I/O console allows us to test our integration by generating a JWT and providing us the exchange URL. See the I/O documentation for programmatically generating your JWT and exchanging for an Adobe access token.
  • Back at your command prompt or terminal window, type cat stage_reactor_qe_test_private.key (or whatever you named your private key)
  • Copy the key value and paste it into the “Paste private key” field on the JWT page in your browser. Click “Generate JWT”
  • Click “Copy” under the “Sample CURL command” section and paste it into your command prompt or terminal window
  • You should now see "token_type": "bearer", and your "access_token" value in your terminal.
  • The value of the bearer access token is what you will use in your API calls to upload and patch your extension packages. We suggest you save that bearer token value, Adobe access tokens are valid for 24 hrs.

The following are some example API calls commonly used by extension authors. The details of the API are described in detail here.

Example - List Extension Packages

With your Access Token and Client ID we can now make API calls. Here’s the command to request a list of extension packages:

curl \
  -H 'Accept: application/vnd.api+json;revision=1' \
  -H 'Content-Type: application/vnd.api+json' \
  -H 'Authorization: Bearer [TOKEN]' \
  -H 'X-Api-Key: Activation-DTM' \
  -X GET

In this example, note the line -H 'Authorization: Bearer [TOKEN]' \. [TOKEN] needs to be replaced with your specific bearer token value you created in the steps above. Also note the Activation-DTM client ID value on the line -H "X-Api-Key: Activation-DTM" \.

Here are the first few lines of the JSON response:

  "data": [
      "id": "EPe5790d2dd0184b89b66cb6e246fefe88",
      "type": "extension_packages",
      "attributes": {
        "actions": [
            "id": "EPe5790d2dd0184b89b66cb6e246fefe88::actions::custom-code",
            "name": "custom-code",
            "schema": {
              "type": "object",
              "oneOf": [
                  "required": [
                  "properties": {
                    "global": {
                      "type": "boolean"
                    "source": {
                      "type": "string",
                      "minLength": 1

Creation - Initial Upload of an Extension Package

The reference docs to Create an Extension Package are useful. The command looks like this:

curl -X POST \ \
  -H 'Accept: application/vnd.api+json;revision=1' \
  -H 'Content-Type: multipart/form-data' \
  -H 'Cache-control: no-cache' \
  -H 'Authorization: Bearer [TOKEN]' \
  -H 'X-Api-Key: Activation-DTM' \
  -F 'package=@[PATH]'
  • [TOKEN]should be replaced by your specific bearer token. Do not remove the word Bearer. The line should look similar to: -H 'Authorization: Bearer eyJ4NX...' \ where eyJ4NX... is replaced with your actual token value. Note the space after the word Bearer.
  • [PATH] should be replaced by the path to your extension package .zip file. Like this example: 'package=@/Users/jeff/Repos/extension/'.

Update Existing - Patch and Over-write an Extension Package

Note: when patching and over-writing an existing extension package you previously uploaded, you must use the same name and version in the extension.json file.

curl --request PATCH \[PACKAGE-ID] \
  -H 'accept: application/vnd.api+json;revision=1' \
  -H 'authorization: Bearer [TOKEN]' \
  -H 'cache-control: no-cache' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -H 'postman-token: ce1e0c50-d2aa-c8a3-d177-3d8b8aa6dc68' \
  -H 'x-api-key: Activation-DTM' \
  -F 'package=@[PATH]'
  • [PACKAGE-ID] should be replaced by the ID of the extension package you previously uploaded. This is available in the JSON response from your upload command, or you can retrieve the list of extension packages with the command in the earlier example.
  • [TOKEN]should be replaced by your specific bearer token value.
  • [PATH] should be replaced by the path to your extension package .zip file. Like this example: 'package=@/Users/jeff/Repos/extension/'.

Note: in the integration environment, developers can see other extension packages and you should be careful to select a unique name for your extension or you run the risk of overwriting an existing extension.

After patching an extension package, you can use the next command to get status and details. Also, after patching an extension package, the response json will contain an entry for both created_at and updated_at. The created_at entry reflects the timestamp for when the extension package was originally created or uploaded and it does not change. The updated_at reflects the timestamp for when the extension package was patched and it changes for each patch completed.

When uploading or patching, extension packages are placed into a pending state while the system asynchronously extracts the package and deploys. While this process is taking place, you can poll the extension_package ID for its status. However, listing all extension_packages only returns sucessfully installed packages, so your extension package won’t show up in the catalog until it has been fully processed.

Get Status and Details

You can get useful information about your extension package with this command:

curl -X GET \[PACKAGE-ID] \
    -H 'accept: application/vnd.api+json;revision=1' \
    -H 'authorization: bearer [TOKEN]' \
    -H 'cache-control: no-cache' \
    -H 'x-api-key: Activation-DTM' \
  • [PACKAGE-ID] should be replaced by the ID of the extension package you previously uploaded. This is available in the JSON response from your upload command, or you can retrieve the list of extension packages with the command in the earlier Example section.
  • [TOKEN]should be replaced by your specific access token generated from your I/O integration.

Introduction to the Launch Interface for Extension Developers

In order to develop extensions for Launch, it helps to be familiar with some common concepts and workflows in the user interface. This introduction is for extension developers to learn some key parts of the system, and to help you set up an end-to-end test on your test site.

We also have a Youtube playlist for the Introduction to Launch, by Adobe, and the user help docs have more detail on the user interface.

Creating a Property

When you sign in to the Launch interface at, it’s typical to see the Properties screen first:

You see my ‘test’ property here but you won’t see any properties on your screen the first time you sign in. Click New Property to create one. Enter a name and a URL. You’ll probably want to use the URL of your test site or page where you’ll be testing your extension. This domain field can be used by some extensions or by a condition using the Core extension (which we’ll look at later). Note that localhost won’t work, so if you’re on a localhost URL, just use any value for this testing, like

You can ignore the Advanced Settings for now.

Click the blue Save link at the bottom to save your new property.

This brings you back to the Properties screen. Click on the name of your property that you just created. This is the Overview screen in a property. Not much work happens here, but there are links to each area of the system, with the global navigation links at the top.

Install Launch in Your Test Site or Page

To install Launch on your test page we need to add just two lines of code in your page or site template(s). We call them Embed Codes. We just need a few quick steps to get those lines of code.

Click on the Adapters link in the main navigation links at the top:

Then click the blue Create New Adapter link.

Give your adapter a name like ‘dev’ or whatever. For Type, we suggest Akamai. This means the library files for Launch will be hosted in our Akamai account and referenced by the Embed Codes we’re about to see. You can use this adapter for multiple environments, if you need multiple development environments.

Click the blue Save link at the bottom. You should see a green Success indicator on the screen now. Click Close at the bottom.

Next, click on the Environments link at the top in the main navigation links. Then click the blue Create New Environment:

Next you’ll see choices for the types of environments you can create Development, Staging, and Production. An environment is a destination for deployment. An environment has a 1:1 relationship with an Embed Code. In Launch, a user can have as many different development environments as they want, but for testing your extension we’ll keep it simple with the minimum set up.

Click Select under Development:

Enter a name (like ‘My Precious’ or whatever) and choose the adapter we created earlier from the Select Adapter dropdown. Click the blue Create link. When you click Create you’ll see a new section in the lower half of the screen with the Embed Codes we need to install Launch in your test site.

You should add the Header Embed Code in the <head> section of your document or site templates. Also add the Footer Embed Code just before the closing </body> tag. And with those two little lines of code, Launch is now installed in your site.


Note: if you’re using the asynchronous option, you won’t use the Footer Embed Code. See the Help Docs and this article for more detail.

Click Close at the bottom to close the Environments screen.

Install Your Extension

To install your extension in this property, click on the Extensions link in the main navigation links at the top.

You’ll see the Core extension on this Installed screen. The Core extension contains all the tag management functionality within Launch. To add your extension, click on the Catalog:

The catalog displays card icons for each available extension. If your extension isn’t displayed in the catalog, be sure you completed the steps above in the Adobe Administration Console Set Up and Creating Your Extension Package sections above first. Also, check the results of your extension package upload or patch. Failed extension packages have a status_detail field that will help troubleshoot packages that failed to install.

When you hover your mouse over the card for your extension, it will reveal an Install link, click that:

This will bring up the configuration screen you built for your extension. Add any information needed to configure your extension and click the blue Save link at the bottom.

Here’s an example with the Facebook extension:

You should now see the Installed extensions screen with the Core extension and your extension.

Data Elements in Launch

Data elements exist in Launch to help users persist values. Each data element is a mapping or pointer to source data. A single data element is a variable that can be mapped to query strings, URLs, cookie values, JavaScript variables, etc.

Extensions can define data element types if needed for your extension to operate, or simply as a convenience to users. When an extension provides data element types, they appear in a dropdown list for users on the Create New Data Element screen:

When a user selects your extension from the Extension dropdown, the Data Element Type dropdown is populated with any data element types supplied by your extension. The user can then map each data element to its source value. Data elements can then be used when building rules in the Data Element Change Event or Custom Code Event to trigger a rule to execute. A data element can also be used in the Data Element Condition, or other Conditions, Exceptions, or Actions in a rule.

Once the data element is created (the mapping is set up), users can reference the source data simply by referencing the data element. If the source of the value ever changes (site re-designs, etc.) users only need update the mapping once in Launch and all the data elements will automatically receive the new source value.

Create a Rule to Use Your Extension

Click on the Rules link in the top navigation, then Add Rule:

First, name the rule, any name is fine. The Create New Rule screen is set up like an if-then statement:

If an event occurs, and conditions pass, and there are no exceptions, the action is triggered. This same flow exists in extensions where you can create or leverage events, conditions, exceptions, data elements, or actions.

Continuing with the Facebook example, let’s add an event for any time a page loads on our site:

With the Window Loaded Event Type, any time a page loads on our site this rule will be triggered. Click Save. For this example, let’s skip Conditions and Exceptions as we want this rule triggered for any page on our site - our “global” On Load rule so to speak.

Under Actions click Add. On this Action Configuration screen we can choose the extension we want to work with and the action we want to occur when this rule is triggered. Let’s choose the Facebook Pixel under Extension, and Send Page View under Action Type:

Click the blue Keep Changes at the bottom, and Save Rule on the next screen. When testing your extension, you can select any events, conditions, etc. supplied by your extension in any number of rules.

Publishing Your Changes

In the main navigation, click on Publishing, then on the blue Add New Library link:

A library is a set of instructions for how extensions, data elements, and rules will interact with one another and with a website. Libraries are compiled into builds. A library can contain as many changes as a user is comfortable making or testing at once.

On the Create New Library screen, add a Name and choose an Environment. dev and dev (development) would be one example. For now, we’ll add all available resources, so click on Add All Changed Resources

Then click the blue Save link at the bottom. Now that we have all our changes included in this dev library, let’s build it:

After the build process completes, you should see a green success indicator next to the library name:

You can now navigate to your test page to see your extension operate from within Launch.

Also remember to re-build your Library anytime you make changes in the interface, and add any new changed resources.

Testing and Troubleshooting

While validating your extension on your test page or site, there are a few console commands that will be helpful:

  • _satellite.setDebug(true); will put Launch into debug mode and output useful logging statements to the console.
  • The _satellite.buildInfo object contains useful properties like _satellite.buildInfo.buildDate and _satellite.buildInfo.environment