Update Product Profile

DEPRECATED: These APIs have been deprecated. Please refer to the User Management Action API for details on the supported approach to assign and manage membership and administrative rights within your Organization.

POST [UM_Server]/{orgId}/products/{productId}/configurations/{profileId}

Manage membership and administrative rights for a specific product profile in a POST request to the profile endpoint. Use this API to grant or revoke the Product Profile Admin role for one or more users.

• Parameters
• Request Body
• Responses
• Example Requests
• Throttling Limits

Parameters

This table summarizes the parameters and how they are provided:

Request Body

The JSON payload specifies lists of users and user groups to add or remove from membership, and users for whom to add or remove the admin role. You only need to specify the lists you are modifying.

Example

{
    "addUsers": [
        "a.smith@myCompany.com"
    ],
    "removeUsers": [
        "b.jones@myCompany.com"
    ],
    "addUserGroups": [
        "UMSDK User Group"
    ],
    "removeUserGroups": [
        "UMSDK User Group 2"
    ],
    "addAdminUsers" : [
        "jdoe@myCompany.com"
    ],
    "removeAdminUsers": [
        "ann.other@myCompany.com"
    ]
}

Responses

Content-Type: application/json

• 200: OK
• 400: Bad Request
• 401: Unauthorized
• 403: Forbidden
• 429: Too Many Requests

200 OK

The response body contains the updated product in JSON format.

400 Bad Request

Some parameters of the request were not understood by the server or the Service Account Integration certificate has expired.

Possible cause:

• Group name already exists

> POST /v2/usermanagement/users/092DE2D65617B9967F000101@AdobeOrg/user-groups HTTP/1.1
< HTTP/1.1 400 Bad request
< Canonical-Resource: /v2/usermanagement/users/{orgId}/{page}/{groupName}
{"errorMessage":"DUPLICATE_GROUP_NAME","errorCode":"DUPLICATE_GROUP_NAME"}

• Attempting to modify a readonly group e.g. update the group name

> v2/usermanagement/action/56EB197B663A09470A494111@AdobeOrg HTTP/1.1
> [
>   {
>     "usergroup": "UMAPI Test",
>     "do": [
>       {
>         "updateUserGroup": {
>           "name": "UMAPI Test Updated"
>         }
>       }
>     ]
>   }
> ]
< Canonical-Resource: /v2/usermanagement/action/{orgId}
< {
<   "completed": 0,
<   "notCompleted": 1,
<   "completedInTestMode": 0,
<   "result": "error",
<   "errors": [
<     {
<       "index": 0,
<       "step": 0,
<       "message": "Usergroup is owned by another org and readonly: UMAPI Test",
<       "errorCode": "error.usergroup.readonly.update_not_allowed",
<       "user": "UMAPI Test"
<     }
<   ]
< }

• Attempting to add a user membership of a readonly group

> POST v2/usermanagement/action/56EB197B663A09470A494111@AdobeOrg HTTP/1.1
> [
>  {
>    "usergroup": "UMAPI Test",
>    "do": [
>      {
>        "add": {
>          "user": [
>            "test@user.com"
>          ]
>        }
>      }
>    ]
>  }
> ]
< Canonical-Resource: /v2/usermanagement/action/{orgId}
< {
<   "completed": 0,
<   "notCompleted": 1,
<   "completedInTestMode": 0,
<   "result": "error",
<   "errors": [
<     {
<       "index": 0,
<       "step": 0,
<       "message": "User cannot be added to group as owned by another org and readonly: UMAPI Test",
<       "errorCode": "error.usergroup.readonly.add_user_not_allowed",
<       "user": "UMAPI Test"
<     }
<   ]
< }

• Attempting to remove a user membership of a readonly group

> POST v2/usermanagement/action/56EB197B663A09470A494111@AdobeOrg HTTP/1.1
> [
>  {
>    "usergroup": "UMAPI Test",
>    "do": [
>      {
>        "remove": {
>          "user": [
>            "test@user.com"
>          ]
>        }
>      }
>    ]
>  }
> ]
< Canonical-Resource: /v2/usermanagement/action/{orgId}
< {
<   "completed": 0,
<   "notCompleted": 1,
<   "completedInTestMode": 0,
<   "result": "error",
<   "errors": [
<     {
<       "index": 0,
<       "step": 0,
<       "message": "User cannot be removed from group as owned by another org and readonly: UMAPI Test",
<       "errorCode": "error.usergroup.readonly.remove_user_not_allowed",
<       "user": "UMAPI Test"
<     }
<   ]
< }

