Adobe I/O Events Frequently Asked Questions (FAQ)

General Questions

Which events are currently supported by Adobe I/O Events?

Adobe I/O Events regularly adds new event providers. As of now, the following Adobe solutions are supported:

What is the guarantee of events delivery?

Adobe I/O Events provides durable delivery. Each event is delivered at least once for each registration. If your webhook endpoint does not acknowledge receipt of the event delivery, Adobe I/O Events retries delivery. See the Webhook FAQ for more details.

Important notes:

Do you guarantee the order of events delivery?

No. Event order is not guaranteed. See the previous answer for details.

What permissions are required to use Adobe I/O Events?

Permissions and entitlements depend on the event provider:

For licensing questions, contact your Adobe account manager.

Which subscription types does Adobe I/O Events support?

Adobe I/O Events supports the following subscription types:

What should I do if I am unable to delete a project because of a conflicting provider?

If you see an error when deleting a project in the Developer Console, it may be due to an event provider associated with the same workspace. You must delete the event provider before deleting the project.

Steps to resolve:

  1. In the Developer Console, select "Project overview" from the left menu.

  2. Click "Download" in the top menu to download the project metadata JSON file.

  3. Open the JSON file and note:

    • Consumer organization ID (project.org.id)
    • Project ID (project.id)
    • Workspace ID (project.workspace.id)

  4. Use the Provider API documentation to fetch your I/O Events providers for the organization id.

  5. Find the provider with the matching workspace id. Note the provider id.

  6. Delete the provider using the Provider API and the ids from above.

  7. Repeat for all conflicting providers, then try deleting the project again.

Error while deleting a project

Why do I see duplicate fields for recipient client ID and event ID in the delivered payload?

Adobe I/O Events delivers payloads with both the new and deprecated attribute names for recipient client ID and event Id to ensure compatibility during the transition to stricter CloudEvents specification compliance.

You may see all four fields in your event payload:

Why are there duplicate fields?

Action required:

Subscriber Defined Filtering (SDF) FAQ

What is Subscriber Defined Filtering?

Subscriber Defined Filtering (SDF) allows you to define custom JSON-based filters for your event registrations, so you only receive events that match your criteria. See the SDF documentation for details.

What operators are supported in SDF filters?

SDF supports a subset of the Event Ruler DSL operators: equals, anything-but, prefix, suffix, numeric, exists, equals-ignore-case, cidr, and $or. See the Supported Operators for examples and syntax.

How do I validate my filter?

You can use the filter validation endpoint to check your filter before saving it. This will catch syntax errors and help you test your logic with sample events. See Validating Filters.

What are common reasons my filter does not work / is not valid?

Are wildcards supported in SDF filters?

No, wildcard patterns are not supported in SDF filters. Use prefix or suffix for pattern matching. See Restrictions.

Can I use multiple filters per registration?

No, currently only one filter is allowed per registration. See Restrictions.

Which registrations are compatible with Subscriber Defined Filtering?

To use SDF, your registration must only include Cloud Events deliveries. Registrations that have AWS EventBridge configured as a delivery method are not compatible with SDF. For more details, see the SDF documentation.

Are filtered events available in the journal?

No, when you apply subscriber defined filters to a registration, events that don't match your filter criteria are completely filtered out and will not be available in any delivery method, including the journal. The filtering happens on Adobe's servers before events are delivered to any destination. It is therefore utterly important to check the validity of your filter before applying it in production. Although I/O Events doesn't accept filters that are syntactically incorrect, you should use the validation API to check for correct semantic of your filter against custom sample events.

Can I have different filters for different delivery methods?

No, subscriber defined filters are applied at the registration level and affect all delivery methods (webhooks, journal, etc.) equally. If you need different filtering logic for different delivery methods, you would need to create separate registrations.

What happens if I delete all filters from a registration?

When you remove all subscriber filters from a registration, it will receive all events for the registered event types without any filtering applied. Make sure your application can handle the increased load before applying the change.

Why does my Exists filter not work on nested objects?

The Exists operator only works on leaf nodes (final field values) and does not work on intermediate nodes (nested objects or arrays). For example, you can check if a field like data.user.email exists, but you cannot check if data.user (an object) exists.

Example Cloud Event:

{
  "specversion": "1.0",
  "id": "123e4567-e89b-12d3-a456-426614174000",
  "source": "/example/source",
  "type": "examplelogin",
  "time": "2023-01-01T12:00:00Z",
  "data": {
    "user": {
      "id": "user123",
      "email": "user@example.com",
      "profile": {
        "name": "Test User",
        "age": 30
      }
    },
    "action": "login"
  }
}

Valid Exists filters (leaf nodes):

Invalid Exists filters (intermediate nodes):

Webhook FAQ

What happens if my webhook is down? Why is my event registration marked as Unstable?

If your webhook is down, Adobe I/O Events retries delivery (see details below). Your event registration may be marked as Unstable.

If Adobe I/O Events fails to receive a successful response code from your webhook within the configured timeout window, it retries the request, including a special header x-adobe-retry-count. This header indicates how many times the delivery of an event or a batch of events has been attempted.

Note: The timeout spans the entire delivery attempt, including the overhead of setting up the HTTP connection. This means that if your webhook handler responds in exactly 10 seconds (or 60 seconds for Runtime Actions), the delivery will still fail due to the additional overhead of setting up the connection.

data-variant=info

