Asset Compute Service HTTP API

The use of the API is limited to development purposes. The API is provided as a context when developing custom applications. Adobe Experience Manager as a Cloud Service uses the API to pass the processing information to a custom application. For more information, see Use asset microservices and Processing Profiles.

Any client of the Asset Compute Service HTTP API must follow this high-level flow:

1. A client is provisioned as Adobe Developer Console project in an IMS organization. Each separate client (system or environment) requires its own separate project in order to separate the event data flow.

2. A client generates an access token for the technical account using the JWT (Service Account) Authentication.

3. A client calls /register only once to retrieve the journal URL.

4. A client calls /process for each asset for which it wants to generate renditions. The call is asynchronous.

5. A client regularly polls the journal to receive events. It receives events for each requested rendition when the rendition is successfully processed (rendition_created event type) or if there is an error (rendition_failed event type).

The @adobe/asset-compute-client module makes it easy to use the API in Node.js code.

Authentication and authorization

All APIs require access token authentication. The requests must set the following headers:

1. Authorization header with bearer token, which is the technical account token, received via JWT exchange from Adobe Developer Console project. The scopes are documented below.

2. x-gw-ims-org-id header with the IMS organization ID.

3. x-api-key with the client ID from the Adobe Developers Console project.

Scopes

Ensure the following scopes for the access token:

• openid
• AdobeID
• asset_compute
• read_organizations
• event_receiver
• event_receiver_api
• adobeio_api
• additional_info.roles
• additional_info.projectedProductContext

These require the Adobe Developer Console project to be subscribed to Asset Compute, I/O Events, and I/O Management API services. The breakdown of individual scopes is:

• Basic

  • scopes: openid,AdobeID

• Asset Compute

  • metascope: asset_compute_meta
  • scopes: asset_compute,read_organizations

• Adobe I/O Events

  • metascope: event_receiver_api
  • scopes: event_receiver,event_receiver_api

• Adobe I/O Management API

  • metascope: ent_adobeio_sdk
  • scopes: adobeio_api,additional_info.roles,additional_info.projectedProductContext

Registration

Each client of the Asset Compute service - a unique Adobe Developer Console project subscribed to the service - must register before making processing requests. The registration step returns the unique event journal which is required to retrieve the asynchronous events from rendition processing.

At the end of its lifecycle, a client can unregister.

Register request

This API call sets up an Asset Compute client and provides the event journal URL. This is an idempotent operation and only needs to be called once for each client. It can be called again to retrieve the journal URL.

Register response

The HTTP status codes are:

• 200 Success: When the request is successful. It contains the journal URL that is be notified about any results of the asynchronous processing triggered via /process (as events type rendition_created when successful, or rendition_failed when failing).

  {
      "ok": true,
      "journal": "https://api.adobe.io/events/organizations/xxxxx/integrations/xxxx/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "requestId": "1234567890"
  }
  

• 401 Unauthorized: occurs when the request does not have valid authentication. An example might be an invalid access token or invalid API key.

• 403 Forbidden: occurs when the request does not have valid authorization. An example might be a valid access token, but the Adobe Developer Console project (technical account) is not subscribed to all required services.

• 429 Too many requests: occurs when the system is overloaded by this client or otherwise. Clients should retry with an exponential backoff. The body is empty.

• 4xx error: When there was any other client error and registration failed. Usually a JSON response such as this is returned, although that is not guaranteed for all errors:

  {
      "ok": false,
      "requestId": "1234567890",
      "message": "error message"
  }
  

• 5xx error: occurs when there was any other server side error and registration failed. Usually a JSON response such as this is returned, although that is not guaranteed for all errors:

  {
      "ok": false,
      "requestId": "1234567890",
      "message": "error message"
  }
  

Unregister request

This API call unregisters an Asset Compute client. After this it is no longer possible to call /process. Using the API call for an unregistered client or a yet-to-be registered client returns a 404 error.

Unregister response

The status codes are:

• 200 Success: occurs when the registration and journal is found and removed.

  {
      "ok": true,
      "requestId": "1234567890"
  }
  

• 401 Unauthorized: occurs when the request does not have valid authentication. An example might be an invalid access token or invalid API key.

• 403 Forbidden: occurs when the request does not have valid authorization. An example might be a valid access token, but the Adobe Developer Console project (technical account) is not subscribed to all required services.

• 404 Not found: occurs when there is no current registration for the given credentials.

  {
      "ok": true,
      "requestId": "1234567890"
  }
  

• 429 Too many requests: occurs when the system is overloaded. Clients should retry with an exponential backoff. The body is empty.

• 4xx error: occurs when there was any other client error and unregister failed. Usually a JSON response such as this is returned, although that is not guaranteed for all errors:

  {
      "ok": false,
      "requestId": "1234567890",
      "message": "error message"
  }
  

• 5xx error: occurs when there was any other server side error and registration failed. Usually a JSON response such as this is returned, although that is not guaranteed for all errors:

  {
      "ok": false,
      "requestId": "1234567890",
      "message": "error message"
  }
  

Process request

The process operation submits a job that transforms a source asset into multiple renditions, based on the instructions in the request. Notifications about successful completion (event type rendition_created) or any errors (event type rendition_failed) are sent to an Event journal that must be retrieved using /register once before making any number of /process requests. Incorrectly formed requests immediately fail with a 400 error code.

Binaries are referenced using URLs, such as Amazon AWS S3 pre-signed URLs or Azure Blob Storage SAS URLs, for both reading the source asset (GET URLs) and writing the renditions (PUT URLs). The client is responsible for generating these pre-signed URLs.

