Deprecation date changed to June 1st, 2026

The deprecation date has been changed from March 2nd, 2026 to June 1st, 2026.

Only the date has been changed. The functionality which will be deprecated remains the same.

On June 1st, 2026, the following API integration functionality will be deprecated:

1. Non-OAuth 2.0 API authorization routes that start with /api/oauth (2025-001)
2. Integration registrations with an empty OAuth Flow Type or "Authorization Code (Obsolete)" (2025-002)
3. PM Pagehooks using the /Aprimo/LaunchExternalApp.aspx route for injecting contextual tokens, including {{authorization_code}}, into a URL for an external application (2025-003)
4. DAM Pagehooks using auth-code parameter for acquiring tokens (2025-004)
5. Uploads via the https://upload.aprimo.com/ endpoint (2025-005)
6. Uploads without a valid API token (2025-006)

Any integrations using the deprecated functionality will stop working after June 1st, 2026. Before this date, transition your integrations to use supported functionality as documented in the migration steps in the following sections.

Migration Documentation

Refer to the documentation of each scenario below for steps to migrate an integration to a supported replacement.

2025-001: Non-OAuth 2.0 API authorization routes (e.g. /api/oauth/...)

The following API routes are deprecated:

• /api/oauth/create-native-token
• /api/oauth/authorize (and /api/oauth/create-token)
• /api/oauth/exchange-auth-code

These routes are used to acquire API tokens to the Aprimo platform. Replace usages of these routes with the available OAuth 2.0 authorization routes.

Specific migration steps for each route are below.

POST /api/oauth/create-native-token (Resource Owner Password Flow)

Before:

POST /api/oauth/create-native-token
client-id: <Client ID>
Authorization: Basic <Base64(UserName:UserToken)>

After:

First, make sure you register your client in Aprimo with the Resource Owner Password flow.

POST /login/connect/token
Content-Type: application/x-www-form-urlencoded

grant_type=password&client_id=<Client ID>&client_secret=<Client Secret>&username=<UserName>&password=<UserToken>

Resources:

• Resource Owner Password Documentation

GET /api/oauth/authorize (Authorization Code Flow)

Before:

1. Navigate user to /api/oauth/authorize?client_id=<Client ID>&redirect_uri=<RedirectURI>
2. User authenticates to Aprimo
3. Redirected to <RedirectURI> with ?AuthorizationCode=<Authorization Code>
4. Make HTTP request:

   POST /api/oauth/create-token
   client-id: <Client ID>
   authorization-code: <Authorization Code>
   Authorization: Basic <Base64(<Client ID>:<Client Secret>)>

After:

First, make sure you register your client in Aprimo with the Authorization Code with PKCE flow.

1. Navigate user to /login/connect/authorize?client_id=<Client ID>&redirect_uri=<RedirectURI>&response_type=code&state=<State>&code_challenge=<Code Challenge>&code_challenge_method=S256

2. User authenticates to Aprimo

3. Redirected to <RedirectURI> with ?code=<Authorization Code>&state=<State>&scope=<Scope>

4. Make HTTP request:

   POST /login/connect/token
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=authorization_code&client_id=<Client ID>&client_secret=<Client Secret>&code=<Authorization Code>&redirect_uri=<RedirectURI>&code_verifier=<Code Verifier>

Resources:

• Authorization Code with PKCE Documentation

GET /api/oauth/exchange-auth-code

Before:

GET /api/oauth/exchange-auth-code
client-id: <Client ID>
X-Access-Token: <Access Token>

After:

There is no direct replacement for this route. Instead, use the Authorization Code with PKCE flow as described above. The exchange-auth-code route is no longer needed because the authorization code is exchanged for an API token in the /login/connect/token request.

Resources:

• Authorization Code with PKCE Documentation

2025-002: Integration registrations with an empty OAuth Flow Type or "Authorization Code (Obsolete)"

Integration registrations (also called integration clients) have a property called OAuth Flow Type which determines which of the OAuth 2.0 flows can be used for that integration registration. The following OAuth Flow Types are deprecated:

• <None>
• Authorization Code (Obsolete)

These OAuth Flow Types remain supported:

• Client Credential
• Resource Owner Password
• Authorization Code with PKCE

Specific migration steps for each of the deprecated OAuth Flow Types are below. In order to support a graceful migration, it is recommended that a new integration registration is created instead of updating the existing integration registration in place.

None

An integration registration with an OAuth Flow Type of <None> can only be used with the non-OAuth 2.0 authorization routes which are also deprecated. Depending on the use case, you should switch to one of the supported OAuth Flow Types:

• Client Credential
• Resource Owner Password
• Authorization Code with PKCE

Resources:

• OAuth 2.0 Documentation

Authorization Code (Obsolete)

Create a new integration registration or update the existing registration to the "Authorization Code with PKCE" flow. Update the integration to pass the code_challenge and code_challenge_method query string parameters to the authorize endpoint (e.g. /login/connect/authorize).

Resources:

• Authorization Code with PKCE Documentation

2025-003: PM Pagehooks using the /Aprimo/LaunchExternalApp.aspx route for injecting contextual tokens, including {{authorization_code}}, into a URL for an external application

The route /Aprimo/LaunchExternalApp.aspx which is used to add contextual tokens (such as PageId) into a URL for an external application as part of a PM Pagehook is deprecated. Intead, configure the Pagehook URL to point directly to the external application and not /Aprimo/LaunchExternalApp.aspx. All contextual tokens that were previously being used are supported, except for the {{authorization_code}} contextual token.

More details are below.

