Events Publishing API

Prerequisites

Create a project and a workspace in the Adobe Developer Console
Add the I/O Management API in this Adobe Developer Console workspace
Generate an OAuth Server-to-Server token
Using Adobe I/O Events Provider API
- create your own Custom Events Provider
- create at least one Event Metadata associated with the above

data-slots=title, text

Data Residency:

Please note that all custom events are stored in the United States (US) region.

Throttling Policy

We do have a throttling policy in place, we accept up to 3,000 requests / 5 secs per api-key. Your throttled requests will receive a HTTP Status 429 (Too Many Requests) response with a Retry-After header, following the RFC 7231 HTTP standard.

Test Drive

Once its Event Metadata is persisted in Adobe I/O Events (see above prerequisites), your Custom Events Provider can start publishing its CloudEvents to Adobe I/O Events publishing endpoint (https://eventsingress.adobe.io).

Please follow CloudEvents v1.0 specification, here is a sample curl command:

curl -i --location --request POST  \
       --url https://eventsingress.adobe.io \
       --header "x-api-key: $api_key" \
       --header "Authorization: Bearer $oauth_s2s_token" \
       --header 'Content-Type: application/cloudevents+json' \
       --header "x-event-phidata: $is_phidata" \
       --data '{
         "datacontenttype": "application/json",
         "specversion": "1.0",
         "source": "urn:uuid:'"${provider_id}"'",
         "type": "'"${event_code}"'",
         "id": "'"${event_id}"'",
         "data": "your event json payload"
         "customattribute" : "cloud events custom extension"
       }'

The environment variables used in this curl command are computed from the above prerequisites

api_key is the api-key associated with your Adobe Developer Console workspace
oauth_s2s_token is an OAuth Server-to-Server token generated using the set up from the same workspace
is_phidata is a boolean value indicating if the event contains PHI data, and is required for HIPAA compliance (defaults to false if not provided)
provider_id is your Custom Events Provider uuid generated by Adobe I/O Events Provider API
event_code is the Custom Events Provider's Event Metadata's event_code as persisted using Adobe I/O Events Provider API
event_id is any id of your choice (examples: UUID, event counter) guaranteeing that source + id is unique for each distinct event see CloudEvents spec
as for the value of data in the CloudEvents body payload, it can be any json payload.
customattribute (a.k.a cloud events extensions) are any attributes defined by you following the CloudEvents attribute naming convention

The API returns

HTTP Status 200 (OK) if the event has been processed correctly and there are active registrations for the event
HTTP Status 204 (No Content) if there are no registrations for the event
HTTP Status 429 (Too Many Requests) if your api-key is being throttled (see our Throttling Policy)
as well as the other usual (4xx/5xx) error codes if there was an issue in processing the request
- HTTP status 400 is returned if payload failed to deserialize due to being non-compliant as per CloudEvents spec

HIPAA Compliance Support

I/O Events is compliant with HIPAA regulation. The event producers are responsible to signal if the event contains PHI data by setting the optional x-event-phidata header to true in the request. When the header is present and set to true:

the resulting CloudEvents-formatted event which is produced will be enriched with a CloudEvents extension, namely, a phidata node, set to true,
with the above phidata extension receivers will be able to identify which events contain PHI data and handle them accordingly,
audit trace logs will be preserved for 1 year in a HIPAA-compliant storage,
the id field in the CloudEvents payload will be used as a trace-id for the above audit trace logs.

In the event of an audit, you will need to be able to provide evidences of how the patient data was handled.

Audit log: storing the mapping between PHI data to ids

It is your responsibility to store the id in your own logs or storage solution for traceability. If you are handling multiple end patients data (PHIs), you should also store what id you produced corresponds to what patient data, to be able to provide information regarding that patient data in case of an audit specific to that patient.

You can ask I/O Events support to retrieve the audit trace logs for a given set of ids you produced. You can reach the support team through the Adobe I/O Forums on Adobe Experience League.