• Attempting to remove a readonly group from the organization

> POST v2/usermanagement/action/56EB197B663A09470A494111@AdobeOrg HTTP/1.1
> [
>   {
>     "usergroup": "UMAPI Test",
>     "do": [
>       {
>         "deleteUserGroup": {}
>       }
>     ]
>   }
> ]
< Canonical-Resource: /v2/usermanagement/action/{orgId}
< {
<   "completed": 0,
<   "notCompleted": 1,
<   "completedInTestMode": 0,
<   "result": "error",
<   "errors": [
<     {
<       "index": 0,
<       "step": 0,
<       "message": "User group owned by another organization. Remove not allowed: UMAPI Test",
<       "errorCode": "error.usergroup.readonly.remove_not_allowed",
<       "user": "UMAPI Test"
<     }
<   ]
< }

401 Unauthorized

Possible causes are:

• Invalid or expired token.
• Invalid Organization.

< HTTP/1.1 401 Unauthorized
< Content-Type: */*
< Date: Thu, 22 Jun 2017 09:47:04 GMT
< WWW-Authenticate: Bearer realm="JIL", error="invalid_token", error_description="The access token is invalid"
< X-Request-Id: user-assigned-request-id
< Content-Length: 0
< Connection: keep-alive

403 Forbidden

Possible causes are:

• Missing API key.
• The organization is currently migrating. Either from DMA or to One Console.
• API key is not permitted access.

< HTTP/1.1 403 Forbidden
< Date: Thu, 22 Jun 2017 09:41:22 GMT
< X-Request-Id: user-assigned-request-id
< Content-Length: 0
< Connection: keep-alive

Throttling

To protect the availability of the Adobe back-end user identity systems, the User Management API imposes limits on client access to the data. Limits apply to the number of calls that an individual client can make within a time interval, and global limits apply to access by all clients within the time period. For this API the throttling limits are as follows:

• Maximum calls per client: 5 requests per a minute
• Maximum calls for the application: 50 requests per a minute

When the client or global access limit is reached, further calls fail with HTTP error status 429 Too Many Requests. The Retry-After header is included in the 429 response, and provides the minimum amount of time that the client should wait until retrying. See RFC 7231 for full information.

The User Management API recommends limiting your syncs to two hourly intervals and consider scheduling your sync for a time that works best for you, taking into account other timezones and clients. This will help to prevent how often your client is throttled.

The following sample shows a 429 response with the Retry-After header detailing the number of seconds to wait before retry:

========================= RESPONSE =========================
Status code: 429
-------------------------- header --------------------------
Content-Type: application/json
Date: Fri, 19 Jan 2018 10:31:43 GMT
Retry-After: 38
Server: APIP
X-Request-Id: iEUtsLiFgj3R4xsbirAyZlMyaxRTo8Xo
Content-Length: 54
Connection: keep-alive
--------------------------- body ---------------------------
{
  "error_code" : "429050",
  "message" : "Too many requests"
}
============================================================

Because of the global limits, and because the specific limits may change, you cannot simply limit the rate at which you make your own calls. You must handle rate-limit errors by retrying the failed calls. We recommend an exponential backoff retry technique for handling such errors.

Handling error responses

When you retry a failed request, the retry can also fail, and can fall back into the retry loop, adding to the system overload. The exponential backoff retry method increases the period between retries, so that the client makes fewer calls while the system is overloaded.

To implement an exponential backoff method, you increase the retry interval with each failed request. You should retry sending the request after a certain number of seconds, and increase that interval by a random amount with each attempt. For example, you can double the retry period each time, or escalate it by a power of 2, and then add a small random delay between failures.

A small random delay, known as “jitter,” prevents the “herd effect” that can occur if many clients attempt to reconnect to a recovering system at the same time. Without jitter, all of the retries could occur after 20 seconds, then 40 seconds, and so on. With the jitter, different retries occur at slightly different intervals. This allows the system to recover without further overloading it.

For an example of how to implement this error-handling method, see “Retrying Requests” in the User Management Walkthrough.