Pagehooks without {{authorization_code}}

Before:

• Pagehook URL: /Aprimo/LaunchExternalApp.aspx?aprimo_registration_id=5737
• Integration registration 5737 Redirect URL: https://my.example.com/?Page={{PageID}}&ID={{ID}}

When the user clicks the Pagehook button, they are sent to /Aprimo/LaunchExternalApp.aspx, which will read the redirect URL in the integration registration specified by the ID of the aprimo_registration_id query string parameter and then replace any available tokens in the URL and finally redirect the user to the external application.

After:

• Pagehook URL: https://my.example.com/?Page={{PageID}}&ID={{ID}}

Note that you no longer have to use an integration registration. All contextual tokens will still be replaced in your Pagehook URL.

If your Pagehook was using the {{authorization_code}} contextual token before, then refer to the migration steps in the next section.

Pagehooks with {{authorization_code}}

To authenticate as the current Aprimo user that triggers a PM Pagehook, register a standard integration client using the "Authorization Code with PKCE" flow. When a user navigates to the external application (either via a Pagehook or otherwise), you can capture any contextual tokens and then start an authorization flow.

Before:

• Pagehook URL: LaunchExternalApp.aspx?aprimo_registration_id=5737
• Integration registration 5737 Redirect URL: https://my.example.com/?Page={{PageID}}&ID={{ID}}&AuthCode={{authorization_code}}

After:

• Pagehook URL: https://my.example.com/?Page={{PageID}}&ID={{ID}}

You should still have an integration registration configured, but your redirect URL should NOT contain any contextual tokens. When the user lands on your application, you can then start an authorization flow. You will likely need to capture and save any contextual tokens that are important for your flow (such as in a Cookie or other browser storage).

Resources:

• Authorization Code with PKCE Documentation
• PM Pagehooks Documentation

2025-004: DAM Pagehooks using auth-code parameter for acquiring tokens

The auth-code parameter used in DAM Pagehooks is deprecated. Migrate to access-token for continued support. Note that access-token is a simpler integration because it does not require an integration registration to be created and the Pagehook endpoint will receive an API token in the initial request instead of a code that has to be exchanged for an API token. The API token received still represents the user that triggered the Pagehook.

Specific migration scenarios are described below.

DAM Assets

Before:

<add
  type="Adam.Web.Extensions.Providers.Actions.PageHookAction, Adam.Web.Extensions"
  name="Page Hook"
  include="auth-code"
  url="https://my.example.com/pagehook"
  location="[self / new]"
  clientId="[client id]"
/>

Where [client id] represents the integration registration's Client ID.

When the Pagehook is triggered, the url receives a POST request with a body of content type application/x-www-form-urlencoded that looks like:

auth-code=XXX

Then, it would call POST /api/oauth/create-token to exchange the code for an API token.

Finally, it could use the API token to call Aprimo APIs authenticated as the user that triggered the action.

After:

<add
  type="Adam.Web.Extensions.Providers.Actions.PageHookAction, Adam.Web.Extensions"
  name="Page Hook"
  include="access-token"
  url="https://my.example.com/pagehook"
  location="[self / new]"
/>

(Note that the include="auth-code" is replaced with include="access-token" and clientId is removed.)

When the Pagehook is triggered, the url receives a POST request with a body of content type application/x-www-form-urlencoded that looks like:

access-token=XXX

The Pagehook can use the API token it receives to call Aprimo APIs authenticated as the user that triggered the action.

There is no need for an integration registration.

Resources:

• DAM Pagehooks Documentation

DAM UI

Before:

{
  "name": "value",
  "type": "pageHook",
  "translationKey": "value",
  "parameters": {
    "sendToken": "auth-code",
    "url": "https://my.example.com/pagehook",
    "location": "[self / new]",
    "clientId": "[client id]"
  }
}

Where [client id] represents the integration registration's Client ID.

When the Pagehook is triggered, the url receives a POST request with a body of content type application/x-www-form-urlencoded that looks like:

auth-code=XXX

Then, it would call POST /api/oauth/create-token to exchange the code for an API token.

Finally, it could use the API token to call Aprimo APIs authenticated as the user that triggered the action.

After:

{
  "name": "value",
  "type": "pageHook",
  "translationKey": "value",
  "parameters": {
    "sendToken": "access-token",
    "url": "https://my.example.com/pagehook",
    "location": "[self / new]",
  }
}

(Note that the "sendToken": "auth-code" is replaced with "sendToken": "access-token" and clientId is removed.)

When the Pagehook is triggered, the url receives a POST request with a body of content type application/x-www-form-urlencoded that looks like:

access-token=XXX

The Pagehook can use the API token it receives to call Aprimo APIs authenticated as the user that triggered the action.

There is no need for an integration registration.

Resources:

• DAM UI Actions Documentation

2025-005: Uploads via the https://upload.aprimo.com/ endpoint

The Upload Service at https://upload.aprimo.com is deprecated. File uploads should use the upload route available on the Aprimo application domain e.g. https://<tenant>.aprimo.com/uploads.

2025-006: Uploads without a valid API token

When doing an upload via the Upload Service (either the deprecated endpoint https://upload.aprimo.com or the Aprimo application domain https://<tenant>.aprimo.com/uploads) a valid API token is only required for the initial request. An expired API token can be used for any subsequent chunk uploads. This is now deprecated.

Going forward, the Upload Service will require a valid bearer token for all requests during an upload. Make sure you are always including a valid bearer token. If you receive a response with status code 401, make sure to refresh your bearer token before continuing the upload.