Process request JSON

The request body of /process is a JSON object with this high-level schema:

{
    "source": "",
    "renditions" : []
}

The available fields are:

The source can either be a <string> that is seen as a URL or it can be an <object> with an additional field. The following variants are similar:

"source": "http://example.com/image.jpg"

"source": {
    "url": "http://example.com/image.jpg"
}

Source object fields

A complete process request example

{
    "source": "https://www.adobe.com/content/dam/acom/en/lobby/lobby-bg-bts2017-logged-out-1440x860.jpg",
    "renditions" : [{
            "name": "image.48x48.png",
            "target": "https://some-presigned-put-url-for-image.48x48.png",
            "fmt": "png",
            "width": 48,
            "height": 48
        },{
            "name": "image.200x200.jpg",
            "target": "https://some-presigned-put-url-for-image.200x200.jpg",
            "fmt": "jpg",
            "width": 200,
            "height": 200
        },{
            "name": "cqdam.xmp.xml",
            "target": "https://some-presigned-put-url-for-cqdam.xmp.xml",
            "fmt": "xmp"
        },{
            "name": "cqdam.text.txt",
            "target": "https://some-presigned-put-url-for-cqdam.text.txt",
            "fmt": "text"
    }]
}

Process response

The /process request immediately returns with a success or a failure based on the basic request validation. Actual asset processing happens asynchronously.

Status codes:

• 200 Success: If the request was successfully submitted. Response JSON includes "ok": true:

  {
      "ok": true,
      "requestId": "1234567890"
  }
  

• 400 Invalid request: If the request is incorrectly formed, such as required fields missing in the request JSON. Response JSON includes "ok": false:

  {
      "ok": false,
      "requestId": "1234567890",
      "message": "error message"
  }
  

• 401 Unauthorized: When the request does not have valid authentication. An example might be an invalid access token or invalid API key.

• 403 Forbidden: When the request does not have valid authorization. An example might be a valid access token, but the Adobe Developer Console project (technical account) is not subscribed to all required services.

• 429 Too many requests: When the system is overloaded by this client or in general. The clients can retry with an exponential backoff. The body is empty.

• 4xx error: When there was any other client error. Usually a JSON response such as this is returned, although that is not guaranteed for all errors:

  {
      "ok": false,
      "requestId": "1234567890",
      "message": "error message"
  }
  

• 5xx error: When there was any other server side error. Usually a JSON response such as this is returned, although that is not guaranteed for all errors:

  {
      "ok": false,
      "requestId": "1234567890",
      "message": "error message"
  }
  

Most clients are likely inclined to retry the exact same request with exponential backoff on any error except configuration issues such as 401 or 403, or invalid requests like 400. Apart from regular rate limiting via 429 responses, a temporary service outage or limitation might result in 5xx errors. It would then be advisable to retry after a period of time.

All JSON responses (if present) include the requestId which is the same value as the X-Request-Id header. It is recommended to read from the header, since it is always present. The requestId is also returned in all events related to processing requests as requestId. Clients must not make any assumption about the format of this string, it is an opaque string identifier.

Opt-in to post-processing

The Asset Compute SDK supports a set of basic image post-processing options. Custom workers can explicitly opt in to post-processing by setting the field postProcess on the rendition object to true.

The supported use cases are:

• Crop a rendition to a rectangle whose limits are defined by crop.w, crop.h, crop.x, and crop.y. It is defined by instructions.crop in the rendition object.
• Resize images using width, height, or both. It is defined by instructions.width and instructions.height in the rendition object. To resize using only width or height, set only one value. Compute Service conserves the aspect ratio.
• Set the quality for a JPEG image. It is defined by instructions.quality in the rendition object. The best quality is denoted by 100 and smaller values indicate reduced quality.
• Create interlaced images. It is defined by instructions.interlace in the rendition object.
• Set DPI to adjust the rendered size for desktop publishing purposes by adjusting the scale applied to the pixels. It is defined by instructions.dpi in the rendition object to change dpi resolution. However, to resize the image so that it is the same size at a different resolution, use the convertToDpi instructions.
• Resize the image such that its rendered width or height remains the same as the original at the specified target resolution (DPI). It is defined by instructions.convertToDpi in the rendition object.

Watermark assets

The Asset Compute SDK supports adding a watermark to PNG, JPEG, TIFF, and GIF image files. The watermark is added following the rendition instructions in the watermark object on the rendition.

Watermarking is done during rendition post-processing. To watermark assets, the custom worker opts into post-processing by setting the field postProcess on the rendition object to true. If the worker does not opt-in then watermarking does not applied, even if the watermark object is set on the rendition object in the request.

Rendition instructions

These are the available options for the renditions array in /process.

Common fields

Rendition specific fields

For a list of currently supported file formats, see supported file formats.

Watermark-specific fields

PNG format is used as a watermark.

Asynchronous events

Once processing of a rendition is finished or when an error occurs, an event is sent to an Adobe I/O Events Journal. Clients must listen to the journal URL provided through /register. The journal response includes an event array consisting of one object for each event, of which the event field includes the actual event payload.

The Adobe I/O Event type for all events of the Asset Compute Service is asset_compute. The journal is automatically subscribed to this event type only and there is no further requirement to filter based on the Adobe I/O Event type. The service specific event types are available in the type property of the event.

Event types

Event attributes

Metadata

Error reasons