data-slots=text
Please note that if an event delivery fails with a response status code of 429 Too Many Requests, or with any response status code in the range of 500 to 599 except for 505 HTTP Version Not Supported, then those events are retried. Events that fail with any other response status codes are not retried.

Adobe I/O Events will keep on retrying delivery to your webhook for 24 hours using exponential and fixed backoff strategies. The first retry is attempted after 1 minute and the period between retries doubles after each attempt, but is at most 15 minutes (see below table outlining the retry pattern).

Table
Retry Attempt 1 2 3 4 5 6 7 ...
Retry After Interval 1m 2m 4m 8m 15m 15m 15m ...

Please note that above retry intervals are not guaranteed and may vary in few exception scenarios.

Adobe I/O Events changes the state of an event registration based on the below criteria:

For an Unstable event registration Adobe I/O Events still keeps on attempting delivery. This gives you sufficient time to restore your webhook, and avoid it from getting marked as Disabled. Once restored, it will be marked as Active on the next successful event delivery.

If all retry attempts get exhausted and the event still isn't delivered (webhook not responding or responding with a non 2XX response) or the registration is still in Unstable state, Adobe I/O Events drops the events, marks the event registration as Disabled, and stops sending any further events.

An email notification is sent to the admins of the organization when a webhook endpoint is marked as Unstable or Disabled.

Here you can see a sample email notification sent when a registration is marked as Unstable: Unstable Event Registration Email Notification

A similar email notification is sent when a registration is marked as Disabled.

You can use the Journaling API to retrieve events published while your webhook was down. Once your webhook is restored, you can re-enable your event registration (see next question).

How can I re-enable my event registration after downtime? How can I retrieve missed events?

  1. Fix the issue preventing your webhook from responding.
  2. Log in to the Adobe Developer Console.
  3. Edit your event registration. This triggers a webhook challenge request and re-activates your registration.

While your registration is disabled, Adobe logs events in your Journal. You can retrieve all events for the past 7 days using the Journaling API documentation.

How can I read the delivery retry count (and other request headers) in my runtime action configured as a webhook?

The (subset of) request headers pertaining to the event delivery can be read from the __adobe_headers action param:

const { errorResponse } = require('../utils');

function main(params) {
    const headers = params['__adobe_headers'];
    const retryCountValue = headers['x-adobe-retry-count'];
    // The x-adobe-retry-count header is not always present (it's missing on the very first delivery attempt)
    // Only if the first delivery attempt fails, the subsequent requests will have this header present
    if (retryCountValue !== undefined) {
        // All header values are strings
        const retryCount = Number(retryCountValue);
        if (retryCount >= 3) {
            // Exceeded 3 retry attempts, signal to no longer retry processing this event
            return errorResponse(400, 'Exceeded 3 retry attempts')
        }    
    }

    try {
        // Process the event
    } catch (e) {
        // This will trigger a retry attempt
        return errorResponse(500, 'An unexpected error occured');
    }
    
    return {
        statusCode: 200,
        body: 'Event processed successfully'
    };
}

For details on which headers are passed to the user action, see Runtime Webhooks Request Headers.

What happens if my webhook cannot handle a specific event but handles others?

What are non-standard 6xx webhook status codes?

Adobe I/O Events uses custom 6xx status codes to indicate specific issues when no HTTP response is received from your webhook server. See Debug Tracing: 6xx Custom Status Codes for details.

Does every Adobe I/O Events webhook HTTP request include a signature?

Yes. Every request includes a x-adobe-signature header, including the initial challenge GET request. See Security Considerations for more information.

Do Adobe I/O Events notifications come from static IPs?

No. Adobe I/O Events notifications are sent from AWS and Azure, and their IPs change over time.

Security note:

What is the size of notifications in batch delivery style?

When registering a webhook, you can choose the delivery style:

How can I debug and see logs for successful invocations to my runtime action (configured as webhook)?

To debug successful invocations, relay the activation_id of your target user action as a response header (e.g., x-target-action-activation-id). This allows you to trace activations in the Developer Console without enabling the x-ow-extra-logging=on header (which also impacts Runtime performance).

Journaling FAQ

How far back are I/O Events available via the Journaling API?

Adobe I/O stores 7 days of subscribed events, retrievable via the Journaling API.

Why do I only get one event, regardless of the limit I use?

The Journaling API limit parameter sets the maximum number of events returned. You may receive fewer events than the limit, depending on the incoming traffic. This is expected. For example, you may only see a single event in a journal batch/page even when the journal holds more than 1 event. See the Journaling API documentation for details.

Can I retrieve all events in one request?

No. The Journaling API does not support retrieving all events in a single query. Use the since parameter and follow the journal's rel=next Link to fetch events incrementally.

Can I start fetching events from a specific point in time?

Yes. Use the seek parameter with the Journaling API to start from a specific point in time, using an ISO 8601 duration (e.g., -PT2H for 2 hours ago, -P1D for 1 day ago). This is especially useful for investigating events within a particular time window. See the Journaling API documentation for examples.

Custom Events FAQ

Why is my Custom Events Provider not showing up in the Adobe Developer Console?

If you create a Custom Events Provider using the Provider API, it will only appear in the Adobe Developer Console after you create at least one Event Metadata associated with it.

After associating Event Metadata:

Does Custom Events Provider support high volume? Is there a throttling policy?

Yes, there is a throttling policy. See the Events Publishing API guide for details. For high-volume use cases, contact Adobe to discuss your needs.