Any users who use the Managed by Adobe Host can now retrieve builds for the last five production library publishes.
For regular, non-archive builds you an republish the build. This will link your Production embed code to the build for the older library that you’ve selected. If you’ve discovered a problem with your production library and need to quickly restore it to a known good state, this gives you the ability to rollback to a known good library. This only links the embed code to an older build, it does not change the state of any resources on your Property.
For archived builds, you can simply download a copy of the older library.
We cannot republish any builds that used the SFTP Host type.
We currently keep the five most recent builds for production libraries. Any older builds are cleaned up. You can only republish one of these five.
Through the API, this is accomplished by PATCHing the build itself and supplying a meta action. For a specific example, please check the Republish Build API doc.
Notes are now available to be attached to Properties, Data Elements, Rules, Rule Components, Extensions, and Libraries. Notes are short, text-only annotations that can be used for descriptions of what a resource does, how a resource should be used, and much more.
Learn more and get started using Notes in the Notes API section of the docs.
The Notes API is not yet finalized, and may change in ways that are not backwards-compatible.
When we first released the Launch API, Adobe I/O integrations were not fully integrated into Adobe’s Admin Console where regular user accounts are controlled. As a result, these integrations had a different set of available permissions.
Adobe I/O integrations can use the same permission groups (called Product Profiles) - created and managed in Adobe’s Admin Console - that regular users use.
When you login to the Adobe I/O console to create a new integration (or update an existing integration), instead of the older role selector, you’ll now see a list of product profiles from the Admin Console. You’ll need to select the product profile you want the integration to belong to. If desired, you may select more than one product profile for your integration to belong to.
Newly created integrations will use the assigned product profile.
Existing integrations will continue to function using their assigned roles for the next 4 months. Beginning in January 2020, integrations that do not have an assigned product profile will cease to function until they are updated. If you assign a product profile to an existing integration before January 2020, then no action will be needed at that time. This also means that if you want to test your integration in a product profile before January, the only way to do that will be to create a new integration.
To update your configuration, login to the IO Console, select the Company the integration belongs to, click on the integration you want to update, click the Services tab, under Configured Services hover on “Experience Platform Launch API”, and then click the Config icon. Choose the product profile with the appropriate permissions and click Apply.
We recently made a change to the hosting paths for libraries to use a much shorter ID to represent Company, Property and Environment in the embed codes. These changes will be most visible on newly created environments. All the embed codes that are already in use will continue to be valid. If you want to use the new shortened embed codes for existing environments, that will also work.
LIKEmodifier on filters, this was replaced with a
CONTAINSmodifier before we went to GA and the
LIKEwas kept around for compatibility to give people time to move over. The time is up.
reactor-releaser is available on npm. This tool will help you transition your extension packages from
private. No more Postman scripts if you don’t want to use them.
If you are passing a
meta block on a PATCH request, any
attributes that you pass on the same request are not required and will be ignored. This change will prevent modifying a resource and transitioning it to a new state at the same time. This will allow you to get a resource back from the API, and transition its state without having to explicitly remove the
attributes block before you PATCH it back. This change affects the following resources.
The Reactor API is officially versioned at 1.0. Within the 1.x series of releases, we will not make any breaking changes. We will continue to make additive changes. Those changes will be documented here in the release notes and the Reference section will be kept up to date as changes are made.
The following changes were made with today’s 1.0 release. Some of these changes are breaking from the previous behavior and were made so that we don’t have to break it in the future.
Retrieving the resources within a Library has been changed to be consistent with the way that you retrieve resources for a Build. You can retrieve each resource type from a paginated endpoint under Library.
/library/:library_id/extensions /library/:library_id/data_elements /library/:library_id/rules
Some endpoints support an
?includes parameter to retrieve the resource along with other related resources. A few of these did not have any limits in place, such that you could ask for an unlimited number of resources. These have been removed:
Rule Components used to exist as children of a Rule. That made it impossible to reuse the same components across multiple rules. In order to enable us to add this capability in the future, Rule Components need to move out from under a Rule and live at the Property level.
Please see Rule Components for detailed examples.
Most everyone we talked to told us that the name Adapter didn’t make much sense. Much debate ensued. Adapters are now called Hosts. Please see Hosts for detailed examples.